Managing Project Risk

Overview

"Let us never negotiate out of fear, but let us never fear to negotiate."

—JOHN F. KENNEDY

It is rare to encounter a project where everyone involved feels things are adequately under control. There never seems to be enough time, funding and staffing seem too low, and there are generally a few technical challenges yet to figure out. Managing project-level risk involves understanding all of this well enough early in your work to set realistic project expectations and, if necessary, to negotiate at least minor changes to the project. While it is never possible to deal completely with project risks and issues, shifting things to minimize the worst problems may be sufficient. Once a project is seen to be feasible, hard work, with a bit of inspiration, cleverness, and luck, is often enough to let you close the rest of the gap.

The main point of this chapter is to deliver on the title of the book—to provide techniques for failure-proofing your project. Managing project risk begins with the risk assessments and plans of the preceding chapters. This chapter builds on that foundation, discussing how to effectively use risk and project data to influence necessary changes, to clearly communicate project risks, and to adopt ongoing risk management practices that detect new risks promptly and minimize problems throughout the project.

Most of the content of this chapter falls into the "Risk Response Planning" portion of the Planning Processes in the PMBOK Guide, but it goes beyond that material to include concepts from other Planning Processes. The principal ideas in this chapter include:

Project Documentation Requirements

One of the only things less interesting than assembling project documentation is reading a lengthy description of what it "must" include. Since technical projects come in all sizes, shapes, durations, and complexity, the requirements for project documentation—the written descriptions for project deliverables, plans, and other relevant information—vary a great deal. Whether the documentation is lengthy and elaborate or fairly informal, it serves as your basis for project execution and control. Project teams that fail to put adequate documentation in place know too little about their projects, and they carry more risk. In addition, when you lack data, you have a much lower chance of influencing necessary changes to your project, because your proposals and negotiations will not have enough facts supporting them. While it is certainly possible to overinvest in project documentation, it is far more common on technical projects to do too little. Prudent project risk management tends to err on the side of capturing more, rather than less, data.

Project documentation is most effective when it is available in "layers." At the most detailed level, there is the thorough, Encyclopedia Britannica version of the project plan needed by the project team. For others, such lengthy detail is neither necessary nor appropriate. You also need clear, summary-level documentation that can be used in discussions with sponsors, stakeholders, and others who are less involved with the project but who will take part in project discussions, negotiations, decisions, escalations, problem solving, and other project communication.

Thorough project documentation created during your planning and risk assessment gives you a foundation for validating your project plan. It also provides the leverage you need to negotiate project modifications when it is necessary to transform a project that would almost certainly fail into something more realistic. The ultimate goal of this process is to set your project plan of record consistent with both the project objective and a realistic plan. Ongoing project risk management also requires periodic plan reviews and an effective change management process, and these also rely on thorough documentation.

Project Documents

Project documents fall into three categories: definition documents, planning documents, and periodic project communications. Definition documents are generally assembled earliest. They include:

Additional necessary documentation may include detailed specification documents, a high-level project financial analysis, the project budget, detailed release or acceptance specifications, any market research reports or user investigations, and any other specific project data required by your organization.

Planning documentation is also assembled in the earliest project stages, but it may be modified and augmented throughout the project as a result of approved changes or new information. Typical project planning documents are:

Periodic project communications accumulate throughout the project. They include:

Project documents are most useful when they have a consistent, easy-to-read format, so you should adopt an appropriate existing format (or define one) and stick with it. Especially for lengthy documents, use a format that begins with a high-level summary or abstract that is no longer than half a page of text. It is always risky to bury important information on page 43 of a project report. For each project document, identify an owner (often the project leader) who will be responsible for creation, maintenance, and distribution. Define how and when document changes can or should be made. When there are approved changes, you need to assign responsibility for providing up-to-date documents and for marking old versions obsolete.

Documents have value only if the people who need them have ready access to them. Storing documents on-line (with appropriate access security) is an effective way to ensure that all team members have access to and are working from the same information. Establish a centralized location for any paper documents (or several, for geographically separated teams) that is well known and easily accessed. Whether your project documents are in a notebook, in a file cabinet, or on a server or use some other medium, keep them available and current.

Project Start Up

One of the most significant problems on technical projects is lack of team cohesion, particularly for projects that have geographically separated teams. Completing a difficult project requires teamwork, trust, and a willingness to look out for and help the others on the project. Under tension, chains tend to break at the weakest link; projects staffed by "virtual" teams have nothing but weak links.

One method for countering this problem and minimizing the risks that result when projects must be staffed by people who do not know each other is to hold a project start-up workshop. A start-up workshop (sometimes referred to as a project launch, a "kickoff" meeting, a planning workshop, or a project initiation meeting) is an event intended to initiate the project processes and to build teamwork. A well-run start-up achieves a common understanding of the project goals and priorities and avoids wasted time and redundant efforts. It also builds a more cohesive team that will get a fast, efficient start on the project.

Typically, you will want to hold these workshops very early in the planning process, at the start of project execution, and before each major new phase of the project. The precise objectives vary somewhat for workshops held at these different times, but all start-ups focus on team building and on common project understanding. Achieving these objectives substantially reduces many types of project risk.

Justify and Prepare for the Workshop

