Order 1299446: Leading teams and managing relationships

Reconstructing project management reprised a knowledge perspective

Project Management Journal Morris, Peter W. G.

How to cite this article: Morris, P. W. G. (2013). Reconstructing project management reprised: a knowledge perspective. Project Management Journal, 44(5), 6–23.

INTRODUCTION

In May 2013, Wiley-Blackwell published Reconstructing Project Management (Morris, 2013), a book I had been working on, I suppose, for over 40 years, about the knowledge needed to manage projects and programs efficiently and effectively. I was invited to summarize the main points in the book in an article for Project Management Journal (PMJ)®, which is what this is.

Many academic researchers are primarily interested in projects as examples of temporary organizations, rather than in questions about building a discipline for the delivery of goals. Indeed, they may well be skeptical about our ability to define the kind of normative or prescriptive nature of the knowledge that would be required for such a discipline, or the value of such guidance should it be available. Having spent many years in the ‘real’ world of delivering projects, I believe that there does need to be, and that there is, a discipline for managing projects; and further, that this discipline needs to be enlarged from how many perceive it today. Doing this will not be easy, but the result will be an enormously more useful and relevant body of knowledge.

Reconstructing project management reprised: a knowledge perspective by Morris, P., in Project Management Journal, Vol. 44/Issue 5. Copyright 2013 by PMI Publications. Reprinted by permission of PMI Publications via the Copyright Clearance Center.

This thesis is explored in the book's three parts. Part 1 traces how our knowledge of the field developed, and how the subject has come to be constructed in the way we think of it today. Part 2 takes this construct apart—deconstructs it—describing the range of functions and skills that collectively constitute the latest thinking on the discipline. Part 3 then looks at how these elements of project management may need to be recombined— reconstructed— to meet today's needs and tomorrow's challenges. We need, I argue, to focus more on enhancing value and influencing context, while making an effective impact and addressing the major issues facing society today.

Except for Part 2, which is not reprised here, this paper more or less follows this structure but does so from the perspective of investigating what knowledge we need, as a discipline, to manage projects and programs, efficiently and effectively. Specifically, it investigates:

• How our knowledge of managing projects (which, for brevity is often, but not always, taken also to cover programs) was ‘invented.’ (It was not ‘found’);

• How robust that knowledge is, in the sense of being reliable and true; and • In what way and to what ends we should be using that knowledge, and

why.

Constructing Project Management: How We Got to Where We Are

Why should we bother to understand the history of the development of the discipline? How ‘true’ can this history be? Understanding how things developed helps us to understand why they are what they are today. Understanding one's history is a sign of maturity. Less pompously, it deepens and strengthens the knowledge base (Söderlund & Lenfle, 2013).

Truth is elusive, particularly in the social sciences. Today, history is rarely viewed as an objective, disinterested enquiry but rather as socially constructed. Historians create historical facts according to their interests— gender, poverty, Marxism, and so forth: study the historian to understand the history (Carr, 1961). My focus is how best to manage projects. Critically, my unit of analysis is the project, not management processes and practices. So I look for examples of how projects were, or were not, successfully managed. My history is thus different in scope and purpose from the more traditional project management preoccupation with planning and control.

Pre the Language of Modern Project Management All projects, without exception, follow the same generic development cycle: going roughly from Concept to Feasibility to Design to Execution to Hand-over and Operations. The progression is essentially linear, though there may be considerable iteration within stages, particularly the early, front-end ones. This development life cycle is what distinguishes projects from non-projects.

Defined as such, projects have existed since the beginning of time. Prehistoric hunting was a project-based activity. And probably most projects were managed well, some spectacularly so (the pyramids, henges, fortifications, and so forth). Chapter 2 walks through this landscape for almost ten pages before getting to the point where modern management thinking begins to surface techniques and practices that we now recognize as core to modern project management. Adamiecki's 1903 Harmonygraph, for example; the U.S. Bureau of Reclamation's “project office” of 1902 with its ‘project engineer’ in charge of a complete project (Pinney, 2001); and the rise of the project coordinator function in the aircraft industry in the late 1920s and 1930s.

World War II saw thousands of de facto projects and programs but no evidence of a formal management approach called project management, or project coordination, or anything similar. Clearly D-Day, for example, was a massive ‘program of programs of projects,’ but project management terms, other than schedule or program, just weren't used. Many argue that the Manhattan Project—the U.S. program to develop the Atom Bomb—was where project management was born but it didn't formally apply any of the tools, techniques, or arguably language or concepts of the discipline as it became articulated post the early to mid-1950s (Lenfle, 2012; Rhodes, 1988).

In fact, it wasn't until 1952–1953 that the concepts and tools that a modern project manager would recognize as characteristics of the discipline were invented and began to be applied. Efforts to improve coordination between the R&D and the production arms of the U.S. Air Force (USAF) involving the establishment of Project Offices had been initiated in 1951. Around 1953– 1954 McDonnell Aircraft formally created the project manager position, the prime responsibility being organization and staffing (Bergen, 1954). More or less simultaneously, Martin (Marietta) established the first matrix organization (Lanier, 1956). The first really major deployment of a project management role was, however, that designed by the USAF for the Atlas Inter Continental Ballistic Missile (ICBM), for which Brigadier Schriever, supported by a systems integration contractor, acted as the project manager from 1955. By 1956 the U.S. Navy had installed Vice Admiral Raborn as program manager for the Polaris ICBM (Sapolsky, 1972, 2003).

