reconstructing project management reprised: a knowledge perspective

P

AP

ER

S

6 October 2013 ■ Project Management Journal ■ DOI: 10.1002/pmj

Project Management Journal, Vol. 44, No. 5, 6–23

© 2013 by the Project Management Institute

Published online in Wiley Online Library

(wileyonlinelibrary.com). DOI: 10.1002/pmj.21369

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 pro-grams effi ciently 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 exam-ples 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.

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 con-structed 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 mak-ing 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 fol-lows this structure but does so from the perspective of investigating what knowledge we need, as a discipline, to manage projects and programs, effi-ciently 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 AreWhy should we bother to understand the history of the development of the discipline? How ‘true’ can this history be? Understanding how things devel-oped helps us to understand why they are what they are today. Understanding

Reconstructing Project Management Reprised: A Knowledge PerspectivePeter Morris, University College London, United Kingdom

October 2013 ■ Project Management Journal ■ DOI: 10.1002/pmj 7

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 con-structed. 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 man-agement 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 proj-ect management preoccupation with planning and control.

Pre the Language of Modern Project ManagementAll 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 pro-gression 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 mod-ern 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 coordi-nator function in the aircraft industry in the late 1920s and 1930s.

World War II saw thousands of de facto projects and programs but no evi-dence 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 proj-ects,’ 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 proj-ect 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 man-ager 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 TheoryThe challenges for all these weapon systems programs were great technical

uncertainty plus huge schedule pres-sure (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 man-agement, 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 pro-gram” further developed and show-cased the new discipline, but project management, as applied at this time, was essentially an engineering man-agement 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 envi-ronmental issues. The U.S. Super Sonic Transport plane, for example, was cancelled due to environmentalist opposition (Horwitch, 1982), with envi-ronmental 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 avail-able 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 com-panies were either forced by DOD or by NATO to implement these new tech-niques (many of which called on newly emerging computing capabilities), or applied them out of curiosity or convic-tion, people began attending seminars, symposia, congresses, and similar events to learn from, and to share, their experi-ences. (Principally, interestingly, most of the discussion was about planning.)


Reconstructing Project Management Reprised

PA

PE

RS

manager’s authority, conflict manage-ment, and the matrix (Davis & Lawrence, 1977; Knight, 1976; Larson & Gobeli, 1989; Might & Fischer, 1985). An important sequence of work on integra-tion 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 signifi-cantly. 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 pic-ture perspective on projects.

The first of these, Morris and Hough (1987), looked at data on 1,653 projects and found that typical sources of diffi-culty were such things as: unclear suc-cess 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, inappropri-ate contracting strategy, unsupportive political environment, lack of top man-agement 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 analy-sis as the project as an organizational entity—was the best way to address the subject, suggesting in 1994 that the dis-cipline should be thought of as “the management of projects” (Morris, 1994) (Figure 1).

The “management of projects” par-adigm was used as the theoretical

primarily the project/product develop-ment process (the project life cycle), despite its fundamental importance, but a simple ‘initiate->plan->execute->monitor & control->close’ sequence, which applies across the various ‘knowl-edge 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 charac-ter 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 fundamen-tally 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 impor-tant to the successful management of projects are omitted. And strangely, of those that are covered, there is little ref-erence 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 pro-grams and its philosophy of project management are so fixed, and are so widely disseminated, that they domi-nate the general perception of the disci-pline. 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: pri-marily ‘how to’ work on planning and organizational topics such as the project

So were born around the late 1960s/early 1970s the professional project management societies.

The Bodies of Knowledge, Critical Success Factor Studies, and Other ResearchBy the mid-1970s PMI, the U.S. head-quartered 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 demonstra-tion of the mastery of a body of knowl-edge 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 prob-ably a more accurate statement of where we are at present.) In 1983 a pilot ‘base-line’ attempt at defining a project man-agement ‘body of knowledge’ (BOK) was drawn up that proposed six knowledge areas as “unique to the project manage-ment field” (Project Management Institute, 1996): Scope, Time, Cost, Quality, Human Resources, and Commu-nications. In 1987 PMI formally pub-lished 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 sup-posedly truly unique to project manage-ment (which in fact it isn’t). Deciding this however requires some form of pre-conception of what project manage-ment is. After all, project management is a social construct; projects are ‘invented not found.’ One needs a frame-work if only to enable discussion. PMI’s construct was a set of processes—not


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 dis-cipline is about: broader and more rounded; concerned with setting the project goals; working with stakehold-ers; managing and shaping the emerg-ing 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 man-agement (Davies, Hobday, et al.), innovation (Gann), supply-chain man-agement and networks (Cox, Pryke), organizational learning (DeFillippi, Sense, Grabher), critical management

