Examples of Charteris experience in RDA

A team of Charteris experts was retained to advise a public sector client on a series of disputes with its IT suppliers in the context of a very large-scale, complex procurement. Many of these disputes involved alleged delays in delivery of both specifications and systems. The Charteris team deployed specialised RDA techniques to quantify the impact of delays on both sides and the mitigating actions that the suppliers could take. A Government department cancelled a contract because of the alleged lateness of provision of service by the supplier. The supplier argued that it had been defaults by the department that had caused the supplier to be late in delivering its service. Charteris experts were retained to undertake a Retrospective Delay Analysis to establish whether there were causal links between the alleged defaults and the delay in the provision of service and, if so, to evaluate the extent of the delay caused. A consortium of banks cancelled a contract for common banking systems on the basis of alleged delay by the supplier. Charteris was retained to analyse changes in deliverables, timescales and manpower over the period of the delivery. Our analysis of the time and manpower delivered over the course of the project identified the impact of changes in scope which flowed from specific customer requests and actions. A multi-year implementation of a major IT system ran into difficulties because of delayed availability of software and hardware; late definition of business processes; delays in agreeing the structure and content of key technical documents; a deviation from the suppliers normal methods of working; and a variety of unexpected technical issues.

A Charteris team helped to identify the key issues impacting project progress and clarified how the actions and inactions of the customers and suppliers project teams had contributed to the delays to the project.

A large-scale IT development programme involving the integration of many software and hardware components was delayed because of a combination of factors including failure to mitigate key technical risks early enough; insufficient attention to integration issues; changing specifications of customer requirements; and insufficient modelling of external constraints on the system. Working from details of the specification changes, project plans and timesheet data, Charteris experts produced a graphical analysis of delays to the programme, clearly showing our assessment of delays attributable to the supplier and to the customer.

Retrospective Delay Analysis

Chris Rees Charteris plc Napier House 24 High Holborn London WC1V 6AZ

David Sharp Charteris plc Napier House 24 High Holborn London WC1V 6AZ

Telephone: 020 7600 9199 Facsimile: 020 7600 9212 chris.rees@charteris.com david.sharp@charteris.com www.charteris.com
Registered No. 3165591 Charteris plc 2013

An Expert Service from Charteris

Why do IT projects run late?

Why was the project so late? Whose fault was it? Where did the effort go? Did the supplier fail to develop a realistic project plan at the outset? Did the customer change his mind about what he wanted the system to do? Did the supplier underestimate the tasks in the plan or fail to understand the relationships between the tasks? Did the customer fail to define requirements until too late? Was the real cause a combination of these and other factors?

Such dependencies, in project management parlance, are hard. Even in the pre-construction phases, there are hard dependencies: the plans cannot be finalised until planning permission has been obtained. It is not the same in IT. In IT there are no such easy certainties. A change to one component or requirement can affect many other components, in ways not governed by any spatial intuition. Much of the functionality has usually already been built into off-the-shelf packages; a big IT project is about integrating these components in novel and complex ways. Dependencies are pervasive, and cannot be fed into simple formulae to calculate delays. It needs extensive experience of IT project realities. There are some hard dependencies in IT. The supplier cannot start testing the code until the hardware has been delivered and commissioned. But others are less so. If some but not all of the customers business requirements for the system have been signed off, the supplier can start on design and may even be able to make headway with development. He cannot complete the task until some time after the customer has delivered all his requirements, but how much time is then necessary? These dependencies may be more or less soft, depending on the nature of the project. It requires experience to assess which are indeed hard and which soft. There are other fundamental differences too. For instance in IT projects the customer has to provide legacy data for conversion to the new system. Data which does not match the specification can cause material delays to the supplier. There is no equivalent to this in the construction world. Many construction tasks are estimated by measurement and then using set formulae. In IT, there are no set formulae, and there is much more subjectivity in assessing the effort likely to be required. Special expertise in this field is essential.

The Charteris expert approach to RDA

In an IT project the question, How much did this particular delay cause to the achievement of that milestone or to the eventual delivery of the project? is not straightforward. It requires:

a methodology for the analysis of IT project plans and reports; the tools to support the assessment of the results most important, deep experience of IT project management so that the expert can make informed judgements about what would and would not have been reasonable for the parties to accomplish, and the real impacts of any failures to deliver.

The need for Retrospective Delay Analysis

Such questions are often central to disputes about IT systems. Equally many of them have been central to construction industry disputes since long before IT was invented. Consequently the experts who advise the courts on Retrospective Delay Analysis (RDA) have traditionally had a background in construction industry project management and have developed techniques and tools to analyse delays which relied on that experience. Since there are many similarities between construction industry and IT industry disputes, this seemed a reasonable approach to IT project disputes. However the courts and the lawyers who practise in the IT field are increasingly becoming aware of its limitations: knowledge of the construction industry does not equip you to make judgements about IT project problems or vice-versa.

Construction experts do not normally possess all these. Charteris experts do. Charteris has been providing expert witness services in IT-related cases for nearly ten years. We have acted in some of the largest disputes concerning IT projects to come before the courts, as well as many that settled through negotiation, mediation or ADR. Today the firm has some twenty experts, a number of whom have appeared in the Technology and Construction Court, other courts and arbitration tribunals. All our experts are practising IT consultants, project managers or software engineers. None are full-time experts. In many cases, Charteris experts have deployed RDA techniques to produce their expert evidence. Now we have synthesized this experience into a methodology supported by a toolset which enables our experts to analyse IT project delays costeffectively. We use project plans and industry standard metrics to inform our judgments, but the most vital component is our deep familiarity with the way major IT projects should be managed and the problems that arise when they are not.

What is different about IT projects?

Analysing delays in construction is simpler than in IT projects because the constraints and dependencies follow primarily from spatial considerations and mechanics or from the law. To take some very simple examples, you cannot erect the walls of a house until the foundations are laid or the roof before the walls. It is not just gravity that stops you but also building regulations and the inspector.