Total Project Control: a Manager’s Guide to Integrated Project Planning, Measuring, and Tracking

3/11/04 Total Project Control: A Manager's Guide to Integrated Project Planning, Measuring, and Tracking By Stephen A. Devaux, published by John Wiley & Sons, NY, 1999 (A book review by R. Max Wideman) Introduction Stephen Devaux published this book in 1999. In it, Stephen attempts to establish a common metric, quantitative data and analysis, by which the project can not only be managed, but also compared to every other project conducted by the organization. In his Preface, Stephen observes: 1 â€Å"The head of a construction company erecting a downtown skyscraper, the pharmacologist overseeing clinical trials for a new drug, the account manager supervising the development of a database for a Fortune 100 client – all three are engaged in project management. Yet chances are that the things they do are very different. . . . But out side of the work itself, all these projects actually have a great deal in common. †¢ Each has a schedule . . . †¢ Each has resources . . . †¢ Each has a budget . . . †¢ Each is going to run into unforeseen circumstances . . Most important of all, each has a scope of work to be accomplished. [But] traditional project management [methodologies] are unable to deal with work scope in an acceptable quantifiable manner. As a result, traditional project management â€Å"factors out† work scope from the management process by assuming it to be a â€Å"prerequisite† to the process . The traditional approach is: â€Å"Once you determine your work scope, we can provide you with a multitude of quantitative techniques for planning, scheduling, resource budgeting, and tracking your project. All of these techniques are based on a defined and constant work scope. †¦ However, the work itself is never quantified in a way that can support decision making. . . Other than saying that â€Å"Scope definition is important,† modern project management is silent. † As many of us have experienced, for example in software development, project scope can in fact be highly variable. Since the book was written, there has been an exponential increase in these types of projects giving rise to interest in project portfolio management. So, there is clearly a need for a common metric upon which acceptance or rejection of competing projects can be based. This is true whether the projects are contemplated or on going, and extends to decisions on changes to their respective work scopes. As Stephen observes:2 Precisely because work scope varies greatly from project to project, and even over time, within a single project, the ability to manage that changing work scope is vital: †¢ To ensure a satisfactory level of quality for acceptable cost. AEW Services, Vancouver, BC  ©2004 Email: [email  protected] ca Total Project Control Page 2 of 7 †¢ †¢ †¢ To select the best elements of scope to cut when forced to do so in order to meet schedule and/or budgetary requirements. To increase scope where the project's return on investment (ROI) can be enhanced by the additional deliverables(s) To determine which of many possible project work scopes should be undertaken as part of the multi-project portfolio. In his book, Stephen introduces a number of metrics with catchy names to support his â€Å"theories†. We'll describe some of these in our next section. Book Structure Total Project Control, referred to throughout as â€Å"TPC†, consists of eleven chapters as follows: 1. The Nature of a Project 2. An Overview of TPC Planning 3. An Overview of Planning the Work 4. Planning the Work Scope 5. Developing the Work Breakdown Structure 6. Scheduling I: The Critical Path Method (CPM) 7. Scheduling II: The Precedence Diagram method (PDM) 8. Activity-Based Resource Assignments 9. Resource Scheduling and Leveling 10. Tracking and controlling the Project 11. Conclusion Stephen just loves acronyms. His first â€Å"new metric, the â€Å"DIPP†, which he claims is fundamental to TPC3 is first mentioned in chapter 1. However, it is not explained until chapter 2, and even then only after introducing the â€Å"CLUB†, Cost of Leveling with Unresolved Bottlenecks, and â€Å"AIM FIRE† his acronym for the management cycle of Aware, Isolate, Measure, Forecast, Investigate, Review and Execute. So, what does DIPP stand for? We had to search the index to find out and guess what – it stands for Devaux's Index of Project Performance! DIPP has a formu la which is EMV (expected monetary value of the project, as of the current completion date) divided by ETC (estimated cost to complete the project. Chapter 2 also mentions Stephen's VBS (value breakdown structure)5 but it is not until chapter 5 that we learn that it is a TPC concept that brings the scope/cost/schedule triangle of value analysis down to the micro-project or activity level. 6 Chapter 5 introduces another concept, the DRAG (Devaux's Removed Activity Gauge) that is the quantification of the amount of time each activity is adding to the project. It is the opposite of total float, and like total float, since it only exists on the critical path activities, it is the amount of time an activity can be shortened before it has a DRAG of zero and another path becomes critical. A good explanation of its use is given in chapter 7. A metric for the resource elasticity of an activity, called DRED, again is mentioned in chapter 6, but is explained in chapter 7. It turns out it stand s for Doubled Resource Estimated Duration and is an estimate of how long it would take if the rate of resource usage anticipated in estimating its duration were to be AEW Services, Vancouver, BC  © 2004 Email: [email  protected] ca Total Project Control Page 3 of 7 doubled. Consequently it is an index of resource elasticity. But perhaps the high point is another acronym called RAD that appears in chapter 9. Chapter 9 is a discussion of the parameters surrounding resource scheduling, leveling and availability, both on and off the critical path, and the calculation of DRAG. Stephen explains that there are three different causes of DRAG:9 1. Delay due to the logic of the work, i. e. CPM schedule DRAG, 2. Delay due to other ancestor activities, which unavoidably push out the schedule of the successor, and 3. Delay due to the specific activity having to wait for resources, which we will call resource availability DRAG or RAD. So there you have the definition of RAD. In practice, RAD itself has mathematical constraints and the calculation is complex, requiring computer software. Stephen provides the formula and explanation, but you can skip this section if you wish. The point is, this metric is typically not calculated, so the real impact of unavailable or over stretched resources on projects as a whole is unknown to the organization and hence not accounted for when it comes to assessing project failures. What we liked This may ound like fun stuff with acronyms, but behind it all is the serious issue of â€Å"How can any investment decision be made, on a quantified basis, unless there is at least some sense of what value awaits a successful outcome? â€Å"10 Indeed, Stephen might have added â€Å"or even what constitutes a quantified successful outcome? † Later, Stephen answers his own question by observing â€Å"There are thousands of corporate organizations that depend on projects for more than 90 percent of their revenues. Yet, other than intuitively, they have no way of tying the projects they do to their profits. 11 Even under traditional project management, an absolute minimum data for each project in a portfolio should be the expected monetary value, the current completion date, and the cost estimate to complete. 12 Actually, having worked for respectable real estate development companies, we can state that these concepts are well known to them. However, having also worked with software development organizations, it appears that these metrics are not only rare but tend to be foreign to proponents of the latest forms of software development project management. Under Stephen's TPC approach, the data required is even more profound. In a portfolio of projects, it should consist of:13 †¢ Project Name †¢ Expected Monetary Value †¢ As of (i. e. Current reporting date) †¢ Current Completion Date †¢ Loss per Week Late (%) †¢ Gain per Week Early (%) †¢ New Expected Value †¢ Cost Estimate to Complete †¢ Simple DIPP Note the addition of the time value of being ahead or behind schedule, not in terms of project overhead AEW Services, Vancouver, BC  © 2004 Email: [email  protected] ca Total Project Control Page 4 of 7 costs but in terms of gain or loss in value of the product to the organization. Stephen provides many examples of his approach, although not all calculations are explicit. Stephen wades into the assembly of work breakdown structures, and CPM scheduling to illustrate his theories. On the question of how do you plan the work scope, he suggests: 14 â€Å"Each type of project is different, and each project is different. It is therefore difficult to set hard-and-fast rules for assembling scope documents. The best idea I have found is to †¢ Start with the benefits you want to achieve, †¢ Incorporate them into a business plan, †¢ Then move as rapidly as possible to a concrete image of the thing that will provide those benefits. † This is sound advice [The bullets are mine, by the way. On the matter of estimating, Stephen offers more sound advice:15 The person who is going to be responsible for the work should be the one who generates the estimates. This is probably the most important contributor to accurate estimates. The reasons for this are: 1. This person will be a subject matter expert, trained in the discipline necessary for the par ticular work. 2. This person is the only one who will know precisely how he or she plans to do the work. 3. He or she will usually have a vested interest in meeting his own commitment, and establishing the reliability of his or her own estimates. Unfortunately, the practicality in many cases is that, (a) the contributors don't know how to estimate, (b) they don't want to estimate, and (c) if they are really busy, they don't have the time to estimate. Still, it does suggest that estimating ought to be a part of production skills. Downside Under Scope/Cost/Schedule Integration, Stephen observes: 16 â€Å"Work scope is the foundation on which the whole project rests. It is the reason for doing the project – to obtain the value that will accrue from the work . . . Once we recognize this, two things come into clearer focus: 1. Quantifying scope is important. It is directly related to profitably. In a project-driven company, if you haven't quantified project scope, you cannot accurately estimate, or work to increase, profit 2. The metric used to quantify scope is the dollar. To be precise, the expected dollar that measures the value that the project is undertaken to generate. † But Stephen skates round the issue of how you arrive at this expected value by stating â€Å"Now, how one goes about estimating the value of a project is a topic of its own, beyond the scope of this book. 17 Unfortunately, that means the whole premise of his book rests on an undefined EMV parameter – which itself is changing due to external influences. Stephen's thesis, and consequent metrics, relies on a tacit assumption. This is that you have projects where the activities can all be identified, their resource requirements established and the time and cost of AEW Services, Vancouver, BC  © 2004 Email: [email  prote cted] ca Total Project Control Page 5 of 7 each reasonably accurately estimated. And further, that those resources are sufficiently flexible that schedule changes can be accommodated. On most projects, this is unreasonable, and for projects in the early part of their life span, this is patently impossible. Some of the metrics may be open to question. For example, Glen Alleman, VP, Program Management Office at CH2M HILL has commented on the DIPP formula (i. e. EMV divided by ETC), as follows:18 â€Å"There are several issues with the DIPP equation. 1. The denominator creates a â€Å"divide by zero† error as the project reaches the end and the estimate to complete approaches zero. This is poor behavior of a performance indicator not a ratio of two values drawn from the same time sample. . The indicator has nonlinear behavior over its life cycle. 3. The ETC value in the equation needs to be the sum of multiple estimates to complete, since EMV is the sum of all possible outcomes. The equation's ETC is a point value with no index i to correlate with EMV's sum across the indices of possible outcomes. The primary issue here is that DIPP does not include the sunk costs of the project. â€Å"Devaux states these are not necessary for the assessment of completion decisions. In fact the estimate to complete is based on the previous performance. The ‘performance factor for remaining work' is most often derived from the performance of the previous work. Past is a predictor of the future. The sunk costs are accruals and burden the net profit of the project. Ignoring sunk costs is not only poor financial management it is poor project management as well. The sunk costs must be paid by â€Å"someone. † The project manager must consider whom and how much is to be paid in assessing future decisions for the project. Ignoring these is like driving in the rear view mirror. It can be done, but not recommended. † We may not agree entirely with Glen's assessment, but the point is well taken. Another bone of contention is about reserves. Stephen cites the example of catching a plane under a plan based on median time estimates. Such a plan would probably mean that we would miss the plane 50% of the time. Clearly this is unacceptable so we must add contingency time. Stephen then says this is sometimes called â€Å"management reserve† and19 â€Å"There is an important difference between management reserve and padding. Management reserve is always added either at the end of the project, or immediately before a major milestone. It belongs to the project manager and the entire project. We agree with the intent but not the definitions. In our view, â€Å"Contingency† should provide for variances in durations and belongs to the project manager. â€Å"Management Reserve†, as the name implies, should belong to management for possible changes in scope (like picking up a coffee and donut at the airport), and â€Å"Padding† is a political issue and should be a no, no. Still, where workers are required to work on several projects concurrently, may be it is necessary to cover loss of productivity because as Stephen says: â€Å"Such multitasking is one of the great time wasters of corporate projects. 20 But here's a thought. If we are in DRED of missing that plane we just talked about, how much safer would we be if we doubled our resources and had two people running to catch that plane? AEW Services, Vancouver, BC  © 2004 Email: [email  protected] ca Total Project Control Page 6 of 7 Summary It is time that project management practitioners started a serious dialogue on the subject of managing scope as one of the variables, and perhaps the key variable, in project management. Ask not what is the cost of this project, or change, and can we afford it? Ask instead, what is the value to the organization of this project, or change, is it worth it and how does it stack up against our other options? Some may argue that a dollar value metric is not pertinent to their particular type of project, but whichever way you look at it, money is the only common vehicle for comparison between projects in a portfolio. Stephen sums up his position at the end of chapter 1 by observing:21 †¢ The purpose of a project is not to be short or inexpensive, but to make a profit. It should be managed in such a way as to maximize that profit. All the work, and all aspects of the project that impact its profit should be analyzed together, in an integrated way that shows the effect of the various alternatives on the project profit. †¢ Each project that is managed in a context with other projects should be analyzed in an integrated way that shows the effects of each (ostensibly internal) project decision on all other projects, and, specifically, on the multi-project profit. †¢ Insofar as projects are managed without regard to profit, bad (profit-reducing) decisions will be made, both randomly and systematically, throughout the organization. Stephen's book was first published five years ago. In our experience it takes about that long for new ideas to sink into the collective psyche of the project management populace. So, we share Stephen's view. It is time that project sponsors and the creators of the enterprise planning software they use (if any) figure out how to incorporate these variable scope and value concepts, and apply them to their projects. Then, perhaps, we will be in a better position to demonstrate that the traditional definition of project success of being â€Å"On time and within budget† is short term and very narrowly focused. We think that Stephen Devaux's book makes a valuable contribution to the discussion of project and portfolio management, planning and tracking. However, some things have changed in the last five years, or are better understood, so we sincerely hope that Stephen will consider updating and reissuing his book â€Å"Total Project Control†. If he does, we hope he will also add a glossary. R. Max Wideman Fellow, PMI 1 2 Devaux, S. A. , Total Project Control, Wiley, NY, 1999, p xvii Ibid. p xix 3 Ibid. p22 4 Ibid. p7 5 Ibid. p32 6 Ibid. p93 7 Ibid. 139 AEW Services, Vancouver, BC  © 2004 Email: [email  protected] ca Total Project Control Page 7 of 7 8 9 Ibid. p184 Ibid. p257 10 Ibid. p xix 11 Ibid. p8 12 Ibid. p9 13 Ibid. p12 14 Ibid. p63 15 Ibid. p105 16 Ibid. p30 17 Ibid. p31 18 Alleman, G. , The DIPP Formula Control Flag, An Assessment of the DIPP Indicator, Viewpoints, Project Management World Today, November-December 2003, http://www. pmforum. org/pmwt03/viewpoints03-11. htm 19 Devaux, S. A. , Total Project Control, Wiley, NY, 1999, p113 20 Ibid. p114 21 Ibid. p14 AEW Services, Vancouver, BC  © 2004 Email: [email  protected] ca