Managing Project Constraints and Documenting Risks

Overview

"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, to deal with unmet constraints, and to 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 nearly always creates project 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.

Much of the content of this chapter falls into the "Project Time Management," "Project Risk Management," and "Project Integration Management" segments of the PMBOK Guide. The key risk management concepts covered in this chapter are:

• Constraint analysis
• Scope options and opportunity management
• Resource options
• Schedule options
• Assessment of plan alternatives
• Additional project risks

Analyze 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 most likely possible or impossible. Often, it reveals the unpleasant fact that the project (at least as defined so far) is impossible; 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.

Figure 6-1: Objective versus plan.

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 (e.g., people, money) than requested in the project objective, so, on the basis of the current plan, it is infeasible 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.

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; it is never realistic to nail down all aspects of a project, especially 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. While you can get a deliverable out of a project quickly and cheaply, it is unlikely to be very good. This lesson was relearned 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 very 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 very low cost in projects where time is not at issue (though this scenario could result in the "analysis-paralysis" mentioned earlier).

A slightly more sophisticated analysis rests on prioritizing the triple constraint, by rank-ordering scope, schedule, and resources to show which of the three is most important to your project. A simple three-by-three grid is often used to show 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, timing often dominates because of the need to synchronize with fiscal accounting periods, the release (or obsolescence) of software or hardware, and other time-critical requirements. 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 increase gradually over time only through training, mentoring, and other time-honored methods for hauling people up the learning curve. Projects such as this must do the best they can 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, while desirable, may not be absolutely required. The project will accept small changes to the deliverable, particularly if not making the changes would necessitate using more time, more resources, or both.

This prioritization is one of six possibilities, and examples for each of the other five are easily imagined. This particular example is sometimes referred to as the "Sunday newspaper" model, and projects with these priorities may be approached much the same way a newspaper editor manages the weekly project of publishing the Sunday edition. The top priority is time; the paper must be available on Sunday, the only day of the week for most people where such a large quantity of newsprint makes any sense. The next priority is resources; the permanent staff available to put out the paper varies little over short periods of time, and adding extra temporary staff involves high costs and may be unsatisfactory in any case. The highest degree of freedom is with scope, in this case content. If some planned article or feature is not ready when the paper is "put to bed" late on Saturday, as required by the printing and distribution processes, the choices are clear. Holding the paper or pouring on more resources to finish the work cannot be done. In some cases, an unfinished story is simply thrown away. In others, work continues so that it can be used when complete in a future edition, on Monday, or perhaps the following Sunday.

Increasingly, high-tech projects are adopting similar methods. Features are dropped from products being developed. Additional features and capabilities are phased into planned (and frequently adjusted) releases for system software products and for custom application solutions. Even major platform development programs are broken down into a sequence of smaller, evolutionary stages. This philosophy underpins many of the current "agile" software project methodologies, such as extreme programming (XP). Adjustments and adaptations in XP are made frequently, treating each development cycle as a small project with fixed timing and staffing.

While the stated highest priority for high-technology projects is generally schedule, resources are often equally, if not more, constrained. Lack of qualified staff may actually represent a more significant constraint for the project than the deadline. In any case, the point of setting priorities is to understand what matters to the project, and why.

In the example from Figure 6-1, the initial plan failed to meet the deadline and also was not within the 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 is not 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.

Figure 6-3: Plan trade-offs.

For projects where resources are the lowest priority, this tactic may be a good alternative. For projects with priorities like those of the Sunday newspaper, however, it is not likely to be the best plan. It may be better to reevaluate the specifications and to propose a plan that achieves its deadline within budget but falls slightly short on scope. Some projects may find requested requirements that 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.

Figure 6-4: Seeking the "best" plan.

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.

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 a project such as this, you need to negotiate a major change to the objective, abandon the project, or at least think about updating your resume.

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 three sections describe options for scope, then resources, and finally schedule (following the prioritization in Figure 6-2).

Scope Options and Opportunity Management

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, by both adding to the functionality and reducing it. This "what if" exercise helps your team understand the work better and provides you with valuable information for decision making.

Opportunity Management

When the preliminary plan falls short of the project objective, it may seem unnecessary to explore the effect of increasing the scope of the project. The reasons for examining more aggressive project options stem from opportunity management, which is closely related to, and supports, 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. Halfway through the work, realizing that you could have achieved a more valuable result is not very useful, because it is too late at that point on most projects to do anything about it.

