Chapter 6
Managing Project Constraints and Documenting Risks
“A good plan, violently executed right now, is better
than the perfect plan executed next week.”
—GENERAL GEORGE S. PATTON
Reviewing a plan to detect problems and make improvements generally ought to be a brief exercise done toward the end of initial project planning. This chapter is not about obsessive application of every single project management practice in an endless quest for the flawless plan (sometimes called “analysis-paralysis”). The topic here is realistic, common-sense project analysis. The principal objective of reviewing the plan is to find defects and omissions, deal with unmet constraints, and seek an improved plan, quickly. You are not after a perfect plan, just the best one possible using what you currently know about your project.
This part of the planning process relates to risk management in several ways, but two aspects are particularly important. First, the process of replanning to deal with constraints will nearly always create project risk—self-inflicted risk—as minimizing one parameter of a project often leads to more pressure on other aspects of the work, creating additional exposures, failure modes, and potential problems. These new risks result from trade-offs made by the project team, and they need to be recognized, documented, and added to the project risk list. A second type of project risk is that of not taking on the “right” project. All projects have alternatives, and examining at least some of these options is key to opportunity management, also discussed in this chapter.
Analyzing Constraints
As you proceed through preliminary project definition and planning, a coherent picture of your project starts to emerge. Although your project plan is still incomplete at this point, it does begin to provide insight into whether the project objective is possible or not. Often, it reveals the unpleasant fact that the project (at least as defined so far) is impossible, or at least overconstrained; the result of your bottom-up plan leaves at least part of the project objective unmet. Your preliminary analysis might reveal a schedule that extends beyond the deadline, resource requirements that exceed initial budgets, or other significant issues. Your planning process reveals just how much trouble you are in.
Failure of the preliminary plan to meet the overall project objective is not the only issue that emerges at this stage of planning. Above and beyond the high-level constraints, most projects also have other constraints that you must manage. Timing requirements for intermediate documents, prototypes, and other midproject deliverables may mandate fixed-date milestones within the project plan. The profile of available resources may be interrupted at specific times by the business cycle, by holidays and vacations, or by higher-priority projects. In addition, projects undertaken in lean organizations (where keeping everyone busy all the time in the name of efficiency is a top priority) will frequently run into a queue when access to a critical, unique resource is required. Delays for contract approvals, management sign-off, and other decisions are common. Identifying and managing risks from these other constraints is also part of risk management on high-tech projects.
Your primary goal in managing project constraints is to remove, or at least minimize, the differences between the project objective and your project plan, in terms of scope, schedule, and resources. The standard triangle diagram for examining project trade-offs is one way to show these differences, as in Figure 6-1. The plan, represented by the triangle with the dashed-line edges, is quite a bit larger than the objective, shown as the solid-edged triangle.
For this project, the initial plan suggests that the deliverable is probably feasible, so this project is not literally impossible—its scope is within your capabilities. However, as shown, the project will require both more time and more resources (people, money, etc.) than requested in the project objective, so based on the current plan, it is not feasible because of its constraints. For projects where the scope is plausible, the situation in Figure 6-1 is fairly common. Bottom-up project planning begins with a work breakdown structure (WBS) that is consistent with the desired scope, but the initial schedule and resource plans fall wherever the WBS leads them—often at significant variance with the project objective.
Figure 6-1. Objective versus plan.
For some projects, the objective is firm, based on hard limits that cannot be modified. For other projects, the objective may be based on softer constraints, goals that are desirable but not absolutely necessary. Each project is unique, so determining how to approach trade-off analysis for your project requires you to understand what the constraints and priorities are, and how they were determined. In the simplest form, project priorities boil down to the old saying, “Good, fast, cheap: Pick two.” Every project requires at least one degree of freedom. Because of this, it is unrealistic to nail down all aspects of a project prior to completing a thorough analysis of the required work.
Any of the three parameters could be most flexible, but one of them must be. Although you can get a deliverable out of a project quickly and cheaply, it may fail to meet the need. This lesson was re-learned quite often in the late 1990s by projects executed in Internet time, as well as by NASA on several failed Mars missions. Similarly, excellent results are often possible in short time frames, but the cost of this compression is high and may not be justified by the result (“crashing” project activities in the project schedule is covered later in this chapter). You may even be able to deliver good results at low cost in projects where time is not limited (though this scenario could result in the “analysis-paralysis” mentioned earlier).
A slightly more sophisticated analysis rests on prioritizing the triple constraint. Rank-ordering scope, schedule, and resources shows which of the three is most important for your project. A simple three-by-three grid is often used for this, as in Figure 6-2.
Figure 6-2. Project priority matrix.
The project priorities shown here are common for high-tech projects, as timing dominates more and more of the work. In contract work, deadlines with financial penalties are often looming. In product development, pressure from competitors, trade show schedules, and other real constraints on timing are often at issue. Even in application development, delivery often must synchronize with fiscal accounting periods. Schedule in all these cases is the dominant priority, and failure to meet the project deadline will have significant, possibly dire consequences. Schedule is the parameter such projects constrain.
In Figure 6-2, the second priority is resources. This is also common, as the desire to minimize resources and execute as efficiently as possible is a key goal for many projects. In fact, many projects face significant limits on competent, available staff. In the time frame of many technical projects, the number of available people who are familiar with new or evolving technologies is fixed and can only increase gradually over time through training, mentoring, and other methods for hauling people up the learning curve. Projects such as this strive to optimize their resources.
The largest degree of freedom for the project in Figure 6-2 is for scope, indicating that there may be aspects or specifications set in the objective that, although desirable, may not be absolutely required. The project will accept small changes to the deliverable, particularly if not making the changes would require more time, more resources, or both. This prioritization is one of six possibilities, and good examples for each of the other five are easily imagined. Though all prioritizations are possible, today’s technical projects frequently converge on “schedule/resources/scope,” as in Figure 6-2.
For the example in Figure 6-1, the initial plan failed to meet the deadline and also was over budget. Doing some “what if” analysis, you may discover a way to use a top-notch group of consultants (with a credible track record) to perform more work in parallel, shortening the overall project. This approach will not be inexpensive; it makes the budget problem even bigger, and results in the shift shown in Figure 6-3. In this figure, the schedule has been compressed, bringing it in line with the objective, but the resources required for the project, which already exceeded the objective, are even farther out of line with the project expectations.
For projects where resources are the lowest priority, this tactic may be a good alternative. For projects with the priorities in Figure 6-2, however, this is not likely to be the best plan. It may be better to reevaluate the specifications and propose a plan that achieves its deadline within budget but falls slightly short on scope. Some projects may find some of the requested requirements are not actually needed. Other projects may propose delivering the most valuable functionality on time, and delivering the rest in a follow-on project somewhat later. The analysis for such a scope reduction might result in a shift similar to Figure 6-4.
In this case, changes proposed to the initial plan affect all three of the project parameters, with the most significant difference between the objective and the plan being a small reduction in the feature set for the deliverable.
Figure 6-4. Seeking the “best” plan.
The overall objective of the plan review and “what if” analysis is to discover the options available as alternatives to the initial plan, and to see whether it might be desirable, or even necessary, to revisit the project objective and change the project definition. This triangle model can be thought of as a representation of projects in a two-dimensional state space, and the exploration of plan alternatives will reveal where in this space you can find realistic, feasible projects. For particularly ill-conceived projects, the analysis may fail to turn up any options close to the original objective. For such projects, you need to negotiate a major change to the objective, abandon the project, or at least think about updating your résumé.
In most cases, though, reasonable alternatives for your project are not difficult to find. Start your analysis of the project plan with the parameter that has the lowest priority, and explore possible changes related to that aspect of the project. These modifications are generally the easiest to negotiate, so it makes sense to focus first on that side of the triangle. For most projects, you will also want to examine alternatives for the other two parameters. The next sections describe using this “what if” technique for exploring project opportunities, and then for options related to scope, resources, and schedule (following the prioritization in Figure 6-2).
Managing Opportunities
When your preliminary plan falls short of the project objective, it might seem inappropriate to analyze opportunities, because this might make things worse. There are a number of good reasons for exploring these project options, though, and they relate directly to risk management. Where risk management seeks to understand what might go badly in a project, opportunity management looks for what might go better. In particular, opportunity management asks what similar, but superior, projects might be possible. Realizing halfway through the work that you could have achieved a more valuable result is not useful. It’s too late at that point on most projects to do anything about it. Opportunity management also may result in a more interesting, more motivating project that can increase teamwork and provide development opportunities valued by contributors. Mostly, however, it helps to ensure that you are not working on the wrong project. As with risks, a good starting point for opportunity management is the triple constraint of scope, schedule, and resources.
Scope
Deliverables for high-tech projects are set using two kinds of input, user/market demand and technological possibilities. Most project work relies primarily on the first. The sponsors, economic buyers, managers, and others who get projects started are generally doing so to meet a need, solve a problem, or respond to some specific request. Although this may be sufficient, the requested deliverables in high-tech projects can fall well short of what is possible. Technology moves fairly quickly, so user requests may represent continued use of an older technology even after emerging new ideas and approaches are available. If you were collecting specifications for a project deliverable from people sitting on a river bank washing their clothes with two large stones, their requirements would probably involve developing lighter rocks. The concept of a washing machine might not occur to them if the technology is not part of their experience. Similarly, the project team may be able to see possibilities based on technology unknown to the users that would solve the problem or meet the need much more effectively than the original request. Opportunity management is about merging a deep understanding of user needs with the technical capabilities available to create the best deliverable—not necessarily the one initially envisioned.
Scope opportunity management often requires a counterproposal to the original objective, and may involve negotiation. Some project leaders for high-tech projects go to great effort to avoid this sort of confrontation, viewing it as unpleasant and usually unproductive. This is unfortunate, because this process represents one of the real sources of power and influence that the project leader has. There is an old saying, “If you are going to lose an argument, change the subject.” Proposing an alternative that is demonstrably superior to the requested deliverable can effectively “change the subject,” avoiding an otherwise doomed project by substituting a better, more realistic one.
The main motivation for opportunity management, though, is to increase the business value of the project. There are a number of ways to approach this. Surveying the current state of relevant and closely related technologies is a typical starting point. It may be that a new generation of hardware is available that could effectively be used. New technologies or methods may provide greater speed or reliability. New or existing standards may have application to your work, which could extend the possible uses of the deliverable, both in the current project and for future applications. It might be possible to develop a deliverable with capabilities that solve a whole class of problems instead of the single one that triggered the project. Conversely, it may be possible to break up an ambitious project into shorter stages, developing something that provides tangible value (perhaps most of what is actually needed) for a fraction of the time and cost that the entire project would require.
Resources
Explore options for efficiency or schedule reduction through the use of additional, more highly skilled, or outside contributors. If improvements to your tools, systems, or other aspects of your infrastructure will help performance, propose changes. Gain access to and use the best available facilities and methods for communications. Bringing distributed teams together and arranging other face-to-face collaborations may significantly boost progress and teamwork. If so, obtain funding for necessary travel. If additional training for contributors will help the project, schedule it.
If there are team members who have underallocated time during parts of the project, consider replanning to more effectively use the effort available (though this will add less resource reserve and increase potential failure modes).
Schedule
Schedule opportunities include revising the schedule to exploit float, revising logical dependencies, and “crashing” activities. Seek valid shortcuts and better, newer methods for the work. Although each of these can reduce the schedule, each also tends to increase risk. These concepts are discussed in the section on schedule modifications.
Some project leaders list opportunities with risks and assess them together using the processes outlined in Chapter 7. Although opportunities and risks are related, they are not exactly “opposites.” Most people think of risks as threats, and the choice of whether to manage them or not is primarily the responsibility of the project team. Unmanaged risks that do occur are unquestionably going to be seen as the responsibility of the team.
Opportunities are not symmetric with risks. Adopting them, particularly when they involve significant scope changes, is not generally up to the project team, so proposals and approvals are part of the process. The consequences are not really symmetric either. It’s often said, “Success has many fathers, while failure is an orphan.” When things go better than expected, everyone takes credit—especially the managers. When things go badly, the project team will be left standing alone.
Opportunities that significantly change the project require sponsor support, and acceptance of them is nearly always more complex than the risk assessment process described in Chapter 7. Opportunities that do not represent substantial shifts to the overall project objective (including much of what follows in this chapter) mostly fall into the category of “good project planning.” Some of the opportunities you uncover may reduce project risk, while others may increase it. Include all opportunities that you plan to consider, and note their effects on your risk list.
Scope Modification
Proposed changes to the project deliverable may be easily accepted, absolutely nonnegotiable, or anything in between. This depends on the project, the sponsors and users, and the type and magnitude of the change. Whatever the circumstances, a conscientious project team will spend at least a little time examining the effect on the project of adjusting the project deliverable. This “what if” exercise helps your team understand the work better and provides you with valuable information for decision making.
To meet project constraints, many projects will end up trimming scope. Before deciding what features or aspects of the project deliverable to drop or change, determine which requirements are absolute “must have” features, and which (if any) are more expendable. There are several techniques for prioritizing requirements. The simplest is to list the requirements and sort them into a sequence where the most essential ones are at the top of the list and the least important ones fall to the bottom. “Is/is not” analysis, described in Chapter 3, is another possible starting point. You will need to revisit the list of items on the “is” list to validate that each requirement is in fact essential. Determining what portions of scope can be demoted to the “is not” list effectively limits scope. This is particularly useful for projects that have hard limits on timing and budget; the “is/is not” technique establishes a firm boundary for scope that is consistent with the other limits.
The purpose of the exercise, however you approach it, is to capture and document the specifications that you must deliver, separating them from the portions of the requested deliverable that are desirable but not absolutely necessary. Accepting small decreases in reliability or performance may cause a significant reduction in project time and cost, and such trade-offs may result in a project that better meets its overall goals.
Project scope requirements are easiest to change early. Late changes are often painful and expensive, resulting in work that would have been unnecessary had the change been made earlier. Freezing scope early does not mean that project scope will never shift; it just means that any modifications will be subject to analysis and change control before being accepted. Determining the lowest-value features and requirements allows you to intelligently determine what to exclude (either permanently, or to be part of a follow-on project).
Resource Modification
Revisiting the resource plan also can lead to an overall plan that better fits the objective. Alternative approaches to staffing, cross-training, outsourcing, and other elements of the resource plan are all potentially useful options.
Resource Analysis
For some projects, there may be ways to get work done faster without increasing the overall required resources. One possibility is to rearrange the work assignments to use available staffing more fully and effectively. Schedules may be too long because of nonproject commitments. If the external work can be postponed or eliminated, it could have a significant impact on your schedule. You may also be able to find ways to improve the effectiveness of the project team by simply asking individuals what they need to work faster. Many people get more work done through telecommuting, working at times when they are more efficient, or being in a different work environment. Unless you ask, these possibilities will remain hidden.
You may even be able to minimize distractions and noise during some or most of the project through moving work off-site, collocating the team in a closed-off area, or relocating to space that is out of normal foot-traffic areas. One project team I worked with attributed much of their on-schedule performance to their location in a trailer (while new buildings were being completed). It was quiet there, and no one dropped by to visit.
Training Additional Staff
Another tactic that can potentially help the schedule as well as mitigate a source of project risk is mentoring and cross-training. Project timelines are often longer than theoretically necessary on high-tech projects because only one person knows how to do some part of the work. These activities must be scheduled in sequence, queued up for the expert. Work can be speeded up if others on the staff have an interest in this area of expertise and can be trained to take on activities in parallel. Of course, people new to a discipline will rarely work as fast as experienced staff. Duration estimates for activities assigned to them will generally be longer, due to training requirements and lower work efficiency. Activities assigned to the current expert will also take somewhat longer, because of the required mentoring. Despite this, the benefits to the schedule in getting the work done concurrently can be substantial. In addition, the project risk profile will improve, as the project will no longer be dependent on a single person. If the expert becomes unavailable to your project (because of illness, higher priority work, resignation, or any other reason), your project will not grind to a halt but can continue (although more slowly) using the newly trained staff.
Staffing Alternatives
For projects where schedule is much more important than budget, subcontracting work to outside service providers might speed things up, providing that a larger staff can work in parallel on activities that are currently planned in sequence. If the project priority is high, more staff from within the organization may also be an option. Some projects cannot run as quickly as theoretically possible because the experience and talent available on the original project team is low, so it is useful to explore the possibility of finding staff who are more efficient or who do not require any training before taking on project activities. Additional resources of other types, such as faster computers, newer equipment for test and other work, or systems to automate manual activities, can also potentially help to compress the project. New work methods require training and practice, but may still represent options for saving time. All of this will raise the resource cost of the project, but for some projects this trade-off may be justified.
Schedule Modification
Reexamining the schedule also provides alternative projects. Some ideas to consider include using float, revising activity dependencies, and “crashing” the schedule.
Using Float
One simple approach for shortening your project involves reducing the amount of float on noncritical activities. Float is derived from the critical path analysis of the schedule (discussed in Chapter 4), and it measures how much an activity can slip without impact to the project deadline.
To shorten your project using float, you shift some of the work on critical path activities to staff assigned to noncritical activities. These staffing shifts will cause changes to noncritical activities (such as delaying the start, interrupting the activity, or reducing productivity), but as long as the activities retain some float, the additional effort on the critical activities can shorten the project. Bear in mind that this sort of schedule compression comes with a price. Using all (or nearly all) of the float for an activity makes it more critical. This increases project risk by creating new failure modes.
Revising Activity Dependencies
A second, more elaborate idea involves revising activity dependencies. Here, the schedule is shortened through rearranging or redefining the work. The simplest possibility is to inspect the dependencies linking critical path activities, looking for opportunities to shorten the schedule using a more compact logical work flow.
If revising activity sequences is ineffective, you can reexamine the activities and brainstorm alternate ways to approach longer activities on the critical path by using a different breakdown or a completely new approach. This second method often involves breaking critical path activities down further to create smaller activities that can be executed in parallel, as in Figure 6-5.
This concept has a variety of names, including concurrent engineering, “fast tracking,” and simultaneous development. For parallel execution to be effective, there are at least two requirements. First, you need to allow integration time in the estimates for the parallel activities, or define a new activity (as in Figure 6-5) during which all the separately developed components are assembled. The second requirement is often less visible, but it is even more important. Detailed up-front analysis is essential to ensure that the integration works. All the connections, interfaces, and relationships between the independently developed activity deliverables must be defined and thoroughly documented. Whatever this work is called—architecting, systems engineering, or something else—doing it well will be the difference between components that mesh properly and integration efforts that fail. When the system decomposition is done poorly, integration activities can consume all the time you expected to save, and more. Even worse, it may fail utterly, resulting in components that are completely unusable. Before committing to a plan that uses independent parallel development, explicitly identify when and by whom this analysis will be done, and note the integration risks on your project risk list.
Figure 6-5. Converting activities to parallel execution.
Another approach for schedule compression through revising activity dependencies involves overlap of the work. In the plan, there may be finish-to-start dependencies on the critical path that can be converted to start-to-start dependencies with lags.
In Figure 6-6, the preliminary project plan includes a design activity scheduled for three weeks followed by a coding activity scheduled for four weeks. After thinking about it, the project team may decide that it would be possible to begin coding after only two weeks of design, because there will be enough information to start programming for some of the modules at that point, and staffing will be available to get going. Although it may seem that converting a finish-to-start dependency to start-to-start dependency with a lag of two weeks would save one week on the schedule, this is overly optimistic. There is an increased likelihood of rework or discovery of something unexpected in the final week of design, so when you elect to make this sort of change, increase your duration estimates for any activities that you choose to begin early (in this case, about two days have been added to the coding activity), and also explicitly note the new risk.
Figure 6-6. Modifying activity dependencies.
“Crashing” the Schedule
An additional scheduling technique, common on projects with extreme schedule pressure, is “crashing.” In this sense, crashing means applying additional resources to gain speed—as in a crash program. Not all activities can be crashed. It is not possible to crash activities where one person must do all the work, activities that cannot be partitioned, or activities with time constraints you do not control. A good example of an uncrashable activity is sailing a ship from New York to London. With one ship, it takes five days. With five ships, it still takes five days.
Even when crashing helps, it adds both additional cost and new risks to projects. If an activity is efficiently executed by a team of three people, a team of six will rarely be able to do it in half the time. Involving more people requires extra communication, overhead, and complexity, so resources and time do not vary linearly. This has been observed and documented for all types of projects for a long time, but the best discussion of this for high-tech projects remains The Mythical Man-Month, by Fred Brooks. Brooks covers in detail how people get in each other’s way and how inefficiencies grow as the number of people working on a project increases. As efficiency drops, project risk increases because of the larger staff, potential confusion, work methods, and general complexity.
For all this, when time is critical to your project, these trade-offs may be justified. Crashing a project schedule requires you to locate the activities that can be shortened, and to estimate for each what the impact of compression will be, particularly on the project budget. Experienced project leaders usually have a good sense of how to do project work efficiently, so initial plans are generally built using assumptions for staffing and work methods that minimize effort and cost. For any given activity, though, other combinations of staffing and duration may be possible. One person working alone on an activity might take a long time; two working together could take quite a bit less. Adding more people will, for some activities, continue to reduce the activity duration even more. Eventually, though, you reach a point of diminishing returns, where adding more staff makes a negligible difference in the activity duration. A curve describing the relationship between staffing and time has a bend in it at that point, giving it an “L” shape, similar to the curve in Figure 6-7.
For any given activity, there is also a minimum possible duration; no amount of additional staffing, money, or other tactics will allow you to do the work in less time.
Because the initial estimates tend to be near the bend in the curve (where the cost is minimized), shortening projects by crashing can be quite expensive. Strategies for compressing projects by crashing begin by seeking a number of ideas, more than may be needed to meet the project deadline. Examine the schedule for activities that could be crashed, expedited, or otherwise changed in ways that could shorten the project, initially focusing on the critical path(s). Ideas for each activity can then be considered in turn and assessed for both effectiveness and cost.
Figure 6-7. Trade-off between effort and time.
If the next priority after schedule is resource, you will first adopt the strategies that have the least impact to the project budget. This will require you to estimate the “cost penalty” for each idea. The usual way to do this is to calculate the cost per time (usually per day) associated with the schedule reduction. For example, one idea might be to shorten a development activity, initially estimated to take fifteen work days and consume $4,000 of effort. You believe that this could be reduced to eleven days, saving four, if you bring in an outside contractor to help for a week at a rate of $6,000. Both the initial and compressed approaches to this activity are indicated in Figure 6-8, and the slope of the dotted line connecting them, $1,500 per day, defines the cost penalty for schedule compression.
Ideas for schedule compression can come from a variety of sources. The project team can brainstorm, you can consult peers or experts, or you can research what similar past projects did when they ran into trouble and were forced to work faster. In addition to providing a potentially rich source of ideas, project recovery information may offer data on costs and describe the work that will be required.
Typical methods that may prove effective in shortening project activity durations (for a price) include:
• Adding staff
• Paying for overtime
Figure 6-8. Estimates for crashed activity.
• Hiring outside staff to help or outsourcing whole project activities
• Paying to expedite shipping or other services
• Upgrading or replacing slower equipment
• Spreading work over more shifts
For each crashable activity idea you develop, estimate the total cost involved and assess the cost penalty—the expense for each day of schedule improvement—so you can arrange the ideas from least costly to most expensive, per day. Starting with the least costly strategies, make schedule changes affecting critical activities and note the cost of the additional resources. For each modification considered, check that the change does in fact provide a schedule improvement, and monitor for noncritical path activities that become critical. You can continue the process, crashing activities until it is no longer necessary, or is not possible.
Any schedule compression ideas that you do not use can be held in reserve as possible contingency plans for your project. (Contingency planning is discussed in detail in Chapter 8.) An alternative to adopting tactics for shortening the project based on cost takes this concept an additional step. Ideas for crashing can be useful as contingency plans only if they relate to future portions of the project. To maximize the potential utility of any crashing tactics you have developed, you might choose to apply them based on timing. If you start with the ideas that shorten the project by acting on the earliest activities, any leftover tactics will remain available as contingency plans. Although this will generally cost more, it will result in a more resilient plan.
Before leaving the topic of schedule changes, it’s worth noting that a compressed schedule has a lot more failure modes and will generate a good deal more stress for the project. The trade-offs between time and cost and time and scope are visible throughout the process of managing project constraints. The trade-off between time and risk is more subtle, but nonetheless real. At the conclusion of this process, document any changes you made and list all the new risks introduced to your project plan, including the new critical and near-critical paths. Also be aware of the increased overall project risk contributed by the added complexity and stress.
Assessing Options and Updating Plans
After investigating possible scope, resource, and schedule changes, you have the information you need to assess your options and seek the plan that best meets the project objective. Your analysis may result in a credible project plan (including a detailed project schedule, resource plan, and description of major project deliverables) that supports the project objective and any other significant constraints. If so, your next step is risk analysis.
If the “best” plan you can develop is still far from the objective, it is evidence that you have an overconstrained project. In such a case, use your “what if” analysis of scope, schedule, and resource combinations and develop at least two additional plans that achieve slightly different project objectives, such as:
• Fewer resources needed, but longer schedule or reduced scope
• Increased scope (with higher demonstrable value), but more time or resources required
• Shorter schedule, but more resources needed (or scope reduced)
For each option, document relative advantages and risks. These alternative plans can be used in discussions and negotiations. (Negotiating project objective changes is a key topic of Chapter 10.)
Incorporate any plan changes that you are empowered to make into your preliminary schedule and other project documents. If you developed alternative plans, document them as well, with any proposed changes or opportunities that would require higher-level approval.
Seeking Missing Risks
Your list of project risks grows throughout the defining and planning processes, as noted in the preceding chapters. Although you have collected risk data throughout the planning of project work, it is useful to review your scope definition, preliminary schedule, and resource plan, using the ideas in Chapters 3 through 5. You may also want to review the selected risks from the PERIL database listed in the Appendix to further stimulate discovery of project risks. There are also a number of additional methods for detecting potential problems and risks.
Brainstorming
One powerful risk discovery process is brainstorming. With the project team, review the risk list that you have already constructed. Work together to brainstorm additional potential project problems. Examine the methods and processes you intend to use and consider any aspects that are new or that will be particularly difficult. Think about risk that would arise as a consequence of any organizational changes that are rumored or seem likely. Finally, focus on outside factors that might have an impact on your project, such as natural disasters, weather, government or legal changes, and actions of competitors.
Capture every idea without comment, questions, or criticism. Stimulate people to think of new risks triggered by the thoughts of others. List every risk that is mentioned, even those you think you can do nothing about. Keep the brainstorming going, striving to hear from every member of the project team, until the flow of ideas seems at an end. Conclude the process by restating any risks that are unclear, combining or eliminating risks where there is redundancy. Add all the new risks to the project risk list.
Retrospective Analysis
A second idea for finding risks in a new project is retrospective analysis of earlier projects. The old adage “Lightning never strikes twice in the same place” is demonstrably false; lightning strikes the same spot hundreds of times, always the highest place with the best electrical connection to the ground. (If this were not the case, lightning rods would not work.) On projects, the analogous statement “That can never happen again” is equally untrue. Risks tend to recur in project after project, unless you understand the root cause and do something differently to avoid the problem. Data from earlier work (in the form of project retrospectives, lessons learned, postmortems, postproject analyses, or close-out reports) is a rich source of risk information.
These reports generally contain two types of data useful for risk management: effective practices worth repeating and areas where improvement is possible. In the area of good practices, seek specific ideas from what was done well, practices to repeat or extend, and specific significant accomplishments. Examine your plan to see whether you are incorporating opportunities to take full advantage of known good practices. In the realm of things that did not go well, review previous project data for problems, assumptions, poor estimates, actual beginnings and ends of major activities compared to plans, complexity of activities undertaken, number of changes proposed and accepted, sources of delay, and other issues. Identify any aspects that impacted progress.
Scenario Analysis
Additional risks may come to light through scenario analysis. Discuss situations expected along the project timeline, step-by-step, asking questions such as, “What might go wrong here?” and “What will be keeping me up at night during this portion of the work?” You can close your eyes and “play a movie in your head” to gain insight into the project’s work and the problems it may be exposed to. Techniques familiar to software development organizations such as inspections and structured walk-throughs may also be applied to the project plan to reveal weaknesses, omissions, and risks. As you think through project scenarios, test the project assumptions to uncover any that might change.
SWOT Analysis
A similar approach to scenario analysis is “Strengths, Weaknesses, Opportunities, and Threats” (SWOT) analysis. For many projects, particularly those involving delivering solutions, these aspects are examined early in the project. As the project planning process approaches closure, you should revisit both the identified weaknesses and threats for the project to ensure that any that have not been addressed in your planning are noted as risks.
Assumptions Analysis
Also related to scenario analysis is review of your assumptions. As you proceed with your project planning, assumptions analysis will show where initial expectations are no longer valid or could result in possible project failure modes.
Expert Interviews
Risk discovery sources outside your project can also be useful. Expert interviews both inside and outside of your organization can be a potentially rich source of information on risks that your project may encounter. Utilizing the experiences and perspectives of others is a potent technique for identifying and managing risks.
Root-Cause Analysis
Finally, root-cause analysis or “cause-and-effect” exercises may be used for risk discovery. Risk management requires knowledge of the root causes that lead to project problems. There are a number of effective techniques for discovering the sources of problems, and although they are most often applied retrospectively, they can also be used to examine future problems. These techniques include failure mode and effect analysis, fishbone diagrams, root-cause analysis, K-J analysis, or other varieties of cause-and-effect analysis. Using these processes to look for potential risks begins by stating an outcome the project intends to avoid—such as losing a key resource, delay in getting an important input, or significant increases in the cost of some portion of the project. The next step is to challenge the project team to work backward to uncover plausible sources that could cause the problem. In addition to uncovering specific risks that might not otherwise be detected, this exercise will often raise the perception of how probable certain problems are likely to be. Before the sources of trouble are articulated, most projects look fairly straightforward. After documenting the things that can contribute to project difficulty, you have a much more realistic view of the work, balancing the sometimes excessive optimism that is common early in a new project. Further discussion of root-cause analysis as a tool for managing risks is in Chapter 8.
Documenting the Risks
Every time you uncover a risk, write it down. Once all the risks identified have been added to the risk list, review the whole list in preparation for the next steps of analysis and assessment. For each listed risk, check that the description is clear, including a summary of the consequences. Specify the trigger event that signals the occurrence of the risk. For risks that are time-specific, also identify when in the project the risk is most likely to occur. The risk list with this added detail is also called a risk register.
Panama Canal: Improving the Plan (1906)
Many projects, viewed in retrospect, failed because they could not manage the work within mandated constraints. In reviving the Panama Canal project, a great deal of effort went into rethinking the approach to the work, to avoid the most significant issues that plagued the earlier project.
For projects of all types, it is beneficial to invest effort early, investigating whether there are better, faster, more efficient ways to do what is required. New technologies, methodologies, and approaches are born this way. Several key innovations were introduced in the U.S. canal project. Avoiding schedule and cost problems required changes to the equipment used and the methods employed to accomplish the work.
On the equipment side, twentieth-century technology made possible the huge, powerful steam shovels that gave the U.S. effort a big advantage over the earlier project. New technology also provided equipment suitable for use in the warm, damp, machine-destroying environment of Panama.
As important as the hardware was, however, the way the equipment was used made an even bigger difference. John Stevens, as a railroad engineer, saw the canal project as a railroad problem. To him, the canal was “the greatest of all triumphs in American railroad engineering.” To keep the huge shovels digging continuously, Stevens developed a system so that shovel loads could be dropped onto railroad flatcars that ran along track adjacent to the shovels. The flatcars circulated in large loops out to the dams and other places where these loads could be deposited. Once there, huge fixed scoops (similar to the fronts of enormous snowplows) cleaned off the flatcars for their return to the shovels, with no need to stop or pause at any point for this enormous conveyor belt. Using this arrangement and the much larger steam shovels, the U.S. project was soon excavating more in one day than the earlier French project had accomplished in a month.
This system would have been sufficient for the project if the shovels had been simply digging deep holes in one place, but they were not. As the digging proceeded, the shovels had to move, and so did the railroad tracks that carried the flatcars. For this, John Stevens developed an elaborate, elastic method for moving the track, providing a constant, steady stream of empty flatcars flowing by the steam shovels. With his system, twelve men could move almost two kilometers of track in a single day. Using conventional track-laying methods, 600 men would have had difficulty equaling this performance. As the construction continued, excavation in the Culebra Cut widened and deepened, so these methods were used at multiple levels. Each level had its own railroad loop, shovels, and crews. The total track moved in one year approached 2,000 kilometers. Without these innovations, the canal project would have taken years longer to complete and cost far more, and it might well have been abandoned before completion, like the earlier project.