(Hodgson & Cicmil), institutional the-ory (Bresnen, Orr), and indeed many other topics (concurrent engineering, complexity, culture, epistemology, eth-ics, 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;

• Time

• Budget

• Scope

• Time

Project Management as represented by the PMBOK® Guide

The ‘management of projects’ conception extending the PMBOK® Guide to include thefront-end definitional stages

THE MANAGEMENT OF PROJECTSinvolves managing the definition and delivery of the project for stakeholder success. Thefocus is on the project in its context. Project and program management and portfolio managementsit within this framework.

PROJECT MANAGEMENT: “On time, in budget, to scope” execution/delivery

• Budget• Scope “Given”

Project Delivery

• Integration

• Integration

• Time • Human Resources

“Delivered”

“Delivered”

• Communications

• Quality

• Procurement• Organizational (structure & people)

• Commercial (supply chain, procurement, etc. )

• Technology (requirements, design, make, test)

• Strategy & finance

Project Definition

Interaction with the business and general environment

ExecutionDefinitionFeasibilityConcept

Initiate Plan Execute Control CloseOut

Close-Out/Operations

• Cost

• Risk

• Scope

• Time • Human Resources

• Communications• Quality• Procurement

• Cost

• Risk• Scope

Initiate Plan Execute Control CloseOut

Figure 1: “Management of projects” compared with traditional project management.



PA

PE

RS

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 nota-ble contribution, exploring strategy, portfolio management and the role of the owner’s management in new prod-uct development, showing inter alia the value of senior project leadership, team working, concurrent engineering and stage gates.

But there was now a change hap-pening. 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 influen-tial today, which focused on the ‘actors’ and the organizations working on proj-ects, 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 effec-tively’ 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 com-municating 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, dis-tinguished between effective perfor-mance (does the project meet the sponsor’s ‘business’ goals?) and effi-cient 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 effective-ness 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 strat-egy and coping with political, eco-nomic, and social turbulence and outside institutions and (2) dealing with partnership and contractual turbu-lence. 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 iden-tified 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 misrepre-sentation’) or are over-optimistic.