Deliverables for high-tech projects are set using two kinds of input: user/market demand and technological possibilities. The source for most kinds of project work is 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. While this may be sufficient for some kinds of projects, the requested deliverables in high-tech projects may fall well short of what is possible. Technology moves fairly quickly, so the demand for project deliverables may represent continued use of an older technology even after emerging new ideas and approaches are available. If you requested specifications for a project deliverable from people sitting on a river bank washing their clothes with two large stones, their answer would probably involve developing lighter-weight rocks. The concept of a washing machine may not occur to them, as 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.

Opportunity management on projects includes two types of potential changes: to scope or to process. Scope opportunities involve adjustment to the features of the deliverable that are visible to anyone (a washing machine, for example, instead of two extremely light rocks). Process opportunities are not as visible, and they may have no impact on the feature set of the deliverable at all. Scope changes affect everyone, where process opportunities affect primarily the project team.

Scope opportunity management often requires a counter-proposal to the original objective and may involve negotiation. Some project leaders and teams on 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 team 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 a potentially doomed project by substituting a better, more realistic one. The new project may also be more motivating for the team and more fun to work on.

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, or expected during the project, that could effectively be incorporated into a system being developed. New technologies methods may provide greater speed or reliability. New or existing standards may have application to your work, which may 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 much of what is desired from the project) in a fraction of the time the entire project would require.

This approach may even provide new significant business opportunity to the project team. Some years ago, a team I was part of received a particularly incoherent Request for Proposal (RFP) from a large telecommunications company. Our initial reaction was to "no bid," as none of us could figure out what the customer was really asking for. Instead, we decided to counterpropose working with the customer (for a fee) to clean up the RFP and develop a specification that we, and others, could bid on. The company was highly offended by this counterproposal and told us so. As time went on, however, every company to whom it sent the RFP also declined to bid, and it did end up hiring us to structure a new RFP. The new RFP made a lot more sense (and it also included a few things that we could do better than most of our competitors).

Reuse and Leverage

Process opportunities are less visible on a project. Project teams can identify opportunities to develop methods or tools that will make work on the current, as well as future, projects faster and easier. Adopting new methods, current versions of computer-aided design and development tools, or industry standards may also lead to more efficient execution. Reuse and leverage also represent process opportunities.

The tactics of reuse (employing available components) and leverage (modifying available components) are both potentially effective ways to get project work done faster. Unfortunately, the approach used most of the time is retrospective, sifting through all the bits and pieces developed on earlier projects looking for things that might be used again. Usually, most of the code written, or hardware components built, has been quickly developed for a specific project, and it is not easily adapted to new work.

Reuse and leverage are most effective when viewed prospectively, looking forward from the current project to envision places where work can be made easier or more efficient on future projects. Examples of this include parts libraries, software objects, standard component modules, Web style sheets, and a wide range of other resources that can be readily employed to expedite work that is similar, or identical, on successive projects.

Opportunities for reuse and leverage are not limited to components and other deliverables produced by the project; other benefits come from by-products of project activities, such as tools, new techniques, or more efficient methodologies. If work can be reused or leveraged at least three times, the effort invested in generalizing (and documenting) it is probably justified. One opportunity for leverage specific to project management is development of plan templates. Project planning is much faster and more thorough when it starts with all the typical and required project activities already defined. Templates also save data entry time with computer tools. Your planning process still needs to define and list the activities unique to your project, but a template allows you to focus on what is different and saves a lot of time and effort.

Of course, prospective reuse and leverage opportunities are not free, and establishing them usually requires a larger investment in the current project, an investment that you expect will make future work easier and faster. In some cases, the resources and time required for these process investments may be easily incorporated into the project without significant change to the objective. In other cases, necessary changes to the project budget or timeline may require discussion and negotiation. Because the benefits of process opportunities are harder to measure and accrue mainly on future projects, selling your management on process improvement opportunities with significant costs will require extra effort.

