Imagine a parallel universe; far, far away.
We are working in the construction industry. In our strange, Utopian new world, each Contractor studies it obligations carefully and meticulously programmes its work with due regard to the methods and resources available, unconstrained by short tender periods and unrealistic completion dates. Then, that programme is used to actually execute the work, being respected and worked to until something happens which makes it impossible to do so; at which point the programme is rapidly but carefully revised making due account of the delaying or sequence-changing event. The revised programme then becomes the works programme; and working to that revised programme is taken just as seriously as the original programme. The process of revision is repeated for every change on the project. Delays from all sources are shown honestly, whether they are from the Employer, the Contractor, or a neutral third party.
This alliance of excellent planning and strong project management leaves us with a finished project which has been built to a single programme, albeit one which has been constantly revised to reflect changing circumstances, each programme revision reading like sequential chapters of a flowing novel. At all times, the programme is treated as an up-to-date, relevant document of the utmost integrity and is worked to as far as possible. As a result, the programme carries weight: programme revisions provide an audit trail; cause and effect of all project delays can be traced. Thus, delay disputes are unheard of and so a state of eternal bliss pervades our parallel universe. The project stakeholders can sleep easy as their twin suns set beyond the Kryptonite mountains standing tall in the chlorine-filled atmosphere.
Meanwhile, back on planet Earth, there are problems. Big problems. Tender periods can be short, too short for proper planning. Completion dates imposed by the Employer can be tied to political events more than realistic construction constraints. Budgets can be tight. Planning staff can be software jockeys who have little experience in actually digging holes and filling them with concrete. Tender and initial programming can thus become an inaccurate afterthought. Not a good start. And then the work kicks off. The veteran project manager perhaps does not respect, or perhaps does not want to work to the young software jockey’s sometimes inaccurate programming. Sub-contractors (who, after all, are specialists) have no input into the programme, or maybe never get sent a copy of it. Delays occur on site, but perhaps the programme is not kept up to date. Or perhaps the programme is updated, but the update itself is not accurate, or perhaps the party behind the delay does not want it to be accurately shown. So, the Contract Administrator perhaps refuses to endorse a programme which shows that problems with his design are delaying the Contractor, or the Contractor may hide his own delays. Oh dear.
In such cases, instead of being realistic contemporaneous project management instruments, the programme gets gradually contorted to hide as much as it shows, evolving as it does so into a commercial sledgehammer, existing only to prosecute or defend claims. Perhaps such pressures lead to there being more than one programme in existence, to please different audiences: a “This makes the Engineer Look Bad” programme; a “This will Placate the Management” programme, and a “Token Attempt at Acceleration Even Though We Haven’t Got a Chance” programme. All of these programmes are perhaps wildly wrong; none of them are actually being worked to. With programmes which can be inaccurate, ‘cloak-and-dagger’ and entirely disregarded on site, massive, complex delay disputes are inevitable. Who has caused what delay? And, absent a decent benchmark, how to measure those delays? Cue much anxiety for the project stakeholders; struggling to sleep in the suffocating oxygen.
Enter the delay analyst. The forensic programmer. The “practitioner of dark arts”. What does (s)he do? Well, it would be too naïve and simplistic to say that (s)he turns the reality of planet Earth into the fantasy of the parallel universe, but in a formal dispute (such as an arbitration or litigation), when acting as an expert witness, (s)he must provide an independent analysis which resembles the ideals of Utopia as far as possible. Programming mistakes are to be corrected; appropriate impacts of delay events are to be made; and a view as to what delay events actually impacted the critical path of the project and by how much must be taken. In short, the delay analyst must put the tribunal, i.e. the arbitrator or judge, into the best possible position to render a resolution to the dispute, which is effected usually by applying the extension of time mechanism to the critical delays as found by the delay analyst.
Sometimes though, usually at an earlier stage, the delay analyst’s brief is not to act as an independent expert witness, but to wear more of an advocate’s hat: to help to prosecute or defend the delay claims. In this role, (s)he may produce yet more programmes which are politically- or commercially-loaded, and were never intended to be worked to. Sometimes, the Earthly constraints of time and budget conspire to make these programmes little more than simple impacts of delay events into the programme, or subtractions of delay events from an as-built programme. But on occasions even these simple pictures can be of assistance in resolving a dispute before it ever gets to the formal arbitration or litigation stage.
Needless to say, all of this requires practical proficiency in the study of critical path project programming, much patience and a analytical eye when studying claims and other project documents, and some flair in presentation and simply telling the story. If you are a construction planner looking to apply your skills in a different way, you might find that retrospective delay analysis is out of this world.
Scott Adams is a delay analyst who sometimes inhabits planet Earth. He can be contacted on email@example.com.