Aligned Supply: Focusing on ValueWheelwright 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 improve-ment, Toyota believed that it was non-sensical to expect significant perfor-mance improvements if members of the supply chain were not aligned on the same goals, didn’t have similar val-ues, and were not working together closely and effectively. Obvious though this might seem, it was not the tradi-tional way of engaging resources to work on projects: historically, resources had been procured essentially on the basis of the lowest cost. Now, with lon-ger 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 con-tracts. 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 manage-ment 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 atten-tion (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 ManagementBut it was still proving difficult to deliv-er 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 manage-ment discipline is whether project management should be responsible for ensuring that requirements are ade-quately defined. In many organizations there is no question but that it is; in oth-ers, as in the PMBOK® Guide, it either is not or, at best, its role is ambiguous.


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

The difficulty of accurately specify-ing 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 require-ments were specified through ‘close cou-pling’ between the user and the software

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; neverthe-less Agile software project management continues to attract attention to this day.

At the other end of the spectrum, program management was positioned

Segment management frame

Project finance management

Project organization management

Project resource management

Information management

Value management

Project strategy management

Project systems management

Project goal management

Risk management

Relationship management

Communication management

Project Management

1. Definition, basic attribute, frame2. Project management common view3. Integration management4. Segment management5. Integration management skill

Program Management

1. Definition, basic attribute, frame2. Program platform3. Profiling management4. Program strategy management5. Architecture management6. Platform management7. Program lifecycle management8. Value management

Entry

II. Project Management

III. Program Management

IV. Segment Management

I. Entry

Japanese professional project management is organized under the banner of Kaikaku ProjectManagement (KPM) and works as follows:

1. Profile the project in terms of its mission. The mission may have implicit as well as explicit meanings.2. Propose the best strategy option within the scope envelope that meets the program mission.3. Design the ‘structural,’ functional, and behavioral ‘architecture’ for the program within the limitations of the ‘scheme’ business plan, systems context, and Operations and Maintenance service requirements.4. Design the human operating environment (Ba) to perform and deliver as required: active, knowledge-oriented, supportive, good communications.5. Make decisions in synch with external market, internal enterprise, and embedded program and project drivers. Concurrent engineering is recommended.6. Perform multi-dimensional value management.

Figure 2: P2M: The Japanese Body of Knowledge.



PA

PE

RS

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 man-agement (Office of Government Commerce, 2003). This, together with OGC’s sister guide for project manage-ment, 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 commod-ify 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 over-reached themselves in proposing that projects produce only outputs, mea-sured 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 assess-ment 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 manage-ment. 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 SupportMaturity 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 promul-gated 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 sup-port software; an increased interest in benchmarking practices and perfor-mance; and the growing sense of frus-tration 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 man-agers, charged simply (sic) with deliver-ing projects successfully, were having to propose ‘best practice’ as though it was easy to assimilate and perform, regard-less 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 main-streamed the importance of tacit knowl-edge 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 Management opines (Morris, 2013). Why? Because one rarely gets the perfect fit; it’s diffi-cult to assess how people will really per-form 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 produc-tion, are animate—they have egos, are passionate, willful, emotional, and make mistakes. And, amazingly, many people don’t actually have their compe-tency 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 return-ing 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 pro-grams thus becomes a matter of consid-erable 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 com-petencies, 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 develop-ment of the discipline and it is time to begin examining how robust our knowl-edge is on how best to manage projects. This is what the book focuses on in Part 2, which examines the principle knowl-edge areas individually, and the begin-ning of Part 3, which looks at the ontology, epistemology, and methodol-ogy underlying this knowledge.

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.”


Deconstructing Project Management: The Knowledge BaseAlthough modern project management (as defined, for example, in the lan-guage 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 moni-toring. 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, perfor-mance 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 per-form better. Appendix 1 of Reconstructing Project Management lists 91 CSF studies published between 1967 and 2011. These consistently demonstrate a con-sistent 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 TheorySo, 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 knowl-edge we are working with and partly on the methodology used to generate that knowledge.

First we need to widen the epistemo-logical base. With project management

knowledge we are nearly always operat-ing 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, refut-ability 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 quan-tum level). Yet, much project manage-ment knowledge is often presented in a positivist, absolute manner: as, for exam-ple, in guidance which is ‘method-ori-ented’ such as PRINCE2 or the PMBOK® Guide. While this might seem appropri-ate 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 moti-vational dimensions) let alone leader-ship and the other ‘people’ topics—would suggest that more interpretive episte-mologies are needed.

Even where practice might need mandating regardless of local conditions

• Does project management cover the management of the project front-end, the definitional, development stages, or is it concerned essentially only with execution delivery? What should it be responsible for? How far does it stretch into concept definition at one end and operations at the other?

• If it does not cover the front-end (a) is it fit-for-purpose (b) do we need an enlarged discipline or body of knowledge to cover what we need to know about managing the overall project? (Since managing the front-end is key (i) in building-in value (ii) in building-in [or out] future problems.)

• When and how can we get away from a PMBOK that is based around what was chosen as being ‘the knowledge that is unique to project management’ rather than that which we need to know in order to develop and deliver projects successfully?

• Should there be, resources allowing (personnel, funds), one [senior] person responsible for, and in charge of, the project from beginning-to-end? (What does ‘beginning-to-end’ really mean?)

