COST ENGINEERING Vol

Document Sample
COST ENGINEERING Vol Powered By Docstoc
					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: ttague@csgprojectcontrol.com

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:
csg@csgprojectcontrols.com.

				
DOCUMENT INFO