Introduction
There has long been a great deal of evidence that the front-end of projects is where things can go badly wrong and, conversely, where there is the best chance of positively influencing the chances of a successful outcome. Our knowledge of just what this entails, however, has often been hazy and too often project managers have been excluded from this vital area. This paper draws on the results of two research projects on the way projects interact with, and can shape, enterprise strategy, and the role of project managers in leading that shaping. The paper suggests that we might usefully extend A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and Organizational Project Management Maturity Model (OPM3™) by looking at the frontend of projects not as external to the project management's scope of action, but rather as being absolutely within its domain.
The Importance of the Front-End
There is good reason to claim the origins of modern project management as coming primarily from the US aerospace industry, particularly the Atlas, Polaris and Apollo programs and the practices introduced into the US Department of Defense (DOD) by Robert McNamara (Engwall, 1999; Morris, 1994). The vision of the discipline at that time, as is still common to many people, was one through which would be delivered projects successfully – meet the requirements, and be delivered on time and in budget. From the early 1960s DOD was operating a five phase systems life cycle. Projects have never been easy however and by the mid 70s it was accepted that there were major problems and that the practices being followed weren't working effectively. Much of the difficulty lay around the areas of the authority of the program manager, the basis upon which external resources are contracted onto projects and programs, and the technical risk and cost estimating difficulties in the front-end. As a result there was a major review of DoD practice, one result of which was “the emphasis on greater attention to increased front-end definition and competition [which] resulted in the establishment of a new milestone ….Milestone 0 – approval of the mission element need” (Morris, 1994: p.132). SMART acquisition practices (www.ams.mod.uk) and the recent history of the two UK aircraft carriers suggest things have not changed very much since in 30 years!
In the mid 1980s, Morris and Hough surveyed the results of all the literature on project success and failure they could find in the public domain (Morris & Hough, 1987) – data on over 3,500 projects – and found that overruns of between 40 and 200% to be the norm. The reasons, they concluded, are “generally to be found in areas which have traditionally not been the concern of project management” (p. 12), and that to improve project delivery performance (i) all parties need an attitude truly desirous of project success (ii) the project must be properly defined and should not be committed to until that definition is shown to be workable; it should then be ‘frozen’ to the extent possible (iii) external forces influencing project definition should be monitored and their impact managed (iv) the affect of the project definition on the project finance, schedule and manner of implementation must then be assessed (v) the choice of the right people is crucial (pp. 266-8).
Cooke-Davies, in one of the most recent and thorough assessments of the literature on project success suggests that in terms of delivering successful projects and programs, the discipline of project (and program) management is best looked as needing to be capable of (1) delivering projects properly (2) ensuring the project has been defined, developed and selected effectively (3) doing this repeatedly within the enterprise (Cooke-Davies, 2004). The first of these aligns closely with the traditional PMBOK® Guide elements. The second suggests something broader, to which we will return in a moment, and covers: maintaining clarity about goals; maintaining commitment to the project on the part of all significant stakeholders; ensuring a means of delivering project benefit; and developing a project strategy that is appropriate to the project (p. 116). The third refers, in Cooke-Davies' view, to learning, resourcing, and measurement – both of project performance (are we doing this right) and project success (did the project turn out as expected).
Two conclusions stand out from these two studies. One, that following the PMBOK® Guide elements may be sufficient to deliver projects properly in process and practice terms but probably is not enough to ensure that the project is successful. Two, that to do the latter one needs to concentrate more on the managing the front-end.
But it is the contention of this paper that one can take the argument a stage further: project execution is itself improved by concentrating more on the front-end; and that the project (and program) management professional has a significant role to play managing projects and programs for business success. Benchmarking data in the oil and gas industry, for example, shows conclusively that effort spent (up to a point) on front-end definition (so-called ‘Front-end Loading’ – FEL) correlates positively with project outcome performance. And second, there are a number of practices which the ‘project management’ professional can deploy which will positively enhance the strategic value of the project to the sponsoring organization(s). It is these contentions that this paper explores.
Strategy and the Front-End in the Bodies of Knowledge
The PMBOK® Guide (PMI, 2004) is effectively silent on the contribution that project management specifically can make to managing the front-end. Projects are seen as “a means of achieving an organization's strategic plan” (p. 7) though no guidance is given on how the two interact: the implication is that the plan is ‘given’ to the project. In Chapter 4, Initiation, the organization's strategic plan is an input to the project Charter and hence to the project scope. Requirements are taken as a given, as is funding. Value Management is not mentioned (except as ‘Earned Value Management’) (though Value Engineering gets six mentions.) The role of leadership in setting up the project is not mentioned. Stakeholders are indeed recognized as important players in the project (Section 2.2. for example) but the implication is that they need to be managed only ‘to meet the project requirements’, which they do of course but the lessons of many projects is that their management pre-definition, at the requirements definition & planning stage, is absolutely critical – planning approvals, finance, environmentalists, local communities, user groups, etc. Getting these people effectively engaged is essential both in ensuring the requirements are appropriate and in minimizing potential opposition downstream.
OPM3™ (PMI, 2003) continues the execution orientation. Program management, is positioned as “a group of related projects managed in a coordinated way to obtain benefits and control not available by managing them individually” (p.24) with the interaction with project strategy being positioned higher, at the portfolio level. Admittedly there is some confusion on the way program management is defined and interpreted in the profession but, in the UK at least, it is additionally as a means of achieving strategic change and has a clear proactive involvement in strategy (APM, 2000, 2005; OGC, 2003; Reiss, 1996; Thiry, 2004).
Part of the trouble is the process basis used to define projects and project management. The PMBOK® Guide and OPM3™ are organized not around managing the project life cycle (Concept, Appraise, Define, Develop, Execute, Operate – or some similar equivalent – as outlined in Chapter 2 of the PMBOK® Guide), but against a generic Initiate, Plan, Execute, Control, Close sequence. Both are valid. Not emphasizing the former, however, leads to many of the real characteristics of projects and programs being overlooked – not least the importance of the front-end.
The result is that debate about project management can too easily fall into nominalist traps of getting snagged on the way we name things. In fact the argument is more fundamental than this: it is about what we mean by the discipline. Is project management about “the application of knowledge, skills, tools and techniques to project activities to meet project requirements” as PMBOK® Guide defines it (p.8), or is it the discipline of managing projects successfully as other Bodies of Knowledge define it (APM, 2005; PMCC, 2001, Caupin et al, 1998)? The argument this paper is proposing is that projects are only done for a reason – generally the sponsor's reason – often, though not always, expressible in financial terms, most obviously NPV (Net Preset Value) (though other measures are often used, as in Benefits Management and the Balanced Scorecard (OGC, 2003; Steward, 2001). For many people the undoubted reality of their project management is that it is a pre-dominantly execution oriented activity, in some cases, possibly even just concerned with getting to the next stage gate. This is certainly the tenor of the PMBOK® Guide. For others however it must embrace delivering projects for stakeholder or business value. This is the broader ‘management of projects’ perspective (Morris, 1994; Morris & Pinto, 2004) underlying the other BOKs, where the project (and its requirements) has to be developed and defined effectively as well as built; where managing the interaction between the project and its environment to best meet project requirements is as critical as simply building the project to some set of approved requirements. Where managing the front-end definition is as much a part of the domain as managing execution.
Suffice to say, then, that there is some uncertainty around the role of project and program management in the front-end and the interaction between corporate strategy and project, or program, strategy can best be influenced by the discipline. To investigate this area further, PMI funded a research project at University College London (UCL) to look at the way corporate strategy is translated into project strategy (Morris & Jamieson, 2004). The results from this study provide the core of the rest of this paper. In addition however further research at UCL has been undertaken as part of the as yet unpublished revision to the APM Body of Knowledge (APM, 2005) which shows clearly the roles and expectations of project and program managers in the front-end stages. We shall begin with this work.
Mapping the Front-End
As part of the APM Body of Knowledge (BOK) work, the UCL team interviewed 50 senior project executives from a variety of industry sectors and obtained extensive responses from over 400 web-based questionnaires. The web-based questionnaires were designed to find out, amongst other things, whether the respondents (a) felt the topics given in the questionnaires should be included in the new BOK (b) whether they would propose amendments to the proposed definitions.
Of the web-based questionnaire respondents, percentages rating the following front-end topics as relevant or highly relevant were as follows. (At the time of writing, these results are still preliminary.) (Exhibit 1)
Exhibit 1
In summary, the results show an overwhelming vote for including KPIs, strategy, finance, stakeholder management, value management, benefits management, risk, quality, HSE, scope, technology, estimating, and most people factors – all representatives of front-end topics – in a project management Body of Knowledge.
This is not to say that such topics are necessarily used in practice however. To investigate the extent to which this is done we conducted a number of studies to map the topics proposed for inclusion in the APM BOK 5th edition against the processes and practices used by the following industry sectors/ organizations:
- aerospace (second tier supplier)
- construction (owner-operator of major facilities)
- defence procurement (client procurer)
- drug development (R&D/manufacturer)
- IT-enabled change (government agency)
- energy (oil and gas developer/operator)
- software and systems development (first or second tier supplier).
The results (APM, 2005) show clearly and conclusively that virtually all the BOK elements are expected by the organizations surveyed in the front-end stages (defined variously as being, on average, the three stages before Execution), though with the following exceptions.
- Construction, defence, and drug development did not use the term ‘benefits management’.
- Defence was silent on value management.
- Drug development was quite on all people topics except teamwork.
- IT-enabled change was silent on teamwork.
Prima facie, therefore, there is very clear evidence here that the discipline of project (and program) management applies to the pre-execution front-end stages (the parts of projects that the PMBOK® Guide says project management is not within its scope) as much as to the post requirements definition, capital approval, execution phases!
What, then, did the PMI study show about the role of project management in translating strategy from the enterprise level to the project level?
Translating Corporate Strategy into Project Strategy
Again, there is further survey evidence (Morris & Jamieson, 2004). Thirty-two questions were developed to examine the processes, practices and people issues involved in moving strategy from the corporate level to projects. The questions covered business management, strategic management, portfolio management, program management and project management. The questionnaire was sent out randomly to PMI Chapter members in Europe. Seventy-five responses (about 50% from UK) were received from people, at various levels of seniority, in small, medium, and large enterprises in a diverse range of business sectors such as aerospace, automotive, IT, telecommunications, pharmaceuticals, retail, transportation and publishing; and academia and consultancy. The following represent the principle findings.
- 67% used a generic business model. 50% believed they had extensive processes for moving corporate goals into project strategy; 90% had adequate or better interconnection between corporate, business and project management processes. Over 53% recognized a hierarchy of objectives and strategies (68% at the SBU level).
- 50% used some form of portfolio management, 95% used some form of program management (with 75% having business benefit management as an explicit part of this).
- 85% used extensive or partial project management processes to manage project strategy; most (75%+) had specific strategy inputs into project management, 65% doing this in an ‘emergent’ manner (see below). 85% used a gate review process with clear sponsorship responsibilities. 65% upgraded strategy as the project progressed.
- 55% had a process for optimizing the value of the project; 75% of this 55% combined this with risk management.
- 80% had project management competencies defined of which 75% included those for managing the strategy development process.
In short, once again there is strong if not overwhelming evidence that project (and program) management has important work to do in front-end operations, here specifically in integrating project and programs, often via portfolios (but beyond the extent suggested in OPM3™), to enterprise strategy. And again, there are some important project management practices which are hardly if at all mentioned in the PMBOK® Guide, most notably Value Management and Benefits Management.
Several case studies were additionally specially prepared for the research and each has a telling observation on the way project management interacts with enterprise strategy. (Full write-ups can be found in Morris & Jamieson, 2004).
The drug development case
Drug development occurs as a large number of candidate molecules go through a highly regulated, highly structured development life cycle. There are, so at least the enterprise hopes, usually many more candidate molecules than there are resources available to develop them. Hence managing the resources – capacity planning – has to be a core competence of the organization. Typically this is done across a highly complex matrix, where project and program management shapes the project development strategy and manages the product's evolution as it goes from the discovery labs into toxicity and efficacy testing studies prior to submission for regulatory approval. Candidate molecules fail at a spectacular rate: of every 10,000 to 30,000 compounds entering discovery, only 250 will make it to pre-clinical evaluation; only 5 to 10 to clinical; and only one will get approved and to the patient (Foulkes & Morris, 2004). Managing the resource allocation process across such a spread of (potential) projects is a major task, one which is done by ‘governance’ largely at the portfolio level (as described in OPM3™). What is so special about the drug development example is (a) the high degree of interaction between each of the three levels of portfolio, program and project, and (b) the way newly emerging data feeds into the governance decision making and influences governance strategy at the enterprise level. This is a prime example of ‘emergent’ strategy, to use the term coined by Mintzberg (Mintzberg & Quinn, 1996).
The aerospace case
The aerospace company modelled in the research, on the other hand, was a good example of Mintzberg's ‘deliberate’ strategy, i.e. where strategy is formulated and then implemented, in this case by program management. The notable thing about this case is the clarity (i) of the project life cycle with its stage gate reviews, and (ii) how at each gate review project topics are systematically assessed. Of the 11 topics reviewed at each gate, one is project strategy. Project strategy is in fact managed, in considerable detail, by project teams throughout all the stages and all the associated phases of the project management process.
The financial services case
This is an example of what happens when project management is not effectively linked to enterprise strategy. In this company there was a clear process path for moving corporate strategy through business unit strategy and into program and project strategy. The front end of the project management process translated business strategy into program and/or project strategy and confirmed the alignment of the two. From that point, however, when the scope of the project was planned and defined, project strategy was no longer mentioned in the project management plan, even though the business case for the project — which contains the operational vision and strategy for the project — could be included in it. As a result when things begin to deviate from plan, linkages with changes in benefits realization were not managed effectively. Integrating project strategy management throughout the project management process, and not just at the front-end or in the business case, and making it a core project management practice, would have improved the performance of the project team and the outcome of the project.
The construction case
This company, a major transportation utility, had an extremely structured means of cascading strategy down from the centre to its business units – the OGSM method (Objectives, Goals, Strategies, Measures). Once flowed into the capital assets facilities and construction division, the strategy was then developed through a systematically controlled life cycle process. What is interesting about this case is that the term ‘project management’ is not used at all! Pre the capital approval gate the project was led by a Development Manager; post by a Project Leader. There are two things striking about this example. One is the resistance to the notion of project management as mechanistic and insufficiently about setting a vision and acting in a leadership role (Morris, 2004). The second is an undoubted consequence of that view (and is found in a number of large process engineering client organizations as well): the positioning of project management as execution only and not a discipline relevant to the front-end!
Summary and conclusions
We have come full circle. What you give out, you get back. If we position project management as an execution-only discipline, we will be seen as just that and cut-off from the really important parts of the project: those where value can most be created: the front-end.
The reality, as shown by the results of two separate surveys, is that the overwhelming majority of practitioners polled believe that project management does apply in the pre-execution stages.
The survey of seven organizations' life cycles show that these companies expect project management practices and principles to be applied in these pre-execution phases as well in the downstream execution ones.
But as the four case studies show, there is still confusion in practice, with some organizations seeing project management pre-eminently as a managerial, execution oriented activity. The PMBOK® Guide and OPM3™ fully support such an interpretation. Yet it is at odds with what the literature, and many companies' experience, shows to be the case: that managing projects effectively begins in the very earliest of phases (Milestone 0). If projects, and programs, are only done for a purpose, they should be dynamically connected to the enterprise strategy. For, as the case studies show, the evolution of projects generates new information which often needs to be fed in to the enterprise's ‘emergent’ strategy.
As a post script: there are some who will claim that project management is indeed about execution and it is really the responsibility of program management to be concerned with strategy and business benefit. In some cases, in some companies, it may work like this, but as a generic answer for the discipline as a whole this surely is inadequate. We need to be voicing a view of the discipline which provides a holistic approach to managing projects, and programs, from their earliest stages to their last in order to deliver business benefit. I call this ‘the management of projects’.