One reason given for not holding start-up workshops is cost. Particularly for global teams who must travel to take part in a face-to-face workshop, costs and travel time can be significant. But the cost of not doing a project start-up is also high; serious problems and loss of productivity can result whenever people are uncooperative or misunderstand information in complex projects. For technical projects, it is not a choice between the expense of a project start-up workshop and saving money; the choice is between investing a relatively small amount of time and money early or spending a lot more time and money later in the project. Establishing common objectives and language for the project and building relationships among the project team members minimizes risk and creates the environment needed for a successful project.

The most effective start-up meetings are held in person at the beginning of the project. On longer projects, the exercise is best repeated at least every six months. Face-to-face meetings are best for team building, and periodic renewal of acquaintances establishes the foundation that allows distance collaboration and other means of communication to work smoothly and well. When the timing or cost aspects of a project start-up genuinely make an inperson meeting impossible, at least plan and hold a meeting, or a series of meetings, using videoconferencing or other teleconferencing technology. Such a meeting is much less effective for team building and generating trust, but it still contributes to better common understanding, and it is much better than doing nothing.

As the plans for project start-up take shape, allow some time during the meeting for some nonwork activities to let people get to know one another better. If the workshop takes place over multiple days, consider using evenings for team dinners or other events. Even for "virtual" meetings, invest some time in activities that encourage people to connect, such as individual discussions of hobbies and interests or sharing other personal information. Having distant team members interview one another before the meeting and then asking each person to report some of the information gathered to start the meeting is very effective in building the personal relationships that difficult projects depend on. Exchanges of pictures, items of interest, or even food with distant team members involved in the meeting are also good ways to connect people.

Productive project start-up workshops are organized well in advance. Put sufficient effort into details such as the agenda, a facilitator, the information required, the place and time, and the people who should participate. Set an agenda that includes introductions, discussion of project objectives and deliverables, exploration of planning information, defining of team roles, and other project aspects that you need to cover. Specific project start-up workshop agenda items vary depending on the timing of the meeting, the size of the project, and the length of the workshop. Include sufficient time on the agenda for discussion of each topic, and clearly specify any outputs or decisions expected for each part of the workshop listed in the agenda. For small projects, a start-up meeting might only require half a day. For large programs, a series of workshops could run for a week, or even longer. When working with global teams, allocate additional time to accommodate factors such as language and culture. Prioritize the agenda to cover the most important items first, and review the agenda in advance with your project sponsor.

Some of the objectives and benefits of a start-up workshop are difficult to achieve when the project leader is also the facilitator. The facilitator's main job is to keep the team focused on the agenda. The project leader is better able to participate in the meeting and contribute to the results if he or she is not also facilitating. One alternative is to ask a leader from another project to facilitate and then to reciprocate later by offering to facilitate his or her meeting. This not only allows you to participate more fully in your start-up but also leads to broader awareness of other projects, lowering organization-level risks. Another option is to use a professional facilitator.

The meeting objectives also require up-to-date project information, in a form that is easily distributed and used for the workshop. Assemble project documents and distribute any necessary data in advance of the meeting. For specific outputs that are listed on the agenda, be sure to provide any examples, formats, and templates that are available.

Determine the people you need to participate in the workshop for it to be successful. Include all of the core project team, as well as others who will make significant contributions. Schedule the meeting to minimize timing conflicts for the attendees. Invite all the participants, and get their commitment to attend the full workshop. Select your meeting place to minimize distractions and interruptions. Meetings held off-site, away from the normal workplace, allow you to accomplish more in less time.

Hold the Workshop

Begin the meeting with personal introductions, and work to ensure that the people attending start to get to know one another. Each person has a role in the project, and his or her introduction should include a summary of what that role will be, and why it is important to the project. Long meetings tend to meander, so set meeting ground rules and enforce them throughout to focus the meeting and keep it productive. Open the start-up workshop with a review of the meeting agenda, project objectives, and other necessary background information to set expectations and to gain common understanding of the project.

Throughout the workshop, have someone capture issues, questions, action items, and other data produced by the team. As the workshop progresses, work together with the attendees to review, develop, and improve the project definition and planning documents. During all the discussions and presentations, strive for common understanding of the project objective, project priorities, the major project deliverables, the roles and responsibilities of contributors, and at least a high-level version of your project plan. Depending on the timing of the workshop, the focus may be on development of these items or on review and understanding, but team buy-in for the project is always a primary objective.

Toward the end of the workshop, review the issues and assumptions captured, and assess them for project risks. Risk identification is a significant byproduct of start-up workshops, so explicitly add any newly uncovered risks and significant issues to your risk list for further analysis and follow-up. Wrap up the workshop by identifying all assignments, due dates, and owners for all action items and other required additional work. Close the meeting by thanking the participants for their contributions.

Follow up after the Workshop

After the workshop, provide all the participants with a written summary of the meeting's outcomes and decisions. Integrate the work done during the workshop into project documents as appropriate, and put the updated documentation where it can be referenced and used. Follow up on all action items and other assignments made during the workshop, by either bringing them to closure or adding them to your project plan.

Selecting and Implementing Project Metrics

Project metrics are very important for project risk management. Some metrics relate to risk triggers, and others may provide trend data that foreshadows future project problems. The value of project metrics depends on what, and how much, is measured.

