May I run this past you.
Just the way I see it, but happy to be contradicted.
Suppose there is a Task such as Lay 10000 bricks in 10 Days, using one
bricklayer at $50 per hour (80 hours x $50 = $4000) and 10000 bricks at $1
each ($10000), Total Cost = $14000.
Similarly, the Task could be Pour 1000 m3 Concrete or Shoot 3000 Pigeons.
When this Task is planned, everything is related in direct proportion so we
expect to be able to have a planned rate per day for Duration (1 Day), Work
(8 Hours) and direct labour Cost ($1400) and Bricks (1000).
But after a few days of reality they are no longer (necessarily) connected.
MSP knows about Duration, Work and Cost, but it knows nothing about Bricks,
or concrete or pigeons, which is a bit unfortunate since that is how we
would like to measure progress and re-schedule this Task.
But it is not difficult to bring the numbers of bricks into it. Spare fields
can be used for the planned number of Bricks, the observed number of bricks
up to the Status Date, and then a few more to calculate Remaining Duration,
which is the real objective. The % Physical Complete field can be used for
this but others are needed as well. I prefer to not use % Physical Complete
at this stage.
At any given Status Date, the full set of ingredients looks like this:
Actual Duration
Remaining Duration
% Complete
Actual Work
Remaining Work
% Work Complete
Actual Cost
Remaining Cost
% Cost Complete
Actual Task (Bricks)
Remaining Task
% Task Complete
Some of these are in MSP and are in the default Tracking Table.
Others are in MSP but are not in the default Tracking Table.
Others aren't fields in MSP but you can put them in spare fields.
Then I put them all in a Table called Special Tracking Table #1.
In the example, if it is like the Bricks, you go and have a look at the site
at the end of Day 7 and expect to see 7000 Bricks laid.
But, sadly, you only see 50% or 5000 Bricks laid. Your daily rate is only
5/7 of 1000 Bricks. Instead of 1000 Bricks per day you are only getting
about 714.
The estimated Duration was optimistic. The original planned Duration
should/could have been 10000/714 Days = about 14 Days.
You are at (ie Status Date) end of Day 7. Remaining Duration = 14 - 7 = 7
Days, which amounts to a "recommendation" or an "estimate", based on the
observed production, which may not be the only consideration for RD.
Many people, especially in the construction industry, do not re-estimate the
RD and do not extend the finish Date of the Task because they cannot allow
(or show the client) all of the Successors and probably the Project Finish
Date to move to the right. Usually, if a project finish date looks late then
some re-casting of the future remaining plan to reduce durations on the
critical path and optimise the predecessor links will do the trick, if it is
not too late and if all of the options haven't already been used up. But in
the construction industry it is common contractual practice for a contractor
to provide a client with a Baseline on Day 1. Progress and performance are
tracked against the Baseline and clients may refuse (because they are
suspicious) to allow the re-planning necessary to stay on track. The way the
contracts are written often contradicts the principles and practice of CPM,
while at the same time appearing to require it.
If the PM really thinks that the RD need not be changed because the
remaining 5000 Bricks can be laid in the remaining 4 Days, ie he has some
secret method for suddenly obtaining 1250 Bricks per day where previously he
only managed 714, then that's fine. But otherwise, it just amounts to
ignoring observed facts. Except for miracles, the only way, probably, to
raise daily production is to throw in more Hours (Work), more bricklayers
(Units), which may or may not be possible, and if possible will definitely
increase Cost.
But unless the PM thinks it is a good idea to kid himself, so that every
future progress report is a worse surprise than the last, he really should
re-estimate that RD and see what it does, and try to find other options that
will get the project finish date back where it should be, or just face facts
and accept and 'fess up that it's going to be late. What else would be
rational?
Many construction projects are reported as being on schedule (ie will finish
on time as per the contract) even when the contractor has no real plan for
how it can be done, how to achieve increasingly difficult increasing
production rates, simply aiming for an original Baseline set of deadlines
even though they have all been made irrelevant by actual events, usually
caused by not working to the plan, or not being able to work to a wildly
over-optimistic plan, in the first place and not hitting early targets on
the Critical Path. This kind of planning usually has the finish milestone
nailed down to a date while all of its late critical predecessors accumulate
Negative Float (Total Slack), which gives the game away anyway.
An alternative calculation to the one above, favoured by many who are a bit
confused and perhaps using P3, and a few planning consultants and Quantity
Surveyors as well, is to look at the 5000 Bricks, declare this to be
equivalent to 5 Days Actual Duration and type 50 into the % Complete Field.
If Remaining Duration is re-estimated at all, it is re-estimated as 5 Days
(rather than 7). It looks better. It feels better. It is still a comforting
delusion.
Not all Tasks are so easily measurable as Bricks, but it is nice to reduce
as much of a project as possible to Tasks which can be measured like this.
If Tasks aren't so easily measurable, such as "design something", then they
should be broken down further into short Duration Tasks which can be
measured as done or not done, 0% or 100% only and there is no need to
attempt to make nonsense estimates such as "design something is 80%
complete". If this is allowed, all such Tasks are reported 90% Complete very
early but then stay there forever.
Simple rule: if Tasks are long, they have to be measurable, if not
measurable, then must be short.
The "design something" Task might consume 80% of Duration, Person-hours and
dollars but this does not mean that the Task is 80% done, unless it is the
kind of Task where we simply declare it 100% done, wherever it gets to, when
100% of everything is consumed.
