Planning Project Human Resource Management

Hanford project workersThe PMBOK describes “Plan Human Resource Management” as the process of identifying and documenting project roles and responsibilities, determining the skills required to perform in those roles, defining the reporting relations of the people on the project, and creating a staffing management plan. As you might expect, two of the primary inputs to this process are the project management plan and the activity resource requirements. This makes sense, in that you need a good idea of what work needs to be done before you can do that other stuff. But most projects operate under constraints, which the PMBOK refers to simply as “enterprise environmental factors.” These constraints can add complexity to your human resource management plan, and may affect cost and schedule.

Availability of Resources

Some of the people with the required skills, knowledge, and authority to work on the tasks described in the project plan have other responsibilities, aside from the project. It is not uncommon for projects to be delayed, because a project resource with production duties is unable to complete a task on time. For example, those who work on year-end financial reporting or tax processing may be largely unavailable for project work in December and January. When you identify a resource, determine if their work schedule may conflict with the project schedule. It might make sense to back-fill the production work with a temporary worker, or make some other arrangement.

Availability of Skills

Some skills required to perform in certain project roles may not be immediately available. You have several alternatives: train a current employee, hire a new employee with the requisite skills, engage a contingent worker for the duration of the relevant tasks, or outsource the work to an external firm. Each of these alternatives has cost implications, and most organizations have policies governing them. Engage the right people in the Human Resources or Purchasing departments, as required, to assist in estimating cost and time required for each alternative.

Remote Locations

Many organizations are global in nature these days, and virtual project teams are not uncommon. While this adds complexity to communication and collaboration, coordination with distant managers also adds complexity to project governance, and possibly introduces certain risks. I know of one project that was delayed because a key team member in another country was downsized, and no one notified anyone on the project team. In another case, a team member was injured in a traffic accident. Ensure that you record contact information for the managers or administrators of your team members in remote locations. Establish communication with the responsible person, and ask them to notify you in the event of an unexpected absence or change in status.

Projects that involve team members from multiple organizations, across multiple locations and time zones, are challenging to plan and execute. In creating your staffing management plan, be sure you understand the constraints that imposed on your access to human resources, consider your alternatives, and anticipate the issues and risks, so you can manage for success.

Tracking Qualitative Risk in Microsoft Project

I use Microsoft Project to schedule the tasks in my work breakdown structure. Then I flesh out the task list with things like external events, define milestones and summary roll-ups, identify dependencies, and assign resources. During execution, I use it to track progress on completion of tasks, in support of everything from communicating and managing team activities to status reporting and change management. I use several different views, flag fields, and filters to highlight the information I want to extract, and then print to a PDF file for distribution. It’s not perfect, but it’s effective.

One of the challenges in project management is preventing the gradual disconnect between the project schedule and risk management. When we’re in execution mode, we tend to focus on the list of tasks and the dates in the plan, and only occasionally on the results of that qualitative risk analysis we prepared in the planning stage. In order to see the gradual reduction in total project risk, I wanted a way to incorporate risk attributes into tasks on the schedule. I also wanted to factor in the work we’ve already accomplished, in order to see how much residual risk remains when a risk has been retired. I implemented this in Microsoft Project, using calculated fields.

Qualitative Risk DemoIn the simple example above, we have decided to track execution risks on three project tasks. Our qualitative analysis classified the probability of occurrence and the impact as Low, Medium, or High, scored 1, 2 and 3 respectively. In all three cases, the risks will be retired gradually, as the tasks are completed. We want to monitor this process of risk reduction graphically, using the formula Probability * Impact * Work Remaining to Retire the Risk, defined as 1 – (% Complete / 100). In this example, a score greater than 3.0 is considered high risk (red); as the score falls below the threshold, the visible risk indicator changes to yellow, and when the task is completed and the score drops to zero, the indicator changes to green.

Custom Fields - ProbabilityI implemented the Probability and Impact fields using Lookup values in number fields, and implemented the Risk field using a formula, with appropriate graphical indicators. At a glance, you can see that task 4, Data Conversion Mapping, was determined to have a performance risk with high probability and low impact; now that the task is 100% complete, it has been retired. Task 7, Code and Unit Test, was determined to be medium probability, medium impact. At the current 20% Complete, it shows as a high risk [2*2*(1-0.2)=3.2], but once it gets to 25% complete, it will drop to a medium risk [2*2*(1-0.25)=3.0]. Task 14 reflects low probability, high impact, and medium risk. As each task is worked, the associated risk is reduced in linear fashion. If you wanted to use a quadratic calculation, you could adjust the formula accordingly. To adjust the High risk threshold, change the value associated with the graphical indicator.

Edit Lookup Table - ProbabilityThe Lookup function was used to define four values: None, Low, Medium, and High.  I associated the None value with a blank graphical indicator, and the other values with appropriate graphics.  As a result, only rows with actual Probability and Impact values have indicators.  The Risk value is implemented using a Formula. To see how I’ve previously used a formula to implement a Status field calculation, click here. To download the MS Project 2007 file that was used to prepare this sample, click here.

I’ve previously described the four common risk response strategies: avoid, transfer, mitigate, and accept. In this example, the risks were accepted and they will be retired through execution of the associated task. When a risk is avoided, there should be no need to track it as a task on the project schedule. Depending on the situation, you might want to track performance and retirement of a transferred risk as a task, or you might not. In a mitigation strategy, there might be one or more tasks to track separately from the execution tasks. Consider how you want to tell the story to your sponsor, team members, and stakeholders, as they are the primary consumers of this information.

As long as you associate the Probability and Impact score with a detail task to calculate the risk, it will work correctly. Note that this technique will not work with summary tasks, because MS Project doesn’t calculate percent complete for summary tasks in a way that is usable for calculated fields. If you have any questions, comments, or ideas for improving this design, please add a comment below.

Software Extension to the PMBOK Now Available

Software ExtensionThe Software Extension to the PMBOK Guide Fifth Edition is now available. According to the PMI web site, “This standard, developed by PMI jointly with IEEE Computer Society, provides guidance on the management of software development projects, and bridges the gap between the traditional, predictive approach described in the PMBOK® Guide and iterative approaches such as agile more commonly used in software development.”

“This groundbreaking work … draws upon the wisdom of programmers, IT professionals, and working project managers from around the globe. Designed to be used in tandem with the latest edition of the PMBOK® Guide, this comprehensive volume closely follows the PMBOK® Guide’s approach to style, structure, and naming, while providing readers a balanced view of methods, tools, and techniques for managing software projects across the life cycle continuum from highly predictive life cycles to highly adaptive life cycles.”

If you are a current PMI member, you can download a complimentary PDF copy here. Scroll down to the PMI Standards Extensions section and expand the section related to the Software Extension. If you’re not a member, or you just want a paper copy, you can order it here. The price for non-members is $52.95. PMI members get a 20% discount.