A project is a complex system, so one metric generally is not sufficient to adequately monitor the overall process. Using too few metrics may also lead to inappropriate conclusions, resulting in undesirable decisions or behaviors. Defining too many metrics also causes problems, starting with the excessive cost and effort required to collect them. When there are too many data, it is easy to overlook important information hidden in the jumble. Strive to define the minimum set of project metrics that you need to give a balanced view, consistent with the goals and values of your organization.

There are examples of many useful metrics in Chapter 9. Selecting a few appropriate measures and collecting data regularly provides useful information for both your current project and future projects.

Selecting Metrics

Useful metrics are objective; if they are evaluated by several people, each person will get the same result. Good metrics are also easy to understand and to collect. Clarify how and what you need to measure, and verify through discussion that everyone involved understands the process consistently. Define the units and precision to be used for the measurements, and use the same units for all collection, evaluation, and reporting. For example, you might decide that all measurements for duration estimates will be rounded to the nearest full workday. Also, determine how often to measure. You need to collect data frequently enough to support the results you desire, but not so often that the collection represents higher than necessary overhead. Capturing data too often also displays "noise," variations in the data that have little or no meaning.

Prioritize any metrics you are considering, using criteria such as criticality, contribution to potential process improvement, linkage to desired behaviors, or availability of data. Collect only metrics that make a meaningful difference; do not collect data just because you can. An effective set of metrics also provides tension—improvement of one measure may diminish another one. Opposing a metric measuring speed of execution with another measuring defects or quality results in more appropriate behavior than either measurement by itself. Work to minimize "gaming" of the metrics by eliminating factors that might improve the measurement without achieving any desired results. It is possible to subvert almost any metric, so define them in terms that minimize differing interpretations and loopholes.

For project metrics that measure factors that are under the control of the project team, use input and computational definitions that are unambiguous and not subject to change. Avoid metrics based on subjective interpretations.

Finally, work to ensure that any metrics collected are used primarily for process monitoring and improvement, not as a basis for punishment. Metrics are powerful tools for identifying opportunities for beneficial change and determining trends, but the quality of the data that people provide will be less useful if they know that they will also be used to evaluate their performance. Once metrics are identified with processes used to rank and cancel projects, the reliability of future data deteriorates substantially. Use metrics for process control and improvement, not to generate criticism of the project team. If any personal information is involved, ensure that the measurements are kept confidential.

Implementing Metrics and Collecting Data

Before you start to use a metric, discuss it with everyone who will be affected by it. For project metrics, work to get consensus from all members of the project team on the definition, the planned collection and use of the data, and the meaning of the results. Get commitment from everyone who will collect or supply data in advance, and seek agreement not to "game" the metrics.

Once a set of metrics is defined, the next step is to define an acceptable or desirable normal range. For well-established metrics, baselines are probably already documented. For new measures, or for metrics used in a new application, you need to establish the initial data range. While you can begin with an educated guess as a provisional baseline for a new metric, you should use the first several cycles of data collected to confirm it. Use this initial data only to validate or to correct the baseline. Until you have established the baseline using measurements, resist the temptation to make decisions and process changes.

Document each metric and its parameters, and provide these data to everyone affected. Include information such as the name of the metric, the intended objective, data required, measurement units, measurement frequency, the method for data collection, any formulas used, the target acceptable range, and who is responsible for making the measurement.

After setting a measurement baseline, collect project data as planned, and use the information to guide your project decisions. Set baselines for diagnostic metrics early in projects, using current data or data from similar earlier projects. For retrospective metrics, set baselines using existing data from earlier projects, or wait until several completed projects have collected the data required. For predictive metrics, establish corresponding retrospective metrics (for example, validate financial ROI predictions against actual performance), and establish norms that plausibly connect to the desired results. With all metrics, you should remain skeptical; review the data, and confront any suspected "gaming" of the measurements. Periodically reevaluate all metrics, especially after significant organizational or process changes. Following changes, review the baseline and acceptable range for each metric. Validate any necessary adjustments with new baseline measurements before considering additional system changes.

Throughout the process, make the measurements visible. Report the status of measured factors as planned, to all project stakeholders who need the measurements or are affected by them. Be prompt in evaluating and reporting the data to ensure timely feedback and early detection of significant variances.

Management Reserve

Imagine a large target with a big, red, circular bull's eye in the center. If you stand two meters away from the target and aim a target rifle right at the center, you should have no difficulty hitting the middle of the bull's eye. If you were to repeat the shot, but this time from two hundred yards away, the situation would change. For the second shot, aiming at the bull's eye would no longer be effective, because you could no longer rely on the projectile to fly in a straight line. If you were to aim at the center of the target, you would hit below its center. The parabolic arc that controls the flight of the bullet was described with precision hundreds of years ago by Sir Isaac Newton, and the principle is so well understood that even the average middle manager would not be tempted to give the bullet a lecture on "flying smarter, not harder." Everyone knows that you need to aim higher than the point you wish to hit, to compensate for the effects of gravity.

