University of Sydney Library Electronic Item

Author of chapter: Williams, Terry

Title of chapter:

Assessing & building on the underlying theory of Project Management in the light of badly over-run projects. Proceedings of PMI Research Conference, 2004, 11-14 July, Renaissance London Chancery, London, United Kingdom pp.111.

Source:

COMMONWEALTH OF AUSTRALIA Copyright Regulations 1969 WARNING This material has been reproduced and communicated to you by or on behalf of the University of Sydney pursuant to Part VB of the Copyright Act 1968 (the Act). The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice

Ref No: 1

Assessing and Building on the Underlying Theory of Project Management in the Light of Badly Over-run Projects
Terry Williams, PhD, PMP, Strathclyde University, UK

There has been a great deal of prescriptive work done in project management leading to extensive guidance and bodies of knowledge, and in particular A Guide to the Project Management Body of Knowledge (PMBOK Guide). And this has served the project manager well, enabling many projects to be finished more effectively and efficiently. However, experience shows some projects to overrun or overspend hugely. This has led in very recent years to calls either for new project management methods, or for changes to the underlying project management methodology. But we need to understand not just what happens in practice but why it happens. Only then can we see how our methodologies fail and where they need rethinking. And, gradually over the past 20 years a number of centres worldwide have developed lines of research into the behavior of large projects, seeking to understand and model the dynamics, frequently using System Dynamics (SD) techniques. This work explains the systemic effects that can come into effect in a project, and the (sometimes counterintuitive) effect of management actions. This paper looks at the underlying theory implicit (but rarely explicit) in the prescriptive project management work (as exemplified by the PMBOK Guide). It will highlight a number of underlying, generally unstated, assumptions, and point out a number of particular emphases within the PMBOK Guide. It will then review the work on project behavior described above, describe how it clashes with each of the three assumptions of traditional bodies of knowledge, and outline what these SD models tell us about why failures occur in projects (which might have been well managed by traditional project-management methods) using ideas of project complexity as a framework. Recognition of some of the problems of traditional project management methods has given rise to a number of management methodologies in which the project emerges rather than is fully pre-planned. These methodologies are usually identified by words such as lean or agile and are frequently seen as being in opposition to PMBOK Guide-type methodologies. This paper will use the conclusions from the SD work to start to classify projects by looking at their propensity for systemic effects, indicating different management styles that might be appropriate for different types of projects. This aims to enable project managers to choose effective ways to manage their projects based on understanding and modelbased theory. The implications for the PMBOK Guide will be studied as the paper seeks to build upon the PMBOK Guide rather than suggest opposed alternatives.

What actually happens in project management practice?

PMI and other project management societies have carried out very large programs to define the core knowledge of Project Management, culminating in PMIs case in the A Guide to the Project Management Body of Knowledge (PMBOK Guide) (Project Management Institute, 2000), now an American National Standards Institute standard. Project management as set out in this work is presented as a set of procedures that are selfevidently correct: following these procedures will produce effectively managed projects; project failure is indicative of inadequate attention to the project management procedures. Does this then mean that we know how to manage projects and when these procedures are followed then project success or at least a reasonable level of success logically follows? Well, that doesnt appear to be the case. It is commonly observed that many projects fail in various ways (Buchanan, 1991). One of the most well known texts outlining such failure, at least up to the mid-1980s, is Morris and Hough (1987). They list 33 references containing databases of project outcomes, prefacing the list thus: "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 [referenced to a Financial Times article], 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 summarizing their database, they state that "There are hardly any reports showing underruns. ... In all the other cases, representing some 3,500 projects drawn from all over the world in several different industries, [cost] overruns are the norm, being typically between 40 and 200 percent, although greater percentage overruns are found in a number of groupings, particularly certain defence projects and in the U.S. nuclear industry." Studies since then have shown similar results. In the 1980s, for example, the National Audit Office (1986) found real increases of 91%, and a survey of 246 U.S. Army programs by Arbogast and Womer (1988) showed cost over-runs of -21% to +437% (mean 15%). Studies in the 1990s generally found similar results, although with less-easily quoted statistics (see some references in Williams, 1995). Most collections studied particular industries, such as Flyvberg, Holm, and Buhl (2002), who covered 258 major transportation infrastructure projects and showed an average overspend of 28% with 90% projects overspent.

