The development was carried out in a number of projects. Typically, these overran their estimated duration by 30 per cent. This in itself is intriguing. There is some quite serious research that suggests a 30 per cent overrun for a software project is almost routine. If this is true you would think the obvious thing would be to add 30 per cent to the planned schedule - but this does not seem to make much difference. It is almost as if there is a special Parkinson’s Law for IT: ‘Work expands to fill the time available plus a third’.
One truism of software project management is that you should break the work into phased activities, such as interface design, architecture design, build and test. The relationship between these sequences of activities is assumed to be ‘finish-to-start’: the previous phase has to be completed and signed off before the next one starts. The theory is that you want to be happy that the outputs from the previous phase will form a sound foundation for the next phase, so that you will not need to go back and, for example, revise the design because of a hole discovered when you are building the code. In practice in the projects studied, where the finish of a phase was delayed, the next phase was still started on time using whatever incomplete bits and pieces the last phase was able to supply.
If you do this the big risk is that if, for example, a build is based on an incomplete specification, developers will have to make assumptions about the details of the specification. These may turn out to be wrong, leading to code having to be torn up and reworked. You would expect the coding phase to take longer than planned as a result. In fact in the projects studied, the project manager was able to keep things looking like they were ticking over nicely - until the testing phase. This is where the chickens came home to roost.
When you draw up the project plan - especially if you are using a tool like Microsoft Project (other planning tools are available) you create little boxes representing activities. The assumption is that each of these boxes is self-contained. It is as if the people carrying out the task are going to be locked in a room with all they need, including nutritious food and drink, but no-one is to be let in or out until the activity is completed. (I hope this does not give any bosses any ideas - it is a metaphor, OK?)
Now with testing clearly this is not the case. When a tester finds a possible fault, they pass it back to the developers for resolution. There might be a formal channel for this. The appropriate developer could now be working on a new software component - which might even be on the critical path. So it may not be easy to get her immediate and full attention for the rework. It could be that the fault is caused by an ambiguity in the design. Thus it needs the original designer or specifier to be involved. All this is out of the hands of the tester. So we are now in an uncertain world of potentially unending loops and externally imposed delays. It is not surprising that our PhD researcher found that most delays were recorded during the testing phase. Let us be clear: he was not saying that the causes of delay were created during testing.
These projects were carried out where the software components were to be elements of an integrated platform-based enterprise system. It has been a great hope of UK Government IT strategy that the use of such platforms will be the key to glowing success for government IT. However, in the projects my friend looked at there were many delays because of the concerns that bugs in the new software components could contaminate the existing systems. There was a long list of project stakeholders whose approval would be needed at particular stages of developing a software component. These stakeholders had job roles such as technical environment manager, solution architecture manager, enterprise service bus manager, technical architecture manager, third party software suppliers and cross project delivery managers. Suddenly our closed boxes seem to be more like the open plan offices most of us know with communication and management lines that are many, complex and noisy. No wonder projects can be delayed.
