Structuring a Delay and Disruption claim

Paper 2208

Structuring a Delay and Disruption claim: an application of cause-mapping and System Dynamics

Terry Williams (*), Fran Ackermann, Colin Eden Department of Management Science, Strathclyde University, Glasgow G1 1QE, UK

(*) Corresponding author. Department of Management Science, Strathclyde University, 40 George Street, Glasgow G1 1QE, UK Tel

+44-141-548-3548

FAX

+44-141-552-6686

E-mail [email protected]

-1-

Structuring a Delay and Disruption claim: an application of cause-mapping and System Dynamics

Terry Williams (*), Fran Ackermann, Colin Eden Department of Management Science, Strathclyde University, Glasgow G1 1QE, UK (*) Corresponding author. E-mail [email protected]

Abstract The idea of “Delay and Disruption” within projects is well-known and is often the subject of litigation claims. However, the term is ill-defined, and it is difficult to justify such claims within a legal process. This paper demonstrates a well-developed approach, which is a logical, transparent, auditable and sustainable means of presenting such a claim. It describes the format for a claim document that presents first the disruptive triggers, then using a formal qualitative model builds the case from the interacting effects of these triggers. Transformation of this model into a computer simulation and the ability to explore different scenarios provides the quantitative part of the claim document. Thus three elements are presented in the document: demonstration of causality, of responsibility and of a quantum for the claim. This process also provides additional benefits, including a high level of participant “buy-in”, and the basis of a model that can be used to support the claim.

Keywords: project management and scheduling, delay and disruption, litigation, cause mapping (structuring and analysis)

1. Introduction

Large and complex projects often lead to cost and time over-runs, and we are not surprised when we read in the newspapers of major projects that have considerably exceeded budget and schedule. A recent article in the UK's Daily Telegraph newspaper (16th June 1999) said "The 25 biggest projects commissioned by the Ministry of Defence will cost almost £3.5 billion more than expected and will be completed more than three and a half years late. Only two of the projects are expected to produce battle-ready weapons on time” Usually, the cause of part of these over-runs is immediately apparent: the owner has asked for changes to the specification, or force majeure events have arisen such as bad weather or strikes. Often, however, after all the “direct” causes have been taken into account, there is still a large element of over-run left apparently unexplained. In claim documentation this may simply appear as an unspecified “lump” under a heading entitled “delay and disruption”. This term (or, “disruption and delay” or, “D&D”) is generally ill-understood and ill-defined.

-2-

Where “D&D” forms a major head of claim, it can be undefined and ill-understood, because it is difficult to: −

prove causality: that is, show what the factors were that caused the D&D, and how these factors caused over-spends and/or time over-runs;

−

prove responsibility: that is, show that the party being claimed against was indeed responsible for these outcomes;

−

prove the quantum: that is, show that the factors caused a specific quantum of over-spend / time over-run.

All of these are clearly needed for a fully justifiable, quantified claim for D&D.

A team at Strathclyde University (including Andrew Tait and Susan Howick as well as the authors of this paper) has been undertaking work in post-project litigation for a number a years. During this time we have been involved in identifying, modelling and quantifying D&D in a number of projects. In particular, we have prepared (with a good degree of client satisfaction and continued use) significant parts of eight major claims, which have total value in excess of $1billion, for projects in Europe, Canada, UK and the US. As such the authors have considerable experience in surfacing the necessary information required firstly to understand the event, and secondly to structure and quantify the claim.

This paper therefore describes a new approach to structuring a claim document to show causality, responsibility and the quantum of a D&D claim. It follows a logical structure of a claim document. It does not describe the process of developing the content of a claim (building a claim model); a good example, which shows the messiness of this process, is described in Ackermann et al (1997). Rather, after the claim model(s) has been developed, this paper describes the presentation of a claim to a client in a way that seeks to be logical and transparent, clearly showing a route from actions for which the client was responsible to the resultant quantums of over-spend and time over-run.

This paper is written from the viewpoint of a contractor (i.e. a party paid to execute a project who will not own the output from that project) claiming against a client (i.e. the party who pays the contractor, who does not directly execute the project but who does own the final output) (Turner 1993). The examples used are fictitious, and by necessity of a generic nature; however, they are typical of concepts modelled in the claims studied by the authors.

-3-

2. Delay and Disruption

