Practical Project Management Tips, Tactics, and Tools phần 7 pdf

there is a baseline plan (schedule and usually cost and effort), which is used to calculate variances. In theory, we talk about freezing the baseline, early in the project. But we all know that a frozen baseline is like the abominable snowman. It is a myth, and it melts under pressure. So the issue becomes: What are valid changes to the baseline and how do we incorporate such changes into the database? There are some reasonable and prac- tical approaches, which we share with you, here. There is also an auxiliary benefit from addressing baseline management. It also provides a basis for controlling the demon of all projects: scope creep. A Basic EVA Concept When we develop a project plan, we identify the work to be performed (activities and tasks), which we then schedule and budget. Once we have negotiated a feasi- ble plan, one that balances the work objectives with schedule, resource, and cost considerations, we establish that plan as the baseline. A basic premise of the earned value analysis protocol is that we establish such a project baseline and then evaluate progress against that target. The traditional EVA nomenclature uses this target, the Budget at Completion (BAC), as an es- sential component of the base formula. The planned effort to date, which we call the Budgeted Cost of Work Scheduled (BCWS), is calculated by multiplying the BAC by the planned percent complete. Sounds complicated? It’s really not. If you have identified a task and a cost (budget) for that task, then you have the BAC. If you have scheduled that task, then the system knows the planned percent complete at any point in time. When the system multiplies the budget by the planned %C, it has calculated the BCWS, which is the planned accomplishment at a specific point in time. Your software will do all of this for you. All that you have to do is read the results of the calculations. Later, when you have entered the task progress, the system will use the actual %C to calculate the Budgeted Cost of Work Performed (BCWP). Schedule vari- ances are then determined by comparing the work accomplished (BCWP) to the plan (BCWS). Tip Got a language problem? Let’s substitute some everyday terms for the EVA jargon: BAC (Budget at Completion). The budget. BCWS (Budgeted Cost of Planned accomplishment (at Work Scheduled). any point in time). 220 CHANGE CONTROL AND SCOPE TEAMFLY Team-Fly ® BCWP (Budgeted Cost of Earned value or Work Performed). accomplishment value (at any point in time). ACWP (Actual Cost of Actual cost to date. Work Performed). SV (Schedule Variance). Difference between planned accomplishment and EV. CV (Cost Variance). Difference between actual cost and EV. So it is essential that a baseline be established and controlled. For the most part, this is a simple and straightforward process. However, there is the potential for complicating circumstances. For instance: • What if the project workscope changes? Does it invalidate the EVA? What constitutes a legitimate baseline change? • How do we manage the baseline for phased projects, wherein each phase defines the successor phases? In this chapter, we discuss how to build a project baseline, followed by illustra- tions of pragmatic practices for managing the baseline and avoiding scope creep. We also address the challenges noted above. Building the Project Baseline Let’s make this really simple. The project baseline is essentially a project plan. Even if you were not planning on measuring performance, you would still want to develop a basic plan for the project. Figure 1.1a (pg. 7) illustrates the basic activi- ties and products associated with developing a project plan. These include: • Identification of the work. • Scheduling of the work. • Assigning resources. • Budgeting. As we develop the plan, we balance objectives and constraints associated with the defined workscope, and schedule, resource, and cost issues. The result, a list of scheduled tasks, with resource assignments and cost estimates, becomes the project baseline plan. BUILDING THE PROJECT BASELINE 221 The process is made much easier if we develop structures for the workscope and the schedule at the start. We use a Work Breakdown Structure (WBS) to or- ganize the workscope. This is essential if we are going to use the baseline plan for EVA. For scheduling, it helps to develop a Project Milestone Schedule to identify time objectives and constraints and to guide the process. It is possible to conduct performance measurement operations without having a project budget, but we assume that there is one for these illustrations. Now, let’s look further into managing the project baseline and avoiding scope creep. Part 2—Managing the Baseline (Note: Much of the material presented in Parts 2 and 3 of this chapter is also included in Part 2 of Chapter 6.1, where it is discussed as a solution for managing cost contingency. It is repeated here to maintain continuity and flow, during this discussion on change control and scope management. Con- tingency management and baseline management involve many of the same concerns and practices.) Avoiding Scope Creep It is difficult to read stories about projects without coming across references to scope creep. In the Information Technology area, especially, the stories tell of a double loss. The project workscope keeps escalating (often without providing ad- ditional 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. Even if we are not doing Earned Value analysis (EVA), 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. Rather, we must manage the additions to scope, both for controlling project costs and to maintain a valid baseline for earned value analysis. We all know that scope creep is something that we wish to avoid. Here are some easy ways to deal with the problem. 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 EV measurements. We assume that the project has been planned, and that a list of work items has 222 CHANGE CONTROL AND SCOPE 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: • We have left things out of the plan. • We have to change the way that we will do the work. • Some of the estimates for time, effort, and costs have been challenged. • The project sponsor or client has requested additions to the scope. To this, we add performance issues, such as that it is taking longer to do the work, and the estimated costs for materials did not hold up. How do we contend with all of these perturbations and maintain a valid base- line for EVA? Let’s take each of these situations and propose a practical response. 1. We have left things out of the original plan. This is to be expected and it is appropriate to adjust the baseline plan early in the project to in- corporate the better thinking that is available as the project gets into gear. The project team should establish a reasonable cutoff date for modifica- tions to the baseline, say within five percent of the planned project dura- tion. Caution! Additions should be associated with the approved project scope. These are not scope additions, but rather additions to the list of work items that comprise the approved scope. This is why we try to de- sign a contingency into the project budget (see earlier discussion on Man- aging Contingency). 2. We have to change the way that we will do the work. Ditto! We should also expect changes in project methodology as initial feedback comes in from the project participants. It is foolhardy to automatically resist changes just to preserve an early baseline, which may no longer be valid. Apply same rule as in (1), above. SEPARATING LEGITIMATE CHANGES 223 3. Some of the estimates for time, effort, and costs have been chal- lenged. Here, again, we can expect that we will learn more about the work to be performed and its associated timing and costs. We should leave some room, early in the project, to incorporate such changes. Again, apply same rule as in (1), above. 4. The project sponsor or client has requested additions to the scope. Additions to the workscope should require justification, planning, and ap- proval. Such additions should be accompanied by an increase in funding or the contract price. Before these additions are placed into the baseline plan, the work items should be identified and the work should be scheduled and budgeted. An audit trail should be maintained, so that any workscope addi- tions can be traced back to the originator and the funding source. 5. The planned work is taking longer than expected and costs have exceeded estimates. Now, here’s where we draw the line. The very rea- son that we are employing EVA techniques is to be aware of schedule and cost overruns. If we were to tinker with the BAC or BCWS for work items just because things are not going as expected, we would destroy the basis for the measurement and lose our ability to evaluate schedule and cost variances. So the rule here is plain and simple. We do not make changes to the baseline to accommodate poor performance. Rather, we maintain the baseline so that incidences of poor per- formance are disclosed. Maintaining a Valid EVA Baseline Summarizing the preceding paragraphs, we can adopt this policy. • A preliminary baseline will be established, containing the project work items and estimates for time, effort, and cost. • Adjustment will be allowed to the above, early in the project, until the base- line is frozen. • Additions to the baseline due to additions to project workscope shall be fully identified as to work items, schedule, effort, and cost and will be ac- cepted to the project baseline only after such full definition and after valid authorization. • No changes shall be made just because the work is not going according to plan. Having established our baseline plan, we can now look at an example of a prag- matic way to manage scope creep. 224 CHANGE CONTROL AND SCOPE Part 3—Managing Scope Creep Managing Scope Creep In the previous segment, we list four policies that should be established to main- tain a valid baseline. Bulleted item 3 is: Additions to the baseline due to additions to project workscope shall be fully identified as to work items, schedule, effort, and cost and will be ac- cepted to the project baseline only after such full definition and after valid authorization. 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 (tasks, 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. Tip By the way, scope changes can be negative. That is, they may involve a scope reduction. This is actually a legiti- mate means of balancing schedule, cost, quality, and scope requirements, wherein the scope is reduced to meet sched- ule, 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 documented and approved. MANAGING SCOPE CREEP 225 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. A Simple Change Control Method In Figure 6.1a (pg. 189), we illustrate a simple spreadsheet-based method for log- ging changes to project scope. We use this illustration, both for an example of providing 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 ap- proach can be applied to internally funded projects, with some modification. This example also supports my philosophy that divides the contract into three cost segments. 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 control, its con- tent would consist of all the work items included in the task budget, including schedule, effort, and cost baselines. Wouldn’t it be grand if we were so wise as to be able to identify every work item at the onset of the project and even enjoy the benefit of foreseeing the fu- ture to pre-identify all potential problems? However, we have learned from expe- rience that such is not the case. We somehow manage to omit some items from the original plan. And, sooner or later, a few unplanned problems will pop up. So we learn to allow a contingency for these incidents. Segment Two, therefore, is what I call Management Reserve. It is a contin- gency amount (in this case 15%) that has been set aside (based on experience) for items that we expect to add to the project workscope, but have not yet been de- fined (because we don’t know what they will be). It is called management reserve because it is a fund that is to be managed, rather than a bucket of dollars available to any passerby. Funds are moved from management reserve to task budget only when a specific cause 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, 226 CHANGE CONTROL AND SCOPE unused management reserve, if any, becomes part of the profit. By the same rule, an overrun of either the task budget or the management reserve will eat into the profit. Figure 6.1a shows the base dollars and schedule, plus an audit trail of five ap- proved changes. Where the changes were not chargeable to the account of the client (and were not due to performance issues) dollars were moved from the management reserve to the task budget. In each of these (changes 1 & 2) addi- tional work was defined and added to the project plan, and the EVA baseline. In change 3, the additions were chargeable to the client, and in change 4 the extra work was split with the client. The source of funding is immaterial to the task budgeting process. In each case, the extra work is defined and added to the baseline. In change 5, we have a deletion from the workscope. The effect on the task budget is similar. Only this time, we identify work to be removed, and the task budget and EVA baseline are reduced. Changing the Workscope While Maintaining a Valid EVA Baseline Let’s examine what we have gained from employing this simple, spreadsheet- based, change control system. • We have an audit trail of all changes. • We maintain control over the management reserve fund, as well as the makeup of the contract dollars. • We have a negotiated and accepted change in the project completion date. • We have a valid basis for calculating schedule and cost variances for our EVA system. Imagine if we did not have such a change control system. What do we use as the project BAC? Is it $100,000 or $115,000? Which is fairer? To answer this, we look at this case further, and assume that the project gets completed at an actual cost of $108,000. If we use the lower budget figure ($100,000), and the project comes in at $108,000, then we are apt to report that the project had overrun the budget. Yet $10,000 of work had been added to the project. Would it be fair to penalize the project team for the overrun, when it really wasn’t such? If we use the higher budget figure, which includes the management reserve, ($115,000) then we give the team credit for cost performance that was not due to actual project performance but rather to unused contingency. CHANGING THE WORKSCOPE 227 With our Change Control Log and Management System, we know just what the actual cost performance was. The project team spent $108,000 to do $110,000 of work. A valid basis for Earned Value measurements was retained. Part 4—Managing the Baseline for Phased Projects (i.e., IT/AD Applications) EVA Baselines: Purposes and Problems In this chapter on practical applications of Earned Value analysis concepts we have discussed the benefits of establishing a project baseline for the purpose of measuring and analyzing variances from the project plan. We have provided ex- amples of simple methods to manage the baseline and to avoid scope creep. We declared that paramount to effective utilization of EVA, in any degree of implementation, is the need to establish a valid baseline and to manage the base- line for the inevitable changes without invalidating the baseline. In Parts 2 and 3 of this chapter, we discussed practical approaches to avoiding scope creep and how to incorporate authorized changes into the EVA baseline. In the examples provided, we used a contract-based project model wherein the project was pri- marily defined at the time of authorization and only minor changes were ex- pected—mostly very early in the project execution. Obviously, this contract-based model does not apply to a large portion of man- aged projects, especially those in the Information Technology/Applications De- velopment (IT/AD) arena and other applications where the project scope is defined (or refined) as the project progresses. Phased Baselining Human nature dictates that we cannot expect people to participate in a flawed process. In the case of EVA, if the participants realize that the baseline is suspect or invalid, then how can we demand that they diligently manage the project to achieve baseline values? If the project team is experiencing rampant changes in the measurement base, perhaps 20 percent to 50 percent of original values, how can we ask them to then manage the project to stay within, say, 10 percent of the baseline? The process becomes a farce, and support for that process goes down the drain. With the recognition that such is that nature of many IT/AD and other devel- opment projects, does this mean that the EVA process cannot be effectively ap- plied in this environment? The answer is an emphatic NO! 228 CHANGE CONTROL AND SCOPE The solution lies in integrating the EVA process with the normal phased ap- proach toward IT/AD projects. What happens in these projects is that as each phase develops, a finer definition of the phases to follow is included as part of its deliverables. If we develop a work breakdown structure (WBS) based on the project phases, we can create an EVA model that will permit us to have: • An original EV baseline, based on the estimated scope of the project when it is authorized. • A modified EV baseline, based on the updated estimate at the completion of each phase. • A phase-specific baseline based on the latest valid estimates for each phase. For example, let’s use a phased project model that appears in Lois Zell’s book Managing Software Projects (QED Information Sciences, Inc., 1990). The phases are: 1. The Kickoff Phase. 5. The Design Phase. 2. The Sizing Phase. 6. The Coding Phase. 3. The Data Gathering Phase. 7. Testing. 4. The Implementation Modeling Phase. Refining the Baseline In such a phased project, it would be reasonable to assume that the project estimate and workscope would be refined as we completed each phase. Here is a way that we could deal with this phenomenon to maintain a valid EVA baseline. 1. Develop an Original baseline based on the project workscope as con- ceived at the time of authorization. This might be developed using one of the traditional estimating methodologies, such as COCOMO or Function Point Analysis. Or it may be derived from a repository of project models, perhaps applying a multiplier. In some cases, it might be a top-down au- thorization, just to establish a preliminary budget. For instance, the spon- sor authorizes a preliminary budget of $150,000, which, based on prior experience and models, is broken down into percentages for each phase, totaling 100 percent for the entire project. At this time, the WBS is only two levels: Project and Phase. REFINING THE BASELINE 229 [...]... measurements are essential for any kind of project, if the project manager is to maintain control of the project, make practical decisions based on knowing what is going on, and avoid surprises when the project is late and overexpended This would apply to any size project as well as any type of project in any industry It would also apply to internal projects as well as projects being performed for an external... message) Receiving project plans and compiling project plans and saving project plans into database Checking plans for resource requests against resource availability and reallocating resources if necessary, based on interproject priorities Recalculating project plans and sending back said plans based on resource allocations Sending project status reports and reminders to organization work group team... systems cannot manage projects or work groups They can only offer aid to the people charged with the responsibility to deliver project and operational results We need sophisticated tools that will make it easier to plan and track work, to evaluate the impact 246 AUTOMATIC PROJECT MANAGEMENT of new work, to evaluate the progress of existing work, and to help with the assignment of scarce and shared resources... evaluate the schedules and assignments and to address issues and conflicts Our experience with such tools and concepts tends to reinforce the evidence that traditional critical path techniques, supported by well-designed software and organized project teams, is the best way to go A Utopian System A few years ago, I came across a patent for an Automated, Electronic, Network Based, Project Management Server... don’t collect actual cost data? 2 What if the project workscope changes? Does it invalidate the EVA? 3 How do I manage the baseline for projects where the baseline changes with each phase of the project? Further Reading For a good review of the workings and application of EVA, try Earned Value Project Management, Quentin W Fleming and Joel M Koppelman, Project Management Institute, 1996 For an in-depth... Method and Software), from Erudite (1990) fall from the face of the Earth? Why has adRem’s Project Toolbox, based on an advanced resource allocation method, lacked real success? I think that the reasons are similar to the PIM situation In using such tools, we lack a strong project- centric focus on the work, and fail to set up standardized practices under the direction of responsible project and functional...230 CHANGE CONTROL AND SCOPE Project Milestone Schedule TE Figure 7. 1a AM FL Y 2 Along with this high-level, phase-based cost estimate, there should be a phase-based project milestone schedule This will define the top-level schedule objectives and constraints at the time of project conception (See Figure 7. 1a.) 3 During the Kickoff Phase, the project review team puts the request or... process If the project passes review (some projects may not survive this initial screening), it gets placed in the project portfolio Surviving projects will probably have modifications to scope and budget 4 Each phase may have some modifications and the next phase (Sizing) should have a detailed plan, schedule, and EV (earned value) estimate This plan (for the Sizing Phase) should expand the WBS at... In the Beginning In the earliest days of modern project management, handling project data was a batch process—by necessity Progress data was collected and transferred to coding sheets, and in turn was transferred to punched cards and submitted to the computer operator Then we would wait for the results, review the output, correct errors, resubmit, and eventually publish the output This process could... Therefore, in Section 7, we presented some illustrations of practical applications of the Earned Value analysis concept In Section 8, we continue to address common issues and misunderstandings about EVA and provide additional examples of very simple and practical uses of this extremely valuable tool Performance measurement, utilizing EVA concepts, has been a common requirement on many projects under the . maintain continuity and flow, during this discussion on change control and scope management. Con- tingency management and baseline management involve many of the same concerns and practices.) Avoiding. modern project management, handling project data was a batch process—by necessity. Progress data was collected and transferred to cod- ing sheets, and in turn was transferred to punched cards and. 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, 226 CHANGE CONTROL AND SCOPE unused management