Book Review of ‘Fundamentals of Project Performance Measurement’

This short book (119 pages) covers the basics of measuring project progress via earned value management.

The author (Robert R. Kemps) argues that you cannot measure project progress simply by monitoring cost expenditures versus budgeted expenditures. If your actual expenses by a certain date is less than the budgeted expenses by that date, that information doesn’t really tell you anything – are spending less than expected or are you simply running behind schedule? Adding the work completed to the measure gives you better understanding: you can now tell why your project is spending less than expected. It could be because, some of the work that was expected to being had not yet begun.

Kemps also underlines the importance of technical performance as the third measure to factor in. Just because work is reported as being complete does not mean it is complete.  Unfortunately there is not much information in the book as to how to measure technical performance besides ensuring that it is tracked.

A baseline is important, the author asserts, because without it, the integrity of the project progress measures (and by extension, project management), is at risk, because readjustments to cost and schedule and technical performance leaves no trace behind.

It lists neither references nor a bibliography.

Recommendation: A basic book on earned value measurement, useful as an introductory reference for both the motivation behind earned value and how to do it.

Using PERT in MS Project 2010, Part 1

I want to investigate and write about how to use PERT effectively in MS Project.  But first I’ll do a review of the basics of PERT.

PERT was first developed within the United States Navy’s Polaris submarine program as a tool to help manage that very large, very complex, and unprecedented undertaking. 

The term stands for Program Evaluation Review Technique.  The focus of this management tool is on evaluating and forecasting the likely duration of a project.

Its distinguishing characteristic is recognising that project tasks are not deterministic: you cannot say with absolute confidence that task A will finish in 3 days, task B will finish in 5 days and so on. 

The reality is that task A might finish in 2 days if everything goes well, might finish in 3-4 days in most circumstances, but can potentially take 8 days if some problems arise.  So any project schedule crafted on the basis that A will take 3 days and B will take 5 days is simplistic, and is not based on reality.

To properly use PERT, you need to provide 3 duration estimates for each task in your network of activities:

1. The optimistic duration (T_Optimistic)
2. The most likely duration (T_{Most Likely})
3. The pessimistic duration (T_Pessimistic)

The optimistic duration is our estimate of how long a task will take if everything goes well.  If we have previous experience of finishing a similar task where everything went according to plan, we can use that historical basis for our estimate.

The most likely duration is our estimate of how long the task normally takes, given the normal disruptions of normal execution.

The pessimistic duration is our estimate of how long the task will take to complete if things just are not working out.  We can also use historical data if available. We’ll need to put an upper bound on this estimate because clearly there is no limit to the kinds of things that can go wrong, and we cannot include all of them in the estimate.  If the task was painting the exterior of a house, we might consider such things as the impact of rain suspending the work, or of one worker calling in sick, or even running out of paint and the accompanying delays of buying more paint. 

Once we have gathered the 3 durations, we use the following formula to come up with the most likely duration of the task:

T_Likely = (T_Optimistic + (4 * T_{Most Likely}) + T_Pessimistic) / 6

Example:

TOptimistic	20 days
TMost Likely	25 days
TPessimistic	35 days

Then

T_Likely = (20 + (4 * 25) + 35) / 6 = 25.83 days

And we will use 25.83 days as our estimate for this task. 

We perform the above procedure for each task in the project network,  computing the T_Likely duration for each.