• Does project management cover Estimating and Contracts and Procurement? Are they parts of the discipline? (Organizationally, they are often not treated this way.)

• Should project managers work to achieve effectiveness goals (value, functionality, business performance) or just stay with efficiency ones (on time, in budget, to scope, etc.)?

• Is program management just the management of projects with shared aims and possibly resources or does it have some special ownership of delivery of the business case benefits? If the latter, why? Shouldn’t projects also have this concern?

• Is Agile a project management discipline or really just a form of task or workstream management? • What is the role of theory in explaining project management?

Figure 3: Current issues in project management as a discipline.



PA

PE

RS

or opinions—rules about financial dis-bursements perhaps, employment con-ditions, health and safety, or engineering design, document management or change control—so that a prescriptive, positivist manner may seem appropri-ate, 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 real-ity it is relative. Health and safety stan-dards, for example, may seem to reflect a strongly positivist epistemology but ulti-mately only because that is how our soci-ety 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 every-thing, 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 turn-ing what at the operational level may be focused and meaningful into some-thing which at a high level is almost platitudinous. Take the guidance sum-marized in Figure 5 for example; this is an attempt to outline best practice principles in the management of proj-ects. I would contend that it is concep-tually 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 con-text X. And then we’re back to the prob-lem that the knowledge at this level of detail may not be universally applicable.

Project Management Topic Area Project Management Topics

General Discipline Areas

Governance and strategy

Goals, strategy [sponsor’s/project’s], portfolio management, program management, innovation, stakeholder management, reviews/audits, value management, risk management, quality management, learning

Strategy, law, psy-chology, risk, man-agement

Technical definition

Requirements management/interface with systems engineering, design management, build, testing, [I]V&V, RAD, CAD/CAE/CAM, technology [maturity], R&D, manufacturing

Systems engineer-ing, technology, ICT, engineering management

Commercial Finance, joint ventures, acquisition and contracting strategy, partnering, contract administration, procurement

Finance, econom-ics, law, manage-ment

Control Scope (PBS, WBS), change management, configuration man-agement, scheduling, critical path, fast tracking, concurrent engineering, estimating, resourcing, critical chain, last planner, cost management, performance measurement, benefits man-agement, project management methodologies, ICT, Asset models

Cybernetics, General Systems Theory, economics, ICT

Organization Project life cycle, RACI, integration/differentiation, project/functional/matrix structure, matrix swing, stage gates, concur-rent engineering, PMO, organizational capabilities, maturity modelling, social/organizational network analysis, contingency theory, organizational learning, institutional theory

Social science, organization theory, psychology, man-agement, engineer-ing management

People Teams, leadership, stakeholder management, culture, compe-tencies, communications, trust, emotional intelligence, influ-encing and negotiating, conflict management, decision-mak-ing, delegation and empowerment, motivating

Social science, psychology, organi-zation theory, man-agement

Figure 4: Topics in the discipline of managing projects.


recognizing that there are really two major sources of uncertainty: market (or goal) uncertainty and technological (or task) uncertainty. Thus, the NTCP (nov-elty, technology, complexity, and pace) model emerged” (ibid). And that ex cathe-dra statement is the sole basis on which these four parameters are chosen.

ScholarshipDoes 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 reflect-ing on practice, are inventing the disci-pline. 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

and/or had less than the required fea-tures 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, complex-ity, and pace (NTCP). Where do the four come from? Originally, Shenhar and Dvir concluded there were “three dimensions that characterize each project: uncer-tainty, 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,

One consequence of Figures 4 and 5 is that we can see there are several epis-temologies 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.

MethodologyOur 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 exam-ple, 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

Governance • Set, monitor, and maintain values, objectives, strategy, assurance mechanism, risk/return expectations

Definition • Align the project strategy with the sponsor’s, including periodic reviews • Define the requirements doing so in a manner such that specifications and solutions can be verified • Manage design and technology so that innovations are thoroughly examined before proceeding to full project

commitment