Simple, short projects are analogous to the first shot. Setting a date and planning to hit it works more often than not, because the time window is brief, the work is fairly obvious, and the risks are small. For most technical projects, though, the analogy of the second shot is better. The longer duration, with substantial unknowns and risks, is a very different situation. As with gravity for the flying bullet, risk has an effect on the trajectory of a project. Project plans that set deadlines to line up exactly with the final planned activities, even if the plans are based on reasonable, realistic estimates, have little chance of completing on time. The "force" of risk makes this sort of schedule unreliable.

Management reserve is a general concept for managing project risk that reduces uncertainty. Reserve—in time, in budget, or in both—based on expected risk may be used to develop credible schedules. Establishing reserves is not about padding estimates or making scheduling choices to accommodate sloppiness or team sloth; it is about using risk assessment information to set appropriate buffers at the project level to allow the project to deliver on commitments. In effect, management reserve is about setting project objectives with ranges, with the size of the range, or reserve, defined by project-level risk assessment.

Management reserve is based on two factors: known risks, with contingency plans or worst-case scenarios (this includes any known risks you may have elected to passively accept—that you have decided not to manage), and unknown risk. The first factor, discussed in detail in earlier chapters, comes from planning data. Unknown risk, by definition, is risk you are unable to anticipate and describe. Explicit planning for unknown risks is not possible, but metrics from earlier projects can provide guidance on the magnitude of exposure. Using project risk assessment data and metrics, you can estimate appropriate schedule and budget reserves. In effect, management reserve is a generic contingency plan for your overall project. Reserve is never allocated to the activity level, and it is managed by the project leader, not by activity owners.

Schedule Reserve

Management reserve for schedules may be implemented in several ways. The simplest method is to estimate the amount of expected schedule exposure and then to develop a plan that supports completion of the project earlier than the required completion date by that amount. In dealing with problems, the project can slip by any amount less than the reserve and still meet the project commitment. The published project schedule could show only the more aggressive, target completion date, or it could show the target date as a milestone followed by a dummy activity and then the committed deadline. The dummy activity has a name such as "allowance for risk," and it has a duration estimate equal to the schedule reserve.

For known risks, the amount of reserve needed for a given project can be estimated using methods that have been described in earlier chapters of this book. From Chapter 4, the idea of worstcase estimates provides one source. Using the "most likely" duration estimates establishes one possible project end date. Schedule analysis based on the worst-case estimates calculates a second end date for the project further out. The difference between these two dates can be used to determine the required reserve. How you do this depends on your confidence in the data, but it is common to set up half of the difference as a reserve—managing the work using the "most likely" schedule, but setting the project deadline to be a date midway between that schedule and the worst-case end date.

A second method for determining schedule reserve relies on data from your contingency plans. This process uses the method discussed in Chapter 9 to aggregate activity risk data. In this case, you would track and manage your project using the project plan as a target, but your committed deadline would be later by a duration defined by the cumulative expected consequences of having to use your contingency plans.

A third way to assess schedule reserve using data from known risks, also discussed in Chapter 9, relies on PERT or PERT– type analysis. The histograms or expected distribution can also be used to estimate required reserve, by determining the duration between the "most likely" (30 to 50 percent likelihood) date and some higher probability point farther out that is consistent with your project's risk tolerance. Again, your plan supporting the "most likely" dates will be used to manage the work and define the early point of a range window of acceptable dates. The upper boundary of the window will be the project commitment.

Estimating schedule reserve using any of these ideas is still incomplete. These estimated allowances for reserve are based only on known risks, so, without some consideration of the magnitude of your unknown risk, the reserve allowance will be too small. If you have metrics that measure typical schedule impact from unknown risk, incorporate this into your estimate of required reserve.

One very common example of reserve for unknown risk is explicit in many kinds of project plans. At the end of many construction and relocation projects, there is an activity scheduled called a "punch list," or something similar. The purpose of this activity is to fix and close out all the defects, problems, omissions, or other issues that accumulate on a list during the project. At the start of the project, a duration estimate based only on the list would logically be zero—there is no work yet identified. Since a duration estimate cannot be based on explicit knowledge of the work, it is based on the history of dozens, or hundreds, of similar projects. Experience from earlier work tells you how much time and effort, on average, you can expect between completion of the final scheduled activity and customer sign-off. Metrics that measure unscheduled effort, the number of activities added during projects, underestimated activities, and other indicators of plan incompleteness are all useful for estimating typical "unknown" risk.

An alternative method for estimating the schedule consequences of unknown risk is the project appraisal idea discussed in Chapter 9. The comparison projects include the effects of unknown risk, whereas your planned current project does not. Part of any difference shown in an assessment is due to unknown risk.

The amount of required schedule reserve varies greatly depending on the type of project. A reserve of only a few days may be appropriate for short, routine projects. For complicated, aggressive projects, target dates may need to be established weeks, or even months, before the committed deadline to deal with the many possible problems and potential sources of slippage. Whether the reserve is short or long, remember that it, like schedule float, belongs to the project as a whole. It is available only for problem solving, not for personal convenience. Using reserve established to manage project risk for other purposes (especially for scope creep) increases project risk.

How schedule reserve is best handled varies. On some projects, reserve is openly discussed and managed by all. Schedules posted and distributed reflect its existence, and the status of remaining schedule reserve is discussed in status meetings with other topics. On other projects, the management of reserve is more covert. As far as the teams on these projects know, the deadline for the project is the date that follows the final activity in the plan. While this has the desired effect of focusing attention on getting the work done as promptly as possible, it is inconsistent with open and honest project communications. While managing the reserve openly is usually the better method, it is easily undermined unless you effectively guard against two potential issues: scope creep and Parkinson's Law.