Pre Project Management Theory The challenges for all these weapon systems programs were great technical uncertainty plus huge schedule pressure (Johnson, 1997). The book describes techniques that were invented in both programs, and on subsequent ones, to help address these challenges—techniques such as design reviews (in effect stage gates), configuration management, and PERT scheduling. (The Critical Path Method came out of DuPont, contemporaneously with Polaris's PERT, in 1956–1957.) The emphasis on tools grew even stronger with the arrival of Robert McNamara as Secretary of State for Defense in 1960, with his desire to see greater control over DOD activities and expenditure (Acker, 1980). The Apollo “moon program” further developed and showcased the new discipline, but project management, as applied at this time, was essentially an engineering management function (Brooks, Grimwood, & Swenson, 1979; Johnson, 2001). In fact, it was only really in the early 1970s that the discipline, as it had now clearly become, began to be seriously affected by social, economic, political, and environmental issues. The U.S. Super Sonic Transport plane, for example, was cancelled due to environmentalist opposition (Horwitch, 1982), with environmental issues impacting several oil and gas projects (Alaska, North Sea, and so forth); even space exploration was hit by budgetary shortfalls. This seemed to be a class of management rife with difficulty and failure. The theory-light engineering project management available at this time was just not rich or powerful enough to help managers deal with the uncertainties created by this new generation of externalities.

Meanwhile, as more and more companies were either forced by DOD or by NATO to implement these new techniques (many of which called on newly emerging computing capabilities), or applied them out of curiosity or conviction, people began attending seminars, symposia, congresses, and similar events to learn from, and to share, their experiences. (Principally, interestingly, most of the discussion was about planning.) So were born around the late 1960s/early 1970s the professional project management societies.

The Bodies of Knowledge, Critical Success Factor Studies, and Other Research By the mid-1970s PMI, the U.S. headquartered Project Management Institute, began exploring the idea that if project management was to be a profession, surely there ought to be some form of certification (Cook, 1977), for one of the attributes of professionals is demonstration of the mastery of a body of

knowledge distinctive to it, leading to a ‘license to practice’ (Hodgson & Muzio, 2010). (A position we have not yet quite achieved: an ‘endorsement of competence’ is probably a more accurate statement of where we are at present.) In 1983 a pilot ‘baseline’ attempt at defining a project management ‘body of knowledge’ (BOK) was drawn up that proposed six knowledge areas as “unique to the project management field” (Project Management Institute, 1996): Scope, Time, Cost, Quality, Human Resources, and Communications. In 1987 PMI formally published the first edition of the PMBOK and added Risks and Contracts/Procurement. A 1996 revision added Integration as a knowledge area and importantly changed the document's name to A Guide to the Project Management Body of Knowledge (PMBOK® Guide). There have since been several more updates, most relatively minor. Project Stakeholder Management was added in 2013.

The aim of the PMBOK® Guide was not to cover all the knowledge needed to manage projects, as would be typical of most professional disciplines’ bodies of knowledge, but only that which was supposedly truly unique to project management (which in fact it isn't). Deciding this however requires some form of preconception of what project management is. After all, project management is a social construct; projects are ‘invented not found.’ One needs a framework if only to enable discussion. PMI's construct was a set of processes—not primarily the project/product development process (the project life cycle), despite its fundamental importance, but a simple ‘initiate->plan- >execute->monitor & control->close’ sequence, which applies across the various ‘knowledge areas’: scope, time, cost, quality, etc. Unfortunately, this process basis masks, critically, the characteristics and challenges of the different stages of the project development life cycle. This is particularly important with regard to the project ‘front-end’ in which the character of the work is substantially different from the more traditional execution nature of project management, being more exploratory, creative, and ‘organic’ (Burns & Stalker, 1961) as well as setting the character for much of the project's following stages (Miller & Lessard, 2001). This perspective was absent at the time of drafting the PMBOK® Guide, which reflected an ontology that is fundamentally execution oriented, as in fact it does still now, even in its latest edition with its acknowledgment of the need for ‘Plan’ stages at the beginning of its Scope, Cost, Schedule, and Stakeholder Management knowledge areas. This emphasis means that many of the things that are important to the successful management of projects are omitted. And strangely, of those that are covered, there is little reference to pertinent literature.

All this might be seen as academic nit-picking were it not that, despite these criticisms, the structure of the PMBOK® Guide, its certification programs and

its philosophy of project management are so fixed, and are so widely disseminated, that they dominate the general perception of the discipline. Despite the many excellent papers in the Project Management Journal® and elsewhere and in research symposia and similar events, the PMBOK® Guide remains largely ‘theory light.’ While this may have been understandable in the 1980s, it is not so any more.

By the 1980s there had certainly been some research, but not much: primarily ‘how to’ work on planning and organizational topics such as the project manager's authority, conflict management, and the matrix (Davis & Lawrence, 1977; Knight, 1976; Larson & Gobeli, 1989; Might & Fischer, 1985). An important sequence of work on integration from the late 1960s to the mid- 1980s laid out the theoretical grounds on “why” one would need “how much” project integration of organizational units, and “when” (Galbraith, 1973; Lawrence & Lorsch, 1967a, 1967b; Miller & Rice, 1967; Mintzberg, 1979; Thompson, 1967). By the late 1980s and 1990s research had expanded significantly. A number of “Critical Success Factors” studies were beginning to build a more over-arching perspective on what one needs to do to manage projects successfully (Jugdev & Müller, 2005). All emphasized the importance of the development of the front-end definition and the key role of the owner/sponsor, and all took a holistic, big picture perspective on projects.

The first of these, Morris and Hough (1987), looked at data on 1,653 projects and found that typical sources of difficulty were such things as: unclear success criteria, changing sponsor strategy, poor project definition, technology (the fascination with, uncertainty of, and design management), concurrency, poor quality assurance, poor linkage with sales and marketing, inappropriate contracting strategy, unsupportive political environment, lack of top management support, inflation, funding difficulties, poor control, inadequate manpower, and adverse geophysical conditions). Most, though not all of these factors fell outside the standard project management rubric of the time. Morris and Hough therefore proposed that managing the shaping and delivery of the project—taking the unit of analysis as the project as an organizational entity—was the best way to address the subject, suggesting in 1994 that the discipline should be thought of as “the management of projects” (Morris, 1994) (Figure 1).

The “management of projects” paradigm was used as the theoretical framework for developing APM's (the UK's Association for Project Management's) BOK (Association for Project Management, 2013), which was first published in 1993. The result was a radically enlarged view of what the discipline is about: broader and more rounded; concerned with setting the project goals; working with stakeholders; managing and shaping the emerging

front end; managing technical, commercial, control, organizational, and people factors, with an emphasis on effectiveness as well as efficiency; and resting on a pluralistic knowledge base.

By the early 21st century there was ongoing work across a very wide spread of subjects, for example: governance (Müller, Turner), strategy (Artto, Loch, Morris, & Jamieson), technology management (Davies, Hobday, et al.), innovation (Gann), supply-chain management and networks (Cox, Pryke), organizational learning (DeFillippi, Sense, Grabher), critical management (Hodgson & Cicmil), institutional theory (Bresnen, Orr), and indeed many other topics (concurrent engineering, complexity, culture, epistemology, ethics, funding, knowledge management, ICT, sustainability, trust, etc.) (Müller & Turner, 2005; Turner & Keegan, 2001; Artto, Kujala, Dietrich, & Martinsuo, 2007; Loch, 2000; Morris & Jamieson, 2004; Davies & Hobday, 2005; Gann & Salter, 2000; Cox & Ireland, 2006; Pryke, 2001; DeFillippi & Arthur, 1998; Sense & Antoni, 2003; Grabher, 2002, 2004; Hodgson and Cicmil, 2006; Bresnen, 2007; Bresnen & Marshall, 2000; Orr & Scott, 2008). Wheelwright and Clark's Revolutionizing Product Development (Clark &

Fujimoto, 1991; Wheelwright & Clark, 1992) made a particularly notable contribution, exploring strategy, portfolio management and the role of the owner's management in new product development, showing inter alia the value of senior project leadership, team working, concurrent engineering and stage gates.

But there was now a change happening. Whereas originally much of the research had been practitioner-focused, functionalist, instrumental and largely prescriptive and normative—what could, or should, be done to improve our ability to manage projects better—researchers were now beginning to examine what was actually happening. In the fore of this research was ‘the Scandinavian School,’ still very influential today, which focused on the ‘actors’ and the organizations working on projects, and on the reality of that work, “putting less energy into studying what is meant to happen, and more into what is actually happening” (Packendorff, 1996). The result is less a concern with discovering ‘the knowledge needed to manage projects efficiently and effectively’ but more a study of the sociology of working in projects. A concern for explicating the discipline of managing projects it isn't; in fact, the very notion that one might be prescriptive in communicating such knowledge is, for many such scholars, quite problematic (Hodgson & Cicmil, 2006).

