The controversial motoring journalist, Jeremy Clarkson, is very fond of playing a game he calls “Fuel Light Bingo”. He likes to drive with his fuel tank as close to empty as possible. Clearly, Mr Clarkson cannot be described as risk averse. For most of us, carrying around a full-ish tank of fuel in our vehicles provides a measure of comfort. Objectively speaking, Jeremy Clarkson has the right idea – fuel is heavy and carrying around more than we need is uneconomical. By the same argument, carrying around a spare wheel is also wasteful, because it is rarely, if ever, used.

But anyone who has studied to become a Project Management Professional (PMP)^© – preferably on one of our courses – will be too conscious of risk to countenance slim or zero margins for error. Murphy’s Law (what can go wrong will) is our guiding principle and, to cope with disaster, we are encouraged to add reserves to our schedules and budgets to allow for things going wrong.

On this page:

• Understanding Critical Path Method and Float
• Estimating Techniques for Project Management
• The Role of the Optimistic Estimate
• Assessing Risk and Corrective Actions in Software Development
• The Pessimistic View and Project Adjustments

Understanding Critical Path Method and Float

We use techniques like the Critical Path Method to find out what tasks (or schedule activities as the Project Management Institute calls them) have no margin for error available. If something is delayed on the critical path, for any reason, the project end date will be pushed out. This margin for error is called float or slack.

Float is available on the non-critical paths. Putting it formally, if the early finish of one activity is less than the early start of its successor activity, then that activity has what is called “free float”. This means that it can be delayed by the difference between the two values, without pushing out the successor activity.

Estimating Techniques for Project Management

PMP© students will remember calculating the “backward pass” through a network diagram in order to obtain the floats for each activity in the network. These floats are called “total floats”. These figures show the amount of time a given activity can be delayed before the end-date of the project becomes compromised.

But float is only available on non-critical paths. It is a contingency reserve that we get for free, thanks to the topology of the network diagram. For the critical path, we need to assess each activity carefully and see what contingency we need to add to allow for possible disasters. Leaving the critical path without any margin for error is a bit like playing “fuel light bingo”.

There are estimating techniques that seek to make contingency reserves explicit. The problem with asking a project team member for an estimate is that this request is interpreted as a commitment. Too often, the estimate given is padded to cover the possibility of disaster. Using a three-point estimation gives the team member freedom to analyse the actual work and then to explain why extra reserves are required.

The Role of the Optimistic Estimate

What the Project Manager does is to ask firstly for an optimistic estimate. This is the minimum time needed to do a particular task. In other words, if we have a following wind and it is downhill all the way to the finish, how much time would be required? For instance, if a programmer was asked for an estimate to code and unit test a piece of software, the optimistic estimate would determine how long it will take to type in that code, compile it and run the tests. The optimistic assumption being that it will compile first time and all the tests pass first time.

Assessing Risk and Corrective Actions in Software Development

Anyone who writes software will know that this does not always happen. In fact, getting code to work properly can take many more days than the coding tasks physically take. However, because we have broken down the coding operation into discreet tasks, we can now look at the risks with each one. Typing should not be too risky, but compiling is – because of typos in the code. More seriously, the programmer might not be experienced in the programming language’s syntax. This means several compile-correct-re-compile cycles will be needed.

The Pessimistic View and Project Adjustments

The pessimistic view could be that every line of code has a typo on it and there could be hundreds of re-compilation loops. Similarly, every test could fail, necessitating a correction cycle for each test. In fact, it could be worse: it might take several correction attempts before each test passes. We might be looking at hundreds of test cycles as well.

So now we need to use our judgement and our previous experience to choose a most likely number of repair cycles. What were the test failure rates in previous projects?  What are the most likely error types and how long do they typically take to fix?

The Project Manager and the team may decide to allow four compilation cycles and ten test repairs. These are all entered explicitly into the schedule. If test cycles are not needed then this fact can be noted for future Project Managers. If more test cycles are needed, they need to be added into a revised schedule. The important thing is to record what happened. This is the only way to improve the estimation process.