While it is not clear whether project managements track record is improving statistically, certainly high-profile project failures are common at least in the newspapers. Yet project management procedures have been espoused and are being followed. It seems clear that project management is not consistently delivering the benefits it promises; indeed, Koskela and Howell (2002) go as far as to say In the present big, complex, and speedy projects, traditional project management is simply counterproductive; it creates self-inflicted problems that seriously undermine performance. (It is clearly complex projects for which project management is failing, and the meaning of this word will be looked at below). To consider why project management is not performing as it claims it should, we need to look both at the assumptions and theories underlying project management, and also at what actually happens in practice and why Packendorff (1995) calls for more research into projects as action systems (i.e., what does happen rather than what should). A stream of work modeling project behavior over the past 20 years has given rise to some explanations for some project failures. In parallel, there has been a set of work questioning the theoretical basis of project management, some of which will be described in the following section.

The theoretical basis of project management

A statement often made within the project management profession is that there is a lack of underlying theory. Turner (1999) states: Project management lacks a strong theoretical base. Yes, there is an extensive body of knowledge, including many familiar tools and techniques. However, the Project Management Body of Knowledge is not based on a series of premises, from which a strong, consistent theory is derived, but more on conjecture. The Body of Knowledge is based more on empirical evidence than certain knowledge.so belief that one approach to managing a project will be better than another is still to a large extent based on faith than sound knowledge. (The author was talking about International Project Management Association (IPMA) work rather than PMI work, but equally applicable to PMIs PMBOK Guide). A PMI-funded review of project management research over the previous 40 years (summarized in Kloppenberg & Opfer, 2002) does not mention theory, nor does a PMI report on the future of project management (Project Management Institute, 1999). There are three particular underlying assumptions to the various bodies of knowledge that need to be drawn out here (we shall talk about the PMBOK Guide, but the comments are applicable to other project management bodies of knowledge also). The first underlying assumption is that project management is rationalist (Lundin, 1995) and normative (Packendorf 1995). Project management presents itself as self-evidently correct (and therefore presumably an explicit espoused theory is not essential), and provides a normative set of techniques. No justification is necessary, as there is no question that the PMBOK Guide is correct. Secondly, the ontological stance is effectively positivist; or at least, using Morgan and Smircichs (1980) spectrum of six views of the nature of reality, the project management bodies of knowledge would take one of the two concrete views, as contrasted by views that the world and reality are not objective and exterior but socially constructed. The third underlying assumption is that project management (as viewed by the PMBOK Guide) is particularly concerned with managing scope, and that this can be managed by decomposing the total work effort into smaller chunks of work with sequential dependence (Koskela and Howell, 2002a) giving rise to the standard decomposition models (Work Breakdown Structures and project networks being the two fundamental models). Koskela and Howell go on to show that the theory of the project implicit in this is that of management as transformation of inputs to outputs. Koskela and Howell (2002b) add some flesh to the bones by suggesting there are underlying assumptions that tasks are independent (apart from sequential relationships), tasks are discrete and bounded, uncertainty about requirements and tasks is low, all work is captured by top-down decomposition of the total transformation, and requirements exist at the outset and they can be decomposed along with the work. Now clearly the PMBOK Guide does look at integration of the parts, but this is only a small proportion of the PMBOK Guide. These three assumptions lead to three particular emphases in the PMBOK Guide. The first emphasis is a heavy emphasis on planning in the PMBOK Guide. Planning based on analysis always precedes action (Packendorff, 1995). Koskela and Howell (2002a) show that the management theory implicit in the PMBOK Guide is management-as-planning (Johnston & Brennan, 1996). Koskela and Howell (2002a) point out that PMBOK Guide describes one executing process, two controlling processes but ten planning processes. And this is not driven by PMI, but by users. PMI undertook a survey of practitioners (the 2002 Technical Needs Assessment covering 334 project management professionals), and in answer to the question please indicate the priority that PMI should place into research and development in each area [of the five project-management process groups], the highest place was given to planning, with an average score of 4.3 on a Likert scale of 1-5,

