Identifying Project Resource Risk

Overview

"If you want a track team to win the high jump, you find one person who can jump seven feet, not several people who can jump six feet."

—FREDERICK TERMAN, Stanford University Dean and Professor of Engineering

Fred Terman is probably best known as the "Father of Silicon Valley.'' He encouraged Bill Hewlett and Dave Packard, the Varian brothers, and hundreds of others to start businesses near Stanford University. Starting in the 1930s, alarmed at the paucity of job opportunities in the area, he helped his students start companies, set up the Stanford Industrial Park, and generally was responsible for the establishment of the world's largest high-tech center. He was very good at identifying and nurturing technical talent, and he understood how critical it is in any undertaking.

A lack of technical skills or access to appropriate staff is a large source of project risk for complex, technical projects. Risk management on these projects requires careful assessment of needed skills and commitment of capable staff.

Much of the content of this chapter falls into the "Project Human Resource Management,'' "Project Procurement Management,'' and "Project Cost Management'' segments of the PMBOK Guide. In particular, the principal project resource risk ideas covered in this chapter include:

Sources of Resource Risk

Resource risks represent less than one-third of the records in the PERIL database. There are three categories of resource risk: people, outsourcing, and money. People risks arise within the project team. Outsourcing risks result from the use of people and services outside the project team to perform critical project work. The third category, money, is something of an anomaly in the data, as very few of the problems reported were primarily about funding. Money is, however, a key factor in many of the people and outsourcing problems, and the effect of insufficient funding on projects has substantial impact on a project in many other ways. The summary shows:

RESOURCE RISKS

COUNT

CUMULATIVE IMPACT (WEEKS)

AVERAGE IMPACT (WEEKS)

People

45

194

4.3

Outsourcing

17

109

6.9

Money

2

58

29.0

The root causes of people and outsourcing risk are further characterized by type, and a Pareto chart of overall impact by type of risk is summarized in Figure 5-1. Although risks related to internal staffing dominate the resource risk data, the single most damaging factor is delay associated with outsourced work.

Figure 5-1: Resource risks in the PERIL database.

People Risks

Risks related to people represent the most numerous resource risks, accounting for more than two-thirds of the incidents. Availability of people was the primary issue, with four subcategories:

There were a few risks associated with conflict among staff members and some related to motivation.

