IT projects: a question of locked rooms?

Project Eye has been chatting with a young (ish) IT professional who took time out to do a PhD. This analysed, in detail, the progress reports of a substantial software development which took place in an integrated enterprise business environment. The progress reports explained the immediate causes for the delays in individual project activities, as seen at the actual time they occurred.

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.

Comments (3)

Leave Comment
  • 1
    David Kay wrote on 15th Oct 2015

    Question: Did the research make any findings in respect of the original estimates being constrained to meet budget and time limits rather than the project manager's best judgement? And did the planning take into account "elapsed time" as "opposed to CPU time"? I know from experience that getting people to do 30mins work may take 2 days!

    In terms of the testing problem, is the solution to release parts of the system (where possible) in phases so that some problems are identified earlier? I know this isn't always possible but I've used this technique in a number of development projects.

    Report Comment

  • 2
    Project Eye wrote on 16th Oct 2015

    The strong impression was that meeting the deadline was the key concern. It might be that because a fixed number of developers are allocated to a project that means costs are more or less fixed. Of course, if the development goes over the deadline, staff costs go up, but duration is the first concern.
    Taking 2 days to get 30 minutes of work seems quite a good result with getting bugs found in testing corrected. More phases of shorter duration obviously makes sense. But a problem is that if phases are overlapped so that developers are coding the next phase while the previous one is being tested, it may be tricky to get them to drop everything to do a bug fix for the previous phase.

    Report Comment

  • 3
    David Kay wrote on 20th Oct 2015

    The military (I think) have a phrase that goes along the lines of "plan for the worst, hope for the best" and it's probably a good motto for project managers.
    Experience and understanding of the complexity of the solution and the capabilities of the resources should figure in each project plan creation and review which may suggest that allowing some activity time for re-work and re-testing might be appropriate. As the project progresses these activities could be adjusted to reflect actuality.
    Of course the other trick is to ensure there is sufficient robust testing before the code leaves the development team.

    Report Comment

Post a comment

Search this blog

November 2017
M
T
W
T
F
S
S
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30