Possible definitions of what is a delay and what is a disruption are discussed in the construction law literature (e.g. Cushman et al 1996). For example, a delay can be an approval delay, information delay or a piece of work to be done later than originally planned; a disruption can be some event which precludes the contractor completing the work as bid. In the past, simple decomposition methods have been used to analyse the effects of individual delays or individual disruptions (Wickwire and Smith (1974) and Rubin (1983)). However, delays act as disruptions, and the disruptions cause delays, both of which in turn further disrupt the project as they impact on one another. Consequently chains of causality between disruptions and delays occur. In addition where there are a number of delays or disruptions coming together at a particular point of the project, this portfolio of events may result in an effect beyond that imagined when considering the total of each. Finally, positive and negative feedback loops can surface where the consequences of specific disruptions or delays, including managerial responses, can in turn feedback on the original event and cause dynamic behaviour. An example of these can be seen in Ackermann et al (1997), where the authors describe a case study in which small design changes and small delays in design approval caused significant delay to the project; thus to meet a tight time-constraint management had to increase development parallelism; this, in turn, reduced apparent schedule delay but set up feed-back loops that markedly increased total project spend and caused substantial actual delay. Cooper (1994) describes similar effects which focus on the re-work cycle.

There are further complicating issues. For example, it is difficult to attribute “knock-on” events and delays directly to any one disruption or delay. The border-line between directly attributable additional costs and the cost of D&D is fuzzy. Then there are the issues stemming from the resulting acceleration and project compression that need to be considered – and whether the additional cost resulting from acceleration is self-imposed or caused by the client (Howick and Eden, 1999). A full discussion of these and other issues is contained in a paper by Eden and others (Eden et al 2000).

As these issues have already been discussed in Eden et al (2000) and they are not the main focus of this paper, further examination is not provided. Instead, this paper shows how the D&D claim is constructed; starting with the triggering events imposed upon the planned project, building a structure of causality from them, and quantifying the total spend and schedule. The resulting total claim therefore is this ‘total spend’ less the ‘planned spend’. In particular, it should be noted that the question of what part of this total claim is “direct claim” and what part is “D&D” is not dealt with here – this complicated issue is touched upon in Eden et al (2000).

-4-

3. Cognitive mapping

One of the possible first steps in developing a D&D claim is to interview members of the project team to identify the full variety of explanations of what occurred. In addition, the draft of the claim document, when it has already been created, can be analysed as if it were an interview. The technique used by the authors for the analysis of interview data or the report is "cognitive mapping" or cause mapping respectively. This technique structures the way in which humans construe and make sense of their experiences by developing maps consisting of elements (“constructs”) joined by links/arrows showing the relationships between elements (as directed graphs). Eden (1988) gives a general description of this technique and its theoretical background, and Ackermann et al (1997) discuss its use within one of the authors’ case studies.

To help develop, structure, share and analyse the extensive maps, specialist software is used, Decision Explorer1. The cognitive map from each interviewee is entered into a single computerised model. This integration allows the different views to be combined (through entry of inter interviewee relationships and the merging of identical constructs) to form a holistic representation of the project’s life – the qualitative model. The resultant model – now a cause map as it does not represent the group’s thinking per se - can be developed and validated working in a visual interactive mode with groups of senior members of the project team (Eden and Ackermann 1992). It is at this point that the alternative approach of creating a model from the initial draft of the claim may be compared with that of interviews. As the participants work through this model they not only check the reliability of the material but also, through gaining an overall understanding of what occurred, begin to refine the representation adding more detail as they gain more confidence with the model (Ackermann and Eden, 1998). Conflicting or ambiguous aspects are researched and further explored.

Typically in D&D claims, the resulting cause map/model generated is large - for example, the map described in the case study by Ackermann et al (1997) contained around 750 concepts and 900 links. However, the analysis and clustering methods within Decision Explorer (Eden and Ackermann 1998) enable users to identify the feedback loops, the events that caused them (triggers), and the consequences of the feedback loops. This identification of the dynamic impact of the known effects helps the group (lawyers, and modelling team) to understand how the delay and disruption was caused. Nevertheless, whilst the analysis helps in detecting the feedback loops, the overall loop structure may still be complex, but this is also true of the dynamics of the real situation - the overall behaviour of inter-connected and nested feedback loops being characteristically difficult to discern subjectively, and producing what many in a project team see as “chaos”.

1

Decision Explorer is supplied by Banxia Software, Glasgow; it runs in the Windows environment -5-

Figure 1 shows an example of a small part of a cause map displaying some of the D&D concepts relating to the case study mentioned above and some additional information. It should be noted that for confidentiality reasons, this example has been modified and generalised; however, in practice the models built using the mapping technique ensure that the structure is informed by what actually occurred (bottom up) rather than by some template. Even this small, generalised map contains 16 feedback loops.

Figure 1: small section of a map illustrating some generalised D&D concepts with feedback loops highlighted