Scope creep is always an issue on technical projects; the more time the team spends thinking about and doing the work, the more ways they come up with to make it "better." In projects that possess a time buffer for risk management, the temptation may become overwhelming to add and modify the project scope, since "we have the time available." On all projects, risk management depends on disciplined and thorough control of changes, and this is particularly true of projects that have visible schedule reserve. Schedule reserve should be used only to accommodate project changes that are a direct result of project problem solving and issue resolution. Schedule reserve is not a tool for project "improvement."

The second issue, Parkinson's Law—work expands to fill the time available—also presents a significant challenge. Misuse of schedule reserve, particularly unused reserve still available late in the project, is a constant temptation. One method for guarding against this is to establish the available window of time for project completion and to set up rewards for the team proportionate to any unused reserve at the end of the project. Incentives for avoiding misuse of the reserve can be very effective, but they need to be developed carefully so that they are effective in discouraging misuse and scope creep but not so desirable that the reserve is not applied when necessary to solve problems and deal with risks. In setting up incentives, you need to discover what kinds of rewards your team will value. The best leaders make recognition for good performance fun, and rewards meaningful. Use rewards that encourage teamwork. Individual rewards, particularly of money, can erode teamwork and cooperation.

The best methods for reserve management ensure that all decisions are ultimately in the hands of a project leader who will apply the available reserve only to deal with real-time problems, issues, and conflicts. This way, the established reserve operates to counteract the effect of risk and helps aggressively scheduled projects complete on or before their committed deadline.

Budget Reserve

Reserve for resources uses project resource analysis and risk data. Budget reserve at the project level can be used to expedite work, add additional resources, or take other necessary actions to stay on schedule.

The amount of reserve needed is estimated similarly to the schedule reserve discussed earlier, from analysis of known risk using worst cases, contingency plans, or PERT analysis. For unknown risk, estimate reserve using metrics derived from earlier projects. Base your determination of required budget reserve on the best data you have available.

Again, it can be a challenge to be aware of the budget reserve while resisting the temptation to use it for project modifications that have nothing to do with risk. It is usually somewhat easier on technical projects to manage budget reserve than schedule reserve, because decisions concerning money and resources are generally made by the project leader, and sometimes even higher in the organization.

Using Management Reserve

While determining a prudent allowance for schedule and/or budget reserve is the first step, establishing these requires discussion, negotiation, and approval from project sponsors and stakeholders. You need all the planning and other data you used to calculate required reserves, but this is not sufficient. You also need to identify and factor in your project constraints. Requesting schedule reserve that is not consistent with a hard completion date for the project probably makes no sense, nor would a proposed budget reserve that exceeds the expected benefit for the project. Work to keep your analysis consistent with the goals and objectives for the project, and understand that when your estimate for reserve exceeds what is logical for the project, project risk is very high, and it may be an indication that your project is doomed. Abandoning such a project in favor of better alternatives could be the best decision.

Project Baseline Negotiation

Managing project risk nearly always involves some shift in the project objective. In the unlikely event that your bottom-up plans and risk assessment are wholly consistent with the project objective, no negotiation is necessary; validating the plan and documenting the baseline is all that you need to do. For most projects, however, there are issues to confront, often significant ones.

Project negotiation serves a number of purposes. The most obvious one is to shift an unlikely, perhaps impossible, objective enough to bring it in line with a realistic plan. Other reasons for negotiation include building awareness and support for the project from sponsors and stakeholders, setting limits on project scope, and managing expectations.

Strong Sponsorship

Risky projects need all the help they can muster, so work to get and retain high priority and visible support for your project. Projects that have substantial risk are generally undertaken because there are large potential benefits expected, and you should make sure that all discussions of the project emphasize the positive results that will come from the project, not just the risks, problems, and challenges. Build awareness of your project, early and often, so that your management will continue to support the project in their words and actions. Particularly on risky projects, you need commitment for quick resolution of escalated issues, protection of the project team from conflicts and nonproject commitments, and approval for any requested management reserve. You may also need sponsor approval for training to acquire new skills and to streamline or change processes. Projects are surrounded by organizational "white space," generally managed by the project sponsor. The sponsor can lower risk for the project by aggressively removing organizational barriers and administrative overhead and by dealing with organizational and business factors that may inhibit fast execution of the project. Conversely, management can exacerbate risk by contributing to these factors and initiating new work that requires people currently assigned to your project. Strong, continuing sponsorship is one of the key factors that separate risky projects that succeed from those that crash and burn.

Setting Limits on Project Scope

Another goal of project negotiation is to set boundaries for the project. A great deal of risk for technical projects, as was discussed in Chapter 3, arises from the fact that there may be any number of different conceptions for what, exactly, your project is supposed to produce. Even though you and your project team probably have a fairly clear definition as the planning and risk analysis come to closure, there still may be residual "fuzziness" in other quarters. The project scope must be just as clear as the deadline to everyone involved.