Not all opportunities are worth pursuing. Before either accepting a small process opportunity or deciding to propose changes to scope or significant process opportunities, you should do some cost-benefit analysis. Estimate the expected value derived from the proposed changes, and then deduct the estimated incremental cost for those changes to the project. If an idea has a credible positive net value, it is probably worth considering. Even when the cost impact is too high, you will still know a lot more about the project as a result of the analysis, and you will also gain confidence that the objective you are working toward is likely the best available.

Trimming Scope

While opportunity analysis is useful and may reveal superior projects, for many projects the scope will end up shifting in the other direction. 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. More analytical tools for ranking and valuing release criteria and other requirements can be found in tools such as quality function deployment (QFD).

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 result in significant reduction in time and cost for the project, and such trade-offs may result in a project that better meets its overall goals. Other tactics to consider include using older technologies or methods to achieve functionality similar to the requested deliverable or avoiding custom-developed components in favor of purchased ones. These ideas might protect all or most of the specified scope while lowering cost and reducing the planned schedule, but each trade-off potentially introduces new risks to the project that you must note and manage.

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. From a risk management standpoint, the "is/is not" technique, discussed in Chapter 3, is the most effective technique. 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.

Defining scope using "is" and "is not" lists 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). It also provides you with limits on project deliverables early enough to support thorough planning and risk analysis.

Resource Options

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 identify any portions of the plan where project team members are not busy, rearranging the work to use their time more fully and effectively. Schedules may be too long due to nonproject commitments by your project staff. 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 in order to work faster. Many people get more work done through telecommuting, working at times when they are more efficient or in an atypical 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, co-locating 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 its on-schedule performance to its location in a trailer (while new buildings were being completed) where it was quiet 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 of the required activities. The work must be scheduled in sequence, queued up for the expert to do it. 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, and 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 as dependent on access to a single person. If the expert becomes unavailable to your project (due to 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 can speed things up whenever a larger effective staff can work in parallel on activities that are currently planned in sequence. If the project priority is high, adding staff from within the organization may be an option. Some projects cannot run as quickly as theoretically possible because the experience and talent available on the original project team are 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. If adding these people is not possible, propose exchanging staff with projects that the more capable people are working on, especially if your project has higher priority. Additional resources of other types can also potentially help to compress the project, such as faster computers, newer equipment for tests and other work, or systems to automate manual activities. 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 Options

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 (or slack) 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.

Figure 6-5: Converting activities to parallel execution.

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—it will make the difference between components that mesh properly and integration efforts that fail. When the system decomposition is not done well, the integration activity can consume the time you expected to save, or 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.

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 may 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, as there will be enough information to start programming for some of the modules at that point, and staffing will be available to get going. A word of warning, however, is necessary. 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. For actual projects this is overly optimistic, as there is an increased likelihood of rework or discovery of something unexpected in the final week of design. When you choose to make this sort of change, increase your duration estimates for all activities that you plan to begin early (in this case, adding about two days to the coding activity estimate), 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. Four additional ships are not useful in speeding the process of crossing the Atlantic Ocean.

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 due to 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.

Figure 6-7: Trade-off between effort and time.

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. A common strategy for compressing projects by crashing is to minimize the overall cost 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.

Normally, you will want to apply the strategies that have the least impact to the project budget, so you need 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.

Figure 6-8: Estimates for "crashed" activity.

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. Many effective ideas for crashing originate from actions taken in the past in response to some crisis or project disaster. While not all the actions taken midproject to solve problems are effective, sometimes people come up with great solutions that work. In addition to providing a potentially rich source of ideas, historical project information may also offer data on costs and outline 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
• Hiring outside help to augment staff
• Outsourcing whole project activities
• Paying to expedite shipping or services such as printing, testing, fabrication, or installation
• 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 that you can arrange the ideas from least costly to most expensive, per day. Starting with the least costly strategies, make schedule changes that affect 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.) At the conclusion of this process, document any changes you made, and note all the new risks and failure modes, including the new critical and near-critical paths, introduced to your project plan.

