What if Project Activities Go Wrong?

16 November, 2015

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.

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.

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.

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.

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.

Usually, a programmer might cover this risk by allowing a day to get the code compiled. However, it might prove that typing it in takes an hour and compiling five minutes. However, the analysis of the compiler’s errors and warnings, corrections to the code and a re-compilation could take fifteen minutes. This means that we can go through the re-compilation loop four times in an hour. So we could allow two hours for the coding and record how many loops were actually needed. This will allow future projects learn from the averages coming from this project to base their loop counts and durations on. The test run has the same logic. How long does it take to analyse a test failure and to correct the code? Will the design be impacted? How many test failures would we expect during unit test? It might take several projects before we start seeing a trend in the actual figures, but identifying the steps in the process will lead us to estimates based on fact rather than guesswork.

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.

In other words, if your car uses 5 litres of fuel per 100km, would you put 10 litres in the tank to visit someone 100km away? What happens if there is heavy traffic? What happens if the person is not at the address you were given and you have to drive to a different location? Unless you are Jeremy Clarkson, filling the car is only way to have peace of mind.

By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital