IT programmes go wrong for a variety of reasons, but at the heart of every failed programme is poor communication between people. People make mistakes, relationships deteriorate and delays happen. Delay in itself becomes a compounding factor as situations and requirements then change. Dealing with those issues in a timely and cost-effective manner will help prevent delays becoming endemic.
Before you can formulate a strategy to resolve issues, you must first investigate what has happened as soon as possible in order to understand your contractual rights, remedies and obligations. The first step is to collect the evidence that illustrates why the delay has occurred.
Governance documents are the best place to start, particularly notes of meetings between supplier and customer. These notes should present an agreed picture of the state of the programme at a given date and they are therefore valuable evidence in establishing why things have gone wrong.
However, evidence collation can be a difficult process in terms of both records kept and access by both parties to that information. Dealing with imperfect or unbalanced evidence at the outset of the process will help minimise the potential for serious issues to arise later. Forensic delay analysis relies upon being able to determine the critical path and sequence of events through a programme at any particular time and in particular at the point where a delay event has occurred. Retrospective delay analysis looks at the delay that has occurred in hindsight and tries to establish any entitlement to extensions of time.
There are a number of recognised approaches such as applying delay events to a starting programme plan, or comparing a final plan to the initial plan or removing the effect of delays from the final plan. Each approach has its strengths and weaknesses, but there are challenges that are common to all when analysing delay to an IT programme.
Each of the methods is dependent to a large degree on there being a sound programmatic plan with linked and maintained dependencies. The reality of most large IT programmes is that while plans may exist in overview, a detailed programmatic plan that covers and links a number of issues and which accurately captures all of the activities and dependencies rarely exists. It is even rarer that such a programmatic plan is accurately maintained over time.
A challenge in all delay analyses is dealing with concurrent or parallel delays. In theory, given an adequate programme plan, programmatic analysis could identify where a number of activities may have slipped in parallel, and which of those would drive the critical path. However, decisions to delay a key milestone on an IT programme are usually taken by a joint steering group, which may consider a number of wider factors (including political and emotional aspects) and the issue which the steering group chooses to focus on may not be the issue that is actually causing the critical path delay in the programme plan.
As well as the need for the baseline programme plan, an understanding of the elements that underpin the plan is required in order to look at the size and nature of any delay. In particular the nature of any dependencies needs to be understood, as do any assumptions relating to the timing and sequence of activities that may evolve as the programme situation changes.
Complex IT programmes therefore have a number of features that make them difficult to assess (see bullet points below).
Undertaking delay analysis may require a combination of approaches to look at the different possibilities. One should start by identifying key major milestones and determining any movements on these milestones. This requires good and accurate programme records to determine the movement of dates and what the programme governance believed were the issues and underlying reason(s) for delays.
Having assessed what has caused the delay, it is time to revisit the contract to work out who is liable and the relevant remedy:
• Interdependencies are often complex and not well understood at the outset
• Intangible nature of product and associated business change makes it hard to rationally measure and assess progress of programme activities
• Nature of programmes means that they nearly always involve significant organisational change
• Steering Groups will consider wider factors than programme activity progress e.g. organisational readiness for change, confidence etc
• Fluidity of assumptions and dependencies means that a dynamic analysis is needed to reflect the changing state of the programme
Simon Kenyon is partner and head of IT litigation at DLA Piper, and Philip Hay-Jahans is senior manager at Boxwood
This opinion piece will be continued next week
Sometimes, the power of the mainframe is the most cost effective answer. Computing's Peter Gothard puts Computing's readers' questions on the future of the mainframe to IBM's Z13 expert Steven Dickens.
This Dummies white paper will help you better understand business process management (BPM)