Assess Options and Update 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 not very close to the objective, it is evidence that you have a failure-prone project. In this case, you should examine 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 to focus the discussions and decision making for the project on facts and possibilities, rather than on politics and emotions. The key to managing projects that will fail because of excessive constraints is fact-based, principled negotiation. (Negotiation of plan-based objectives 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 they would require that need higher-level approval.

Seek Missing Risks

Your list of project risks grows throughout the defining and planning processes, as noted in the preceding chapters. As your preliminary plans near completion, review them for undetected risks and consider additional risk sources.

Review Your Plans

Although you have collected risk data throughout the planning of project work, it is useful to review your scope definition for any other risks that could arise from:

• Required use of new technology and other feasibility issues
• External sourcing for a key subcomponent, utility, or tool
• Levels of technical complexity significantly higher than those in past projects
• Unclear aspects of product definition
• Inconsistent specifications
• Potential for excessive requirement changes
• Unfamiliar or inappropriate development tools or methods
• Extreme quality or reliability requirements
• Poorly defined acceptance or testing criteria
• Loss of proprietary information.
• A large number of activities

Also review your preliminary schedule, checking for unlisted risks relating to:

• Very large worst-case (or pessimistic "PERT") estimates
• Long-duration activities
• All activities that lie on or near a critical path
• Multiple critical paths
• Compressed or "crashed" activities
• Merge points in the schedule and major milestones
• External dependencies
• Estimates with high uncertainty
• Projects with deadlines farther out than a reasonable planning horizon
• Excessive optimism
• Potential project tracking problems
• Incorrect schedule logic
• Inadvertently omitted project activities
• Inexperience with computer project management tools
• Learning curve issues with new skills

Review the resource plans as well, to uncover additional risks due to:

• Activities that require a large staff
• Activities dependent on overcommitted resources
• Activities that require skills not currently available
• Activities that depend on still unidentified resources
• Activities that require a unique or very scarce resource
• Geographic or functional separation of staff
• Activities that depend on staff also dedicated to other projects
• Activities with insufficient resources
• Project staff that is new or lacks relevant experience
• An overall project team larger than that used in previous successful projects
• Productivity impact from the work environment
• Potential staff loss through illness, injury, or resignation
• Training and staff development requirements
• Communications and language difficulties
• Potential loss of the project sponsor

Additional Risks

Reviewing the planning documents can uncover many risks, but there are several other 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 other things in the project that could possibly go wrong. Consider risks to the project that may not have come to light during scope definition and project planning. 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 it seems 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 seems to be redundancy, and adding all the new risks to the project risk list.

Retrospective Analysis

A second idea for finding risks in a new project is to look at 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) are a potentially 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 taking 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. Also look for unintended consequences of corrective actions taken, where solving problem "Q" led to new problems "R" and "S." These past problems can point to risks in any of your planned work that is similar, and should be added to your project risk list.

Organizations that take these project processes seriously review project histories regularly and prepare comprehensive checklists and templates that contain common risks for use on new projects. In addition to making common problems more visible, risk templates are an effective tool for stimulating thinking by the project team so that new risks related to past problems can be uncovered. The role of retrospective project analysis in ongoing project risk management is discussed in Chapter 12.

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.

A similar approach to scenario analysis is the "strengths, weaknesses, opportunities, and threats" (SWOT) analysis. For many projects, particularly those that involve 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.

Risk discovery from outside your project can also be useful. Interviews with peers and experts 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, "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 be used to examine future problems. These techniques include failure mode and effect analysis (FMEA), fishbone diagrams, root cause analysis, K-J analysis, or other variations of cause-and-effect investigation. To use these processes to look for potential risks, begin 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 often raises the perception of how probable certain problems are likely to be. Before the sources of trouble are articulated, most projects look fairly straightforward and problem-free. 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.

Selected specific risks from the PERIL database are listed in the Appendix to further stimulate your thinking about and discovery of project risks.

Document 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 quantification. 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, and, for risks that are time-specific, also identify when in the project the risk is most likely to occur.

Key Ideas for Constraint Management and Risk Discovery

• Minimize differences between project plans and objectives.
• Understand and clearly document project priorities.
• Use priorities to identify project alternatives.
• Explore project opportunities.
• Identify and explicitly remove unnecessary project scope.
• Determine risks and costs of proposed project changes.
• Minimize unknown risk through brainstorming, analysis, and research.

Panama Canal Improving the Plan (1906)

Many unsuccessful 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 in 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 United States 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 that allowed shovel loads to 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. When the flatcars arrived at these sites, huge fixed scoops (similar to the fronts of enormous snowplows) cleaned them off for their return to the shovels, with no need for them 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 this 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 (more than 1,000 miles). 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.