The project documentation prepared for discussions with sponsors should be unambiguous about what the project will include and specific in outlining what it will not include. Setting limits on scope early, using "is/is not" scope definition descriptions that are understood by all, either validates the project team's conceptions or triggers discussions and necessary adjustments. Either way, doing this early in the project is the best course; it lowers risk and results in consistent expectations for all parties.

Fact Based Negotiation

Project baseline negotiation requires your definition and planning documents. Initial discussions focus on summaries, so writing clear, informative summaries is essential. In preparing project information for discussion, include a high-level objective summary, a milestone project schedule, a high-level WBS, a project appraisal, and a summary of major assumptions and risks. If your planning shows a major mismatch between the current project plan and the requested project objective, you should also have several high-level proposals that describe project alternatives.

With these data in hand, your next step is to set up a meeting with the project sponsor to discuss the project, the results of your planning, and, if necessary, the alternatives. Begin the discussion with a presentation of your planning results. Whenever your project plan is inconsistent with the originally requested project objective, you need to negotiate changes. Changes to consider include requesting additional resources, extending the deadline, getting contributors with more experience or more training for the people you have, reducing project scope, or any number of other options.

Having data is critical for your success, because the balance of power in such negotiations is not in your favor. While it is relatively easy for sponsors and managers to brush aside concerns and opinions, it is much more difficult for them to dismiss hard facts. When there is a significant difference between project expectations for timing and resources as seen by the project team and their management, a half-page project appraisal (described in Chapter 9) can be a good starting place for the discussion, showing why the requested project is not likely to be done as quickly or inexpensively as desired. ("Remember this project? That's the one we had to do in two months, and it ended up taking six.") When the issue is a request to do a project much faster than is possible, your project Gantt chart, showing all the activities and durations, is an effective tool. When the deadline requested is far too short to accommodate the work, hold up the chart, and say that you can do it on schedule only if the sponsor selects which activities to delete. Most sponsors will back down and be willing to begin a productive discussion of alternatives, rather than randomly removing work they probably do not understand. Any project information backed up by historical, documented data can be a good starting point for a fact-based, not emotion-based, negotiation.

Reducing project risk through negotiation is best done with the ideas outlined by Roger Fisher, William Ury, and Bruce Patton of the Harvard Negotiation Project in their book Getting to Yes. Their process of principled negotiation is effective for "win-win" negotiations, where all parties get at least some of what they seek. In project negotiations where only the sponsor "wins," everyone has actually lost. It does no one any good to force a commitment to an infeasible project. The team and project leader lose because they are stuck on a doomed project. The sponsors, managers, and customers lose, too, because they do not get what they expect and need. Principled negotiation, done early, is essential for dealing with failure-prone projects.

Some useful ideas for project negotiations include separating the people from the issues and focusing on interests, not positions. By sticking to facts and mutually understood needs, you raise the discussion beyond "This project is hard" on the project side and "You are the best project leader we have" on the other. While both of the statements may be true, neither one actually addresses the real issue—that the project objective, as stated, is not possible. As you prepare for negotiation, develop project alternatives that provide for mutual gain, such as exploring opportunities that could extend beyond the original project request or segmenting the project into a sequence of smaller projects capable of delivering value earlier. In your negotiations, base decisions and analyses on objective criteria. Brainstorm, problem-solve, and get everyone involved in seeking better options. Ask lots of questions, and focus on resolving the issues, not just arguing about the project.

One of your best assets in all of this is your knowledge. As a result of your project planning, no one alive knows more about the project than you do. You also have a track record and credibility, built up over a body of prior work. The managers and project sponsors are aware of this; that is why they requested you to lead the project. Proceed with negotiations using your technical and planning expertise, and the experience of your project team.

Lay out the consequences of accepting a commitment to a project with excessive residual risk in clear, fact-based terms. By using conservative assumptions to support the analysis of the potential project problems, you will end up with one of three possible results. The most desirable outcome is shifting the project objective in line with, or at least closer to, your plan. For other projects, realistic analysis of the work and risks may lead to the conclusion that the project is not a good idea, and it is taken no further. Either of these outcomes avoids a project destined to fail.

The third possibility is that your data may not be sufficiently compelling or that your sponsors pay no attention to them. In this case, you may end up forced to commit to an infeasible project, with no realistic plan to support it. Should this happen, document the situation for future reference, to make it less likely to recur. Then you can either try your best and hope for miracles or consider finding a way out of the project.

Project Plan Validation

Following discussion and negotiation, validate that you have consensus on the project. Verify that you have a plan supporting the project objective that is acceptable to the project sponsor and other stakeholders, as well as to you and your project team.

Use the project documents from the planning processes, with any negotiated modifications, to establish the project baseline plan of record. Before finalizing the plan, review it to ensure that it includes periodic risk reassessment activities throughout (at least at major phase milestones). During these reviews, additional risks not apparent at project start will be identified, and your contingency plans can be updated.

Publish the final versions of the project documents and distribute them so that the project team can access and use them to manage progress throughout the project. Put your project documents on-line if possible so that everyone has access at any time to current versions. If a computer scheduling tool is to be used for project tracking, save the project schedule as a baseline and begin tracking activity status in the database.

When you set the project baseline, freeze all specifications. Set both the project scope definition and your baseline plan at the same time, and change neither one without using your established process for making changes. Freezing the schedule and resources on a project while allowing the scope to continue to meander is a massive source of project risk.