Control • Define and manage the project scope, schedule, resource, and budget (optimal financing) including limiting changes

once the design has been agreed (design freeze), integrating cost, schedule and scope measurement, and conducting trend analyses on anticipated out-turn cost. Ensure realistic contingencies

Resourcing • Procure/induct resources into the project in as cost effective/value enhancing manner as possible • Build effective project teams • Exercise leadership

Performing • Ensure appropriate people and organizational maturity. Enable instinct. Effect decision making and communications.

Influence stakeholders. Shape context. Put a premium on people. • Seek out value

Learning • Review lessons learned after and during the project; peer review sessions; link to competency development

Figure 5: General principles of a discipline for developing and delivering outcomes that meet sponsor’s goals.



PA

PE

RS

Demographic changes will increas-ingly 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 mil-lion 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 pro-duce about 70% more food than we do today, in conditions where land and water are scarce; where, because of cli-mate 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 bil-lion 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 pro-vide new ones: over US$40 trillion is required over the next 25 years. The impact of global warming will exacer-bate this need significantly: sea levels will rise substantially during this cen-tury, possibly by several meters, partic-ularly 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 mas-sive new oil and gas exploration and production in remote and difficult loca-tions. CO2 emissions need reducing dramatically: The biggest emitter is the existing built stock. How should this

Reconstructing Project Management: The Next EraKnowledge, particularly social knowl-edge, needs an owner. It is interpreted through social values. What are the val-ues that managers of projects and pro-grams should be displaying? What should be the ethos of project manage-ment? 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 cus-tomer/sponsor? In essence, it has to be the latter, because if it is not, project management is an inward looking pro-fession that in the long-term few seri-ous managers are going to get very excited about. What managers in gov-ernment, business, academia—just about everywhere in fact—are con-cerned 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 main-stream effectiveness performance measures, discuss benefits, and dis-suade 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 seri-ous and dangerous issues in its history, yet project management is almost totally silent on how to help address them.

Global ChallengesThe world’s population, currently around 6 billion, will probably peak at about 9 billion by 2050. Humankind already well exceeds the Earth’s carry-ing capacity: the trouble is, we don’t know by how much.

discipline of project management, say scholarship here is a waste of time any-way. 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’ top-ics, such as risk management or sched-uling, 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 con-sensus in their views. Practitioners are at the sharp end of ‘a’ reality but gener-ally 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, schol-arship 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 dis-cipline on solid social science method-ology: 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 circum-stances, on what basis, and for what rea-son? The professional community will inevitably coalesce around certain con-ceptions and definitions, but with new times come new needs and new percep-tions, 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.


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 oper-ationally 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; insti-tutional project and program man-agement will support this improved instinctiveness. Arguably the best way to do this is through training and edu-cation. Thus learning and develop-ment will become more important—the two being linked in ways they have not really been to date. But again, more plurally, not in so singu-larly 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 ManagementProgram management is the elephant in the room here. Do we understand it properly? Do we have an adequate the-ory or theories for it? Programs are col-lections 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 manage-ment of the collective set of such inter-dependent 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 with-out this emphasis in product develop-ment 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 Management sug-gests that Geels’ transition theory is one cogent candidate, one which could prove particularly apposite for address-ing the societal challenges we face (Geels, 2004).

Shaping ContextBattles are fought in terms of objec-tives, 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, envi-ronment, personalities, and so on. But management doesn’t have to be pas-sive; 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 chunked-up and its parts managed discreetly; urgency (speed, pace) may be modified through phasing, fast-tracking or con-current 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 respond-ing to given environmental and project characteristics, Reconstructing Project Management explores how it can respond to independent or semi-independent 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 ‘envi-

ronment’ on the project’s business case, in particular the political, eco-nomic, and the social environments.

And the remaining four that are more a consequence of the emerging

problem be addressed? Changing behaviors has to be part of the solution but really we need a bigger, more com-prehensive approach. Project and pro-gram management has a major role here.

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

