Dr. Andrew Makar, DMIT, PMP of Gantt Head has an article titled Project Schedule Assessment Case Study. The article requires a free membership, so Google that title and join.
Andrew makes a good start at the assessment of project schedules, but commits the cardinal sin of project planning.
Measuring progress in the schedule by the passage of time
The passage of time is just that the passage of time. It is also the consumption of money. But this information in NO WAY states what progress is being made. The only thing that the scheduler sees of the progress bar on MSFT Project moving to the right. This is the siren song of the Gantt Chart.
The ONLY way to tell if the project is on schedule, is to predefine what the units of measure of Physical Percent Complete are, then assess the Actual Physical Percent complete at a point in time. This is called EARNED VALUE.
The measure of schedule progress is the Schedule Variance (SV) and the resulting Schedule Performance Index (SPI), which of course is:
- SV = BCWP - BCWS
- where SV is the Schedule Variance
- BCWP is the Budget Cost of Work Performed
- BCWS is the Budget Cost of Work Scheduled
So when Mark says in Figure 2, the project dashboard, he has a variance in the dates, this is literally true. The dates are late by some percentage. But this is meaningless in the absence of knowing the actual work accomplished to date - the EARNED VALUE.
You may be 15% late on the Conversion task in terms of dates. But this task may actually be only 85% complete in terms of "done." OR, it may be only 50% complete in terms of "done." Can't tell by just looking at the dashboard presented in the article.
This a Good Start
The approach taken here is a good start. It's better than nothing. Actually more than better than nothing. But this approach is not the right approach to getting back on schedule for a very simple reason.
You don't know what progress has been made in units of measure of Physical Percent Complete toward DONE
This is a very common approach in the IT world. It is forbidden in the large construction and government program domain. It is also - by the way - mandated for SOX projects.
What's a PM to Do?
First start with a stand down of the project. Then define - with all the subject matter experts - what DONE looks like for each of the deliverables. Then determine where you are along the way to getting to DONE. This is a measure of the current Physical Percent Complete.
The units of measure for this assessment must be in tangible evidentiary outcomes. Not the consumption of time or money.
Show me the money, as Gerry would say
Instead show me the deliverable. This is a perfect link to agile development by the way. But velocity is NOT Earned Value directly.
Here's some resources for the details of how to make this connection
- Using EV to Plan Software Projects and Using EV to Track Software Projects
- Making Agile Development Work in the Government Contracting Environment
- Performance Based Earned Value
- Earned Value Project Management
- Lesson Learned Using Agile Methods on Large Defense Contracts
- Agile Earned Value and the Technical Baseline
- Dispelling Some Myths about Earned Value Management (EVM)
- Applying Earned Value to Software Intensive Programmes
So In The End
Do Not measure progress by the passage of time, the variances resulting from measuring the passage of time, and the forecasts of future progress by the passage of time.
