Excerpts from COST ENGINEERING Vol.4A9/No.9 SEPTEMBER 2007 TECHNICAL ARTICLE “Einstein’s Percent Complete” Thomas Tague and Franklin Morrison ABSTRACT: Projects controls’ invisible hand has guided modern man’s greatest ideas from concept to application. Although project controls does not invent or implement projects, it does make such projects possible by holding down costs, delivering faster schedules, and anticipating challenges before they become problems. Project controls’ continual emphasis on gauging incremental progress (percent complete and earned value) empowers the project manager (PM) to focus limited resources toward achieving objectives. Earned value analysis begins with a calculation of BCWP (Budgeted cost of work performed). In its simplest form, it is calculated by multiplying the approved baseline budget by the percent complete. The baseline budget is usually constant; the percent complete is variable. KEY WORDS: Budgets, costs, earned value, percent complete, project controls, and schedules Relative Percent Complete: Projects controls’ invisible hand has guided modern man’s greatest ideas from concept to application. Although project controls does not invent or implement projects, it does make such projects possible by holding down costs, delivering faster schedules, and anticipating challenges before they become problems. Project controls’ continual emphasis on gauging incremental progress (percent complete and earned value) empowers the project manager (PM) to focus limited resources toward achieving objectives. The link between project controls and applied science was demonstrated at the dawn of the 20th Century by the relationship between the pioneer Project Controls Engineer (PCE), Count DeDollare, and the young scientist, Albert Einstein. At that time, Einstein was an unknown researcher and Swiss patent clerk trying to make his scientific mark. Although Einstein demonstrated talent, his research budget was limited, and he could not develop his schedule beyond a level one. He needed help, and the local Duke assigned Count DeDollare to “get Einstein’s project in line.” The Count advised him, “Albert, if you are going to keep that stream of shillings flowing, you must report your progress, your percent complete.” “Well, report it,” Einstein countered with youthful arrogance. “This is a two year grant, and I just finished my first month. That is 1/24 or about four percent complete,” he computed in his head. Count DeDollare frowned, “Listen Albert, there are many ways to compute percent complete, and you can’t be so Newtonian in your approach. Some methods use a relative percent complete, basing the calculation on dynamic, changing parameters, like durations, scope changes, or changed conditions. Accuracy requires an understanding of this relativity.” Einstein’s hair suddenly stood straight on end, and he listened as the Count explained. “Let me put this in terms you can understand,” the Count began. If two men play catch in a moving train car, the velocity of their pitches may be 30 mph. This seems normal to them because they are gauging speed by the distance between them. To someone on a hillside watching the same game, the distance the train and ball moves through is not the 30 feet length of the car, but the distance the train and ball travel between the time the ball is thrown and caught. An extraterrestrial watching from space might gauge this distance based on the earth’s movement. So the velocity of the pitch is based on the time taken and the distance the ball has travelled, that distance being relative to the observer’s perspective. Earned value analysis begins with a calculation of BCWP (budget cost of work performed). In its simplest form, it is calculated by multiplying the approved baseline budget by the percent complete. The baseline budget is usually constant, the percent complete is variable. Although this seems a straight forward mathematical approach, the determination of percent complete is a complex matter, often misunderstood by both project managers and project controls engineers. Like the players in the pitch and catch example, the PCE and PM must understand when a static evaluation is appropriate and when a more relative approach is required for qualifying a dynamic scope. This relativity of percent complete is often the core communication problem that every PCE faces when explaining earned value. Like the distance values in the pitch and catch example, the percent complete calculation can be based on relative, changing perspectives. Often, the earned value for a particular set of tasks does not reflect the PM’s impression of his progress. A dynamic scope may not be factored into his baseline. He may be accomplishing work at the established estimated unit rate, but earning little. He may meet his unit rate, but his percent may stagnate or diminish when scope increases. Unless both parties understand the methodology for determining percent complete, the results of earned value analysis are often confusing and contentious. Percent complete can be based on any number of parameters. For instance, it can be defined in terms of the percent complete of the task duration, or the percent complete of the resource allocation or of the percent complete of the commodity total. The total may be based on the original budget, the remaining budget, or the estimate at completion. Since the percent complete is a calculation based on the entirety of a population, the methodology for determining that population is paramount. If that population is held as a constant and the project is dynamic, then the accuracy of the calculation is questionable. When the population is based on ever changing conditions (the reality of most projects), the calculation can yield unsatisfactory results. The PCE’s role is to shape the output into an understandable analysis, not just report a number. Since percent complete can be determined by different methods, the importance of standardizing the project method of generation increases its significance for reporting. Of course, communicating that methodology to the PM is equally important. No matter the method the PCE and PM acknowledge the challenges of dynamic scope . It is not enough for the PCE to report earned value; he must both understand the computation methodology and communicate the results to his teammates. Standard Concepts Review For the purpose of this analysis, the percent complete methodology is developed within the Primavera scheduling database (using the default autocost rules). Developing this information within the scheduling database drives the standardization of process and reporting. Both task duration and the resource allocation percent completes are developed within the scheduling tool, primavera (P3). (The commodity unit rate is neither addressed nor maintained in the P3 database. It can, however, be developed external to the scheduling database and then entered into the P3 database.) BCWP should be determined directly from the data contained in the P3 database. The following concepts remain constant throughout this analysis. The project can earn between 0 and 100 percent of the budgeted amount. The budgeted amount figures are maintained in the approved time-phase baseline (the target schedule), which is compared against the working schedule for earned value evaluation. At completion, the task earns its entire budgeted amount. For a completed activity, BCWP = baseline budget for that activity. For an activity not started, BCWP = 0. The BCWS value (budgeted cost of work scheduled) equals the amount of baseline budget for the given period or project. The total BCWS equals the total budget. For the purpose of this analysis, BCWS is used as the budgeted figure. Since the schedule is developed and maintained at the task level in the scheduling database, the BCWS may be computed using the task percent complete and BCWS. The summation of activities to the WBS level generates the BCWP values for the WBS. Primavera computes cumulative totals only; it does not generate current period values. An auxiliary program may be used to calculate the current period figures. The period figures may be calculated by taking the difference between the current period cumulative values and the previous period cumulative values. Several popular methods are regularly used in earned value management systems, including the following. The Ostrich Method This popular strategy entails doing nothing with earned value reporting and thereby casting the project’s financial fate to the winds. One is reminded of the old question, “Who knows what the ostrich sees with his head in the sand?” Static Baseline Method This method computes BCWP based on the original baseline scope. The estimate at completion (EAC) (either rising or falling) does not influence this performance measurement because additional scope is not evaluated. This represents the standard P3 application of earned value. The percent complete is based on the original budgeted scope, which is represented in the task duration. Thus, if 50 percent of the original task is completed in a given period, then the project would receive an earned value of half of the current approved budget. Likewise, the percent complete figure would compute the remaining duration as half of the originals duration. This method effectively models performance when the task is on or ahead of schedule. However, it yields misleading results in the following instances. The implementation duration is dynamic, and When resources are varied to meet the time constraints of the schedule. For instance, if a task is commodity based (dollars/cubic yards of concrete) and the quantity remains constant, then the task manager’s earned value can be- Task Percent Complete = Original Duration – Remaining Duration Original Duration Task BCWP = Task % Complete X Task BCWS WBS BCWP = Task BCWP Equation 1 – Activity Level BCWP computed by multiplying the unit rate times the commodity. Since the percent complete of the commodity may differ from the percent complete of the activity duration, this method may yield inaccurate results. Commonly in many projects, BCWP is calculated at the WBS level by summing the individual BCWP earned by the activities. At the activity level, the BCWP is the product of the activity duration percent complete times the original duration, See equation 1. Although this method gives the PM the means to evaluate task performance of static scope, its modelling capability fails in the following two common cases. When the implementation dynamics change, and When resources are adjusted. If, for instance, the implementation duration increases, the incremental BCWP does not reflect work completed. When the remaining duration (RD) is revised to be equal or greater to the original duration, the percent complete is calculated as zero (because it is greater than the baseline original duration). In this situation, no credit is given for work accomplished. As a result, the PM lacks a tool to allocate his resources effectively. Although this method is the standard P3 application, it is impractical for modelling field application dynamics requiring precision metrics. Because its percent complete is based on original duration, it is inaccurate in portraying the percent complete of the revised implementation duration. Likewise, this method does little to reflect resource/worker power revisions. If, for instance, an activity in the field is not meeting its incremental schedule goals, the RD may be held to its original finish date by increasing resources. This method continues to portray the percent complete of the original duration without recognizing that the original budget amount is now inadequate to meet the revision in resources. Thus, it overstates the percent complete. Although this default method is easily implemented, its two major deficiencies include the following. Revisions to the implementation dynamics, and adjustments to the resources make its accuracy problematic. Estimate at Complete Method (EAC) As discussed earlier in the static baseline method, the two deficiencies are dynamic durations and dynamic resource applications. This EAC approach attempts to remedy the first deficiency by modifying the default methodology for computing percent complete. Unlike the default method, which bases the percent complete on the approved budgeted amount (the original duration), the EAC bases the percent complete on the estimate at completion (a revision to the original duration). Thus, the percent complete is computed on the most up to date forecast of the total cost, not just a reflection of its relationship to the original cost. To understand this methodology, the PCE must review the mechanics of calculating percent complete. At the activity level in the primavera software, the percent complete can be computed based upon the activity’s progress, see equation 2. However, the default software method yields unsatisfactory results when the RD is equal or larger than the original duration. The mathematics yield negative numbers, and the scheduling software merely shows a zero percent complete. Neither the mathematics nor the software is accurate because some work was accomplished even if the projected conditions changed from those originally budgeted. The scheduler can attempt to remedy this inaccuracy by reflecting the dynamics of the implementation duration. This would consist of using a revised duration instead of the original duration, where the revised duration would equal the actual duration, plus the remaining duration, see equation 3. Unfortunately, this purely mathematical approach, although easily implemented, fails to model several conditions. When an activity is started in the software, it can progress at its projected rate or it can progress at a higher or lower rate, and sometimes not at all (riding the data date). Task Percent Complete = Original Duration – RD Original Duration (equation 2) Task Percent Complete = Actual to Date Duration Actual to Date Duration + RD (equation 3) Revised Original Duration = Remaining Duration Current Percent Complete (equation 4) Task BCWP = Task Percent Complete X Task BCWS WBS BCWP = Task BCWP (equation 5) For instance, if an activity is started and has two days of RD, it may ride out without progress through several updating cycles. The activity just may not be working. Its revised duration would increase, but its RD would remain the same at two. The percent complete calculation would change with each update cycle, thus yielding false indicators. In another case, if an activity is commodity based (a well – defined unit rate), the progress of the commodity may not equal the percent complete of the duration. Thus, the percent complete of the duration may not equal the percent complete of the scope. These examples demonstrate the inaccuracy of a purely mathematical solution. To remedy this challenge, the scheduler may directly intervene and manage the percent complete figure at the task level. The percent complete figure in the scheduling database is manually adjusted, being based upon the update input. If, however, (under the default autocost rules) the scheduler adjusts this percent figure, the RD value changes to reflect the percent complete of the original duration, not the duration representing the EAC. Since the scheduler must manage both the RD and the percent complete, he may adjust the original duration to supplement the software’s modelling weakness. This method attempts to model the dynamic changes in the implementation duration; it requires a revision to the original duration in order to represent the total duration as it would have been if the present worth of the existing conditions had been known at the project initiation. The revised original duration is the ratio of the RD to the current percent complete, see equation 4. This allows the scheduler to enter the percent complete and RD for an activity and then balance their ratio to the original duration. The scheduler then makes the required adjustment to the working schedule original duration. (Note: the original duration remains intact in the baseline database.) Once the activity progress is balanced, the scheduler can use the software in the standard fashion, using the corrected percent complete, see equation 5. With this minimal workaround, the scheduler is able to increase the accuracy of the existing tool. The resulting BCWP from this revised percent complete gives positive credit for the work completed, even if that value is diluted by the intermediate percent complete calculation. The BCWS, the RD, the projected completion dates, and the estimate to complete (ETC) are unaffected. The second challenge with the static baseline deals with revisions in resources. Since the percent complete is based on the task duration, the scheduler is faced with the challenge of identifying those cases when the resources are increased (or decreased) in order to maintain the task duration. For instance, an activity may have an original resource profile of five workers for 10 days duration, a total of 50 worker-days. If after the completion of day five, the update shows a RD of five, the percent complete is 50. If however, the supervisor is maintaining his scheduled end date by doubling the resource usage to 10 workers, then the computation based on the original duration is inaccurate. Instead of being 50 percent complete, the task is actually 33 percent complete. The EAC is now the amount expended (5 workers multiplied by five days = 25) plus the ETC (10 workers times five days = 50). The EAC is 75 and the amount of work completed is 25, or one – third of the EAC. Remedying this resource challenge is problematic on databases with many thousands of activities. First, the scheduler must recognize that the resource conditions have changed. This recognition is sometimes difficult since such changes are not readily evident in the software’s reporting functions, and a large database makes manual reviews time consuming. To flag such changes, the PCE must compare the current resource profile to the previous period’s profile (not the simplest task). Estimate To Complete Method (ETC) This method computes the percent complete by subtracting the ETC from the task budget and then dividing that remainder by the budget, see equation 6. By definition , no activity, WBS summation, or project can earn more than its approved budget figure. Computing the difference between the current approved budget (BCWS) and the ETC yields the BCWP figure directly and the mathematics simplify, see equation 7. This simplification of the mathematics allows ease of implementation. However, like the static baseline method, it is impractical for modeling field applications because it may yield negative numbers when the conditions dynamically increase. If ETC equals, or is greater than the original budget, then the equation goes to zero or shows as negative. No progress is earned. Although this approach can be explained during analysis, it is not intuitive to most users, and therefore, the communication is complex and often confusing. The potential of negative numbers indicates no performance and no progress toward project completion. The PCE must remember that the purpose if the earned value system is to quantify the progress that has been made, not to illustrate how the percent number compares to the baseline (better in a graphical representation). PM’s and their staff who have worked diligently during the current reporting period are not pleased to see a calculation that portrays a negative period performance. Task Percent Complete = BCWS – ETC BCWS Task BCWP = Task Percent Complete X Task BCWS WBS BCWP = Task BCWP (equation 6) Task BCWP = Task BCWS – ETC (equation 7) Each method presents a workable strategy to calculate percent complete. Both the static baseline and the ETC methods are less effective at calculating and communicating the dynamics of the project than the EAC method. Since the EAC method is based on the most current estimate at completion, its modelling accuracy is superior to the default software method and the ETC manipulation. Although the PCE is required to correct any inaccuracy of percent complete by manipulating the original duration, this minor manipulation is well within the PCE’s capabilities, since his existing update responsibilities include remaining duration and resource accuracy. An earned value approach should be based on the needs and resources of the project. Limited, well – established, and repetitious scope projects would be better served by using the basic P3 static baseline methodology. Unique projects with unknown or dynamic scope, like large scale industrial construction or remedial D&D projects, should enhance the basics of their default system. Additionally, any methodology used for computing earned value is dependent upon the abilities of the project controls staff to implement its approach. Small projects may be unable to afford the senior level staff required to implement these enhanced methods. A one size fits all approach is not realistic. Implementation should be based on staff capabilities. The key to project controls success centers on the staff’s ability to analyze and communicate their knowledge to the rest of the project team. Both PCE’ and PM’s must understand the limitations of their percent complete calculations. Sometimes a project can be modeled using the static method, but dynamic circumstances necessitate a relative approach. It is not enough to calculate a percent complete and expect other team members to understand its meaning intuitively. PCE must communicate what it represents. PM’s should understand the methodology of their percent complete calculation. No one should wonder if the reported percent complete represents the baseline percent complete, the resource percent complete, the duration (time) value, the budget value, or the percent based on the latest projection (EAC). With his explanations completed, Count DeDollare closed his briefcase and left an excited young Einstein scribbling numbers and mumbling about relativity and the speed of light. ABOUT THE AUTHORS Thomas Tague is a project controls engineer with Control Solutions Group, 1700 Royal Harbor Lane, in Knoxville, TN 37922-7202. He can be contacted by sending e- mail to: firstname.lastname@example.org Franklin Morrison is a principal with Control Solutions Group, LLC, at 748 Brachardt Blyd., at Knoxville, TN 37934. He can be contacted by sending e-mail to: email@example.com.