with executing lying fourth out of five with a score of only 3.6 (Stefanou 2003) (interestingly, and relevant to the previous assumption, in the same survey, management of scope also got the highest score in the knowledge areas). Second, and following the emphasis on planning, is the implication of a conventional control model, often called the cybernetic-control or thermostat model. Once a project starts, progress and performance are continuously assessed against the project plan (epitomised perhaps in the earned value concept (Fleming & Koppelman, 2000)). This model can be seen say in Harrisons (1985) control cycle, which shows Plan and budget, management decision and resource allocation Project execution Measurements of input & output The control analysis Plan and budget However, while this model is implicit in the PMBOK Guide, as stated above the PMBOK Guides emphasis is on how to plan rather than how to control. Third, fundamental to the idea of project management is that the management of the project is generally decoupled from the environment. The project plan sets out the objectives and motivations of the project, and the project manager is left to execute the project plan (following the management-as-planning philosophy). That is not to say that risk management doesnt play a key role in the PMBOK Guide (e.g., Pritchard, 2001), but the view of the PMBOK Guide is fundamentally that the project is to be managed according to the Plan, and that changes to the Plan should be rare and, if possible, avoided. While it is clearly incorrect for Morris (2002) to point to external risks that Morris and Hough (1987) showed were the cause of project failures (client-driven specification changes, weather, geotechnical problems, among others) and say that few, if any, of these factors are even addressed today in much of the project management literature; however, there is clearly a sense in the PMBOK Guide that perturbations or risks are there to be managed away to bring the project back to the Plan. A project is seen as an island of order in the disorderly flux of organizational life (Dubinskas, 1994 and Lampel, 2001, quoted in Melgrati & Damiani, 2002). giving instructions to passing measurements to passing data to which gives information back to

Systemic project models extending our understanding

Our understanding of how complex projects behave has been extended over the past two decades by a body of work in systemic modeling. A complex system, says Simon (1982), is one in which the behavior of the whole is difficult to deduce from understanding the individual parts that is, when we look at a complex project, while we might know the effects that impacted upon the project and the outcomes from the project, it can be difficult to understand intuitively how the latter came from the former. It is here, we will see later, that traditional PMBOK Guide-type methods can become unstuck. This work is particularly due to two teams. The first was Cooper (1980) and others at PA Consulting and also MIT, who use System Dynamics (SD) methods see, for example, Graham (2000). Cooper, Lyneis, and Bryant (2002) point to a number of factors that inhibit successful project analysis, including the difficulty in determining the true causes of project performance. They discuss feedback structures as the root of the complexity, pointing to three particular structures that they say generally underlie project dynamics: the main one being the rework cycle (including discovery of unexpected rework) (see also Friedrich, Daly, & Dick, 1987), the other two being feedback effects on productivity and work quality, and ripple effects from upstream phases to downstream phases (see Cooper, 1993, and Lyneis, Cooper, & Els, 2001). The second team at Strathclyde University, UK, has been involved in post-mortem analysis of a range of projects. Eden and Ackermann had already developed cognitive/causal mapping techniques appropriate for studying structures of causality in a project, and these provided a natural combination with System Dynamics: the former providing the structure to apparently messy problems, with a logical structural interface to the latter for producing quantitative results. The techniques used on the first claim, the Channel Tunnel Shuttle train-wagons, are described in Ackermann, Eden, and Williams (1997), and all successive claims have been characterised by the use of these techniques. Results are similar to, but more general than, the PA results, with explanations for project behavior deriving from systemic interrelated sets of causal effects. The key results derive from dynamics set up by these effects turning into positive feedback loops, or vicious circles, (or vicious cycles) producing catastrophic over-runs. Many of the key loops identified in this work are set up and exacerbated through management response to project perturbations - hence the sometimes counter-intuitive effect of such actions, sometimes highly magnifying small effects (see Eden, Williams, Ackermann, & Howick, 2000; also Williams, 2002). 4

