Jeff Floyd on Management

Clearly, the HRM systems of an organization must complement the other departments/systems in the organization. Picture a wagon with a rope on each corner. Now picture four kids pulling on those ropes in four different directions. The wagon may move, but it will move slowly and most likely in the direction of the biggest kid. If all the kids were pulling in roughly the same direction, the wagon move a lot faster and with less effort expended.  Similarly, each department of a well designed and functional organization contributes to the success of the overall organization in complementary manner.

Rummler et al. (1995) describes a systems approach to organizational design. The leadership team determines the structure that provides a mechanism for the company to take in raw material and transform it into business value. Part of this process determines the “services” allocated to the human resource department.

Another point from Rummler et al (1995) is the performance monitoring. A key component of systematic organizational design is metrics or the measures to determine its performance or success. The combination of systematic design and performance measures is the primary reason that Rummler’s work influenced this discussion posting. Monitoring the metrics and the controls allow the leadership team to gauge past performance and possibly predict future performance.

Key goals in the design of the human resource department include:

• Establish key systems and metrics to manage employee benefits.
• Establish, deploy, and manage key policies covering sexual harassment, workplace safety, termination, etc.
• Establish internal relationships with each hiring manager to document job descriptions for every job function in the company.
• Establish external relationships with key recruiters and industry professionals to identify star performers in the local area and industry.
• Establish a talent management system that locates, attracts, and retains key talent. (Gregorie 2006) The system includes tuition reimbursement, compensation, and incentive pay, etc.
• Establish linkage between talent management and business model. (Bowen et al. 1991)
• Exit interviewing and lessons learned
• Maintain Ethics Standards

The human resource department is not an island in the company; it along with the other departments must function in unison working toward the same company goals. The human resource department has a contribution to keep talent in the company. However, the marketing, engineering, accounting, legal, and other departments must all play a part in attracting and keeping talent.

References

Bowen, D., Ledford, G., & Nathan, B. (1991, November). Hiring for the organization, not the job. Academy of Management Executive, 5(4), 35–51.

Gregoire, M. (2006). Consistently acquiring and retaining top talent. Workforce Management, 85(19), s6

Rummler, G. Brache, A. (1995) Improving performance: how to manage the white space on the organization chart. San Francisco, CA: Jossey-Bass Inc.

Version 98 and up

• Use a Work Breakdown Structure (WBS) to add structure and logic to the task list.
• DO NOT assign a resource or time to a summary task
• Do Not use summary tasks as a dependency (Unless it is to be removed later)
• Do not assign a dependency to a summary task (Unless it is to be removed later)
• Assign resources to tasks before adding hours
• Assign only one resource to any task
• If a task has more than one resource it may need to be broken down further
• Use Verb Noun format for task names
• Make each task name complete and able to stand alone. (If the task is pasted into an email, it will be known what the deliverable is with out the context of the WBS structure.)
• No task over 40 hours in length. If longer break it down.
• Do Not use dependencies to level resources.
• Use priorities, leveling and manually moving tasks.
• Set leveling options to use Priority and task number to level.
• Set leveling options to split tasks
• Dependency field is length limited (in 98)
• If task A and B have a Finish-to-Start relationship, then make sure A will complete before B starts. If work is started on B before A is complete, sometime the schedule will react strangely
• Accounting for less than 100% productivity can be tricky. Before assigning a resource to any task, open the resource sheet and create needed resources. Set the max units for the resources that will have less than 100% productivity. When you assign the resource to a task that productivity number will be used and show up as a percentage to the right of the resource name in the list.
• Future Lessons
• Find a way to deal with
• < 100% efficiency Hard to check the network integrity
• Find a way to deal with out of project activities (if not in scope should not be in schedule)

When planning or re-planning a new project keep these handy tips in mind. They will save effort later in the project.

• Do not assign tasks to people outside the team. Make someone on the team responsible for the task.
• Structure the WBS on how progress will be measured (% complete if deliverable for example)
• Introduce new features via Change Requests
  • Defect for bugs,
  • Suggestion for enhancements.
• If a defect CR will be worked on by multiple people, go ahead and break the single line rule and pass the one person per task rule.
• Schedule defects with one line item on the schedule.
• Schedule suggestions with full development life cycle
• Do a component level responsibility matrix
• Do a Deliverable based responsibility matrix
• Add milestones to the schedule for?
  • Code complete
  • Feature freeze
  • Code Freeze
• Add section to executive status summary for scope changes
• Put risks in categories and summarize the risk for reporting
• Consider milestone chart for executive report
• Review designs before implementation.
• Use” use cases” to justify design
• Schedule tracking, status report with re-occurring task not a broken task
• Schedule only one person per task.
• Use priority to help leveling.
• Do not use soft dependencies, it is hard to maintain
• Input feature development and tasks in priority order wrt WBS
• Include debug cycles in schedule.
• It is OK to have unlinked build and test tasks that are re-occurring
• Schedule testing by test case
• Have a separate schedule for marketing requirements development managed by marketing. (Hold them to their schedules. They will hold you to yours.)
• Hold re-planning session for major scope changes
• Print schedule at least every other week and post for all to see.
• Find a way to do risk management
• Update schedule daily

Reporting the status of your project is the single most important way to keep your stakeholders informed on the progress, direction, and health of your project. What follows are lessons on reporting different aspects of your project.

Software Test Status / Defect Reporting
A good way to monitor and report  test progress is to track

• the number of test cases started as a percentage of the complete set
• track the number of new test cases started each week
• the number that fail

From this you can predict the number of weeks you have left to complete the first pass of functional testing.

Graphs are much more effective in communicating defect status compared to tables with the same information. The graphs can contain more historical information and are easier to defend.

Use one graph with cumulative defects found and cumulative defects resolved. Use another graph for number of defects entered, resolved, verified, and closed per period (usually per month).

Design the defect tracking process to separate defects on a per release basis. It does not matter when the defect was fixed (in terms of the release) just that is was fixed.