4 Part 1 of the claim document: the triggers

Once a cause map has been generated to explicate what happened in the course of a project, a start can be made on preparing the claim. The first part of the claim lays out the triggers to the Delay and Disruption – that is, those events or actions which have acted upon the project to set up the causal chains, acting exogenously rather than having been caused endogenously. Discussion with the project team and analysis of the qualitative cause model will normally identify the key triggers (which have to include both those that are self-inflicted and those which are to be claimed).

As the model represents a very rich and detailed picture of the project’s life the mapping software cannot identify the triggers automatically. However, clues to the triggers can be found with the analysis available within Decision Explorer (Eden and Ackermann 1998) rather than simply looking at the starting points of the model. This inability to detect immediately the triggers is because; in general when the authors have been developing the cause maps, the triggers have been surrounded by explanatory material (as indeed will be discussed below when referring to ‘tear drops’ of explanatory material). However, these effects that have triggered off the chains of causality are usually fairly clear to both the project team and the analysts, with the software acting as a check. It is these triggers that will form the exogenous inputs to the model.

The triggers will obviously vary from case to case. Two were mentioned in the case study referenced above (Ackermann et al 1997): −

Specification changes by the client, whether or not subject to a contract Change Order: while the direct cost of a specification change is often easy to see, the knock-on effects on cost and schedule are often grossly under-estimated (Rodrigues and Williams 1998);

-6-

−

Delays in client review and approvals. Often there will be points in the design / procurement process in which the client has to review documentation, or approve contractor’s plans; the contract might well contain target durations for such review/approval processes. However, the impact of not achieving these targets is difficult to evaluate without acknowledging feedback. This is particularly the case if there are a great number of small delays rather than 3 or 4 easily identified critical delays.

The following are also typical of triggers that appear frequently: −

client interference in the design: where the contractor designs (and sometimes builds) something fit for purpose, but the client insists on a different, equally valid (as seen by the client), item (the contract states “a door”, the contractor builds a yellow door, then the client insists on a replacing it with a green door), or “preferential engineering” (the contract states “a door”, the contractor builds a wooden door, then the client insists on it being a gold-plated door);

−

client interference in the project execution: this is a vague term which needs to be defined more tightly in any claim, but could cover a number of ways in which the contractor’s work would be slowed down by the client actions;

−

client insistence on extra design activity, such as answering spurious questions or comments on the design, or benchmarking the design against other working designs elsewhere, or unreasonable demands for research.

The triggers found will depend also on the contractual relationship – for example, whether the contract is of a fixed-price EPC (Equipment Procurement and Construction) type or a more partnership-type arrangement, such as EPC(M) (Equipment Procurement and Construction and Management).

However, Part 1 of the claim cannot be just a simple statement of what the triggers are, - through exploring the cause map, a detailed explanation of the triggers must be made, enhancing the understanding of what each trigger means and how they relate to one another. By looking at all of the statements coming into the trigger on the cause map, a fuller description of what constitutes that trigger is generated. This ‘drilling down’ can obviously be continued as long as there is further explanatory material in the model. Figure 2, shows a section of a map displaying the concepts feeding into the trigger concept “interference in design and procurement process”. This firstly gives more elaboration of what is meant by this concept. Secondly, since the concepts feeding into “interference” are likely to contribute to other triggers or supporting argumentation, it is preparing the reader for the systemicity, which is the characteristic of D&D (Eden et al, 1999, 2000). It also shows the direct relationship of one trigger on other trigger (e.g. two further key triggers are also shown on this map as they impact upon the idea of “interference”). From examining the direct and indirect (through the explanatory concepts) relationships between triggers, some idea of the dynamics and escalatory effect can be demonstrated.

-7-

Figure 2: ‘Tear-drop’ showing explanation of a trigger (Interference) with other associated triggers (italic, comic script) also present.