Over the last two decades, a fair amount of literature has built up modeling the systemic effects in projects using System Dynamics; a good review of literature up to the mid-1990s is given by Rodrigues and Bowers (1996). This work clashes with each of the three assumptions described for the traditional bodies of knowledge above. The main clash is with the third assumption. These systemic models show behavior arising from the complex interactions of the various parts of the project. They demonstrate how behavior arises that would not be predicted from an analysis of the individual parts of the project, and thus show how the traditional decomposition models in some circumstances can be inadequate. Koskela and Howell (2002a) start to quote a little empirical evidence that decomposition models do indeed fail to capture the behavior of a whole project, but the systemic modeling work has given some more underlying explanation. Since the behavior is complex and nonintuitive, then it is not surprising that the first assumption is also challenged: Project management techniques are thus not necessarily self-evidently correct, which gives a problem to the normative nature of the PMBOK Guide. The second assumption is also challenged. The models incorporate not only real data but also management perceptions of data. The models differ from the project management bodies of knowledge in their emphasis on, or inclusion of, soft factors as well as the concrete aspects. These soft variables can often be an important link in the chains of causality that set up feedback loops, and thus can be critical in determining the project behavior; such variables might include subjective effects within the workforce, such as morale, schedule pressure, the effects of overtime and overcrowding, etc., as well as the effects caused by the project client (scope changes, delays, interference, lack of client-contractor trust, etc.), or effects caused by management decisions themselves. These models thus capture the socially constructed nature of reality in a project.

Since the emphases of project management outlined above are derived from the three assumptions, it is reasonable then to look to this body of work to see if it can begin to offer some explanations as to why the use of project management and these emphases can lead to ineffective management of projects and sometimes even failure.

Why do project management failures occur?

