- Shopping Bag ( 0 items )
IN RECENT YEARS, the need for help in understanding project behaviour has been exacerbated, as projects have become more complex while time-scales have tightened, adding to project complexity. Project teams however, rarely pay sufficient attention to modelling the behaviour of projects and this can lead to inadequate risk analysis, ineffective project control, and uninformed "lessons learned".
Because the behaviour of complex projects is often puzzling, or counter-intuitive, we need models. This book presents a structured toolkit of techniques, developed gradually from the simple to the more complex, and provides examples to show where, when and why the techniques should be used. It looks at what causes project complexity, describes various aspects of project behaviour and develops modelling tools.
Starting with more traditional techniques modelling individual effects on projects, giving a full treatment (including some novel network concepts) the book enables readers to build breakdown - and network - type models. It also considers some of the more difficult aspects of modelling by moving into the "softer", more subjective, effects and then looking at systemic models of the effects as they come together. Finally, it looks at various methods of developing hybrid tools, to utilise the benefits of combinations of techniques.
Based on a wealth of practical experience and bringing together a range of tried and tested techniques, this book explains where the use of modelling can help estimate, monitor, control and analyse projects and thus lead to successful implementation.
Introduction to the book and the author
This book is about how to model the behaviour of complex projects. It isn't about how to manage projects-although you'll be expected to know the basics of project management-and reading this won't make you into a better project manager. This book is written for analysts and workers in project management who find themselves needing to model how a project behaves. This could be at any point in the project life-cycle-from feasibility studies before the project proper begins (when the modeller might be helping to advise and inform senior management about project strategies and risks) to project post-mortems after the project is completed (when the modeller might be helping a project team understand what happened in the project to learn lessons for the next project, or might be involved in preparing legal claims) and, of course, all points in between. The modeller can be fulfilling any of a number of roles: independent auditor, advisor to a project manager, part of a project support office, expert witness for a legal claim, consultant to a project client, and so on.
The book doesn't offer one particular point of view or technique. It collects together techniques that have been found useful by the author in his practice as a project modeller over the past 15 years. So perhaps a brief introduction to that experience would be usefulhere. The author is an operational researcher ("OR"-er) at heart, starting his career with a few years' lecturing in OR. He then moved to work in OR in an engineering and naval consultancy. There he quickly became interested in modelling some of the big defence projects, particularly looking at their risk before the projects began, and developing prototype project risk analysis computer tools. This field of work was given added emphasis at the time as there were political moves to pass risk from government to private industry-so, for example, industry had to be sure that it was not taking on too much risk, while government had to be satisfied that it wasn't being charged too much in terms of risk premium for having risk taken away from it. But the work was at that point given a particular incentive by the mandating of formal project risk analysis and management by the Ministry of Defence (MoD)'s Chief Scientific Adviser (CSA, in MoD jargon-he has a crucial role on MoD's Equipment Acquisition Committee). This was largely a consequence of the Nimrod project, a story which is well told by Humphries (1989), then Assistant CSA. But as well as pre-project risk analysis, the author was also involved in mid-project reviews, then, when the consultancy was taken over by a major defence contractor, acted as risk manager on major multi-company defence contracts. After nine years with this company, the author rejoined Strathclyde University's internationally known Department of Management Science, to research and carry out independent consultancy in project modelling and risk analysis (and also in his spare time to look after an MSc class in OR!). There he immediately got involved in the other end of project modelling: post-project claims for litigation. His first project was the building of the wagons for Le Shuttle in the Channel Tunnel (described in more detail in the list of projects below): a project which had significantly overspent for reasons which were at that point not particularly clear, and difficult to prove were the fault of the project client. A team led by Professor Colin Eden, with Dr Fran Ackermann (both well-known in eliciting information from groups and analysing the structure of causality to gain understanding of the dynamics in "messy" situations) and the author, built up models and evaluated the extent to which the overspend and time overrun was due to "disruption and delay" caused by the project client. This supported a large claim to this project client. This work has led to work on other disruption and delay claims by the same team (later joined by Susan Howick), and some of these will be referred to in this book. It also led to research and teaching within the manufacturer to learn lessons from the project. Carrying out project post-mortems is a very good source of knowledge and experience to help carry out risk analysis and risk monitoring-it is surprising how often, in practice, risk analysis is carried out by "risk analysts" while post-mortems are carried out by claims consultants, with little communication between them, instead of each being informed by the other.
Coming back to this book, as an introduction we'll look at why the book has been written, and why the subject is becoming of increasing importance; then the structure of the book will be briefly described and, finally, you will find out what you need to know about already to be able to read this book.
Why is there a need for this book?
In the next chapter, we'll describe what we mean by a "project" for the purposes of this book. Taking for now the common usage of the word, projects have always been important in the development of the environment in which the human race lives. This is true in two common senses of the word "project"-construction projects with a tangible output (the Pyramids; Stonehenge; the Great Wall of China) and projects which bring about a change in the organisation of society (the biblical bringing the Israelites out of Egypt, claimed by Martin Barnes as the first recorded major project; Columbus' setting out and discovering America). While it is true that society has always tried to improve incrementally the way it operates and produces goods, projects have through history formed the major stepping stones for step-changes. This continues to be true today, and indeed projects are becoming more important to industrial life. The preface to Turner (1993) extrapolates from statements by British Telecom to suggest that the annual spend on projects in the UK would be around £250mn.
A whole field of endeavour has therefore arisen to try to manage projects better. "Project management" had its origins in the chemical industry as far back as the 1930s, but really became well-defined and developed in the 1950s: the key point at which it became a discipline in its own right was in the Atlas and Polaris programmes. Gradually, methods were formulated and codified. Professional societies were developed: the US Society became the Project Management Institute (PMI); European nations' national societies joined in a society initially called "Internet" then later (as something else with this name became widespread!) this was renamed the International Project Management Association (IPMA). Degree courses (generally at Masters level) are offered at many universities around the world. PMI also has a widely recognised accreditation scheme, and many IPMA member societies have their own accreditation schemes.
But the nature of projects has been changing in recent years. One change has seen the continued rise of extremely large projects. While we have already mentioned a few giant projects that occurred before the mid-twentieth century, and of course many other major construction projects can be included, such projects are becoming more common. Kharbanda and Pinto (1996), for example, list over 40 projects underway in the mid-1990s in India, China and south-east Asia alone, each forecast to cost over $1bn. These are mainly construction projects, but engineering projects are also becoming larger in some industries as the investment needed to develop new products increases-the break-even point of an aircraft development programme is generally held to be at least 300 units, and the development cost of a new model can approach the sales equivalent of the order of 100 units. But, along with their size, it is generally held that the complexity of projects is also increasing: "Construction projects are invariably complex and since World War II have become progressively more so" (Baccarini 1996). What complexity is, and why it is increasing, is explored in more detail in Chapter 4. But it is worth noting two compounding causes for projects increasing in complexity (from Williams 1995c). The first is that products being developed today are increasingly complex themselves, which leads to more complex projects. The second is that projects have tended to become more time-constrained, and the ability to deliver a project quickly is becoming an increasingly important element in winning a bid; and furthermore, there is an increasing emphasis on tight contracts, using prime contractorship to pass time-risk on to the contractor, frequently with heavy liquidated damages for lateness. Chapter 4 will look further into how this compounds increasing project complexity, and Chapters 8 and 9 will look at how to understand and model this compounding.
The last four decades of project management are characterised according to Laufer et al. (1996) by an evolution of models appropriate to changing dominant project characteristics: they characterise the 1960s by scheduling (control), for simple, certain projects; the 1970s by teamwork (integration) and the 1980s for reducing uncertainty (flexibility), both for complex, uncertain projects, and the 1990s by simultaneity (dynamism) for complex, uncertain and quick projects. These latter are precisely the challenges we will face in this book, and it is the increase in such projects that has given rise to the need for models to support the projects, and has led to a need for this book.
One aspect of the future is obvious: all new undertakings will be accomplished in an increasingly complex technical, economic, political and social environment. Thus project management must learn to deal with a much broader range of issues, requirements and problems in directing their projects to successful conclusions. Certainly, project management in every field will be called upon to address complexities and risks beyond anything experienced in the past (Tuman, 1986).
So how successful have projects been in the past? If we have been successful at bringing projects in, then perhaps new methods aren't needed. Some anecdotal evidence is available: for example, Cleland and King (1988b) cite half a dozen American examples, including Forbes magazine's comments on the US nuclear power programme, and the well-known case of the $8bn Trans-Alaskan Pipeline, of which the State of Alaska claimed that an $1.6bn spend was "imprudent". This evidence is not sufficient to draw firm conclusions. However, there has been a certain amount of work collecting data on historical project out-turns, beginning with work such as Marshall and Meckling (1959), who collected data to try to predict overruns. Let us look first at four studies done in the late 1980s.
The key text in summarising the historical evidence, at least up to 1987, is Morris and Hough (1987). They list 33 references containing databases of project out-turns, and the reader is strongly recommended to read the beginning of this book to study the conclusions drawn. Morris and Hough's preface to their list of databases states that:
Curiously, despite the enormous attention project management and analysis have received over the years, the track record of projects is fundamentally poor, particularly for the larger and more difficult ones. Overruns are common. Many projects appear as failures ... particularly in the public view. Projects are often completed late or over budget, do not perform in the way expected, involve severe strain on participating institutions, or are cancelled prior to their completion after the expenditure of considerable sums of money.
In summarising their database, they state that, "There are hardly any reports showing underruns.... In all the other cases, representing some 3500 projects drawn from all over the world in several different industries, overruns are the norm, being typically between 40 and 200 per cent, although greater percentage overruns are found in a number of groupings, particularly certain defence projects and in the US nuclear industry." (This last figure relates to cost overruns.)
It should be noted, however, that Morris and Hough also give a number of caveats to their cost overruns which are worth considering, as we will need to bear these in mind when we look at our example projects in the next section. First, some of the "overruns" relate to customer-requested changes. Some of these are simply increased order quantities (indicating a successful rather than an unsuccessful project). Regulatory changes, such as in the US nuclear industry, causing "a substantial proportion of the cost growth in this industry", are also included in this category. However, this is perhaps too simplistic-for semi-public or mixed private/public projects, which increasingly make up mega-projects, regulation changes are possibly the major risk, and will feature in the discussion of systemic effects in Chapers 8 and 9. The second most important caveat is the treatment of escalation. Many government projects specifically exclude any allowance for inflation in the tender price, and escalate payments in accordance with some accepted index; an example quoted in Morris and Hough is that the "Central Electricity Generating Board (CEGB) discounts all costs back to the project's budget base dates. This makes comparison of overruns on UK nuclear power plants with those experienced by the US nuclear plants, for example, almost impossible to make accurately-US plant costs include not only inflation but generally the finance charges for funds used during construction". Third, the treatment of contingencies differs from datum to datum: quoting again, "The Apollo programme, for example, came in at $21 billion, only $1 billion over its original estimate. Few know that the initial estimate included $8 billion of contingencies ... Very few public projects have even semiformal contingency budgets". Finally, of course, cost- and time- out-turns are not the only measures of project success, a subject which will be considered further in Chapter 2.
A major study carried out since Morris and Hough is Merrow (1988). This is an analysis carried out with RAND on a database of 52 projects, all worth over $500mn. Analysis showed that many projects met their time-target-the average slippage was 17%-but there was a clear overrun on cost-the average overspend was 88%, although the caveats made by Morris and Hough must be made here, since it is not clear what the original budgets contained for the projects. The main problem causing overrun was again found to be regulatory problems, and we will revisit this question of regulatory problems later in the book, in particular, in the naval ship life extension example in Chapters 7-9.
Excerpted from Modelling Complex Projects by Terry Williams Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
1. This book.
Introduction to the book and the author.
Why is there a need for this book?
The structure of this book.
What do I need to know before I read this book?
What is a project?
What are project objectives?
Basic project management techniques.
Projects referred to in this book.
What is a model?
Why do we model?
Modelling in practice.
4. What is a complex project?
What is complexity? Structural complexity.
What is complexity? Uncertainty.
What is complexity? Summary.
Tools and techniques-and the way ahead.
5. Discrete effects and uncertainty.
Uncertainty and risk in projects.
Cost risk: additive calculations.
Time risk: effects in a network.
Analysing time risk: simulation.
Criticality and cruciality.
The three criteria and beyond.
6. Discrete effects: collecting data.
Collecting subjective data: identification.
Collecting subjective data: general principles of quantification.
Collecting subjective data: simple activity-duration models.
Effect of targets.
7. The soft effects.
Some key project characteristics.
Client behaviour and external effects on the project.
Subjective effects within the project.
Summary and looking forward.
8. Systemic effects.
A brief introduction to cause mapping.
Qualitative modelling: simple compounding.
Qualitative modelling: loops.
9. System dynamics modeling.
Introduction to system dynamics.
Using system dynamics with mapping.
Elements of models.
How effects compound.
10. Hybrid methods: the way forward?
Adapting standard models using lessons learned from SD.
Using conventional tools to generate SD models.
Using SD and conventional models to inform each other.
Extending SD: discrete events and stochastic SD.
The need for intelligence.
11. The role of the modeler.
What makes a good modeller?
Stages of project modeling.
Appendix: Extension of time claims.