The opening of the 21st century saw the publication of two CSF studies that were to have a major impact on our thinking, those by Miller and Lessard (2001) and Flyvbjerg et al. (2002). Miller and Lessard, reporting on a study of 60 ‘Large Engineering Projects’ in the energy and transportation sectors, distinguished between effective performance (does the project meet the sponsor's ‘business’ goals?) and efficient delivery (on time, in budget, to scope). Interestingly, performance was much worse on effectiveness (around 40%) than efficiency (75%). (This would seem explainable since efficiency is what most projects are assessed on, but shouldn't it really be effectiveness that we should strive for; shouldn't we, therefore, be doing better on effectiveness than efficiency?) The key issue was, again, the sponsor: 85% of the successes and failures could be explained by the sponsor's abilities in (1) shaping strategy and coping with political, economic, and social turbulence and outside institutions and (2) dealing with partnership and contractual turbulence. Consequently, they concluded, risk management needs to be focused on more than just cost and schedule (efficiency) but also include technical, market, finance, social, institutional, and other risks affecting effectiveness performance. Flyvbjerg, in his review of transportation projects, similarly identified the criticality of the sponsor, and in particular, his or her accountability. The danger, Flyvbjerg showed, is that sponsors, particularly of

public sector projects, often knowingly pitch their initial budgets low (‘strategic misrepresentation’) or are over-optimistic.

Aligned Supply: Focusing on Value Wheelwright and Clark had based the material for their research largely on the practices of Toyota. Springing from the Total Quality philosophy of focusing on the customer and his or her needs, and on continuous improvement, Toyota believed that it was nonsensical to expect significant performance improvements if members of the supply chain were not aligned on the same goals, didn't have similar values, and were not working together closely and effectively. Obvious though this might seem, it was not the traditional way of engaging resources to work on projects: historically, resources had been procured essentially on the basis of the lowest cost. Now, with longer term contracts and with contract awards being made on broader grounds than simply lowest compliant bidder, suppliers began to be able to focus on value and innovation, targets often being set in multi-year framework contracts. This does not necessarily mean a softer contracting environment, but it did cause a major change in project management practice. It directly inspired the Japanese project management Body of Knowledge published in 2002 (ENAA, 2002; Ohara & Asada, 2002; Figure 2), for example, and informs much of the ethos of Reconstructing Project Management. Partnering and Alliancing spread rapidly (though not without critics). As it did so, associated practices such as risk management, quality management, and health and safety began to receive increased attention (Faculty of Actuaries, Institute of Actuaries, the Institution of Civil Engineers, 1998; Office of Government Commerce, 2002a; Ward & Chapman, 2003; Chapman & Ward, 2011; European Construction Institute, 1999; BS ISO 10006, 2003).

Technical Challenges and Program Management But it was still proving difficult to deliver projects successfully, particularly in IT and systems-based projects or those having new, unproven technology (Meier, 2008; Sauer, 1993; Wateridge, 1998; Yardley, 2002; The Standish Group, 1994). The difficulty of eliciting and managing requirements lies at the heart of much of this: by the time users receive the product, their needs may well have changed, thus either the requirements/scope have to change or the delivered product functionality has to be accepted as not adequate (Davis, Hickey, & Zweig, 2004; Stevens, Brook, Jackson, & Arnold, 1998). One of the defining issues of the project management discipline is whether project management should be responsible for ensuring that requirements are adequately defined. In many organizations there is no question but that it is; in

others, as in the PMBOK® Guide, it either is not or, at best, its role is ambiguous.

The difficulty of accurately specifying software projects’ requirements and of estimating the time needed to meet them led, around 2000–2001, to a group of software project managers declaring, in the Agile Manifesto (Leffingwell, 2007), that it would be better if requirements were specified through ‘close coupling’ between the user and the software developer with this user- developer ‘team’ working only on a select number of requirements at any one time; and that solutions to these requirements should be delivered within a short time frame. Delivering this functionality takes priority, even if it means that more resources are needed (i.e., budget is exceeded) or, less commonly, that schedule, or even scope, is relaxed to maintain the budget (or schedule). The iron triangle is abandoned! Project management becomes in effect task or work-stream management; nevertheless Agile software project management continues to attract attention to this day.

At the other end of the spectrum, program management was positioned by OGC (the UK's Office of Government Commerce) in its guideline, Managing Successful Programmes,1 and later by PMI (Project Management Institute, 2006), largely as strategic change management (Office of Government Commerce, 2003). This, together with OGC's sister guide for project management, PRINCE2 (Office of Government Commerce, 2002a), became immensely influential, at least in the United Kingdom, in the late 1990s/early 2000s. The net results were indeed to “spread the word” but also perhaps to commodify the discipline.

Program management, as here defined, did bring with it the salutary suggestion of remembering the benefits that were supposed to be accrued from all this project, and program, work. Unfortunately, its advocates overreached themselves in proposing that projects produce only outputs, measured as efficiency, whereas programs produce outcomes (effectiveness). Projects surely are done for a reason: benefits, value, and effectiveness apply to projects too.

Attempts to normalize standards of project management took a new turn in the mid-2000s with the promotion of project management maturity assessment tools (Office of Government Commerce, 2006; Project Management Institute, 2003). This too grew out of the difficulties experienced in delivering software projects. The Department of Defense funded work by Carnegie Mellon University, which resulted in 1991 in the software engineering Capability Maturity Model. A decade or more later, PMI and then OGC attempted to produce tools designed to do the same thing for project management. The results were not so good however: the selection of topics proved difficult, as did the assessment of their capabilities. There is also a bias toward the less mature topics, which are easier to tackle, while the presumption that the highest level of maturity should be the target is not always sensible (Salomo, Weise, & Gemünden, 2007; Wendler, 2012).

Enterprise-Wide Institutional Support Maturity models and guidelines were just two forms of assistance that were being put forth, from the mid-1990s onwards, into providing enterprise-wide support in project and program management. There had, of course, been institutional standards promulgated since the late 1950s/early 1960s, for example in the DoD and NASA (Morrison, 1967; Acker, 1980), but the work was now freshly stimulated by several streams, not least the increased demands of governance from the early 2000s; the increasing functional power of enterprise-wide planning and support software; an increased interest in benchmarking practices and performance; and the growing sense of

frustration that we ought to be able to use the knowledge we have on project and program management to learn and do better.

And, in truth, this frustration is understandable: this is a very difficult area of work. For while critical theorists in the academic community, using a Foucault- inspired power critique, might rail against such guidelines (controls) (Thomas, 2006), good old honest managers, charged simply (sic) with delivering projects successfully, were having to propose ‘best practice’ as though it was easy to assimilate and perform, regardless almost of context, which of course it isn't. And, although the ideas of Argyris and Schön on double-loop learning (Argyris, 1976; Argyris & Schön, 1978; Schön, 1987) may have appeared too abstruse for many, Nonaka mainstreamed the importance of tacit knowledge in organizational learning (Nonaka & Takeuchi, 1995) and Lave and Wenger's ideas on Communities-of-Practice (Wenger, 1998) chimed with governance's calls for project reviews, as in APM's 2004 definition of good governance practice (Association for Project Management, 2004), the two being often combined. Nevertheless, getting people to learn and perform effectively in complex, one-off situations, balancing risk and reward, is not easy. Process can only take us so far—then it comes down to people.

One should never compromise on people, but one always does, Reconstructing Project Managementopines (Morris, 2013). Why? Because one rarely gets the perfect fit; it's difficult to assess how people will really perform in a new situation; people have careers and plans of their own and many resent being pinned down. People, unlike all the other factors of production, are animate—they have egos, are passionate, willful, emotional, and make mistakes. And, amazingly, many people don't actually have their competency assessed in terms of the specific job they are being asked to perform. Chapter 15 reviews what we know about project leadership, teams, individuals’ skills and competencies, before returning to the enterprise level in discussing assessing the enterprise's long-term project management staffing needs. The prediction of staff numbers and competencies needed to manage the pipeline of upcoming projects and programs thus becomes a matter of considerable importance. This function could be viewed as belonging to portfolio management but insofar as it lies close to the enterprise's knowledge of project status (across the portfolio) and of competencies, it is often located either in the PMO (Project/Program Management Office) or adjacent to it as part of the central project management function.

But now we are beginning to leave the historical account of the development of the discipline and it is time to begin examining how robust our knowledge is on how best to manage projects. This is what the book focuses on in Part 2, which examines the principle knowledge areas individually, and the beginning

of Part 3, which looks at the ontology, epistemology, and methodology underlying this knowledge.

Deconstructing Project Management: The Knowledge Base

Although modern project management (as defined, for example, in the language and techniques used) has been around for over 60 years it wasn't, as we've seen, really until the mid-1980s to 1990s that the field began to attract a serious amount of research. During that time, a truly large amount of work has been done involving new tools and concepts, looked at both in terms of their potential and actual performance. This is not to say, though, that all is now done and dusted, textbook clear, with no questions outstanding (as Figure 3 provocatively shows). The subject is now seen as much bigger and broader than it seemed when positioned on its traditional base of planning and monitoring. Not all of its development has, by any means, been discussed above: work on fast tracking, Critical Chain, Last Planner, BIM/asset modeling, uncertainty management, lean, performance measurement, social network analysis, stakeholder management (Mahmoud-Jouini, Midler, & Garel, 2004; Gerwin & Susman, 1996; Goldratt, 1990, 1997; Raz, Barnes, & Dvir, 2003; Eastman, Teicholz, Sacks, & Liston, 2011; Chapman & Ward, 2011; Womack, Jones, & Roos, 1990; Pryke, 2001; Littau, Jujagiri, & Adlbrecht, 2010), and other areas have escaped our attention thus far. Overall, however, we now have a vastly broader knowledge base and framework to help us understand things, address specific issues, and perform better. Appendix 1 of Reconstructing Project Management lists 91 CSF studies published between 1967 and 2011. These consistently demonstrate a consistent range of topics critical to project management success or failure. Figure 4 summarizes some of the theoretical bases for these topics.

Epistemological Appropriateness and Project Management Theory So, within this broader landscape, how robust can we be about what we claim to know about managing projects? This depends partly on the kind of knowledge we are working with and partly on the methodology used to generate that knowledge.

First we need to widen the epistemological base. With project management knowledge we are nearly always operating with the social sciences rather than with natural science. Social science, unlike natural science, is not independent of context or value systems: people bring ideas, values, and sometimes unexpected behaviors so that the requirements of ‘public knowledge’—reducibility, refutability and repeatability (Popper, 1959)—are harder to meet. Social science is always less confident in its predictions than natural science (with the large exception of predictability at the quantum level). Yet, much project management knowledge is often presented in a positivist, absolute manner: as, for example, in guidance which is ‘method- oriented’ such as PRINCE2 or the PMBOK®Guide. While this might seem appropriate for such arguably mechanistic topics as scheduling, the effect of human behavior on most project management knowledge areas—say estimating or even scheduling itself (Critical Chain's motivational dimensions) let alone leadership and the other ‘people’ topics—would suggest that more interpretive epistemologies are needed.

Even where practice might need mandating regardless of local conditions or opinions—rules about financial disbursements perhaps, employment conditions, health and safety, or engineering design, document management or change control—so that a prescriptive, positivist manner may seem appropriate, we will find, underpinning this advice, the norms and values of the enterprise and of society (Giddens, 1984). These can reflect deep-seated assumptions and beliefs making them so strong that they seem to render the knowledge virtually absolute, but in reality it is relative. Health and safety standards, for example, may seem to reflect a strongly positivist epistemology but ultimately only because that is how our society expects it to be. (Ethics is another particularly interesting case.)

But this is only part of the challenge. There are also questions about the validity of our knowledge. How was it generated and how representative is it of the domain? What's a valid sample size; how do we know there isn't a black swan lurking to destroy our inferences (Flyvbjerg & Budzier, 2013)? Since we can't be sure we have covered everything, how do we know what the reality is? Critical Realism seems to address this problem sensibly, proposing that there is a reality out there but that our knowledge of it is inevitably partial (stratified): there may indeed be causal relationships (laws, event sequences, etc.) discernible at a certain level of observation but these are just subsets of what can be observed, and what can be observed is itself a subset of what, at a deeper level of reality, in fact exists (Bhaskar, 1975; Harré, 1972; Sayer, 2000).

The problem is how to avoid turning what at the operational level may be focused and meaningful into something which at a high level is almost platitudinous. Take the guidance summarized in Figure 5 for example; this is an attempt to outline best practice principles in the management of projects. I would contend that it is conceptually valid, being based on “what, at a deeper level of reality, in fact exists”; however, at this level of generality it is pretty anodyne. To give it more bite we need to go down a few organizational levels. But what may be true for Organization 1 in context B might not apply so well

for Organization 2 or context X. And then we're back to the problem that the knowledge at this level of detail may not be universally applicable.

One consequence of Figures 4 and 5 is that we can see there are several epistemologies and theoretical frameworks that will be appropriate for different aspects of the field (as is the case with management more generally). There is thus clearly no single ‘theory of project management’ (Koskela & Howell, 2002). Project management knowledge is pluralistic.

Methodology Our knowledge of managing projects should be empirically grounded. We should have valid data from which to draw lessons. To generate this we need sound methodology. Unfortunately, project management has not always done this well, even among the most influential works. Standish, for example, is infamous for its headline data on the high failure rate of U.S. software projects (only a 16%–32% “success” rate; 50% to 60% were late, over budget and/or had less than the required features and functions; 20%–40% “failed”; i.e., were cancelled prior to completion or delivered and never used, yet these data are almost totally opaque and Standish provides no critique of its data or findings (The Standish Group, 1994; Jørgensen & Moløkken-Østvold, 2006).

We should be alert to language. We should seek transparency of argument. Shenhar and Dvir's influential book, Reinventing Project Management (Shenhar & Dvir, 2007), aims to show how project management

needs to adapt in form and application according to four parameters: novelty, technology, complexity, and pace (NTCP). Where do the four come from? Originally, Shenhar and Dvir concluded there were “three dimensions that characterize each project: uncertainty, complexity, and pace” (p. 41). And the fourth? We are referred to Appendix 3, where all we are told is: “In practice, we have found it helpful to expand this model, recognizing that there are really two major sources of uncertainty: market (or goal) uncertainty and technological (or task) uncertainty. Thus, the NTCP (novelty, technology, complexity, and pace) model emerged” (ibid). And that ex cathedra statement is the sole basis on which these four parameters are chosen.

Scholarship Does all this matter? Can't we “just do it,” as Nike once famously said? Well, project management, to repeat, is “socially constructed”; projects and project management are ‘invented not found.’ It is us, all of us, who, in reflecting on practice, are inventing the discipline. As we've seen, we need therefore to be especially careful in the way we name and define things, set standards, and provide prescriptive guidance. The way we do this will affect performance. We should not give in to those who, skeptical that there is such a thing as a discipline of project management, say scholarship here is a waste of time anyway. I believe the reverse to be the case.

Traditionally academia has ‘owned’ the knowledge base of professions (Abbott, 1992). While this may be true for some project management ‘sub’ topics, such as risk management or scheduling, it is not the case at the summative, integrative level of the discipline. In fact, at this level it is not very clear at all who really owns it. While the professional associations would like to claim that they do, we saw above the lack of consensus in their views. Practitioners are at the sharp end of ‘a’ reality but generally lack the breadth of knowledge and possibly the rigor that scholarship should bring. Academics, on the other hand, often lack the practice-based knowledge of the discipline (to meld Aristotle's techne with episteme) and many have genuine trouble with the instrumental nature of knowledge in the professional domain. But whoever takes responsibility for the knowledge at the level of the discipline as a whole, scholarship is important. Because, since there is a limited single ‘reality’ to check theory against, we need to be especially careful to base our knowledge of the discipline on solid social science methodology: on sound empirical data, rigorously and transparently analyzed; collected in an unbiased manner within a clear and appropriate methodology.

Without rules of some kind we'd be lost (Burns & Flam, 1987). A discipline requires routines and standards. But we should take care: the limitations of

norms, standards, and so-called truths need acknowledging. Ask critically: who defined them, under what circumstances, on what basis, and for what reason? The professional community will inevitably coalesce around certain conceptions and definitions, but with new times come new needs and new perceptions, as we are just about to see. As things change, so we need to be alert, rigorous, and ambitious in our thinking. This is the cry from Reconstructing Project Management.

Reconstructing Project Management: The Next Era

Knowledge, particularly social knowledge, needs an owner. It is interpreted through social values. What are the values that managers of projects and programs should be displaying? What should be the ethos of project management? As I said in 2000: “Put simply, is it to deliver ‘on time, in budget, to scope,’ or is it to deliver projects successfully to the requirements of the project customer/sponsor? In essence, it has to be the latter, because if it is not, project management is an inward looking profession that in the long- term few serious managers are going to get very excited about. What managers in government, business, academia—just about everywhere in fact—are concerned about is that their projects are managed effectively and efficiently; that they represent value-for-money and meet or exceed their strategic objectives” (Morris, Patel, & Wearne, 2000).

This is still the challenge. How often do project managers work to realize business outcomes rather than just delivering to scope, in budget, and on time? (It's hard enough trying to mainstream effectiveness performance measures, discuss benefits, and dissuade people from thinking project management is only about delivering outputs.) The challenge now surely is to focus on impact, which is why Reconstructing Project Management calls this the ‘Age of Relevance.’ This is particularly apt as mankind is currently facing some of the biggest, most serious and dangerous issues in its history, yet project management is almost totally silent on how to help address them.

Global Challenges The world's population, currently around 6 billion, will probably peak at about 9 billion by 2050. Humankind already well exceeds the Earth's carrying capacity: the trouble is, we don't know by how much.

Demographic changes will increasingly impact society—from the way we need to design and use buildings, through finding employment and decent lives for our citizens, to funding of care of the elderly, and dealing with pressures from

immigration. Crucially, the proportion and absolute numbers of the elderly will triple, from 670 million in 2005 to 2 billion by 2050. This will put enormous burdens on younger people. Population affects the provision of infrastructure, goods and services; it is also significantly affecting our ability to staff projects properly.

Feeding 9 billion people will be a major challenge: we will need to produce about 70% more food than we do today, in conditions where land and water are scarce; where, because of climate change, people, regions, and countries dependent on agriculture look vulnerable; where fertilizers and transport are either in short supply and/or are expensive. More than 3 billion people live in ‘water-stressed’ or ‘water scarce’ countries. What is project management doing about this?

The world's infrastructure needs a massive amount of spending to repair or replace existing facilities or to provide new ones: over US$40 trillion is required over the next 25 years. The impact of global warming will exacerbate this need significantly: sea levels will rise substantially during this century, possibly by several meters, particularly if the Greenland glaciers melt, affecting many of the world's biggest cities. Storm damage will increase. ‘The environment’ will, for many, become of overwhelming importance. This is a huge and obvious area for project management.

Energy represents an enormous series of challenges—from new carbon capture and storage technology to massive new oil and gas exploration and production in remote and difficult locations. CO2 emissions need reducing dramatically: The biggest emitter is the existing built stock. How should this problem be addressed? Changing behaviors has to be part of the solution but really we need a bigger, more comprehensive approach. Project and program management has a major role here.

All is not doom. Expect big developments in robotics, including at the nano level, and more and more data and information: a ubiquity of intelligence. There will be an increasing convergence of technologies. Electronics, computing and communication technologies will continue to develop rapidly, powering enormous increases in product performance, improving productivity, and profoundly changing social behaviors. As we rely increasingly on massive interconnected information networks, so we will become more vulnerable to systemic collapse. Currently, project management is scratching the surface, responding in an ad hoc way to Silicon Valley rather than thinking proactively about how it can wring the maximum benefit from these developments.

Implications for the Discipline

Project management can and should have a major role in addressing these challenges, assembling and driving forward emerging solutions. The lever will be addressing context and improving value, as we shall see shortly. Project management practice will vary: agile will be quite different from megaprojects for example. Nevertheless, we can spot some developments relevant to tomorrow's world:

• Control will use integrated, intelligent models more fluently—configuration management and BIM, n-CAD, etc.; risk will be modeled far more readily from more perspectives.

• Organizational forms will be more fluid, agile, and adaptive—more, and better, network-based. This should help improve the leveraging of supply chain capabilities. Strategy and governance will be the lynch pin. The provision of funding and the organizational consequences that result (better control, greater performance responsibility, etc.) could be major forces affecting development.

• Context will be better influenced, in a richer ‘organizational ecology,’ and in multiple, integrated way; institutional theory will become increasingly operationally useful, scenario planning will become more common. Evidence of innovation will be demanded more explicitly. Designers will emphasize resilience and adaptability.

• In this more fluid, networked, agile world, management could become less clunkily formal, more instinctive. And as we develop, so will the work required at the enterprise level; institutional project and program management will support this improved instinctiveness. Arguably the best way to do this is through training and education. Thus learning and development will become more important—the two being linked in ways they have not really been to date. But again, more plurally, not in so singularly a ‘one club’ way as it has tended to be to date: via self- organizing learning and knowledge communities with greater use of coaching and mentoring, learning-led assurance reviews, being supply chain-wide, learning-informed, and value driven.

Program Management Program management is the elephant in the room here. Do we understand it properly? Do we have an adequate theory or theories for it? Programs are collections of projects with shared goals and objectives and perhaps resources, all of whose benefits must be realized for the overall program to work. Program management is the management of the collective set of such interdependent projects. There are many who claim that program

management is qualitatively very different from project management; that it is about organizational or strategic change (Pellegrinelli, Partington, & Geraldi, 2010). It can be, but it is also used without this emphasis in product development and multi-project management (Sapolsky, 1972; Midler & Navarre, 2004). This range of interpretations reflects a theoretical vagueness. What is its underlying theory and drive? Restructuring Project Managementsuggests that Geels’ transition theory is one cogent candidate, one which could prove particularly apposite for addressing the societal challenges we face (Geels, 2004).

Shaping Context Battles are fought in terms of objectives, resources, ground conditions, the spirits of the troops, and so on; this applies whether you are a general or a private. Management battles may be less dramatic, but the same logic applies. Management knowledge is similarly contextual. It is affected by industry practices, technology, environment, personalities, and so on. But management doesn't have to be passive; it can shape context and some of the project's factors may be malleable, to some extent at least. For example, innovation (novelty) can be chunkedup and its parts managed discreetly; urgency (speed, pace) may be modified through phasing, fast-tracking or concurrent engineering; size or complexity can be reduced by breaking the project into component parts and simplifying.

So, instead of the more traditional approach to contingency management, which posits management as responding to given environmental and project characteristics, Reconstructing Project Management explores how it can respond to independent or semiindependent forces.

Seven actions are proposed, the first three in response to factors largely independent of the project, namely:

• Align with the sponsor's, and hence the project's, ‘strategic intent’; • Ensure that the requirements are clearly captured; and • Help influence the effect of the ‘environment’ on the project's business

case, in particular the political, economic, and the social environments. And the remaining four that are more a consequence of the emerging project design and project management strategy:

• Establish funding for the project and how this fits with the business case. But to answer this requires an estimate and an estimate requires a design. So “funding” iterates with “solution development.”Funding requirements

may then result in rescoping or re-design, in de-risking, in choosing specific suppliers, in changing the pace of development, and so forth;

• Then: “solutions development”: technology selection, and work-out; • All this requires, and iterates with, resourcing: contracting, procuring, and

organizing the resources needed to perform and deliver the project; • Then, planning and monitoring and active decision making as needed to

pull everything together and to move the project, or program, forward. Governance arrangements might sit here, setting the tone for the way the project is to be managed. Schedule urgency will reflect the project's “strategic intent” modified by the above; the same for budgets and risks. The constant aim of the project team should be improving value while managing risk.

In summary, Reconstructing Project Management argues that the way we deploy the elements of the management of projects, given the constraints of the project's strategic intent, environment, and requirements, can shape and modify the project's characteristics. So much so in fact, that nearly all of the characteristics that are said to influence the way we should manage projects turn out to be not wholly ‘given’ but rather may be susceptible to modification. Future changes in management technology are likely to make the case for doing this even stronger; in fact, the aim should be for the project to be uprated, with respect to its strategic objectives, its context and its characteristics, to such an extent that the value of the offering is significantly improved, which brings us to the next stage of Reconstructing Project Management’ s argument: enhancing sponsor value.

Building Sponsor Value Reconstructing Project Management argues for a philosophy in which the people whose profession is the business of managing projects—the project management team—serve the sponsor by deliberately seeking actions to improve the value that the emerging project is offering him or her. Project management, using the term in its widest sense, should have a proactive, driving role—one that pre-eminently is about developing and delivering value to its clients, while managing the risk latent in the project. It is much, much more, I contend, than simply planning and monitoring: the cruise-control view of project management as reflected in the PMBOK® Guide and ISO 25100 (Figure 6). It is the basis of the Japanese Body of Knowledge. (Such at least are my values.)

The following are examples of opportunities where project management can implement this valueenhancing approach.

• Governance and Strategy: one of the first tasks in establishing the project is to develop its strategy and ensure that this is effectively aligned with the sponsor's aims and strategy. Stakeholder management is extremely important here: not all stakeholders will support the project and stakeholder prioritization will often be necessary (Aaltonen & Sivonen, 2007; Newcombe, 2003). A systems perspective is helpful in seeing what the elements are that, working as a whole, will influence the achievement of the overall goal: what the organizational, technical, social, and other subsystems that interact are and how significant the interfaces are; what the control and regulatory mechanisms need therefore to be; and what the best way to manage those interactions is. Seeing the project, or program, in its totality helps frame the sponsors’ opportunities. Who is best positioned to do this analysis? It will rarely be the sponsor alone; it is unlikely that he or she will have either the knowledge or the time. It is most obviously the remit of project or program management. As a professional with specialist knowledge about projects and programs, the project manager, I contend, is responsible for making this relationship work as effectively as possible (Helm & Remington, 2005; Miller & Hobbs, 2005; Reve & Levitt, 1984).

• Requirements and Innovation: the project management challenge now is to improve sponsor value. Innovation will be a standard component of project management practice. The experienced project executive will want to assess the impact of technical and commercial issues and will want to be involved in major decisions in moving from requirements through specification and design, into ‘building’ and then verification and validation. If requirements cannot be established so that they remain stable it may well make sense to go in the Agile direction and divide the scope into small pieces and work with smaller cycle times.

• Commercial Platform: similarly, the project management team should provide input into commercial matters, beginning with the project strategy and the choice of contracting strategy; in particular, what functions to contract out, what resources are available, and how risk should be allocated. These typically come under the purview of the ‘Contracts and Procurement’ function but since they can all massively influence the way the project is managed, one would expect the project director (or equivalent) to be engaged, shaping thinking and decisions. The alignment of supplier aims and practices with the sponsors’ aims should be a major objective in this new environment.

• Project and Program Leadership: to imagine that all this shaping, organizing, and challenging can be done somehow automatically is

beyond credulity. Each action needs conceiving, explaining, and supervising. Articulating the project's vision is not just a fundamental task but a core responsibility, particularly in the early stages when the idea of the project has yet to have acquired much currency. Charisma, drive, energy, and negotiating capability—all provide a project with focus, values, and drive. Ideally there should be someone doing this and acting as ‘the single point of accountability’ for the project from its earliest stages right through to taking some accountability for operational performance. And, ideally, to some degree at least, the composition of the project team should reflect all the relevant major subsystems and parties having a bearing on the design and development of the project. Organizing such programming is fundamentally one of the core functions of project management.

• Valuing Time: time is the most potent resource in projects. Engineering value into it is one of the most significant acts that the project management team can perform. Identifying opportunities for fast-tracking (simultaneous engineering/concurrent engineering) is a clear front-end activity. It should be undertaken for all projects and programs, but particularly for the larger ones: the impact can be huge, not just on the schedule but on product quality and sales.

• Control: securing a funded and sanctioned budget is one of the principal objectives of the project's development phase. Planning is fundamental from day 1. Risk needs modeling, appraising, and acting upon, but from a number of perspectives: operational performance, finance, social (community, sustainability, etc.).

• Benefits Management and Opex: benefits management now has an obvious and accepted place in program management, though it need by

no means be restricted to programs: it has an analogue in projects in integrating Operations and Maintenance. Who ultimately is responsible for achieving an appropriate balance between operational efficiency and capital expenditure? Making decisions relative to the long-term benefit of the project, or program, is absolutely the core of what professional project or program management should be about: building value through capital investment. Yet, in reality very, very few project managers have either the education, experience, or the training to do this, nor the incentives: the organization—the sponsor, the head of the project management function— rarely encourages, trusts, or expects them to do it.

Building value through the complete management of projects is what the new future of project management is all about.

Conclusions

Project management is, as we've seen, a social construct. The drivers shaping its development by PMI in the United States in the 1980s were different from those shaping it in Japan at the turn of the century, and from those acting on APM and its BOK in the 1990s. There is nothing wrong with this unless, and except, when titles and labels prevent us from understanding properly what knowledge we need in order to manage projects and programs effectively.

We have seen that there is “public knowledge” about the discipline of managing projects. The validity of much—arguably all—of this knowledge is affected by the context in which management is operating and the values and behaviors of those involved in the project's (or program's) management. This knowledge, as with the discipline generally, is bigger, richer, and more complex when we take it to include setting-up the project and establishing it satisfactorily in its environment and with its stakeholders. Seeing the discipline only as execution management is to miss much that is critical to it.

The discipline needs to be less inward looking: more relevant, not just to the sponsor's needs but to society's challenges in general. We can foresee several changes in the years ahead in the ways projects and programs will be managed, but the obvious immediate needs are to focus more on improving sponsor value and on shaping the context in which projects and programs are formed and implemented.

Reconstructing Project Management ends with a list of 45 conclusions and recommendations. However one labels it, the book has clearly shown that

project management has been, is and will be a dynamic, powerful discipline having plenty to offer society—it's just up to us to deliver it!

References

Aaltonen, K., & Sivonen, R. (2007). Response strategies to stakeholder pressure in global projects. International Journal of Project Management, 27(2), 131–141.

Abbott, A. (1992). The system of professions. Chicago, IL: University of Chicago Press.

Acker, D. D. (1980). The maturing of the DoD acquisition process. Defense Systems Management Review, 3, 3.

Argyris, C. (1976). Single-loop and double-loop models in research on decision making. Administrative Science Quarterly, 21, 363–375.

Argyris, C., & Schön, D. (1978). Organizational learning: A theory of action perspective. Reading, MA: Addison-Wesley.

Artto, K., Kujala, J., Dietrich, P., & Martinsuo, M. (2007). What is project strategy? International Journal of Project Management, 26(1), 4–12.

Association for Project Management. (2004). Directing change. A guide to governance of project management. High Wycombe: APM.

Association for Project Management. (2013). Body of Knowledge (6th ed.). Princes Risborough: APM.

Bergen, W. B. (1954). New management approach at Martin. Aviation Age, 20(6), 39–47.

Bhaskar, R. (1975). A realist theory of science. Leeds: Leeds Books.

Bresnen, M. (2007). Deconstructing partnering in project-based organisation: Seven pillars, seven paradoxes and seven deadly sins. International Journal of Project Management, 25(4), 365–374.

Bresnen, M., & Marshall, N. (2000). Building partnerships: Case studies of client-contractor collaboration in the UK construction industry. Construction Management and Economics, 18(7), 819–832.

Brooks, C. G., Grimwood, J. M., & Swenson. L. S. (1979). Chariots for Apollo: A history of manned lunar spacecraft. Washington, DC: NASA.

BS ISO 10006 (2003). Quality management systems: Guidelines for quality management in projects.London, England: BSI.

Burns, T., & Flam, H. (1987). The shaping of social organization: Social rule system theory with applications. London, England: Sage Publications.

Burns, T., & Stalker, G. M. (1961). The management of innovation. London, England: Tavistock Publications.

Carr, E. H. (1961). What is history? Cambridge, MA: Cambridge University Press.

Chapman, C., & Ward, S. (2011). How to manage project opportunity and risk: Why uncertainty management can be a much better approach than risk management. Chichester, England: John Wiley & Sons.

Clark, K. B., & Fujimoto, T. (1991). Product development performance. Cambridge, MA: Harvard Business School Press.

Cook, D. L. (1977). Certification of project managers—Fantasy or reality? Project Management Quarterly, 8(3), 32–34.

Cox, A., & Ireland, P. (2006). Relationship management theories and tools in project procurement. In S. Pryke & H. Smyth (Eds.), The management of complex projects: A relationship approach (pp. 251–281). Oxford: Blackwell Publishing.

Davies, A., & Hobday, M. (2005). The business of projects. Cambridge, MA: Cambridge University Press.

Davis, A. M., Hickey, A. M., & Zweig, A. S. (2004). Requirements management in a project management context. In P. W. G. Morris & J. K. Pinto (Eds.), The Wiley guide tomanaging projects.Hoboken, NJ: Wiley.

Davis, S. M., & Lawrence, P. R. (1977). Matrix. Reading, MA: Addison- Wesley.

DeFillippi, R. J., & Arthur, M. B. (1998). Paradox in project-based enterprise: The case of film making. California Management Review, 40(2), 125–139.

Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2011). BIM handbook: A guide to building information modeling for owners, managers, designers, engineers, and contractors (2nd ed.). Hoboken, NJ: Wiley.

ENAA. (2002). P2M: A guidebook of project & program management for enterprise innovation: Summary translation. Project Management Professionals Certification Center. Tokyo, Japan: PMCC.

European Construction Institute. (1999). The ECI guide to managing health in construction.London, England: Thomas Telford.

Faculty of Actuaries, Institute of Actuaries, the Institution of Civil Engineers. (1998). Risk analysis and management for projects. London, England: Thomas Telford.

Flyvbjerg, B., Bruzelius, N., & Rothengatter, W. (2002). Megaprojects and risk: An anatomy of ambition. Cambridge: Cambridge University Press.

Flyvbjerg, B., & Budzier, A. (2013). Making sense of the impact and importance of outliers in project management through the use of power laws. Paper presented at the IRNOP 11th Conference, Oslo.

Galbraith, J. (1973). Designing complex organizations. Reading, MA: Addison-Wesley.

Gann, D. M., & Salter, A. J. (2000). Innovation in project-based, serviceenhanced firms: The construction of complex products and systems. Research Policy, 29(7–8), 955–972.

Geels, F. (2004). From sectoral systems of innovation to socio-technical systems: Insights about dynamics and change from sociology and institutional theory. Research Policy, 33, 897–920.

Gerwin, D., & Susman, G. (1996). Special issue on concurrent engineering. IEEE Transactions on Engineering Management, 32(2), 118– 123.

Giddens, A. (1984). The constitution of society: Outline of the theory of structuration. Berkeley and Los Angeles: University of California Press.

Goldratt, E. M. (1990). Theory of constraints. Great Barrington, MA: North River Press.

Goldratt, E. M. (1997). Critical chain. Great Barrington, MA: North River Press.

Grabher, G. (2002). Cool projects, boring institutions: Temporary collaboration in social context. Regional Studies, 36(3), 205–214.

Grabher, G. (2004). Temporary architectures of learning: Knowledge governance in project ecologies. Organization Studies, 25(9), 1491–1514.

Harré, R. (1972). The philosophies of science. Oxford: Oxford University Press.

Helm, J., & Remington, K. (2005). Effective project sponsorship: An evaluation of the role of the executive sponsor in complex infrastructure projects by senior project managers. Project Management Journal, 36(3), 51– 61.

Hodgson, D., & Cicmil, S. (2006). Making projects critical. Hampshire and New York: Palgrave Macmillan.

Hodgson, D., & Muzio, D. (2010). Prospects for professionalism, In P. W G. Morris., J. K. Pinto, & J. Söderlund (Eds.), The Oxford handbook of project management. Oxford: Oxford University Press.

Horwitch, M. (1982). Clipped wings: The American SST conflict. Cambridge, MA: MIT Press.

Johnson, S. B. (1997). Three approaches to big technology: Operations research, systems engineering, and project management. Technology and Culture, 38(4), 891–919.

Johnson, S. B. (2001). Samuel Phillips and the taming of Apollo. Technology and Culture, 42(4), 685–709.

Jørgensen, M., & Moløkken-Østvold, K. J. (2006). How large are software cost overruns? Critical comments on the Standish Group's CHAOS reports. Information and Software Technology, 48(4), 297–301.

Jugdev, K., & Müller, R. (2005). A retrospective look at our evolving understanding of project success. Project Management Journal, 36(4), 19–31.

Knight, K. (1976). Matrix organization: A review. Journal of Management Studies, 13, 111–130.

Koskela, L., & Howell, G. (2002). The underlying theory of project management is obsolete. Conference Proceedings of the 2002 PMI Research Conference, Seattle, WA. Newtown Square, PA: Project Management Institute.

Lanier, F. (1956). Organizing for large engineering projects, Machine Design, 27, 54.

Larson, E. W., & Gobeli, D. H. (1989). Significance of project management structure on development success. IEEE Transactions on Engineering Management, 36(2), 119–125.

Lawrence, P. R., & Lorsch, J. W. (1967a). Organisation and environment: Managing integration and differentiation. Cambridge, MA: Harvard University Press.

Lawrence, P. R., & Lorsch, J. W. (1967b). The new management job: The integrator. Harvard Business Review, Nov-Dec, 142–151.

Leffingwell, D. (2007). Scaling software agility. Upper Saddle River, NJ: Addison-Wesley.

Lenfle, S. (2012). Proceeding in the dark. Innovation, project managment and the making of the atomic bomb (CRG working paper (008–01)).

Littau, P., Jujagiri, N. J., & Adlbrecht, G. (2010). 25 years of stakeholder theory in project management literature (1984–2009). Project Management Journal, 41(4), 17–29.

Loch, C. (2000). Tailoring product development to strategy: Case of a European technology manufacturer. European Management Journal, 18(3), 246–258.

Mahmoud-Jouini, S. B., Midler, C., & Garel, G. (2004). Time-to-market vs. time-to-delivery: Managing speed in engineering, procurement and construction projects. International Journal of Project Management, 22(5), 359–367.

Meier, S. R. (2008). Best project management and systems engineering practices in pre-acquisition practices in the federal intelligence and defense agencies. Project Management Journal, 39(1), 59–71.

Midler, C., & Navarre, C. (2004). Project management in the automotive industry. In P. W. G. Morris & J. K. Pinto (Eds.), The Wiley guide to managing projects (Chap. 10). Hoboken, NJ: Wiley.

Might, R. J., & Fischer, N. Z. (1985). The role of structural factors in determining project management success. IEEE Transactions on Engineering Management, 32(2), 71–77.

Miller, E. J., & Rice, A. K. (1967). Systems of organization: The control of task and sentient boundaries. London, England: Tavistock.

Miller, R., & Hobbs, B. (2005). Governance regimes for large complex projects. Project Management Journal, 36(3), 42–50.

Miller, R., & Lessard, D. R. (2001). The strategic management of large engineering projects.Cambridge, MA: MIT Press.

Mintzberg, H. (1979). The structuring of organizations. Englewood Cliffs, NJ: Prentice-Hall.

Morris, P. W. G. (1994). The management of projects. London: Thomas Telford.

Morris, P. W. G. (2013). Reconstructing project management. Chichester, England: Wiley-Blackwell.

Morris, P. W. G., & Hough, G. H. (1987). The anatomy of major projects. Chichester, England: John Wiley and Sons.

Morris, P. W. G., & Jamieson, H. A. (2004). Translating corporate strategy into project strategy. Newtown Square, PA: Project Management Institute.

Morris, P. W. G., Patel, M. B., & Wearne, S. H. (2000). Research into revising the APM project management body of knowledge. International Journal of Project Management, 18(3), 155–164.

Morrison, E. J. (1967). Defense systems management: The 375 series. California Management Review, 9, 4.

Müller, R., & Turner, J. R. (2005). The impact of principal-agent relationship and contract type on communication between project owner and manager. International Journal of Project Management, 23(5), 398–403.

Newcombe, R. (2003). From client to project stakeholders: A stakeholder mapping approach. Construction Management and Economics, 21(8), 841– 848.

Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company. New York, NY: Oxford University Press.

Office of Government Commerce. (2002a). Managing successful projects with PRINCE 2. Norwich: TSO.

Office of Government Commerce. (2002b). Managing successful projects with PRINCE 2. Norwich: TSO.

Office of Government Commerce. (2003). Managing successful programmes. Norwich: TSO.

Office of Government Commerce. (2006). Portfolio, programme and project management maturity model (P3M3®). London, England: Office of Government Commerce.

Ohara, S., & Asada. T. (2002). Japanese project management. Singapore: World Scientific Management Publishing.

Orr, R. J., & Scott, W. R. (2008). Institutional exceptions on global projects: A process model. Journal of International Business Studies, 39, 562–588.

Packendorff, J. (1996). Inquiring into the temporary organization: New directions for project mnagement research. Scandinavian Journal of Management, 11(4), 319–334.

Pellegrinelli, S., Partington, D., & Geraldi, J. (2010). Program management: An emerging opportunity for research and scholarship. In P. W. G., Morris, J. K. Pinto, & J. Söderlund (Eds.), The Oxford handbook of project management. Oxford: Oxford University Press.

Pinney, B. W. (2001). Projects, management, and protean times: Engineering enterprise in the United States, 1870–1960(Doctoral dissertation). Massachusetts Institute of Technology, Cambridge.

Popper, K. (1959). The logic of scientific discovery. New York, NY: Basic Books.

Project Management Institute. (1996). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: Author.

Project Management Institute. (2003). Organizational Project Management Maturity Model (OPM3). Newtown Square, PA: Author.

Project Management Institute. (2006). The Standard for Program Management. Newtown Square, PA: Author.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide)—Fifth edition. Newtown Square, PA: Author.

Pryke, S. D. (2001). Analysing construction project coalitions: Exploring the application of social network analysis. Construction Management and Economics, 22, 787–797.

Raz, T., Barnes, R., & Dvir, D. (2003). A critical look at critical chain project management. Project Management Journal, 34(4), 24–32.

Reve, T., & Levitt, R. (1984). Organization and governance in construction. Project Management, 2(1), 17–25.

Rhodes, R. (1988). The making of the atomic bomb. Harmondsworth: Penguin.

Salomo, S., Weise, J., & Gemünden, H. G. (2007). NPD planning activities and innovation performance: The mediating role of process management and the moderating effect of product innovativeness. Journal of Product Innovation Management, 24, 285–302.

Sapolsky, H. (1972). The Polaris system development: Bureaucratic and programmatic success in government. Cambridge, MA: Harvard University Press.

Sapolsky, H. (2003). Inventing systems integration. In A. Prencipe, A. Davies, & M. Hobday (Eds.), The business of systems integration(pp. 15–34). Oxford: Oxford University Press.

Sauer, C. (1993). Why information systems fail. Henley-on-Thames: Alfred Toller.

Sayer, R. A. (2000). Realism and social science. London, England: Sage.

Schön, D. (1987). Educating the reflective practitioner. San Francisco, CA: Jossey-Bass.

Sense, A. J., & Antoni, M. (2003). Exploring the politics of project learning. International Journal of Project Management, 21(7), 487–494.

Shenhar, A. J., & Dvir, D. (2007). Re-inventing project management. Cambridge, MA: Harvard Business School Press.

Söderlund, J., & Lenfle, S. (2013). Making history: Revisiting the past, creating the future International Journal of Project Management, 33, 653–662.

Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering: Coping with complexity. Hemel Hempstead: Prentice-Hall.

The Standish Group. (1994). The CHAOS report. Retrieved from www.standishgroup.com

Thomas, J. (2006). Problematizing project management. In D. Hodgson & S. Cicmil, (Eds.), Making projects critical. Hampshire and New York: Palgrave Macmillan.

Thompson, J. D. (1967/2003). Organizations in action. New York, NY: McGraw-Hill/New Brunswick.

Turner, J. R., & Keegan, A. (2001). Mechanisms of governance in the project-based organization: Roles of the broker and steward. European Management Journal, 19(3), 254–267.

Ward, S., & Chapman, C. (2003). Transforming project risk management into project uncertainty management. International Journal of Project Management, 21(2), 97–106.

Wateridge, J. (1998). How can IS/IT projects be measured for success? International Journal of Project Management, 16(1), 59–63.

Wendler, R. (2012). The maturity of maturity model research: A systematic mapping study. Information and Software Technology, 54, 1317–1339.

Wenger, E. (1998). Communities of practice: Learning, meaning, and identity. Cambridge, England: Cambridge University Press.

Wheelwright, S. C., & Clark, K. B. (1992). Revolutionizing product development. Cambridge, MA: Harvard Business School Press.

Womack, J. R., Jones, D. T., & Roos, D. (1990). The machine that changed the world. New York, NY: Macmillan International.

Yardley, D. (2002). Successful IT project delivery: Learning the lessons of project failure. Reading, MA: Addison-Wesley.

Peter Morris is Professor of Construction and Project Management at University College London (UCL). From 2002 to 2012 he was Head of School. Previously he was Professor of Engineering Project Management at the University of Manchester (UMIST) from 1996 to 2002 and was a director of INDECO, a management consultancy, from 1996 until 2010. His research has largely been on the competencies required to develop and deliver projects and programs successfully, focusing on the needs of managing the overall project, including the front-end and the project's environment (see The Wiley Guide to Managing Projects, Wiley, 2005) edited with Jeffrey Pinto; The Management of Projects (Thomas Telford, 1994), and The Anatomy of Major Projects (John Wiley & Sons, 1987) with George Hough. He has also worked on the linkage between corporate and project strategy (Translating Corporate Strategy into Project Strategy (PMI, 2004) with Ashley Jamieson) and on project-based learning. He has a special interest in the history of project management. He is the joint editor, with Jeffrey Pinto and Jonas Söderlund, of The Oxford Handbook on Project Management(OUP, 2011) and is the author of over 120 papers on project management. His latest book is Reconstructing Project Management (Wiley-Blackwell, 2013). Peter Morris was the recipient of the Project Management Institute's Research Achievement Award in 2005, the International Project Management Association's Research Award in 2009, and the Association for Project Management's Sir Monty Finniston Life Time Achievement Award in 2006. He is a Vice President and was previously Chairman of the APM and was also Deputy Chairman of the IPMA. Prior to 1996 he was a director of Bovis, a global construction company, Executive Director of the UK's Major Projects Association, and an international management consultant with AD Little and Booz Allen & Hamilton. He began his career with the construction company Sir Robert McAlpine. He was awarded his PhD in construction project

management in 1972. He is an (Honorary) Fellow of the APM, and a Fellow of the Institution of Civil Engineers. 1 Regarding spelling: The Oxford English Dictionary gives the first spelling of program with one “m,” noting that the French ending was introduced in the United Kingdom in the 19th century and stating that the single “m” ending “is preferable, as conforming with the usual representation of the Greek -γράμμα as in anagram, cryptogram, diagram, telegram.”