Losing people midproject, permanently or temporarily, was the most common people risk, with permanent loss leading to an average slip of more than five weeks and temporary loss causing a typical slip of just over two weeks. The reasons for permanent staff loss included resignations, reassignments to other work or different projects, and staffing cutbacks. Discovering these risks in advance is difficult, but good record-keeping and trend analysis are useful in setting realistic project expectations. The total impact due to permanent staff loss dominated the people risks. Although its overall impact was lower, temporary loss of project staff was the most common people-related risk. The most frequently reported reason for short-term staff loss was a customer problem (a "hot site'') related to the deliverable from an earlier project. Other reasons for short-term staff loss included illness, earthquakes, travel nightmares, and organizational reorganization.

There were also a number of projects that missed the deadline at the end because required staff was not available at the beginning. There were a number of root causes for staff joining the project late, but the most common was a situation described by one project leader as the "rolling sledgehammer.'' Whenever a prior project is late, some, perhaps even all, of the staff for the new project is still busy working to complete it. As a consequence, the next project gets a ragged start, with key people beginning their contributions to the new project only after they break free of the older one. Even when these people do become available, there can be additional delay. Staff members coming from a late project are often exhausted from the bulge of work and long hours typical of a project that runs beyond its deadline. The "rolling sledgehammer'' creates a cycle that self-perpetuates and is very difficult to break. Each late project causes the projects that follow to be late.

Other reasons that can delay engagement of project staff include scarcity of certain skills, which is the root cause of the fourth risk related to people availability: queuing. Specialized expertise is often expensive, and it is common for businesses to minimize the cost of these skills by investing as little as possible. Most technical projects rely on at least some special expertise that they share with other projects, such as system architects needed at the start, testing personnel needed at the end, and other specialists needed throughout the project. If an expert happens to be free when a project is ready for him or her to start work, there is no problem. If the expert has activities for five other projects queued up already when your project activity needs attention, your activity will enter the queue, and any following work will slip while the queued activity waits. Queuing analysis is well understood, and it is used to optimize manufacturing, engineering, system design, computer networks, and many other business systems. Any system subject to queues requires some excess capacity to maximize throughput. Optimizing project resources based only on cost drives out any spare capacity and causes project delay.

Thorough planning and credible scheduling of the work well in advance will reveal some of the most serious potential exposures regarding people. Histogram analysis of resource requirements may also provide insight into staffing exposures a project will face, but, unless analysis of project resources is credibly integrated with comprehensive resource data for other projects and all the nonproject demands within the business, the results will not be very useful. Aligning staffing capacity with project requirements requires ongoing attention. One significant root cause for understaffed projects is a failure to use project planning information to make or revise project selection decisions at the organization level, triggering the "too many projects'' problem. Retrospective analysis of projects over time is also a powerful way to detect and measure the consequences of inadequate staffing, especially when the problems are chronic.

Other people-related risks in the PERIL database involved conflict, where two simultaneous projects had essentially the same objective and each interfered with the progress of the other. Low motivation also contributed to delay on several long projects. Falling morale is one risk (among many) for lengthy projects.

Outsourcing Risks

Outsourcing accounts for more than a quarter of the resource risks. Though the frequency of this risk in the PERIL database is lower than that for people risks, the impact of outsourcing risk was nearly six and a half weeks, well above the database average. The risks related to outsourcing are similar to the people risks: delays, late starts, and turnover.

Delays, such as when a supplier fails to complete assigned work on schedule, are the most common outsourcing risk and represent the largest total impact for the projects in the PERIL database. Delays result from queuing problems and other people availability issues, but often a precise cause is not known. Outsourced work is generally done somewhere else, so the project team may not be able to observe it and assess the cause of problems. Compounding the impact of late delivery is the added element of surprise; the problem may be invisible until the day of the default, when it is too late to do much about it. Lateness of the deliverable was exacerbated in several examples in the PERIL database by work that did not meet stated specifications and caused even more delay.

Late starts are also fairly common with outsourced work. Contracts need to be negotiated, approved, and signed, all processes that can be very time-consuming. Beginning a new, complex relationship with outside people you have never worked with before can require more time than is expected. For projects with particularly unusual needs, just locating an appropriate supplier may cause significant delays.

The third risk, turnover, can also lead to project delay because of the ongoing need to redo training, conduct additional project plan and specification reviews, and rebuild working relationships.

Outsourcing risks are detected through planning processes and through careful analysis and thorough understanding of all the terms of the contract. Both the project team and the outsourcing partner must understand the terms and conditions of the contract, especially the scope of work and the business relationship.

Money Risks

The third category, money, is not very common in the PERIL database. The two data points include the single largest delay in the database (for a project that was subject to such severe funding cutbacks that it was nearly a year late), so the average for this subcategory, twenty-nine weeks, is skewed. As with any other resource needed by a project, however, if there are limits on money that create bottlenecks, the result will be impeded progress and project delay.

Resource Planning

Resource planning is a useful tool for anticipating many of the people, outsourcing, and money risks. Inputs to the resource planning process include the project work breakdown structure (WBS), scope definition, activity descriptions, preliminary duration estimates, and the project schedule. Resource requirements planning can be done in a number of ways, using manual methods, histogram analysis, or computer tools.

Resource Requirements

On the basis of the preliminary schedule and assumptions about each project activity, you will need to determine the skills and staffing required for each activity. It is increasingly common, even for relatively small projects, to load this data into a computer scheduling tool. As early as possible, identify staffing for each activity using the names of each individual. While preliminary resource planning can be done with functions or roles, resource analysis based on names makes it more likely that estimates will be accurate and that staffing will be committed to the project as planned. Identify as a risk any required project staff members who cannot be named during project planning.

For the project as a whole, also identify all holidays, scheduled time off, significant nonproject meetings, and other time that will not be available to the project. Do this for each person, as well, and identify any scheduling differences for different regions, countries, and companies involved in the project. A computer scheduling tool is a good place to store calendar information, such as holidays, vacations, and any other important dates. If you do use a computer tool, enter all the calendar data into the database before you begin resource analysis.

You also need to determine the amount of effort available from each contributor. Even for "full-time'' contributors, it is difficult to get more than five to six hours of project activity work per day, and "part-time'' staff will contribute much less.

Particularly for project activities that are already identified as potential risks, such as those on the critical path, you need to determine and verify the total effort required and ascertain who will be involved with each activity. There are a number of effective approaches for doing this.

Manual Methods

For smaller projects, resource analysis need not be overly complex. The primary objective of resource analysis is to identify portions of the project where the resources available do not support the project work planned. It may be easy to inspect the project timeline to see where the hours needed from an individual on a week-by-week basis exceed what will be available. Even on more complex projects, inspecting the overall plan is a quick way to identify resource problems such as obvious resource shortfalls or significant project milestones that align with holidays or other conflicts.

Tabular Analysis using Computer Tools

While inspections of the plan and manual resource analysis provide a good starting point, computer tools offer some benefits for more detailed analysis. They facilitate tabular resource reporting, and they may be used to easily identify resource overcommitments and undercommitments. Computer tools also help in managing important calendar information. In addition to this, computer-based project management software also is an effective tool for "what if?'' analysis and can make project tracking and collection of metrics much easier. There are dozens of applications to choose from: Microsoft Project, CA SuperProject, Autoplan, Project Scheduler, Primavera, and Project Workbench are just a few. It is even possible to use computer spreadsheet applications to perform project resource analysis.

Whatever tool you choose, planning data may be used to do tabular analysis for individuals, as well as for entire projects. Scheduling tools also permit the resource plan to be updated easily following schedule or other project changes. Keep in mind, however, that a scheduling tool is primarily a database with specialized output reporting capability. The quality of the information the tool provides will never be any better than the quality of the data that you put in. You and the project team must still do the thinking; a computer tool cannot plan your project or identify its risks.

Histogram Analysis using Computer Tools

For more complicated projects, graphical resource analysis is also useful. Loading each person's effort allocation into a computer scheduling tool allows aggregate workload analysis in several formats, in addition to tabular reports. Resource histograms show graphically where the staffing of the project is inadequate on an individual-by-individual or an overall project basis. The graphical format provides a visible way to identify places in the preliminary schedule where project staffing and the logical sequencing of the work are in conflict, as shown in the example in Figure 5-2. In this case, the effort profile for a project team member who is expected to contribute to all these activities demonstrates that, when the activities overlap, he or she would need to work a double shift.

Figure 5-2: Histogram analysis for an individual.

The benefits of entering resource data into a computer scheduling tool include:

These benefits require some investment on your part. Histogram analysis adds complexity to the planning process, and it increases the effort for both planning and tracking. In your resource analysis, allocate sufficient effort for this into your overall project workload.

Histograms for the overall project display the effort profile of the entire project as forecast by the project plan. Different sorts of projects have different sorts of profiles, such as front-loaded, back-loaded, bimodal, flat, and the Rayleigh curve, shown in Figure 5-3.

Figure 5-3: Typical effort loading on projects.

Aggregated effort curves for projects may take any possible shape. The resource profile in Figure 5-3 is fairly common for projects of many types, but measurement and planning may reveal that the effort profiles for projects common to your environment are quite different. One useful technique for a quick plan review is to compare the effort profile from your plan with a profile created using historical project data. Most significant deviations between the two profiles are probably a result of omissions or errors in your plan.

Whatever the shape of the work profile, there is generally a lag between the formal start of a project and the beginning of substantial effort, as in Figure 5-3. As a new project begins, effort consumed builds gradually, not necessarily due to lack of staff (although the PERIL database shows that this is a factor), but because at the start of most projects no one knows exactly what to do. Until planning has begun and the identification and delegation of work is under way, there are few defined activities to work on. This generates two opportunities that relate directly to resource risk: people development and infrastructure upgrades.

Even in the opening days of a new project, a few requirements for training will likely emerge. Even a quick assessment of the project scope will probably reveal new skills and knowledge gaps in the organization, and the early days of a project are an excellent time to address these needs. Waiting until the moment in the project when these new capabilities are required increases two risks: that the time or money required for training may be unavailable and that the "ramp time'' to competence may exceed what you planned. Investment in people development early in a project can also be a powerful motivator and team builder—both of which can reduce risk for any project.

The second opportunity in the early part of a project starts with a quick assessment of your project infrastructure: the equipment, software, and any other project assets. If required computers, software applications, test gear, instruments, communications and networking equipment, or other hardware available are not up to date, replacement or upgrade might greatly improve the efficiency and speed of your project. The effort and money to do this tends to be easiest to obtain during the planning and start-up of a new project. Getting familiar with new hardware and software is less disruptive early on than it will be in midproject, and the effort needed to install and check the new systems is not as likely to delay high-priority project activities (since many of these are not yet identified).

One of the best reasons to jump on these opportunities at the outset is that project budgets tend to be set early, and, unless these needs are identified right away and integrated into the project finances, it may prove impossible to get approval for them at all. Of course, getting such requests approved early on is not a sure thing, but the odds are better, and it never hurts to ask. Even if you fail to get approval, your written proposal coupled with any project problems related to older equipment will make similar requests on subsequent projects more successful.

The most significant project exposures that an overall project resource histogram, spreadsheet table, or other assessment will reveal are the portions of the project timeline where the human resources required by the preliminary plan exceed what is expected to be available. Unless these issues are resolved through additional staff acquisition or procurement of outside services (discussed later in this chapter), replanning (discussed in Chapter 6), or by some other means, the risk to the project is high. Project risks due to insufficient staffing are most significant near the scheduled project completion, as the likelihood of deadline slippage grows and the options for response dwindle.

Another source of project resource risk is the assumption that resources will scale with other project factors. Increases in project duration, the number and complexity of the deliverables, and the number of contributors (or locations) involved will all increase required project effort more than a simple linear extrapolation would predict. Due to communication, overhead, and many other factors, the effort required by a "larger'' project expands geometrically.

An example of this is seen in two otherwise similar projects undertaken recently in Europe. These were staffed differently as an experiment. One project team was at a single site. The other project team was distributed among half a dozen locations, though all still within the same time zone. The assessment of effort following project completion was striking; the distributed team spent about 60 percent more effort getting its work completed, compared with the co-located team. Differences in project factors as low as 20 percent (for example, in team size) start to reveal the nonlinear expansion of required effort. As project factors that complicate the work grow, reflect this appropriately in your effort estimates. Whenever resource analysis indicates requirements that exceed what typical, successful projects have used in the past, record it as a project risk.

Staff Acquisition

Histograms and other project analysis are necessary, but rarely sufficient, to determine whether the project has the staffing and skills required to do the work. Particularly for the riskiest project activities, revalidate both the skills needed and your effort estimates.

Skill Requirements

Through project scope definition and preliminary planning, you can identify specific skills and other needs required by your project. Your initial project staffing will often include adequate coverage for some or even most of these, but on many projects there are substantial gaps. These gaps are project resource risks until they are resolved.

Specific skills that are not available on the project team may be acquired by negotiating for additional staff or through training or mentoring. In some cases, needed skills may be added though outsourcing. These options are most possible when the need is made known early and supported with credible planning data. You may also be able to replan the parts of the project that require unavailable skills to use methods that require only the skills that you already have on the project team.

The goal of staff acquisition is to align the work required for each project activity with specific individuals who can and will get it done. The names of all these people are listed on a roster, or team directory, along with each person's assigned role, contact information, and other relevant data.

Two significant resource risks related to staff acquisition are unknown staff members and contributors with unique skills. Having your project roster remain incomplete late in the planning process is risky. Every identified staffing need that is still blank, identified only with a function, or marked "to-be-hired'' is a risk. Even if these people are later named, their productivity may not be consistent with the estimates and assumptions in your project plan. It is also possible that the names will still be missing even after work is scheduled to begin—and some assignments may never be made. The quality of a plan with unassigned staffing is suspect, and every project staffing requirement that lacks a credible commitment by an actual person is a project risk.

Unique skills pose a problem as well. When project work can be assigned to one of several competent contributors, there is a good chance that it will be done adequately and on schedule. When only a single person knows how to do the work, the project faces risk. There are many reasons why a necessary person may not be available to the project when needed, including illness, resignation, injury, or reassignment to other, higher-priority work. There are no alternatives for the project when this happens; work on a key part of the project will halt. Whenever a key part of your project depends on access to a single specific individual, note it as a risk.

Revisiting Estimates

As noted in Chapter 4, resource planning and activity estimating are interrelated. As the staffing plan for the project comes together, additional resource risks become apparent through review of the assumptions you used for estimating. Project resource risks are usually most severe for activities that are most likely to impact the project schedule—activities that are on the critical path, or have little float, or have worst-case estimates that could put them on the critical path. Reviewing the effort estimates for these and other project activities reveals resource risks related to staff ability, staff availability, and the work environment.

Staff Ability

Individual productivity varies a great deal, so it matters who will be involved with each project activity. Even for very simple tasks, there can be very great differences in performance. Cooks often encounter the requirement for "one onion, chopped.'' The amount of time this task takes depends greatly on the person undertaking it. For a home cook, it might take two or three minutes (assuming that the majority of the chopping is restricted to the onion). A trained professional chef, as watchers of television cooking shows know, dispatches this task in seconds. On the other extreme one finds the perfectionist, who could make an evening out of ensuring that each fragment of onion is identical in size and shape.

Productivity measurements for "knowledge'' work of most kinds show a similar wide spectrum. From research on productivity, people who are among the best at what they do typically work two to three times as fast as the average, and they are more than ten times as productive as the slowest. In addition to being faster, the best performers also make fewer errors and do much less rework.

If a programming activity given to a "world-class'' software engineer takes one day, the same activity given to an "average'' coder will take three days. If the project is unlucky enough to hand the work to one of the least productive programmers, it could take two weeks. Knowing the skills and historical performance of project team members is critical to accurate estimates of effort and duration.

Differences due to variations in productivity are a frequent source of inaccurate project estimates. Project leaders often plan the project using data from their own experience and then delegate the work to others who may not be as skilled or as fast as they are. It is not uncommon on technical projects to select the most talented team member from the last project to take over and lead the next project. Selecting new project leaders this way leads to several potential problems, starting with inappropriately aggressive activity estimates. This tactic also tends to deprive the project of the best technical talent available (or, even worse, to leave the project effectively leaderless because the project leader continues doing technical work). Yet another issue results from taking away responsibilities that a person likes and is good at in exchange for a role that he or she is ill prepared for and may not like. The "accidental'' project manager creates a wide range of project resource and other risks.

When there are historical metrics that draw on a large population, you can accurately predict how fast an average person will be able to accomplish similar work. If your project contributors are significantly more (or less) productive than the average, your effort and duration estimates will be accurate only if they are adjusted accordingly. When you have no specifics on who will be involved in the work, accurate estimates are unlikely and risks are significant.

Staff Availability

No one can ever actually work on project activities "full time.'' Every project contributor has commitments even within the project that are above and beyond the scheduled project work, such as communications. Further, some team members are usually responsible for significant work outside the project. Studying computer and medical electronics firms, Wheelwright and Clark (in Revolutionizing Product Development) reported the effect of assigning work on parallel projects to engineers. For engineers assigned to a single project, roughly 70 percent of the time spent went into project activities. This is equivalent to the often-quoted "five or six'' hours of project work per day and reflects the reality that even someone working on only one project still has other responsibilities, such as meetings, telephone calls, e-mail, and voice mail.

The study reported that, with the addition of a second project, the time spent doing project work rose a little bit, to about 80 percent. The reason for the rise was not included, but it likely relates to queuing effects—an engineer on a single project sometimes will complete an activity before the next assignment is available, but with two projects there is nearly always more work pending. With three and more projects, useful time plummets precipitously. An engineer with three projects uses 60 percent of his or her time on project work, and with four or five the rates fall to 45 percent and 30 percent, respectively.

An engineer working a nominal fifty-hour week on five projects will be available only fifteen hours each week to do project work. The rest of the time will be spent attending five weekly project meetings, communicating with the leaders and others on all five projects, reading five project status reports, and in related activities.

Splitting the fifteen available hours among the five projects gives an average of three hours per project per week (assuming the projects all have equal priority, which they probably do not). At this rate, it will take many weeks to accomplish much. The "too many projects'' problem takes a heavy toll on project progress, and estimates of duration or effort that fail to account for the impact of competing priorities are often absurdly optimistic.

Project Environment

The project environment is yet another factor that has an impact on the quality of project estimates. Noise, interruptions, the workspace, and other factors may erode productivity significantly.

When people can work undistracted, a lot gets done. Realistically, frequent disturbances are commonplace for technical projects, particularly those done in an "open office'' environment. The background noise level, nearby conversations, colleagues who drop by to chat, loudspeaker announcements, and other interruptions may be much more disruptive than assumed in project estimates. People cannot shift from one activity to a different one instantaneously. Studies of knowledge workers indicate that it takes twenty minutes, typically, for the human brain to come back to full concentration following an interruption as short as a few seconds. A programmer who gets three telephone calls, even wrong numbers, or "quick questions'' from a peer each hour cannot accomplish much. Validate your productivity assumptions periodically with measurements, especially for work that must be done in chaotic conditions. Reflect the effects of "context shifting'' in your estimates, and note the risks associated with work subject to frequent interruptions.

Other aspects of the working environment that affect productivity include the size of the workspace, access to services such as printing and copying, the ergonomics and comfort of office furniture, and access to quiet places to get away from telephones for project discussions. While managing risks associated with these factors may be beyond your control as a project leader, you can at least assess the impact, note the risks, and make necessary adjustments to your estimates. The trend in recent years has been toward modular office furniture, which is more compact than traditional desks, credenzas, file cabinets, and bookcases. The primary motivation behind this is to get more people into less space, minimizing office costs. It does not necessarily make workers more productive. While a more compact office can reduce reaching and walking around, which can improve efficiency, the amount of workspace available to spread out books, documents, plans, drawings, and other materials can be significantly less than optimal. The reduction in filing space using modular setups also often results in large piles of paper (which technical people are always reluctant to discard and has to go somewhere), which further cuts down on working space. Without adequate flat, clear space, project activities are more frustrating and require more time and effort. Modular furniture also results in closer neighbors, so the noise and interruptions also increase. All of these factors affect productivity and impact the accuracy of your project estimates.

Adequate lighting and access to adequate tools and other resources are also critical in establishing a realistic basis for aggressive duration estimates. During the power shortage in California throughout much of 2001, many companies cut out some (and, in selected cases, all) of the office lighting to save power and money. Working in a dark office is not conducive to productivity. Replacing printers and copiers with cheaper equipment may seem to save money, but if they are usually out of service and people have to hunt down equipment that works, the change will impede project progress significantly.

Whenever these or other environmental factors seem likely to cause project problems, note them as risks, adjust project plans to reflect the environment, and, whenever it is practical, propose improvements and work toward resolution of problems to minimize the impact of future projects.

Distance is another factor that can invalidate estimating assumptions. New teams go through the "phases'' of team development—forming, storming, norming, and performing. Many project teams never get out of the "storming'' phase, especially if they are a distributed or "virtual'' team where none of the people have ever met each other. People tend to like and trust other people that they have met face-to-face, and they generally mistrust strangers. On a complex project, team members need to trust and depend on one another, and, until there is a basis for this relationship, they don't. Every question someone asks is a challenge. Every project issue is presumed to be "those people over there, out to get us again,'' instead of a legitimate technical problem. When teamwork is weak or lacking, a great deal of time may be lost to miscommunication, confusion, fighting, and disagreement. Without adequate mutual trust, even conservative project estimates may prove to be too optimistic.

A final source of resource risk relates to project team members who are responsible for other work outside your project. The quality of the estimates and plans for work delegated to "multiproject'' resources depends on how these individuals perceive the priorities of their activities. To assess this, ask each part-time contributor about both the importance and the urgency of the work he or she is responsible for on your project. Whenever contributors see the priority of your project's work as low, it is a risk. You may be able to minimize the risks through effective communication, involving and motivating the people, escalating the discussion to their management, or otherwise raising the priority of your project work. In some cases, you may need to consider alternative resources or other methods to do the project work.

Once the staffing for your project is set, consider all these factors, particularly the talent, the proportion of time dedicated to your project, and the effect of the environment on the estimates in your project plan, and make adjustments as necessary. Also, as you consider these factors, identify the resource risks that emerge, and add them to the project risk list.

Procurement Planning and Source Selection

Outsourcing risk is not only a significant source of resource risk in the PERIL database; it also caused an average project slip of nearly seven weeks, well above the database average. Better management of outsourcing and procurement can uncover many of these problems in advance.

Not all project staffing needs can be met with internal people. More and more work on technical projects is done using outside services. It is increasingly difficult (not to mention expensive) to maintain competence in all the fields of expertise that might be required, especially for skills needed only infrequently. A growing need for specialization underlies the trend toward increased dependence on project contributors outside the organization. Other reasons for this trend are attempts to lower costs and a desire in many organizations to reduce the amount of permanent staff. In the PMBOK Guide, Project Procurement Management has six components:

The first four of these provide significant opportunities for risk identification.

Procurement Planning

Outsourcing project work is most successful when the appropriate details and specifics are thoroughly incorporated into all the legal and other documentation used. Outsourced work must be specified in detail both in the initial request and in the contract so that both parties have a clear definition for the work required and how it will be evaluated. The planning required to do this effectively is difficult, and it takes more effort and specificity than might otherwise be applied to project planning.

Specific risks permeate all aspects of the procurement process, starting even before any work directly related to outsourcing formally starts. The process generally begins with identification of any requirements that the project expects to have difficulty meeting with the existing staff. Procurement planning involves investigation of possible options and requires a "make-or-buy'' analysis to determine whether there are any reasons that using outside services may be undesirable or inappropriate. From the perspective of project risk, delegating work to dedicated staff whenever possible is almost always preferable. Communication, visibility, continuity, motivation, and project control are all easier and better for nonoutsourced work. Other reasons to avoid outsourcing may include higher costs, potential loss of confidential information, an ongoing significant need to maintain core skills (on future projects or for required support), and lack of confidence in the available service providers. Some outsourcing decisions are made because all the current staff is busy and there is no one available to do needed project work. These decisions seem to be based on the erroneous assumption that project outsourcing can be done successfully with no effort. Ignoring the substantial and very real effort required to find, evaluate, negotiate and contract with, routinely communicate with, monitor, and pay a supplier is quite a serious risk.

While it may be desirable to avoid outsourcing, project realities may require it. Whenever the "make versus buy'' decision comes out "buy,'' there are significant risks to manage.

Solicitation Planning

The next step in the outsourcing process is to develop a Request for Proposal (RFP). There are other names for this document, such as Request for Bid, Invitation to Bid, and Request for Quotation; they all serve a similar purpose. In organizations that outsource project work on a regular basis, there are usually standard forms and procedures to be used for this, so the steps in assembling, distributing, and later analyzing the RFP responses are generally not up to the project team. This is fortunate, because using well-established processes, preprinted forms, and professionals in your organization who do this work regularly are all essential to minimizing risk. If you lack templates and processes for this, consult colleagues who are experienced with outsourcing, and borrow theirs, customizing as necessary. Outsourcing is one aspect of project management where figuring things out as you proceed will waste a lot of time and money and result in very significant project risk.

Risk management also requires that at least one member of the project team be involved with planning and contracting for outside services so that the interests of the project are represented throughout the procurement process.

Ensure that each RFP includes a very clear, unambiguous definition of the scope of project work, with the terms and conditions for evaluation and payment. While it is always risky for any project work to remain poorly defined, outsourced work deserves particular attention. Inadequate definition of outsourced work leads to all the usual project problems, but it may also lead to even higher schedule and resource risk. Problems with outsourced deliverables often surface late in the project with no advance warning (generally, following a long series of "we are doing just fine'' status reports) and frequently delay the project deadline, as is evident in the PERIL database. There may also be significant increased cost due to required changes and late-project expedited work. Minimize outsourcing risks through scrupulous definition of all deliverables involved, along with all measurements and performance criteria to be used for their evaluation.

As part of solicitation planning, establish the criteria that you will use to evaluate the responses. Determine what is most important to your project and ensure that these aspects are clearly spelled out in the RFP, with guidance for the responders on how to supply the information that you require. Because the specific work on technical projects tends to evolve and change quickly, there is a good chance that well-established criteria for selecting suppliers will, sooner or later, be out of date. In light of your emerging planning data for the project, review the proposed criteria to validate that they are still appropriate. If the list of criteria used in the past seems in need of updating, do it before sending out the RFP. Establish priorities and relative weights for each evaluation criterion, as well as how you will assess the responses you receive. Communicating your priorities and expectations clearly in the RFP will help responders to self-qualify (or disqualify themselves) and will better provide the data you need to make a sound outsourcing decision.

Relevant past experience is also important to avoiding outsourcing risk. In the RFP, request specifics from responders on similar prior efforts that were successful, and ask for contact information so that you can follow up and verify. Even for work that is novel, ask for reference information from potential suppliers that will at least allow you to investigate past working relationships. While it may be difficult to get useful reference information, it never hurts to request it.

Before finalizing the RFP, determine when any bidder conferences or other meetings will be scheduled and to whom the responders should address any questions or other feedback. Also, determine and clearly specify when responses must be submitted, and establish a deadline for making your decision.

Solicitation

Once you have established the specifics of the work to be outsourced, as well as the processes and documents you plan to use, the next step is to find potential suppliers and encourage them to respond. One of the biggest risks in this step is failure to contact enough suppliers. For some project work, networking and informal communications may be sufficient, but sending the RFP to lists of known suppliers, putting information on public Web sites, and even advertising may be useful in letting potential responders know of your needs. If too few responses are generated, the quality and cost of the choices available may not serve the project well.

Communication throughout the process is also essential. Anything that one potential supplier finds unclear in the RFP needs to be addressed, and any clarifications should be provided to all the others who have the RFP. The questions asked by responders are often good early indicators of the working relationship that will develop. Bidders who ask lots of trivial questions or who request information already provided in the RFP will probably not be very thorough and may be a great deal of trouble to work with. Less risky partners are suppliers who provide insightful feedback, ask about things that probably should have been in your RFP but were left out, or otherwise demonstrate in discussions that they really know what they are doing.

Source Selection

Bringing the solicitation to closure is also a substantial source of risk. There are potential risks in decision making, negotiation, and the contracting process.

Decision Making

Decision-making risks include not doing adequate analysis to assess each potential supplier and making a selection based on something other than the needs of the project.

Inadequate analysis can be a significant source of risk. It is fairly common for the decisions on outsourcing to coincide with many other project activities, and writing and getting responses to an RFP often takes more time than expected. As a result, you may be left with very little time to evaluate the proposals on their technical merit. Judging proposals by weight, appearance, or some other superficial criteria may save time but is not likely to result in the best selection. Evaluating and comparing multiple complex proposals thoroughly takes time and effort. Before you make a decision, spend the time necessary to ensure a thorough evaluation. It's like the old saying, "Act in haste; repent at leisure,'' except that, in your case, you will be repenting when you are very busy.

Another potential risk in the selection process is pressure from outside your project to make a choice for reasons unrelated to your project. Influences from other parts of the organization may come to bear during the decision process—to favor friends, to avoid some suppliers, to align with "strategic'' partners of some other internal group, or to use a global (or a local) supplier. Since the decision will normally be signed and approved by someone higher in the organization, sometimes the project team may not even be aware of these factors until very late in the process. Documenting the process and validating your criteria for supplier selection with your management can reduce this problem, but use of outside suppliers not selected by the project team represents significant, and sometimes disastrous, project risk.

Overall, you must diligently stay on top of the process to ensure that the selections made for each RFP are as consistent with your project requirements as possible.

Negotiation

After you select a supplier, the next step in the procurement process is to finalize the details of the work and finances. Once a selection is made, the balance of power begins to shift from the purchaser to the supplier, which raises additional risks. When the work begins, the project becomes dependent on the supplier for crucial, time-sensitive project deliverables. The supplier is dependent on the project primarily for money, which in the short run is neither crucial nor urgent. To a lesser extent, suppliers are also dependent on future recommendations from you (which can be important for ongoing risk management), but, from the supplier's perspective, the relationship is based mainly on cash.

Effective and thorough negotiation is the last opportunity available to the project to identify (and manage) risks without high potential costs. All relevant details of the work and deliverables need to be discussed and clearly understood so that the ultimate contract will unambiguously contain a scope of work that both parties see the same way. Details concerning tests, inspections, prototypes, and other interim deliverables must also be clarified. Specifics concerning partial and final payments, as well as the process and cost for any required changes or modifications, are also essential aspects of the negotiation process. Failure to conduct thorough, principled negotiation with a future supplier is a potential source of massive risk. Shortening a negotiation process to save time is never a good idea.

Since the primary consideration on the supplier side is financial, the best tactic for risk management in negotiation is to strongly align payments with achievement of specific results. Payment for time, effort, or other less tangible criteria may allow suppliers to bill the project even when they fail to produce what your project requires. Contracts based on "time and materials'' can also make it difficult to determine whether the people involved are being treated as outside contractors or as employees of your organization, which creates additional risk. When negotiating the work and payment terms, the least risky option for you as the purchaser is to establish a "payment for result'' contract.

Outsourcing risk can also be lowered by negotiating contract terms that align with specific project goals. While a contract must include consequences for supplier nonperformance, such as nonpayment, legal action, or other remedies, these terms do little to ensure project success. If the supplier fails to perform, your project will still be in trouble. Lack of a key deliverable will lead to project failure, so it is also useful to negotiate terms that more directly support your project objectives. If there is value in getting work done early, incentive payments are worth considering. If there are specific additional costs associated with late delivery, establish penalties that reduce payments proportionate to the delay. For some projects, more complex financial arrangements than the simple "fee for result,'' such as arrangements in which percentages of favorable variances in time or cost are shared with the supplier and portions of unfavorable ones may be deducted from their fees, may be appropriate. Negotiating terms that more directly support the project objectives and involve suppliers more deeply in the project can significantly reduce outsourcing risks.

If the negotiation process, despite your best efforts, results in terms that represent potential project problems, note these as risks. In extreme cases, you may need to reconsider your selection decision, or even the decision to outsource the project work at all.

Contracting

Once the terms and conditions for the work have been agreed to by both parties, they must be documented in a contract, signed, and put into force. One effective tool for minimizing risk is to use a well-established, preprinted contract format to document the relationship. This should include all of the information that a complete, prudent contract must contain so that the chances of leaving out something critical, such as protection of confidential information or proprietary intellectual property, will be reduced. For this reason, you can reduce project risk by using a standard contract form with no significant modifications or deletions. In addition, using standard formats will reduce the time and effort needed for contract approval. In large companies, contracts that vary from the standard may take an additional month (or evenmore) for review, approval, and processing. Adding data to a contract is also generally a poor idea, with one big exception. Every contract needs to include a very clear, unambiguous definition of the scope of work that specifies measurable deliverables and payment terms. A good contract also provides an explicit description of the process to be used if any changes are necessary.

One other source of risk in contracting is also fairly common for technical projects. The statement of work must be clear not only in defining the results expected but also in specifying who will be responsible. It turns out that this is quite a challenge for engineers and other analytical people. Most engineering and other technical writing is filled with passive-voice sentences such as: "It is important that the device be tested using an input voltage varying between 105 and 250 volts AC, down to a temperature of minus 40 degrees Celsius.'' In a contract, there is no place for the passive voice. If the responsible party is not clearly specified, the sentence has no legal meaning. It fails to make clear who will do the testing and what, if any, consequences there may be should the testing fail. To minimize risks in contracts, write requirements in the active voice, spelling out all responsibilities in clear terms and by name.

Finally, when setting up a contract, minimize the resource risk by establishing a "not to exceed'' limitation to avoid runaway costs. Set this limit somewhat higher than the expected cost to provide some reserve for changes and unforeseen problems, but not a great deal higher. Many technical projects provide a reserve of about 10 percent to handle small adjustments. If problems or changes arise that require more than this, they will trigger review of the project, which is prudent risk management.

Outsourcing Risks

There are a variety of other risks that arise from outsourcing. One of the largest is cost, even if the work seems to be thoroughly defined. Unforeseen aspects of the work, which are never possible to eliminate completely, may require expensive fees for change.

Continuity and turnover of contract staff is a risk. While people who work for another company may be loyal to your project and stay with it through the end, the probabilities are lower than for the permanent staff on your project. Particularly with longer projects, turnover and retraining can represent major risks.

Outsourcing may increase the likelihood of turnover and demotivation of your permanent staff. If it becomes standard procedure to outsource all the new, "bleeding edge'' project work, your permanent staff gets stuck doing the same old things, project after project, never learning anything new. It becomes harder to motivate and hold on to people who have no opportunity for development.

There may also be hidden effort for the project due to outsourcing that is not visible in the plan. Someone must maintain the relationship, communicate regularly, deal with payments and other paperwork, and carry the other overhead of outsourcing. While this may all run smoothly, if there are any problems it can become a major time sink. The time and effort this overhead requires is routinely overlooked or underestimated.

Finally, the nature of work at a distance requires significant additional effort. Getting useful status information is a lot of work. You will not get responses to initial requests every time, and verifying what is reported may be difficult. You can expect to provide much more information than you receive, and interpreting what you do get can be difficult. Even if the information is timely, it may not be completely accurate, and you may get little or no advance warning of project problems. Working to establish and maintain a solid working relationship with outsourcing partners can be a major undertaking, but it is prudent risk management.

Cost Estimating

Project cost estimates are generally dominated by staffing and outsourcing costs but also include expenses for equipment, services, travel, communications, and other project needs.

Staffing and Outsourcing Costs

Staffing costs can be calculated using the activity effort estimates or on the basis of your histograms, spreadsheets, or other resource planning information. Using standard hourly rates for the project staff and your effort estimates, you can convert effort into project costs. For longer projects, you may also need to consider factors such as salary changes and the effect of inflation.

Estimate any outsourcing costs using the contracts negotiated for the services, working with figures about halfway between the minimum you can expect and the "not to exceed'' amounts.

Equipment and Software Costs

The best time to request new equipment or upgrade older hardware, systems, and applications for a project is at the outset. You should assess the project's needs and research the options that are available. Inspect all equipment and software applications already in place to determine any opportunities for replacement or upgrade. Document the project's needs, and assemble a proposal including all potential purchases. As discussed earlier in the chapter, proposing the purchase and installation of new equipment at the start of the project has two benefits: getting approval from management when it is most likely, and allowing for installation when there is little other project work to conflict with it. Propose purchase of the best equipment available so that, if purchase is approved, you will be able to work as fast and as efficiently as possible. If you propose the best options and only some of the budget is approved, you still may be able to find alternative hardware or systems that will enable you to complete your project. Estimate the overall project equipment expense by summing the cost of any approved proposals with other expected hardware and software costs.

Travel

Midproject travel requests are often refused; the best time to get travel money for your project is at the beginning. As you plan the project work, determine when travel will be necessary, and decide who will be involved. Travel planned and approved in advance is easier to arrange, less costly, and less disruptive for the project and the team members than last-minute, emergency trips. Request and justify face-to-face meetings with distant team members, getting team members from each site together at the project start and, for longer projects, at least every six months thereafter. Also, budget for appropriate travel to interact with users, customers, and other stakeholders.

There are no guarantees that travel requested at the beginning of the project will be approved or that it might not be cut back later, but if you do not estimate and request travel funds early, the chances get a lot worse.

Other Costs

Communication is essential on technical projects, and, for distributed teams, it may be quite costly. Video (and even audio) conferencing technology may require up-front investments, as well as usage fees. Schedule and budget for frequent status meetings, using the most appropriate technology you can find.

Projects that include team members outside a single company may need to budget for setup and maintenance of a public-domain secure Web site outside corporate fire walls for project information that will be available to everyone. Other services such as shipping, couriers, and photocopying may also represent significant expenses for your project.

Cost Budgeting

Cost budgeting is the accumulation of all the cost estimates for the project. For most technical projects, the majority of the cost is for people, either permanent staff or workers under some kind of contract. The project cost baseline also includes estimated expenses for equipment, software and services, travel, communications, and other requirements. Whenever your preliminary project budget analysis exceeds the project cost objectives, the difference represents a significant project risk. Unless you are able either to devise a credible lower-cost plan or to negotiate a larger project budget, your project may fail due to lack of resources.

Document the Risks

Resource risks become visible throughout the planning and scheduling processes. Resource risks discussed in this chapter include:

Add each specific risk discovered to the list of scope and schedule risks, with a clear description of the risk situation. This growing risk list provides the foundation for project risk analysis and management.

Key Ideas for Identifying Resource Risks

Panama Canal Resources (1905 1907)

Project resource risk arises primarily from people factors, as demonstrated in the PERIL database, and this was certainly true on the Panama Canal project. On the basis of the experiences of the French during the first attempt, John Stevens realized that project success required a healthy, productive, motivated workforce. For his project, money was never an issue, but retaining people to do difficult and dangerous work in the hot, humid tropics certainly was. Stevens invested heavily, through Dr. Gorgas, in insect control and other public health measures. He also built an infrastructure at Panama that supported the productive, efficient progress he required. At the time of his departure from the project, Stevens had established a well-fed, well-equipped, well-housed, well-organized workforce with an excellent plan of attack.

This boosted productivity, but George Goethals realized that success also relied on continuity and motivation. He wanted loyalty, not to him but to the project. The work was important, and Goethals used any opportunity he had to point this out. He worked hard to keep the workers engaged, and much of what he did remains good resource management practice today.

Goethals took a number of important steps to build morale. He started a weekly newspaper, the Canal Record. The paper gave an accurate, up-to-date picture of progress, unlike the Canal Bulletin that had been issued periodically during the French project. In many ways, it served as the project's status report, making note of significant accomplishments and naming those involved to build morale. The paper also provided feedback on productivity. Publishing these statistics led to healthy rivalries, as workers strove to better last week's record for various types of work so that they could see their names in print.

It was crucial, Goethals believed, to recognize and reward service. Medals were struck at the Philadelphia Mint, using metal salvaged from the abandoned French equipment. Everyone who worked on the project for at least two years was publicly recognized and presented with a medal in a formal ceremony. People wore these proudly. In a documentary made many years after the project, Robert Dill, a former canal worker interviewed at age 104, was still wearing his medal, number 6726.

Goethals also sponsored weekly open-door sessions on Sundays when anyone could come with questions. Some weeks more than one hundred people came to see him. If he could quickly answer a question or solve a problem, he did it then. If a request or suggestion was not something that would work, he explained why. If there were any open questions or issues, he committed to getting an answer, and he followed up. Goethals treated workers like humans, not brutes, and this engendered fierce loyalty.

While all this contributed to ensuring a loyal, motivated, productive workforce, the most significant morale builder came early on, from the project sponsor. In 1906, Theodore Roosevelt sailed to Panama to visit his project. Roosevelt's trip was without precedent; never before had a sitting U.S. president left the country. The results of the trip were so noteworthy that one newspaper at the time conjectured that, someday, a president "might undertake European journeys.''

Roosevelt chose to travel in the rainy season, and the conditions in Panama were dreadful. This hardly slowed him down at all; he was in the swamps, walking the railroad ties, charging up the slopes, even operating one of the ninety-seven-ton Bucyrus steam shovels. He went everywhere the workers were. The reporters who came along were exhausted, but the workers were hugely excited and motivated.

On Roosevelt's return to Washington, so much was written about the magnitude and importance of the project that interest and support for the canal spread quickly throughout the United States. People believed that "with Teddy Roosevelt, anything is possible.''

Related

Категории