For risk visibility, create a "top-ten list" of the most significant known risks for the current phase of your project, and post it where the project team will be aware of it—in the team workplace, on the project Web site, or at another prominent location. Commit to periodically reviewing and updating the list throughout the project.

Specification Change Management

Once the project plan is accepted and you have frozen the specifications, carefully consider all changes before accepting them. After the project documents are signed off by all appropriate decision makers—the project sponsor, customers, stakeholders, and others—it becomes very risky to allow unexamined changes in the project. Although new information flows around technical projects continuously, maintaining specification stability is crucial for project success. Unmanaged change leads to slipped schedules, budget problems, and possibly even scope problems due to unintended consequences, as seen in the PERIL database.

Having a process for submission, analysis, and disposition for each proposed change lowers the risks, especially if "reject" is the default decision for submitted change requests. An effective change management process puts the burden of proof on each change request; all changes are considered unnecessary until proven otherwise.

Another requirement for effective change control is to ensure that people responsible for the change process have the authority to enforce their decisions. Change reviewers need to have sufficient involvement with the project to effectively understand the probable consequences of a change, both positive and negative. Change approvers also need to have knowledge of the project, and they need the power to say "no" (or at least "not yet") and make it stick. For reasons of efficiency, some change processes establish change screeners, who initially examine any proposed change and determine when (or even if) a change deserves further consideration.

Change Process

Change control processes need to be documented, in writing, especially on fee-for-solution projects. The formality of the actual process adopted varies a great deal with project type, but at a minimum, it should include:

Change Submission

Ideas for change generally begin in problem solving or from recognition of an opportunity. Submissions of proposed changes should be in writing and include information such as:

Less formal systems may require only brief summaries; more elaborate change management processes often require specifics in a defined format and may also require additional information and specific documentation.

All changes submitted, even in systems that are relatively informal, need to be logged. Maintain an up-to-date list of submitted change proposals throughout the project, with current status information available to the project team. Following submission, examine each submitted change request for form, completeness, and reasonableness. If the information is unclear or key data are missing, return the request to the person who submitted it for amendment. Provide the change request information to those responsible for evaluation, review, and approval.

Change Analysis

Analysis of changes should include at least two aspects, impact assessment and cost/benefit analysis. Impact assessment parallels the processes used for impact analysis of risks. It begins with high-level categorization of change impact:

Specifics of impact are also important. It may be necessary to carry out a new, detailed planning analysis of the project for significant changes, examining costs for additional research and development, equipment modification, acquisition or retrofit costs, changes required in documentation, any required training, the cost of purchasing new parts, and scrapping of any old components not needed. Consider the impact of the change on any legal contracts for purchasing of materials or outsourced services. Changes may also have impact on commitments made to customers or users concerning availability or features.

Finally, analyze the schedule impact of the change. Assess the duration impact of any new activities on project completion and the effect of undoing any work that the change renders unnecessary.

Cost/Benefit Analysis

Each change presumably has credible benefits, or it would not be under consideration. The expected benefits need to be estimated so that they can be contrasted with the expected costs and other consequences.

Changes generally fall into one of several categories. Many proposed changes resolve problems encountered on the project or fix something that is not functioning as required. The benefits of these changes relate to the avoided expense or time slippage that will persist on the project until the problem is solved. Other changes arise from external factors such as new regulatory or safety requirements, the need to comply with evolving standards, or actions by competitors. These types of change, which are solving real problems, complying with company requirements, and reacting to adverse shifts in the environment, are often unavoidable. Your project deliverable will lose much, if not all, of its value unless the changes are made. The consequences of both making and not making the change are usually clear from your project planning data.

Project changes aimed at making the project "better" are on less solid ground—changes that add something to the deliverable, alter something about the deliverable to improve it, or introduce new processes or methods to be used for project work. The benefits of these changes are more speculative, and thus more difficult to analyze. Credible estimates for increased sales, revenue, or usefulness as a result of the change are difficult, and they tend to be very optimistic. While some opportunities for change may result in very significant benefits, many changes intended to improve technical projects generate unintended consequences and lead to benefits that are far smaller than expected. The impact to the project may also be very hard to estimate, particularly if the change involves adopting a new approach to the work. Effective change management systems are skeptical of these modifications and tend to reject them. When outright rejection is not possible, the system should at least be adept at saying "not yet," allowing the project to complete as planned and then embarking on a follow-on effort to pursue the new ideas.

In all cases, a rational consideration of the net benefit of the change—the reasonably expected benefits less the estimated costs and other consequences—is the central focus of the decision process. This analysis should apply to all submitted changes, regardless of their origin. If customers submit changes, the specific consequences in terms of timing and cost must be visible to them, and generally borne by them, as well. If a project contributor submits a change, he or she should provide ample documentation for it and expect to fight hard to get it approved. Politically, the most difficult situation on technical projects arises from the changes requested by sponsors and management. While it is never easy to say "no" to the people you work for, the existence of a documented process that has been approved to manage project change is a vital initial step, and clear, data-supported descriptions of the consequences of requested changes are also crucial. As with risk management generally, managing change risk effectively relies on thorough, credible project planning data.

Disposition