Implications for the DisciplineProject management can and should have a major role in addressing these challenges, assembling and driving for-ward 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 megaproj-ects for example. Nevertheless, we can spot some developments relevant to tomorrow’s world: • Control will use integrated, intelli-

gent models more fluently—configu-ration 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 sup-ply chain capabilities. Strategy and governance will be the lynch pin. The provision of funding and the organi-zational consequences that result (better control, greater performance



PA

PE

RS

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 pro-gram management. As a professional with specialist knowledge about proj-ects and programs, the project man-ager, 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 proj-ect management practice. The experi-enced 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 ‘build-ing’ and then verification and valida-tion. If requirements cannot be established so that they remain sta-ble 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 mat-ters, beginning with the project strat-egy 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 equiv-alent) to be engaged, shaping think-ing 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, organiz-ing, and challenging can be done

which brings us to the next stage of Reconstructing Project Management’s argument: enhancing sponsor value.

Building Sponsor ValueReconstructing Project Management argues for a philosophy in which the people whose profession is the business of managing projects—the project man-agement team—serve the sponsor by deliberately seeking actions to improve the value that the emerging project is offering him or her. Project manage-ment, using the term in its widest sense, should have a proactive, driving role—one that pre-eminently is about devel-oping and delivering value to its clients, while managing the risk latent in the project. It is much, much more, I con-tend, than simply planning and moni-toring: 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 manage-ment can implement this value-enhancing 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. Stake-holder management is extremely important here: not all stakeholders will support the project and stake-holder prioritization will often be necessary (Aaltonen & Sivonen, 2007;

Newcombe, 2003). A systems per-spective 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 subsys-tems that interact are and how sig-nificant the interfaces are; what the control and regulatory mechanisms need therefore to be; and what the best way to manage those interac-tions is. Seeing the project, or pro-gram, in its totality helps frame the sponsors’ opportunities. Who is best

project design and project manage-ment strategy: • Establish funding for the project and

how this fits with the business case. But to answer this requires an esti-mate and an estimate requires a design. So “funding” iterates with “solution development.”Funding requirements may then result in re-scoping or re-design, in de-risking, in choosing specific suppliers, in chang-ing the pace of development, and so forth;

• Then: “solutions development”: tech-nology 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 “stra-tegic 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 manage-ment of projects, given the constraints of the project’s strategic intent, envi-ronment, 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 modifica-tion. 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 up-rated, with respect to its strategic objec-tives, its context and its characteristics, to such an extent that the value of the offering is significantly improved,


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 orga-nization—the sponsor, the head of the project management function—rarely encourages, trusts, or expects them to do it.

Building value through the com-plete management of projects is what the new future of project management is all about.

ConclusionsProject 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.

opportunities for fast-tracking (simul-taneous engineering/concurrent engi-neering) 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 prod-uct quality and sales.

• Control: securing a funded and sanc-tioned budget is one of the principal objectives of the project’s develop-ment phase. Planning is fundamental from day 1. Risk needs modeling, appraising, and acting upon, but from a number of perspectives: oper-ational performance, finance, social (community, sustainability, etc.).

• Benefits Management and Opex: benefits management now has an obvious and accepted place in pro-gram management, though it need by no means be restricted to programs: it has an analogue in projects in inte-grating 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

somehow automatically is beyond credulity. Each action needs conceiv-ing, 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 cur-rency. 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, ideal-ly, to some degree at least, the compo-sition of the project team should reflect all the relevant major subsys-tems and parties having a bearing on the design and development of the project. Organizing such program-ming 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 signifi-cant acts that the project manage-ment team can perform. Identifying