The trigger concept will directly correspond to key exogenous variables in the quantitative model. That is, in the quantitative model there will be a variable “interference” (or perhaps a small set of variables defining its different dimensions), which will be an input to the model, and will be defined as the collection of effects in Figure 2. These will be used in the quantitative analysis to see the effect of increasing this variable from zero to the actual amount of disruption experienced. This means that the material below the “interference” concept, unless it is important in its own right, will not be needed in the quantitative model (and thus the model is only as complicated as necessary (Phillips 1984). Nevertheless, the detail can be referred to, should it be necessary.

Map analyses such as Figure 2 typically take the shape of a “tear-drop”, the focus (trigger in this instance) making up the apex with the surrounding supporting evidence providing the main body.

5 Part 2 of the claim document: direct consequences

These “triggers” will also have some direct consequences that easily can be seen in the cause map by looking at what comes out of them. Thus, it is possible to show the immediate effects of the triggers upon the contractor, without dealing with the complex issues of portfolio effects and feedback loops (Eden et al 2000). Figure 3 gives an example, which takes the characteristic form of a “reverse teardrop”. Thus, for instance, in this (fictitious) example, interferences led to straightforward changes in scope, to “hard” measurable effects such as delays, and to “softer” more subjective issues, such as the feeling of dis-empowerment felt by engineers when their work is continually questioned, criticised and changed by a client (which isn’t to say the harder effects are easy to analyse, particularly when there are many small concurrent delays).

The claim will thus have a set of reverse tear-drops showing the immediate effects of each trigger. These reverse ‘tear-drops’ would ideally not over-lap at all, although this is usually difficult given the interrelated nature of the project (for example a second trigger comes in Figure 3). However, whilst this is problematic, care should be taken to ensure that they over-lap as little as possible, so as to see the immediate consequences of each trigger separately and individually. Where these effects over-lap and combine, the implications of this, and the management of them, in relation to structuring the claim, makes up the next part of the process and is addressed in the next section.

Figure 3: Reverse ‘tear-drop’ showing consequences of a trigger

-8-

6 Part 3 of the claim document: feedback and portfolio effects

Where there are instances of the reverse ‘tear-drops’ of Part 2 overlapping, we see two additional phenomena arising, both instances of the systemicity that defines D&D claims.

The first of these is the “portfolio” phenomenon, where a number of inputs combine to give an output greater than the sum of the inputs – for example, where a number of delays and disruptions together cause a weather window to be missed: a small subset of the inputs would have had a fairly minor effect, it is the impact of all of the inputs together that can have major consequences. This phenomenon can be displayed simply using the maps, and providing an explanation in the accompanying text. However, the phenomenon often has a more quantitative requirement: that is, clarifying where and how the magnitude of the resulting effect is greater than might have been intuitively expected from the magnitude of the combining inputs. In this case, the first stage is to note the phenomenon while recognising that the magnitude will be dealt with when addressing the quantification of the claim. It is worth noting that this process ensures that the claim produced is more comprehensive as the small events hitherto ignored begin to be surfaced. From this identification, participants begin to realise that the sheer number of minor instances, in conjunction with a set of more major difficulties, has had a significant effect on the project’s success.

The second, and in general more important, phenomenon is that of feedback (see e.g. Richardson 1991, and Forrester 1961). Tracking up the chains of argument from the individual triggers and their immediate consequences to subsequent consequences (including management responses to the immediate consequences) will begin to display negative and positive feedback loops and thus either controlling or vicious/virtuous feedback loops/circles. Even the simple example in figure 3, taking only the focus trigger number and tracking the effects one or two levels further leads to a slightly more complex map displaying 10 feedback loops, as shown in Figure 4.

As can be imagined, when the statements arising from more than one trigger are mapped, more feedback loops are detected. Decision Explorer software can be used to identify feedback loops (particularly those that the interview and quantitative analyses show had a significant effect on the project’s out-turn). However, in addition, it can also highlight which pairs of concepts (or rather the link between them) in the feedback loops are particularly potent, i.e. cause the greatest number of feedback loops. In addition, to aid further understanding and better present the consequences, the statements around these loops can be mapped in this stage of the claim preparation. The key feedback loops subsequently can be highlighted or mapped separately, to emphasise the effect. This part of the claim often reveals to the contractor management team how complex the project management was as

-9-

many of the loops are only identified as the different areas of the project (e.g. design, manufacturing etc) come together and the responses to one event impacts negatively on another.

Figure 4: Set of feedback loops from one trigger – feedback links are highlighted

7. The process used for quantifying the claim

In order to produce a credible D&D claim, the qualitative model must be able to be transformed into a quantifiable model in order to calculate a quantum claim. A quantitative analysis technique that could be argued to naturally follow on from the use of cause mapping and feedback is System Dynamics (SD). This has a track record since 1964 for explaining and modelling the systemic effects in projects. It has been used particularly notably by Pugh-Roberts Associates (part of PA Consulting), and a number of successful applications have also been reported at NASA (see discussion in Rodrigues and Bowers 1996). Because of its explanatory power (from the endogenous view it takes of the system it is modelling), it has had particular application in the post-mortem analysis of projects in litigations such as Delay and Disruption (D&D). The first major success was the Ingalls Shipbuilding case against the US Navy in the late 1970’s, in which an SD model was used to quantify the cost of disruption stemming from Navy-responsible delays and design changes; the total settlement was finally $447 million, and Cooper (1980) claims that the model was the basis for at least $200-300 million of this. Since this important precedent, the method has been used on a number of such litigations (Williams 1997). More recently, the importance of feed-back during a project has been increasingly recognised as being useful and powerful by project managers - as SD springs from control-theory ideas it is natural to model such effects.

Following the development of a cause map model, analysis reveals the nature of the feedback dynamics and other endogenous effects, giving rise to the skeleton of a SD model as an Influence Diagram (ID). Key concepts in the cause map model are highlighted in a particular style, and the same wording for the variable is used in the SD model so that their correspondence can easily be seen. Development of the original Cause Mapping model will thus proceed in parallel with development of a corresponding SD model. This is because development of each model can inform the development of the other: the map model forms the basis for the SD model; but the need to quantify relationships in the SD model will raise questions of the map model. Often this process will reveal gaps in the knowledge base of the modelling team that in turn will require further study with the contractor. Sometimes contradictions or errors will appear in the cause map model; analysis and trials with the SD model will bring more questions that again will be referred to the cause map model and possibly on to the client. The aim is to arrive at a cause map model and a SD model, in which the key variables

- 10 -

and their relationships correspond; and in which the cause map model (and ideally the structure of the SD model) has been agreed with the contractor.

Development of this model is not the subject of this paper, and is discussed in papers such as Ackermann et al (1997). But of course the description in the previous two paragraphs is very simplistic, as in any form of OR modelling. In particular, collecting data in practice is often difficult. Many of the parameters modelled in a project SD model are standard project-management parameters, so ought to be available in any well-managed project (see e.g. Turner 1993). But even here, the authors have found that often data is patchy, or contradictory. Other progress parameters are not generally collected, and where SD modelling is implemented within projects a metrics-collection programme has to be set up (see e.g. Rodrigues and Williams 1997). Still further parameters might be required to model subjective measures such as “stress” or “engineer passivity due to constant changes and resultant lack of progress” – here, modellers must rely on the legal idea of “best evidence” (where the plaintiff need only convince the judge that the data is superior (or at least equal) in quality to any other data provided) (Ackermann et al 1997). The modelling can be useful to highlight inconsistencies in the data. A particular feature of SD and other continuous simulation methods is the output of temporal graphs (e.g. spend against time or manpower-usage against time), which can be compared with actual or planned outcomes – although even here, there are difficult issues about what is “close enough”.

8 Part 4 of the Claim Document: The SD model

Part 4 of the claim, then, begins by mirroring the qualitative model developed in Parts 1-3 with a corresponding SD model. Once a model of the project “as bid” has been built, the disruptive effects on the project are modelled by exactly replicating the ID developed from the cause map. The resulting claim might appear similar to other D&D claims based on SD (Weil and Etherton 1990, Williams 1997, Ackermann et al 1997; others quoted in Rodrigues and Bowers 1996). However it differs in that the model can be seen to have been developed through the transparent process above: from triggers (explicated by the ‘tear-drops’ in Part 1), to the direct consequences and combined into portfolio effects and feedback dynamics. It is therefore built from the ground up rather than using an archetype (Senge et al 1994, Richardson 1996). It is also individually built for a particular project rather than using a generic model representing projects generally (Cooper 1997), although of course certain elements do commonly recur (such as re-work cycles).

The model is then run firstly to replicate the project as it should have occurred (i.e. switching off the triggers); and totals corresponding to the expected spend, the shapes of variables over time (such as the

- 11 -

number of workers employed over time) are also checked to ensure a reasonable replication of reality. Of course, the issues of validation go much wider than this and there is not space here to discuss them fully. (A structured framework of such tests for SD models is given by Forrester and Senge (1980); Barlas (1996) describes a more formal approach, which is used by Rodrigues (Rodrigues and Williams 1997); Ford and Sterman (1998) provide further useful discussion for models of design processes; and a full structure encompassing all of this work is being developed by Coyle (Coyle 1999)).

The model can then be run to show what the effects of a subset of triggers being applied have on the portfolios and feedback loops. This run will provide suggestions as to what the effects of those triggers upon the planned project would be (see for example Williams et al 1995, showing the effect of delays in client approvals, the effect of additional client comments, the effect of changes in scope, and then the effects of combinations of those triggers, demonstrating that the effect of two or more triggers was always (in this case) higher than the sum of the effects of the individual triggers). As well as showing the quantum of the total claim, this analysis can also be of value if certain triggers are accepted by a court or adjudicator and not others.

The model can also be used in a second type of analysis. This would show firstly the effect of all the triggers acting together, then what happens when a subset of triggers is removed. The aim of this is to suggest what would have been the effect “had that subset of triggers not occurred”. In other words, rather than looking at the undisrupted project and adding triggers on, we look at the total effect of all triggers and then take triggers off. This latter analysis is likely to indicate a greater D&D effect for each trigger than the former analysis, since Delay and Disruption effects often compound in a “2+2=5” effect. However, it is not clear what attitude a court would take to this type of analysis.

When such models are run, the overspend demonstrated will result from the combination of: the triggers, the direct consequences of those triggers, and the portfolio and feedback effects that come from the triggers (including any necessary management actions taken to accelerate the project). What can be done by running the model is to show the planned spend (running the model with no triggers) and the overall effect of the triggers (running the model with triggers). The difference between these two runs becomes the total claim. The model should represent the overall claim, with the issue of where the boundary between any “Direct” claim and D&D lies being secondary (Eden et al 2000). This assumes, of course, that none of the triggers are deemed to have been “self-inflicted”, otherwise the types of analysis described above (‘adding triggers on’ and ‘subtracting triggers off’) must be used to disentangle the Delay and Disruption effects from the client-caused triggers and the self-inflicted triggers.

- 12 -

9 Using elements of the qualitative model to illustrate key events.

One part of the claim documentary process that has been found to be very powerful is that of providing some form of illustrative device for the judge, advocate, or mediator. Whilst the SD model provides a single figure – the quantum - (contingent on the values placed on the variables) it does not provide a clear and easily understood representation of what occurred. Through the necessity of reducing the project’s life to its key variables, the model becomes cryptic. This lack of clarity is exacerbated when the project either involves state of the art technology, extensive engineering knowledge or incorporates substantial project and product complexity (Williams 1999). For the judge to be able to grasp an overview of what occurred and subsequently comprehend the consequences (causality) of events and determine who was responsible, in addition to matching this information with the SD models quantum, some form of assistance is helpful.

This help is provided through ‘stories’ of two or three trigger events. These events are chosen on the basis of their impact on the project, their sustainability in court (it is clear that the client is responsible for them – i.e. non-contentious), and their impact on one another. Once identified their history is outlined showing the clients interference (causing the event) and the subsequent ramifications in the form of a temporal causal diagram. The story shows how the events evolved over the duration of the project. The links or knock-on effects between the events are also identified and illustrated. Finally the process entails depicting how these relate to the SD variables. Thus the evolution of the event can be shown at the bottom half of the figure with the SD variables at the top (as the relations to them are of a different type to those showing temporal causality). Finally feedback is drawn into the picture.

The entire process aims to replicate that of a cartoon book where as the pages are rapidly thumbed through the characters change simulating movement. In this case the characters are the events moving through the course of the project. It is anticipated that whilst the story only displays the life of two or three events, the implicit message is that it is possible to construct stories for all of the hundreds of events experienced, and that the cumulative effect is significant.

10 Discussion and Conclusions

Modelling what occurred and creating the claim document whilst being separate activities obviously inform one another and are related. The model building provides the contractor and modelling team with the facility to identify the triggers and their consequences and from this to begin to construct a clear picture of causality. This is valuable in itself; however, it also assists with the process of

- 13 -

allocating responsibility, through the cause mapping model, with its rich detail illustrating all of the different nuances that can be considered; the document is able to draw on this rich source of information. Finally the production of the SD model, enables the total spend to be calculated. The logic of presenting the D&D element of the claim as triggers resulting in consequences which are thus quantified is thus a powerful argument.

This paper talks about the process of structuring a claim and the creation of the claim document without direct consideration of the legal team and their role. However, lawyers are involved throughout - the process of going through the steps noted above helps ensure that the models are legally sustainable (as the lawyers challenge the views from a legal perspective) and that the lawyers fully understand the project, what occurred and their ramifications.

The use of the cause-mapping model along with the associated Decision Explorer software for presentation and analysis also assists the structuring of the claim. Where the software is used with the group facility Group Explorer (allowing participants to directly input contributions, relationships and also rate and rank events) then a number of further benefits are accrued. First, it is possible to elicit significant productivity increases as members are able to rapidly make their contributions, explore one another’s perspectives and begin to work towards a common understanding. As the process commences with the development of the cause-mapping model, speeding up the process and encouraging wider contribution are valuable activities. Secondly, the anonymity built into the system allows participants to surface contradictions – critical for the sustainability of the model. The use of the model, whether it is managed by a facilitator with the participants exploring, refining and developing the model, or directly accessed by participants, promotes a sense of confidence/trust enabling further contributions (Ackermann and Eden 2001).

The contribution of this work is thus multifaceted •

It brings structure to an ill-defined concept (“D&D”) used in a “messy” complex situation.

•

It offers a solution to a practical problem: enabling a claim to be put forward for this illdefined concept with causality and responsibility demonstrated, and the quantum calculated in an auditable, defendable fashion; this is to be compared to the current (unjustifiable) practice of simply identifying the total spend, identifying a “lump” of unclaimed spend and claiming that as “D&D”.

•

It offers a novel procedure mixing modelling methods; the use of mixed modelling for presentation of the case (use of qualitative model to demonstrate causality (through stories or sections of the model) and the quantitative (SD) model for the quantum) attends to the various requirements experienced in putting together a claim. In addition it provides a coherency

- 14 -

check with one model compensating for the weaknesses of other and vice versa (Ackermann and Belton 1999). •

It provides a useful process when considering other areas of application. Two such areas that could benefit are new product development or strategy formulation. Through using the cause mapping technique to help with the process of surfacing the aims and objectives, possible concerns, different alternatives and potential opportunities and threats it is possible for a comprehensive view to be taken. Once the process has moved from that of surfacing and exploring to decision making (Ackermann and Eden 1997) it is possible to begin to use SD simulation modelling to test out the sustainability of potential options (in particular future scenarios that might take place) helping make more robust the outcomes and providing confidence to the management team when an initial drop in performance is experienced.

•

It yields both a process and an organizational memory (Eden and Ackermann 1998) for enhancing learning. The process of exploring what occurred not only results in a causal model that provides the basis for the claim document but also the very conversations that occur during its development change the minds of those involved, helping them understand the complexities and therefore providing valuable learning that can be effectively utilised on future projects.

•

It describes a methodology that ensures that the models are grounded in organizational reality – one that can be audited (as noted above) and one that can, through the process of exploration, reassure those involved (in any form of project, not just D&D projects) that what they were experienced was extremely complex (Ackermann and Eden 2001) and therefore give them back confidence in their own managerial competence.

- 15 -

References Ackermann, F., Belton, V., 2000. Mixing methods: Balancing Equivocality with Precision, submitted to Omega, accepted pending revisions. Ackermann, F., Eden, C., 1997. Contrasting GDSSs and GSSs in the Context of Strategic Change: Implications for Facilitation, Journal of Decision Systems, 6 pp 221-250 Ackermann, F. and Eden, C. (2001). Using Causal Mapping with computer based Group Support System technology for eliciting an understanding of failure in complex projects: some implications for organizational research. American Academy of Management Conference, Washington, August Ackermann, F., Eden, C., and Williams, T, 1997. A persuasive approach to Delay and Disruption - using "mixed methods". Interfaces 27 (2), 48-65. Barlas, Y., 1996. Formal Aspects of Model Validity and Validation in System Dynamics. System Dynamics Review, 12 (3), 183-210. Cooper, K.G. 1980, Naval ship production: A claim settled and framework built, Interfaces, 10, (6) 20-31. Cooper, K.G., 1997. System dynamics methods in complex project management. In, Williams, T.M., (Ed). Managing and Modelling Complex Projects. NATO ASI Series, Kluwer Academic Publishers, Dordrecht, Netherlands. ISBN 0-7923-4844-3 Cooper, K.G., 1994. The $2000 hour: how manager influence project performance through the rework cycle. Project Management Journal 25 (1), 11-24 Coyle, G. 1999. The validation of commercial system dynamics models. Paper given at OR41, Operational Research Society Conference, Edinburgh, September 1999. Cushman, R.F., Jacobsen, C.M. and Trimble, P.J. (Eds), 1996. Proving and pricing construction claims. Aspen Law and Business, Frederick, MD Eden, C, 1988. Cognitive mapping: a review European Journal of Operational Research 36 (1), 1-13 Eden, C. and Ackermann, F. 1992. Strategy development and implementation - the role of a Group Decision Support System. In, R. Bostrom, R. Watson and S. Kinney (eds) Computer Augmented Teamwork - A Guided Tour, Van Nostrand Reinhold, New York Eden, C., Ackermann, F., 1998. The Journey of Strategic Change. Sage, Chichester Eden, C., Ackermann, F and Williams, T. 1999. ‘Cognitive/Cause Mapping and Scenarios in Risk Management’ in the Proceedings of the Academy of Management, Toronto, 1999 Eden, C., Williams, T., Ackermann, F. and Howick, S. 2000. On the nature of disruption and delay, Journal of Operational Research. 51 (3) 291-300 Ford, D. and Sterman, J., 1998. Modeling dynamic development processes, System Dynamics Review 14 (1), 31-68 Forrester, J. and Senge, P., 1980. Tests for Building Confidence in System Dynamics Models. TIMS Studies in the Management Sciences, 14, 209-228. Forrester, J.W. 1961. Industrial Dynamics, MIT Press. Howick, S. and Eden, C., 2001. The Impact of Disruption and Delay when Compressing Large Projects: Going for Incentives? Journal of Operational Research Society, 52 (1) 26-34 Phillips, L.D., 1984. A Theory of Requisite Decision Models. Acta Psychologica 56, 29-48 Richardson, G. 1991 Feedback Thought in Social Science and Systems Theory. Philadelphia: University of Pennsylvania Press

- 16 -

Richardson, G. 1996. Problems for the Future of System Dynamics. System Dynamics Review (summer) 12,2: 141-157 Rodrigues, A.G. and Bowers, J., 1996. System dynamics in project management: a comparative analysis with the traditional methods. System Dynamics Review 12 (2), 121-139. Rodrigues, A.G. and Williams, T.M., 1997. Systems Dynamics in Software Project Management: towards the development of a formal integrated framework. European Journal of Information Systems 6, 51-66 Rodrigues, A.G. and Williams, T.M., 1998. Systems Dynamics in Project Management: assessing the impacts of client behaviour in project performance. Journal of the Operational Research Society 49 (1), 2-15 Rubin, R.A. et al, 1983. Construction claims: analysis, presentation, defense. Van Nostrand, New York. Senge, P., Kleiner, A, Roberts, C, Ross, R. and Smith, B 1994 The Fifth Discipline Fieldbook : Strategies and Tools for Building a Learning Organization, Doubleday, New York Turner, J.R., 1993. The handbook of project-based management. McGraw-Hill, London. Weil, H.B. and Etherton, R.L., 1990. System Dynamics in dispute resolution. Proceedings of the 1990 International Systems Dynamics Conference, pgs 1311-1324. Wickwire, J.M. and Smith, R.F., 1974. The use of critical path method techniques in contract claims. Public Contract Law Journal, USA, 7 (1), 1-45 Williams, T.M., 1997. The risk of safety regulation changes in transport development projects. In, K.Kahkonen and K.A.Artto (Eds) Managing Risks in Projects. E&FN Spon, London. ISBN 0 419 22990 6 pp. 284-293. Williams, T.M., Eden, C.L., Ackermann, F.R., and Tait, A., 1995. The effects of design changes and delays on project costs. Journal of the Operational Research Society 46 (7), 809-818 Williams, T.M., 1999. The need for new paradigms for complex projects. International Journal of Project Management 17 (5), 269-273

- 17 -

activities take longer

experience delay to individual activities

increase in parallel working

suffer delays in getting client approval have less productive manpower

have difficulty in getting system frozen increase in the amount of cross-impact between activities

get excess client comments

increase amount of rework

tighten time-scale work on elements for which system not yet frozen

Figure 1: small section of a map illustrating some generalised D&D concepts with feedback loops highlighted

- 18 -

Client interferes directly with designers and slows them down

FOCUS TRIGGER: interference in design and procurement process

Client interferes with commissioning and testing

Trigger 2: late reviews, decisions and approvals

Trigger 3: Changes of scope

client keeps within review-period by giving "holding" answer

Client Domments on re-issues of drawings after 'approval'

experience changes of scope throughout length of project

Client insists on taking part in choice of major suppliers

Client makes changes even though concepts agreed before contract

Client disagrees with definition of tests

client contemplates changes late in life of activities

Figure 2: ‘Tear-drop’ showing explanation of a trigger (Interference) with other associated triggers (italic, comic script) also present.

- 19 -

contractor prevented from achieving performance levels established under project Contract

construction delay engineering become more complicated, redundant & slower

constructor forced to do engineering rework

Trigger 3: changes in scope

increased parallelism in engineering

engineering Critical path affected

engineering effort slipped by x months

contractor experiences engineering delays

engineers feel disempowered

FOCUS TRIGGER: interference in design and procurement process

Figure 3: Reverse ‘tear-drop’ showing consequences of a trigger

- 20 -

less productive manpower work on elements for which system not yet frozen

contractor prevented fromachieving performance levels established under project Contract

construction delay Difficulty in getting system freeze

engineering rework

Increased cross-impact between activities

contractor experiences delays engineering effort slips

increased parallelism in engineering Tight time-scale

engineering Critical path affected

interference in design and procurement process

Figure 4: Set of feedback loops from one trigger – feedback links are highlighted

- 21 -

engineers felt disempowered