For each potential change, you have four options: approval, approval with modification, rejection, and deferral. The process for making a decision on each change request uses the results from the analysis and documented information on project objectives and priorities to make a business decision. The primary criterion for the decision is generally the assessment of benefits versus costs, weighing the relative advantages and disadvantages of each change. The process for this may be relatively informal, taken up during regular project meetings as a part of normal business (with all required analysis done in advance, not during the meeting), or part of formal meetings periodically convened specifically to consider changes. The level of formality scales with the project, but two aspects of the decision process are universal. The first requirement is to make decisions promptly. Change requests, particularly those that address problems, need quick attention. The value of a change can diminish significantly as it sits, so ensure that all changes are considered and closed without undue delay, generally within a week. The second need is for consistent adherence to agreed-upon requirements for decisions. Some change systems are based on approval by a majority of those involved; some require unanimity; and still others grant veto powers to some approvers who have greater authority. Effective change systems avoid having too many approvers, in order to minimize scheduling problems and shorten debate, and they provide for alternate approvers whenever a designated approver is not available.

You should always begin with the presumption that changes are unnecessary and reject all changes that lack a compelling, credible business basis. Even for changes that have some benefits, carefully examine them to determine whether some parts of the change are not needed or whether the change might be deferred to a later project. Seek substantial credible net benefits even for changes you decide to approve with modifications or to defer. Approval and acceptance of changes should be relatively rare and reserved for the most compelling requirements for problem solving or other significant business needs. The more a project is subject to change, the higher the risk. Whatever the decision, close out all requests quickly, within the documented time goals established for the process. Also, promptly escalate any issues or conflicts that cannot be resolved at the project level.

Communicate the Decision

As each decision is made, you need to document it in writing. Include the rationale for the decision and a brief description of any project impact. Prepare a summary of the pending, accepted, and rejected change proposals for the project archive, and distribute the summary to project stakeholders and to your project team members. Also, consider any people impacted by the change who are not in your normal distribution for project information, and communicate the change status to them.

Whenever a change is not approved, respond to the submitter with an explanation, including the rationale for the decision. If there is a specific process for appeal and reconsideration, provide this information to the submitter as well.

Update all relevant project documents—the WBS, estimates, schedules, specifications and other scope documents, the project plan, charts, or any other project documents that an approved change affects. Distribute new versions to holders of original documents, and mark all earlier versions as obsolete. If documents are centrally stored in electronic form, replace them, and move the older versions to the project archive or clearly identify them as noncurrent.

Even for rejected changes, retain the proposals in the project archives. The "good ideas" may be worthy of consideration in follow-on projects or in a parallel projects. When your project is over, you can use the change history to reduce risk on future projects by carefully reviewing the process and the decisions made.

Key Ideas for Managing Project Risk

Panama Canal Adjusting the Objective (1907)

Setting a concrete objective for a project is not necessarily a quick, easy process. In the case of the Panama Canal, although Theodore Roosevelt made the decision to build the canal and the Senate approved the commitment early in 1904, the specifics of exactly what sort of canal would be built were still not settled nearly two years later. All the data accumulated by John Stevens led him to the same conclusion ultimately reached by the French engineers—building a sea-level canal at Panama would be very difficult, if not impossible. He estimated that a lock-and-dam canal could be completed in nine years, possibly eight. A sea-level canal would require a minimum of eighteen years. He convinced Theodore Roosevelt of this, and he thought the matter was settled.

This, however, was not the case. In spite of the French experience, the lock-and-dam versus sea-level debate was still going strong in the U.S. Senate in 1906. Showing much of the same diligence and intelligence one might expect today, the Senate, with responsibility to oversee the canal project, took a vote on how to build the canal. By one vote, they approved a sea-level canal. One unavoidable observation from study of past projects is that things really do not change very much over time, and politics is rarely driven by logic.

John Stevens had just returned to Panama from Washington in 1906, and, although he was quite busy with the project, he turned around and sailed back to the United States. He met extensively with members of both the U.S. House of Representatives and the Senate. He patiently explained the challenges of a sea-level canal in a rain forest with flooding rivers. He developed data, drew maps, and generally described to anyone who would listen all the reasons why the canal could not be built at sea level. As was true earlier for the French, the main obstacle was the flooding of the Chagres River, which flows north into the Gulf of Mexico parallel to the proposed canal for nearly half of its route.

Stevens spent a lot of time with one ally, Senator Philander Knox. Senator Knox was from Pennsylvania—specifically, he was from Pittsburgh, Pennsylvania. Stevens worked with Knox on a speech in which the senator described in detail why the canal had to be constructed with dams and locks. By all reports, it was an excellent speech, delivered with great eloquence and vigor. (It was probably not entirely a coincidence that a sea-level canal required none of the locks, steel doors, and other hardware that would come from Senator Knox's friends in the foremost steel-producing city in the Americas.)

Despite of all this, there were still thirty-one senators who voted for a sea-level canal. Fortunately for the project and for Stevens, there were thirty-seven senators who were paying attention, and the design Stevens recommended was approved.

It had taken him more than a year, but finally John Stevens had his plan completed and approved. Defending the feasible plan required all of his data, principled negotiation, and a great deal of perseverance, but he ultimately avoided the costly disaster of a second failed canal project at Panama.

Related

Категории