1. Develop the project strategy (in line with Stakeholders’ objectives and goals.2. Establish the scope of the project.3. Plan the schedule (if not in detail then in outline or progressive detail).4. Allocate resources.5. Allow for risks.6. Allocate contingencies; agree the budget.7. Monitor and Control that the project keeps to these planned targets.

1. Establish the business case for the project and the proposed strategy for its development and delivery to marry into this.2. Establish the scope of the project, plan the schedule (if not in detail then in outline or progressive detail); allocate resources; allow for risk, allocate contingencies; agree the budget.3. Manage the work on the emerging project definition (a major piece of which will be the pre-sanction product definition) and on preparing for downstream implementation.4. Establish the commercial platform upon which the project work will be done.5. Enhance performance; build value, harvest benefits, manage risk, control performance and drive progress.6. Do all this remembering that projects are done by, with and through (and for) people— that is, manage the people involved in the project.7. Learn and improve.

MONITORING & CONTROL

ADDING VALUE

Source: Author’s own.

Figure 6: Project management in adding value rather than providing cruise control.



PA

PE

RS

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 man-agement of complex projects: A rela-tionship 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 model-ing 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

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 manage-ment 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 organisa-tion: 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 manage-ment systems: Guidelines for quality management in projects. London, England: BSI.

Burns, T., & Flam, H. (1987). The shap-ing 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.

We have seen that there is “public knowledge” about the discipline of managing projects. The validity of much—arguably all—of this knowl-edge is affected by the context in which management is operating and the val-ues and behaviors of those involved in the project’s (or program’s) manage-ment. This knowledge, as with the disci-pline generally, is bigger, richer, and more complex when we take it to include setting-up the project and establishing it satisfactorily in its envi-ronment 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 con-text 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 proj-ect management has been, is and will be a dynamic, powerful discipline hav-ing plenty to offer society—it’s just up to us to deliver it! ■

ReferencesAaltonen, 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 profes-sions. 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.


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 differentia-tion. Cambridge, MA: Harvard University Press.

Lawrence, P. R., & Lorsch, J. W. (1967b). The new management job: The inte-grator. 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 con-struction projects. International Journal of Project Management, 22(5), 359–367.

Meier, S. R. (2008). Best project man-agement 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 indus-try. In P. W. G. Morris & J. K. Pinto (Eds.), The Wiley guide to managing projects (Chap. 10). Hoboken, NJ: Wiley.

Grabher, G. (2004). Temporary archi-tectures of learning: Knowledge gover-nance in project ecologies. Organi-zation 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 evalu-ation of the role of the executive spon-sor 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 hand-book 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 engi-neering, 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 retro-spective look at our evolving under-standing 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 manage-ment is obsolete. Conference Proceedings of the 2002 PMI Research Conference, Seattle, WA. Newtown Square, PA: Project Management Institute.

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 impor-tance 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, service-enhanced 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 sys-tems: Insights about dynamics and change from sociology and institu-tional theory. Research Policy, 33, 897–920.

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

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

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

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

Grabher, G. (2002). Cool projects, bor-ing institutions: Temporary collabora-tion in social context. Regional Studies, 36(3), 205–214.



PA

PE

RS

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 con-struction project coalitions: Exploring the application of social network anal-ysis. 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 con-struction. 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 mediat-ing role of process management and the moderating effect of product inno-vativeness. Journal of Product Innovation Management, 24, 285–302.

Sapolsky, H. (1972). The Polaris system development: Bureaucratic and pro-grammatic 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 sys-tems integration (pp. 15–34). Oxford: Oxford University Press.

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

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 pro-grammes. Norwich: TSO.

Office of Government Commerce. (2006). Portfolio, programme and proj-ect 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 proj-ects: 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 manage-ment: 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, manage-ment, 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

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 engi-neering projects. Cambridge, MA: MIT Press.

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

Morris, P. W. G. (1994). The manage-ment 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


programs successfully, focusing on the needs of managing the overall project, includ-ing 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 cor-porate 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.

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 iden-tity. Cambridge, England: Cambridge University Press.

Wheelwright, S. C., & Clark, K. B. (1992). Revolutionizing product devel-opment. 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 manage-ment consultancy, from 1996 until 2010. His research has largely been on the competencies required to develop and deliver projects and

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

Schön, D. (1987). Educating the reflec-tive 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, cre-ating 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 criti-cal. 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 proj-ect-based organization: Roles of the broker and steward. European Management Journal, 19(3), 254–267.

reconstructing project management reprised: a knowledge perspective

Documents