Practical Project Management Tips, Tactics, and Tools phần 6 doc

CHAPTER 6.1 USING AND MANAGING CONTINGENCY 180 Part 1—Schedule Contingency A major aspect of managing projects is the balancing of objectives and con- straints involving project time, resources, costs, and workscope. These are four key dimensions of any project and for each of these elements there is always the risk of missing defined targets. More often than not, there are penalties involved in missing such targets. Some penalties may actually be spelled out in the contract. Others may be more subtle and ambiguous. Some targets may be imposed as a condition of the con- tract. Others may be implied by a sponsor as a set of objectives. In either case, there is a price to pay when the targets are missed. It may be an inexplicit penalty, such as a dissatisfied client. Or it may involve a significant fee reduction. A missed schedule target could leave a client without key services, or lead you to miss a window of opportunity. The unavailability of key resources when needed could throw a schedule out of joint. Cost overruns or adverse cash flow can turn an otherwise successful project into a financial loss. Any of these could affect the workscope, resulting in a reduction in deliverables, or a reduc- tion in quality. A well-planned project addresses these issues. A well-planned and managed project will identify potential schedule, resource, cost, and workscope problems and will provide defined contingencies for each risk element. TEAMFLY Team-Fly ® Quantifying Contingency As part of the risk analysis process, we identify risks, the probability of the risk, and the impact of the risk. As part of the risk mitigation plan, we identify actions that can be taken to avoid or minimize risks (or the deleterious effects of risks). We also identify alternatives and decision points (when to consider implementing the alternatives). In many cases, rather than allowing for each individual risk, we gather risks into natural groups, for which we then provide for a collective contingency. These contingencies may involve time, resources, money, and even the scope of work. The amount of contingency will depend on the degree of risk and the penalties for missing targets. Here are a few examples. Building In a Reasonable Time Contingency Those of us who use critical path scheduling to calculate a project end date may be lulled into thinking that the date that was generated by the computer is a valid project end date. But you must realize that a CPM schedule would normally represent the most likely duration of the project. That means, in essence, that the calculated end date is at the mid-point of the range of dates that could be realized. In this case, zero float (or zero slack) means a 50 per- cent chance of meeting the schedule. Is that good enough? Well, that depends on a couple of things. The first one is: What is the penalty for missing that date? I can relate this to my philosophy for driving my car to various appointments. For a person who preaches the use of contingency, I am notorious for not allowing any contingency in my planning to get places. My subconscious reasoning, I guess, is that there usually are no deleterious consequences from my being a few minutes late to a doctor’s appointment or a dinner engagement. In other words, there is an accept- able risk. On the other hand, if I am driving to the train station or airport, I do in- ject some contingency into my driving schedule. It is worth the time contingency to avoid the risk of missing a flight. The message, therefore, is to evaluate the potential consequences of a schedule delay, and to factor in a contingency that is consistent with the degree of risk. Certainly, we would take greater schedule precautions in the case of a $10,000 per day penalty contract than we would in a contract without a delay clause. But getting back to the 50 percent issue. The project completion date, that is supposedly a most likely calculation, is based on the workscope that has been BUILDING IN A TIME CONTINGENCY 181 defined to the system. If our model has not recognized several activities that might pop up later (a normal situation), doesn’t the project completion date have even less than a 50 percent chance? How much time contingency should we allow for unidentified work? The point is that we must allow a time cushion. How much of a cushion will depend on: • The degree of acceptable risk or penalty for delays. • How complete the definition of the workscope is. • How well the work will be managed (if pressure is not kept on the schedule, slips of up to 50% can be expected). • How active Murphy is on your job. The easiest and safest way to build in a time contingency is to extend the proj- ect end date to a point where there is a comfortable amount of positive float. But this may not be practical for several reasons. It may not be cost effective. It may not be acceptable to your client. It may not fit with other programs associated with your project. However, it is not prudent to proceed with a zero float plan if meeting the end date is important. Therefore, if the end date can’t be moved, then the work must be replanned to create a schedule with reasonable positive float (time contingency). Replanning, to gain schedule float, can involve one or more of the following: • Selective overlapping of tasks. • Increased resources or use of overtime. • Reducing scope. • Outsourcing. • Alternative strategies. As the available time cushion is reduced, the alternatives are to take preemp- tive actions to prevent high-risk incidents from occurring, and to increase efforts to identify all the work as early as possible. Tip When the schedule contingency is too small to allow slippage, more effort must be spent on managing task interfaces. My experience has been that as much time can be lost between tasks as in the execution of the tasks them- selves. 182 USING AND MANAGING CONTINGENCY Advanced Time Contingency Methods Most project managers seem to agree that the most common weakness of proj- ect schedules is the task estimates. We have trouble estimating the duration of tasks, as well as the effort required to execute the tasks. There are volumes of writings on the problems of task estimating, and there would be considerably more published on the subject, if anyone had any really good solutions for the problem of estimating. There are two well-accepted (but competing) structured methods for dealing with the fallacy of task estimating and the tendency to inject schedule contin- gency into the task estimates. The older, well-established method is often called the PERT method. A newer approach is called the critical chain method. Both have a strong following and are effective ways of quantifying schedule contin- gency within a structured planning environment. In both cases, we avoid fuzzy, undocumented schedule contingency and create a measurable and manageable basis for improved time estimating. The PERT Method This concept relies on three time estimates per task, rather than a single estimate. You won’t find the three time estimate approach to be in great demand. After all, if we have such a terrible time arriving at a reasonable single time estimate, won’t the PERT approach just give us a very precise error? This is certainly possible, and we have to evaluate the justification for this estimating mode on a case basis. On the other hand, it is often easier to provide three estimates for which the basis of the estimate is clear, than one estimate that considers multiple scenarios and blurs the basis for the calculation. Given the softness in our base estimates, what do we gain from the triple esti- mate approach? First, we are more likely to gain precision in the time estimates. When we ask a performer to estimate the duration of the task, we often get a bi- ased estimate. The performer may be overly optimistic, assuming that everything will go well (Murphy is on someone else’s job). Or the performer may be afraid to make a commitment based on a best guess so he adds a little time as a safety fac- tor. So just what does 10 days mean? Is it 10 days if everything goes well, but more likely to be 13 days? Or is it most likely to be 8 days, but we’ll add a couple of days as a cushion? With the PERT approach, we can ask for three distinct time estimates. An op- timistic estimate is usually a duration that would be achievable about 10 percent of the time. Likewise the pessimistic estimate is usually a duration that would oc- cur about 10 percent of the time. The third estimate is the most likely, which we THE PERT METHOD 183 are now able to obtain without deliberate bias. The traditional PERT formula, for calculating task durations, is A + 4B + C over 6, where A is the pessimistic, B is the most likely, and C is the optimistic. Other advantages are: (1) we gain a range of task and project durations, (2) we can adjust weight factors (in some programs) to generate schedules with higher or lower confidence factors, and (3) we can evaluate the potential for achieving any selected project end date. We also expand the capability for performing what-if analyses. We can use this increased information about durations in our analyses of the schedule, whether performed by simple observation or via computerized probability analysis. There is computer software available that supports the PERT approach. Many of these execute a statistical analysis of the resulting schedules, which will provide a confidence factor calculation for any projected end date. In my experience with such programs, I have frequently found that the original calculated end date had less than a 50 percent probability. I don’t necessarily recommend these programs for everyone, or every proj- ect. But when the basis for estimating task durations is weak, or meeting a schedule date is important, and especially when there are dire consequences from missing schedule deadlines, these programs will generate better esti- mates and an understanding of the potential (or improved confidence) for achieving the end dates. The Critical Chain Method This is a concept, documented by Eliyahu Goldratt, in his book Critical Chain. In it, he codifies the concept of shared contingency and extends the approach well beyond the simplified shared contingency that I (and others) had written about several years earlier. Goldratt has popularized this approach and has also developed a loyal group of disciples, who extol the virtues of critical chain, shoot down any of its critics, and champion the cause of this new scheduling elixir. The concepts of critical chain deserve our attention. It makes absolute sense to move the inferred (but unde- fined) contingency out of individual tasks and to grouped, calculated contingency in a shared buffer. In brief, Goldratt builds on the premise that project schedules are always too long, due to the safety factors that are added to the task estimates. He claims that estimates are usually based on a 90 percent confidence factor (rather than 50%). In addition task durations are also padded unless the performer is assured that everything needed to do the task will be ready at the start of the task (which is usually not the case). To this, we generally add a collection factor whenever a 184 USING AND MANAGING CONTINGENCY group of tasks come together, providing some margin in case one of the tasks slips. Similarly, a safety allowance is added by each level of management. Finally, on top of this, everyone knows that the total duration will not be accepted. They expect to be pushed for a 20 percent reduction, so they add 25 percent to the al- ready inflated estimate. The Shared Contingency Idea Essentially, Goldratt’s solution might be called shared contingency (my term), and is applied in several stages. First, he locates the critical path and reduces task du- rations to be consistent with a 50 percent probability rather than 90 percent. Half of the removed duration is added at the end of the path, as a project buffer. Next, the feeder paths are located and treated in a similar manner, and half of the removed duration is added at the end of each feeder path, as a feeder buffer. The overall project schedule is reduced. Emphasis is placed on monitor- ing the project buffer and feeder buffers (for shrinkage), rather than managing the critical path. The moving of the inflated portion of task estimates to a collective buffer has always been an option in traditional critical path programs, and does not require the abandoning of such programs just to adopt the shared contingency protocol. However, commercial products that support critical chain have extended func- tionality to address buffer analysis and additional critical chain features. Trap If you were to adopt the full critical chain philosophy and support programs, you would also have to adopt the full set of rules and processes associated with critical chain, and abandon many of the important features of traditional CPM, such as earned value and milestones. So be sure that you want to do this before changing over to CCPM. Managing Schedule Contingency Now that we have defined several ways to improve task estimating and to create schedule contingency, we have to provide for the management of such contin- gency. It would be wasteful to just move inflation values to a buffer and then as- sume that the buffer duration is up for grabs. In fact, that would have a reverse effect. Float, slack, or buffered contingency are not slop time. They must not be treated as extra time available to waste. MANAGING SCHEDULE CONTINGENCY 185 Schedule contingency should be reserved for changes to the plan, rather than to account for poor performance. Of course, in reality, there is no way to exclude the latter from eating into the contingency. However, the project team should not make the mistake of thinking that as long as there is contingency then it is okay to let things slip. Every effort should be made to hold the team to the estimated and planned durations, allowing the contingency to be available for unplanned additions to task list and uncontrollable delays. Buffers and planned contingency tasks should be monitored and the project manager should maintain awareness of shrinking buffers and the cause. Here are three things that you can be certain of: 1. If there is no schedule contingency, the project end date will be missed. 2. If schedule contingency is not managed, the schedule will slip and the proj- ect will be completed even later than if there were no contingency. 3. Murphy is working on your project. Part 2—Cost Contingency The use of contingency for schedules is quite common and practical. Similar practices are available for resources, costs, and workscope, but often receive even less attention. The following discussion addresses both cost contingency and scope creep. The Concept of Management Reserve There are two primary causes of cost overruns. The obvious one is that more money is spent for the defined work than was budgeted. The second cause is that work is added to the project without additional funding to cover the cost of the additional work. In any discussion of cost contingency, we must address the com- mon incidence of scope creep, which we do below. As we get into the subject of cost contingency, I introduce the concept of management reserve. This is a term that I use for cost contingency, because it better defines the methods that I employ to address the issues of cost and scope management. Management reserve is a sum of money that is put into the project budget, but is set aside for work that has not been specifically defined and planned. Hold on to this thought for a moment as we explore the conditions that lead to the need to employ management reserve. 186 USING AND MANAGING CONTINGENCY Avoiding Scope Creep The project management literature is overflowing with horror stories on scope creep. In the Information Technology area, especially, we are often hit with a double whammy. The project workscope keeps escalating (often without provid- ing additional funding or time) until the project runs out of time, money, or both—and then gets delivered with even less than the original planned content. So there are several reasons to control the baseline and the project workscope. We need to have some means of containing the project workscope. This is not to say that additions to the workscope are necessarily bad and must be forbidden (I did have a client who felt that way). But rather, that we must manage the addi- tions to scope, in order to control project costs. But, you’ve all heard this before. We all know that scope creep is something that we wish to avoid. However, our aversion to control seems to take precedence. We avoid the C word, at all costs, but then pay the costs, big time, for the lack of simple, but meaningful controls. Some Simple Scope Management Methods Let’s look at a few examples for managing the workscope. This first example ad- dresses issues associated with maintaining a valid baseline for Earned Value mea- surements. But the concepts are useful for managing cost contingency, even if EVA is not employed on your project. We’ll assume that the project has been planned, and that a list of work items has been defined to support the project charter. This workscope matches the con- tents of an approved contract or an approved work authorization, and spells out the work to be performed to meet the commitment. In many cases, this list of work items will have time and effort data associated with it, such as schedule dates, effort hours, and costs. Following generally ac- cepted project management practice, we freeze these data as a project baseline. We then proceed to execute the project, and track progress against the plan. Separating Legitimate Changes from Performance Issues Here’s where the fun begins—and the project baseline gets infected with the black plague of the project world, the uncontrolled-scope virus. It doesn’t take long for the plan to change. In the initial weeks upon implementation, we often find that (1) we have left things out of the plan, (2) we have to change the way that we will do the work, (3) some of the estimates for time, effort, and costs have been challenged, and (4) the project sponsor or client has requested additions to the scope. SEPARATING LEGITIMATE CHANGES 187 All the above are typical situations that can affect the defined scope of work and the costs associated with that work. This is all in addition to performance is- sues, such as that it is taking longer to do the work and the estimated costs for ma- terials did not hold up. This first group consists of legitimate conditions that will affect the project budget. How do we contend with all of these changes and maintain control of the costs, as well as the workscope? Managing Scope Creep Here is a recommended procedure for both maintaining control over the workscope and maintaining a valid baseline for EVA. 1. Establish a standard practice for adding to the project workscope. 2. Provide forms, either printed or electronic, to facilitate the practice. 3. Identify roles, including who may originate a scope change and who may approve a scope change. 4. When a scope change is proposed, the work to be performed is to be fully defined, preferably as a list of work items (task, activities, whatever) with work breakdown structure IDs, schedule, effort, costs, as applicable to the current methods in place. 5. The source of funding is to be identified. Is the project budget being in- creased? Is it coming out of a contingency fund? Theoretically, work should not be added to the project database without an adjustment for the added costs. 6. Maintain a record of all scope changes. By the way, scope changes can be negative. That is, they may involve a scope reduction. This is actually a legitimate means of balancing schedule, cost, quality, and scope requirements, wherein the scope is reduced to meet schedule, cost, and quality objectives. In the case of a scope reduction, the same procedure should be followed. The work items slated for removal should be deleted from the project baseline. Such changes should be fully docu- mented and approved. Note that this procedure may violate what is often presented as a project con- trol axiom. We are often told that we create a project plan and freeze a baseline. Yet, in this proposed practice, we allow continual updating of this baseline. It is my belief that a project baseline is managed, rather than frozen. It should always reflect the plan values for all authorized work. However, the changes to the base- line must adhere to a rigid protocol. 188 USING AND MANAGING CONTINGENCY A Simple Change Control Method, Employing Management Reserve In Figure 6.1a, we illustrate a simple spreadsheet-based method for logging changes to project scope. We use this illustration, both for an example of provid- ing an audit trail of such changes, and for registering any changes to the project baseline for EVA purposes. In this example of a telephone system installation project, we see that it is a commercial, for-profit contract for an outside client. However, the basic approach can be applied to internally funded projects, with some modification. This exam- ple also supports my philosophy that divides the contract into three cost seg- ments. Segment One, the Task Budget, includes all the work that has been specifically identified and planned. This Task Budget is the original Baseline for the EVA. If we were employing a traditional CPM system for planning and con- trol, its content would consist of all the work items included in the Task Budget, including schedule, effort, and cost baselines. A SIMPLE CHANGE CONTROL METHOD 189 Figure 6.1a Change Control: Summary and Log BASE Chg #1 Chg #2 Chg #3 Chg #4 Chg #5 Task Budget $3000 $2000 $4000 $3000 –$2000 $100000 $103000 $105000 $109000 $112000 $110000 Mgmt Reserve –$3000 –$2000 $0 –$1500 $0 $15000 $12000 $10000 $10000 $8500 $8500 Margin $0 $0 $600 $0 $0 $15000 $15000 $15000 $15600 $15600 $15600 Contract Total $4600 $1500 –$2000 $130000 $130000 $130000 $134600 $136100 $134100 Effect on Schedule 15-Jun-92 15-Jun-92 25-June-92 15-Jul-92 15-Jul-92 15-Jul-92 Explanation of Changes Change #1 Forgot L.P. Materials – Add $3000 – Take from MR Change #2 Conduit stuffed – Need extra – Add $2000 – Take from MR Change #3 Add 20 phones and new IDF – Add to contract: $4000 + 15% Change #4 Existing trunk line inadequate – Split $3000 cost Change #5 Delete data lines from bldg A – Deduct $2000 from contract [...]... commonly available tools, such as project management software and spreadsheets CHAPTER 6. 3 SOME COMPUTER-BASED APPROACHES TO SCHEDULE RISK ANALYSIS I n Chapter 6. 2, we illustrate several nonstatistical approaches toward schedule and cost risk avoidance and management These included practical, nonmathematical, common sense approaches, such as time contingency, earned value analysis, and management reserve... cycle of a project consists of a series of closing doors Early in the project, there are usually numerous alternatives for satisfying the project objectives As we move along further in the project, constraints in time, cost, and technology tend to reduce the number of available options As a basic part of project management, and specifically a component of contingency management, the prudent project manager... for risk management came from a consulting firm specializing in project control and risk management methodologies, for IS and high-tech manufacturing They report continued success in helping firms to set realistic schedule and cost targets and then to meet those targets, using a homegrown methodology called Risk Averse Project Management Process The process centers on improving estimates and “having... category to the project baseline Alternatives for critical content should be identified in advance, and project reviews should be scheduled prior to the deadline for exercising such options All of this is part of the risk management aspects of a project, with the immediate objective of balancing schedule, cost, resources, and workscope, and an end objective of maximizing client satisfaction and project success... contingency, and (by popular demand) Monte Carlo schedule analysis techniques We draw these techniques together here to present a set of common sense options for risk avoidance and risk management This chapter concentrates on low-tech, common sense methods to address potential risk issues, for time, cost, and technology We then, in Chapter 6. 3, submit to the demand of the more statistically oriented project. .. the funds will be used up and the project will cost even more than if there were no cost contingency 3 Murphy is still working on your project Part 3—Resource and Scope Contingency In the previous parts of this chapter, we devoted most of the discussion to the use and management of schedule contingency and cost contingency In this concluding segment, we will cover resource and scope contingency Resource... costs, workscope, and quality—an essential element of the project management process Again, this is not contingency management as we described for schedules and cost But it does influence us to identify the more flexible parts of the contract SOME CLOSING THOUGHTS 195 workscope and to be proactive in evaluating options and alternatives In this regard, it can be considered to be contingency management Tip... suppose that a project manager’s life would be much simpler if there were never any changes to the workscope, and if the schedule and cost never had to be cast in concrete But, for most of us, that’s not the way it works The typical project has a defined workscope, and a target schedule and budget Therefore, a basic component of managing the project consists of maintaining the plan, and managing changes... cost, resources, and workscope, and an end objective of maximizing client satisfaction and project success Contingency planning and contingency management are essential to project success CHAPTER 6. 2 RISK MANAGEMENT FOR THE SIGMAPHOBIC Managing Schedule, Cost, and Technical Risk and Contingency L ots of things make me nervous, but none like the sight of a sigma, that weird, E-like gizmo that signifies... is noted and the resulting work is planned Funds so moved to the Task Budget become part of the revised EVA baseline Segment Three is the Project Margin or profit It is the Contract Price, less the Task Budget and the Management Reserve At the conclusion of the project, unused Management Reserve, if any, becomes part of the profit By the same rule, an overrun of either the Task Budget or the Management . resources, and workscope, and an end objective of maximizing client satisfaction and project success. Contingency planning and contingency management are essential to project success. 1 96 USING AND. $10000 $10000 $8500 $8500 Margin $0 $0 $60 0 $0 $0 $15000 $15000 $15000 $1 560 0 $1 560 0 $1 560 0 Contract Total $ 460 0 $1500 –$2000 $130000 $130000 $130000 $13 460 0 $1 361 00 $134100 Effect on Schedule 15-Jun-92. options. As a basic part of project management, and specifically a component of contingency management, the prudent project manager iden- tifies the critical decision points and notes the deadline