What then do these systemic models tell us about why failures occur in projects well managed by traditional project-management methods? The key is that the failures analyzed by these methods are in complex projects. Williams (1999) proposed that project complexity can be characterised by two dimensions, each of which have two sub-dimensions, and while different authors argue about the definitions and measurement of these dimensions (and the definition of the word complexity), these dimensions are well represented throughout the literature. Williams dimensions are: structural complexity, made up of (see Baccarini, 1996) the size, or number of elements in the project, and the interdependence between these elements uncertainty, made up of (Turner & Cochrane, 1993) uncertainty in project goals, and uncertainty in the means to achieve those goals. It is where either of these complexity dimensions become important that there are important lessons to be learned from the systemic modeling. PMBOK Guide techniques are clearly designed for projects with large numbers of elements that is, where the first sub-dimension for the structural complexity dimension is large. Equally clearly PMBOK Guide assumes these elements are related into structures. However, these structures are subject to very limited types of interdependence: Work breakdown structures are hierarchical; Critical Path activity networks are sequential and so on. In terms of Thompsons (1967) classical analysis of organisational dependencies, the structures combine pooled dependencies (in which each element gives a discrete contribution to the project, each element proceeding irrespective of the other elements) and sequential dependencies (one element's output becomes another's input). However, Thompson has a third type, reciprocal (each element's output becomes inputs for other elements, with the relationship either returned or moving round in a cycle (eg A BCA), so the actions of each must be modified to the actions of others). This latter type of interdependence is what particularly contributes to complexity. Shenhar and Dvirs (1996) typology of projects has roughly the same two dimensions (the second is specifically technological uncertainty) but in their definition of structural complexity

or scope they divide projects into three categories: assembly, system and array; their results clearly differentiate between the different system-element interdependencies implied by these different categories. The systemic modelling work shows that where the interdependence increases, particularly where there are reciprocal dependencies allowing feedback effects to develop, the project will behave in a way difficult to predict intuitively and certainly at variance to how PMBOK Guide-type techniques would indicate. Even more so, PMBOK Guide-type methods are unsuited to projects under high uncertainty. Frequently events arise that compromise the plan at a faster rate than that at which it is practical to re-plan (Ashton, Johnson, & Cook, 1990). The irony of this unsuitability is pointed out by Melgrati and Damiani (2002), who contrast one of the main reasons for the spread of project management in companies, namely environmental complexity and uncertaintyand exposure to external change with the philosophical underpinnings of PMBOK Guide-type traditional project management methods, concluding In short, the Cartesian clarity of inner structures clashes with the increasing porosity of projects to complex contexts that they seek to deny (Ulri & Ulri, 2000). The risk, in short, is that the idealistic island of order may suddenly turn into a more realistic, very classic, iron cage. The problems that this can cause are highlighted, for example, in Flyvbergs excellent analysis of modern megaprojects (Flyvberg et al, 2003): In terms of risk, most appraisals assume, or pretend to assume, that infrastructure policies and projects exist in a predictable Newtonian world of cause and effect where things go according to plan. In reality, the world of megaproject preparation and implementation is a highly risky one . As discussed under the Theoretical Basis above, project management as defined by the bodies of knowledge are heavily based on the management-as-planning principle. Johnston and Brennan (1996) discuss the underlying assumptions of this principle, in particular that management draws up plans and then there is a largely autonomous causal loop between sensing and acting. They go on to point out that these assumptions are seldom valid in reasonably complex or changing environment. (Similar warnings in the operations management field were given in Machin and Wilson in 1979, pointing out that planning is artificial, removed from the real situation, whereas control has much less theoretical basis; their paper tried to narrow the gap between planning and control). It is when uncertainty affects a traditionally managed project that is structurally complex that the systemic effects discussed above start to produce problems. A well planned project that faces no significant outside influences can follow its plan. A project that is structurally simple can be replanned in the face of changes from the outside environment. However, a structurally complex project when perturbed can become unstable and difficult to manage, and the catastrophic over-runs described above can occur. And the underlying idea of the apparently selfevidently correct set of project management procedures (which cannot cope with such projects) gives no help to project managers, indeed the existence of a perfect model in the PMBOK Guide reinforces the belief that greater formalization can overcome the difficulties of complexity and rapid change (Hodgson, 2002).

New project management styles

Recognition of the problems inherent in prescriptive procedures such as PMBOK Guide has led to the development of contrasting management methodologies. Johnston and Brennans (1996) suggestion in general management is to move from management-as-planning (as noted above, the PMBOK Guides main emphasis) to management-by-organizing, where the manager is seen as designer, coordinator and enabler of otherwise autonomous activities.In short, the management is seen as organizing things rather than planning or scheduling them. For projects in particular, Molin (2003) points out that projects by definition are one-off and unique, so perfect planning is impossible. He distinguishes between the planning approach to projects (in which a well-defined path to predetermined goals is assumed) and the learning approach which sees the project as an ambiguous task with changing objectives as the project proceeds. Clearly, the bodies of knowledge such as PMBOK Guide are firmly placed in the first of these approaches, while the second approach sounds appropriate for projects exhibiting uncertainty in a Turner and Cochrane (1993) sense. (Note that dealing with uncertainty in goals and methods, sometimes also called ambiguity, is not the same as risk management, which does lend itself to structured PMBOK Guide-style planning as the project manager tries to avoid deviations from the pre-defined project plan). This type of idea has given rise to a number of management methodologies in which the project emerges rather than being fully pre-planned. These methodologies are usually identified by words such as lean or agile. The leading domain for developing agile methods is the software industry, because of the highly uncertain nature both of its project goals and means (Turner & Cochrane, 1993). Highsmith (2002) describe some wellknown techniques such as Adaptive Software Development (which arose out of Rapid Application Development, or RAD), Extreme Programming, and Scrum. All of these are oriented to projects where changes, uncertainty, and ill-defined requirements are pervasive features. In Scrum (Schwaber, Needle, & Martin, 2001)

for example, development takes place over 30-day periods called sprints, and daily scrum meetings to identify problems and report back on status; there is no pre-defined activities or work breakdown structure, rather the set-off remaining requirements (the product backlog) is re-visited each month to evaluate remaining work, and at this point the expected project cost and duration is also re-estimated. There is significant evidence that these methods are finding support in practice as they are found to be effective and successful (Udo & Koppensteiner, 2003). Some call such project environments chaordic as they try to capture elements of both chaos and order (see, e.g., Hock, 1999). At the same time, the construction industry, while their projects are not generally subject to the same level of uncertainty as software projects, has also generated some similar agile techniques. One such is Last Planner, developed by Ballard (2000) and described in Koskela and Howell (2002b). Activities that should be executed have their prerequisites prepared; they then become activities that can be executed; and in weekly planning some of these are selected as those that will be executed.

Different management styles for different types of project

So which management style should be used for which type of project? There have been a number of empirical studies recently trying to categorize projects and look for good management styles for the different categories. These have generally used parameters to distinguish between categories of projects similar to the complexity dimensions described above. Shenhar (2001) in an empirical study used Shenhar and Dvirs (1996) typology described above (technological uncertainty ranging from low to super-high, and scope divided into assembly, system and array). In this study, project management styles were clearly and obviously - dependent on the type of project. Low- and medium-technological-uncertainty projects tended to be managed in a formal and rigid style starting from a formal contract; in contrast, in high-technological-uncertainty projects, the project manager had to employ a much more flexible attitude and trade-offs occurred between project requirements; and in super-high-uncertainty projects management required high levels of flexibility and tolerance for change, and high awareness of potential problems. System projects required more integration than assembly projects. And so on. But these styles are defined by the types of project and the question how will a deviation of actual management style from these types affect the project success and its effectiveness? was left for further studies. Lewis, Welsh, Dehler, and Green (2002) carried out an extensive study of product development projects, and divided the project management styles they found into planned (i.e., along traditional PMBOK Guide lines) and emergent. They found that the planned (formal, mechanistic) style was blind to the outside environment and thus led to stability; the emergent (fluid) style led to creativity. Effective product development needed complex mixtures of the two styles, they found. Payne and Turner (1998) based a classification on the Turner and Cochrane (1993) uncertainty matrix and used a questionnaire with 150 replies. Projects with well-defined goals and methods, they said, lend themselves to activity-based approaches to planning that is, traditional PMBOK Guide-type methods. Projects with welldefined goals but for which the method of achieving the goals is the main point of the project (i.e., product development) are best dealt with by goal-directed approaches (i.e., based on Andersen, Grude, & Haug, 1996), they suggest. Where the goals are poorly defined but the methods are known, then life-cycle-based projects such as Prince (CCTA, 1998). However, they do not propose a specific methodology for ill-defined methods and goals. Rich, Loch, and De Meyer (2002) try to put the selection of project-management strategies onto a mathematical basis, distinguishing between instructionist (classical PMBOK Guide-based), learning, and finally selectionist approaches, where the last one represents management under which learning is ineffective or the environment inaccessible so that the optimum policy is often to launch multiple project efforts simultaneously to see which is the most successful. Again, the determining factors to select the best strategy in a project are said to be uncertainty or ambiguity (noting the comment above that risk management does lend itself to structured PMBOK Guide-style planning; this is quite different from ambiguity), and complexity. All of these studies are trying to relate strategy and success. However, project success is a very ill defined concept, and efforts have been ongoing to try to define what is meant by project success at least since the 1986 PMI conference (see many of the papers in Project Management Institute 1986). Shenhar and Wideman (1996) try to relate the definition of success to the structure developed by Shenhar and Dvir (1996) above, suggesting that higher technological uncertainty projects had longer-term success criteria. (That is, a lowtechnological-uncertainty project would have success classically defined as immediate completion on time/cost/to-specification; medium uncertainty would look longer term; for high-technological-uncertainty projects a customer would accept overruns but is looking for significant improvements in the short and medium term; and for super-high uncertainty, immediate over-runs would be most likely but are aimed to bring a

quantum leap in short-term effectiveness and very high benefits in the medium and long term.) Tatikonda and Rosenthal (2000) similarly suggest that more sharply defined success criteria than the standard completing ontime/to-cost; they studied 120 projects to indicate that increasing technological novelty was related to higher unit-cost and time-to-market results, while project complexity was defined by with higher unit-cost; but they point out that their results were more specific than that, and that detailed project task characteristics and specific project goals needed to be studied.

Conclusion
Project management techniques, as espoused in, say, the PMBOK Guide, serve well for many projects. However, the systemic modeling work shows that there are many projects for which conventional management methods fail. Work on project classification and the systemic models explain how large overruns can be brought about in projects that are complex and particularly for those with uncertainty in their goals or their means. For such projects, the normative instructions for project control in the PMBOK Guide, based around the idea of bringing a project back onto a pre-defined plan, can actually cause significant disadvantages to the projects. Thus, rather than simply ignoring the PMBOK Guide and moving to contrary techniques, such as agile techniques, what is needed is more work to define project-nature metrics that can indicate which projects are amenable to PMBOK Guide-type management, and which have a propensity for systemic effects, so that an appropriate management style (i.e., planned or emergent) can be specified as indeed the authors in the previous section above have started investigating. This is a paper describing ongoing thinking and work, and clearly this is one step towards finding appropriate solutions. But it is clear that we need to retain our excellent body of knowledge for the majority of projects for which it is appropriate, while finding those projects which might run away and suffer from catastrophic failure, for which other, more systemic management methods might be appropriate.

References
Ackermann, F., Eden C., & Williams, T. (1997). Modelling for litigation: Mixing qualitative and quantitative approaches. Interfaces 27, 48-65 Andersen, E.S., Grude, K.V., & Haug, T. (1996). Goal directed project management (2nd ed). Kogan Page. Arbogast, G.W.., & Womer, N.K. (1988). An error components model of cost overruns and schedule slip on army R&D programs. Naval Research Logistics 35: 367-382 Ashton, J.E., Johnson, M.D., & Cook, F.X. (1990). Shop floor control in a system job shop: Definitely not MRP. Prod.Inv.Mgmt.J. 31, 27-32 Baccarini, D. (1996). The concept of project complexity - A review. International Journal of Project Management 14, 201-204. Ballard, G. (2000). The Last Planner system of production control. Thesis submitted for the degree of PhD., School of Civil Engineering, University of Birmingham. Buchanan, D.A. (1991). Vulnerability and agenda: Context and process in project management. Brit.J.Mgmt. 2, 3, 121-132 CCTA. (1998). Managing successful projects with PRINCE2, ISBN 011 330855 8 Cooper, K. (1980). Naval ship production: A claim settled and a framework built. Interfaces, 10, 20-36. Cooper, K. (1993). The rework cycle: Benchmarks for the project manager. Project Management Journal. 20, 17-21 Cooper, K., Lyneis, J.M., & Bryant, B.J. (2002). Learning to learn, from past to future. International Journal of Project Management. 20, 213-219 Dubinski, F.A. (1994). On the edge of chaos: A metaphor for transformative change. J.Mgmt.Inquiry 3, 4, 355366 Eden, C., Williams, T., Ackermann, F., & Howick, S. (2000). On the Nature of Disruption and Delay D&D in major projects. J.Opl.Res.Soc. 51, 291 300 Fleming, Q.W., & Koppelman, J.M. (2000). Earned Value project management, 2nd ed. Project Management Institute, Newtown Square, PA, US. Flyvberg, B., Bruzelius, N., & Rothengatter, W. (2003). Megaprojects and risk: An anatomy of ambition. Cambridge University Press. Flyvberg, B., Holm, M.K., & Buhl, S.L. (2002). Understanding costs in public works projects: Error or lie? Journal of the American Planning Association, 68, 3, 279-295 Friedrich, D.R., Daly, J.P., & Dick, W.G. (1987). Revisions, repairs and rework on large projects. J.Construct.Eng.Mgmt. 113, 488-500 Graham, A.K. (2000). Beyond PM 101: Lessons for managing large development programs. Project Management Journal. 31, 7-18 Harrison, F. (1985). Advanced project management. Gower, Aldershot, UK Highsmith, J. (2002). Agile software development ecosystems. Addison Wesley, Boston, MA Hock, D. (1999). Birth of the chaordic age. Berrett-Koehler Publishers, San Francisco, US. Hodgson, D. (2002). Disciplining the professional: The case of project management. J. Mgmt. Studies, 39, 6, 803821 Johnston, R.B., & Brennan, M. (1996). Planning or organizing: the implications of theories of activity for management of operations. OMEGA 24, 367-384 Kloppenberg, T.J., & Opfer, W.A. (2002). The current state of project management research: trends, interpretations, and predictions. Project Management Journal 33, 5-18 Koskela, L., & Howell, G. (2002a). The underlying theory of project management is obsolete. Proc. PMI Project Management Institute Research Conference, Seattle 2002, pp 293-301 Koskela, L., & Howell, G. (2002b). The theory of project management: Explanation to novel methods. Proceedings 10th Annual Conference on Lean Construction, IGLC-10, August 2002, Gramado, Brazil. Lampel, J. (2001). [Editorial.] Towards a holistic approach to strategic project management, International Journal of Project Management. 19, 8, 433-435 Lewis, M.W., Welsh, M.A., Dehler, G.E., & Green, S.G. (2002). Product development tensions: Exploring contrasting styles of project management. Academy of Management Journal, 45, 546-564 Lundin, R.A. (1995). Editorial: temporary organizations and project management. Scand.J.Mgmt. 11, 315-317

Lyneis, J.M., Cooper, K.G., & Els, S.A. (2001). Strategic management of complex projects: A case study using system dynamics. Sys.Dyn.Rev. 17, 237-260 Machin, J.L.J., & Wilson, L.S. (1979). Closing the gap between planning and control. Long Range Planning 1: q2, 16-32 Malgrati, A., & Damiani, M. (2002). Rethinking the new project management framework: New epistemology, new insights. Proceedings of PMI Research Conference 2002, pp 371-380. Seattle, WA: PMI. Molin, K. (2003). Divided loyalties in project management. 3rd European Academy of Management conference, Milan, April 2003 Morgan, & Smircich. (1980). The case for qualitative research. Acad.Mgmt.Rev. 5, 491-500 Morris, P.W.G. (2002. Science, objective knowledge and the theory of project management. Proc.Inst.Civil.Eng. 150, May, 82-90. Morris, P.WG., & Hough, G.H. (1987). The anatomy of major projects: A study of the reality of project management. Chichester, UK: John Wiley & Sons. National Audit Office. (1986). Ministry of defence: Control and management of the development of major equipments. Report by the Comptroller and Auditor General 568. London: HMSO. Packendorff, J. (1995). Inquiring into the temporary organization: New directions for project management research. Scand.J.Mgmt. 11, 4, 319-333 Payne, J.H., & Turner, J.R. (1998). Company-wide project management: the planning and control of programmes of projects of different type. International Journal of Project Management. 17, 1,55-59 Pritchard, C.L. (2001). Risk management: Concepts and guidance (2nd ed.). Arlington, VA, USA: ESI International. PMI. (1986). Measuring success. Proceedings of the 18th Annual Seminar/Symposium of the Project Management Institute, Montreal, Canada, September 1986. PMI. (1999). The future of project management. Newtown Square, PA, USA: Project Management Institute. PMI. (2000). A guide to the project management body of knowledge (PMBOK Guide). Newtown Square, PA, USA: Project Management Institute. Rich, M.T., Loch, C.H., & De Meyer, A. (2002). On uncertainty, ambiguity and complexity in project management. Management Science 48, 8, 1008-1023 Rodrigues, A., & Bowers, J.A. (1996). System dynamics in project management: A comparative analysis with the traditional methods. Sys. Dyn. Rev. 12, 121-139. Schwaber, K., Needle, M., & Martin, R.C. (2001). Agile software development with SCRUM. Prentice Hall, Upper Saddle River, NJ Shenhar, A.J. (2001). One size does not fit all projects: exploring classical contingency domains. Management Science, 47, 3, 394-414. Shenhar, A.J., & Dvir, D. (1996). Towards a typological theory of project management. Research Policy 25, 607-632 Shenhar A.J. and Wideman R.M. (1996). Improving PM: Linking success criteria to project type. Paper presented to the Southern Alberta Chapter, Project Management Institute, Symposium Creating Canadian advantage through Project management, Calgary, May 1996. Newtown Square, PA, USA: Project Management Institute. Simon, H.A. (1982). Sciences of the artificial (2nd ed.). MIT Press, Cambridge Mass, USA. Stefanou, H. (2003). Research program overview. [Report] At Research Program Working Session, PMI Global Congress 2003, Baltimore, US 21st September 2003. Tatikonda, M.V. & Rosenthal, S.R. (2000). Technology novelty, project complexity, and project development project execution success: a deeper look at task uncertainty in product innovation. IEEE Transactions Engineering Management, 47, 74-87 Thompson, J.D. (1967). Organizations in action. McGraw-Hill, New York. Turner, J.R. (1999). [Editorial] Project management: A profession based on knowledge or faith? International Journal of Project Management. 17, 6, 329-330 Turner, J.R., & Cochrane, R.A. (1993). Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them. International Journal of Project Management. 11, 93-102

10

Udo, N., & Koppensteiner, S. (2003). Will agile development change the way we manage software projects? AGILE from a PMBOK Guide perspective. Proceedings of PMI Global Congress 2003 North America, Baltimore, US: Project Management Institute. Ulri, B., & Ulri, D. (2000). Le management de projets et ses evolution en Amerique du Nord. Revue Francaise de Gestion 129, Juin-Juillet-Aout, 21-31 quoted in Malgrati and Damiani 2002 Williams, T.M. (1995). A classified bibliography of research relating to project risk. European Journal of Operational Research 85:18-38 Williams, T.M. (1999). The need for new paradigms for complex projects. International Journal of Project Management. 17, 5, 269-273 Williams, T.M. (2002). Modelling Complex Projects. Chichester, UK: John Wiley & Sons. Williams, T.M. (2003). Assessing extension of time delays on major projects. International Journal of Project Management. 21, 1, 19-26

11