Lip service is paid in many parts of general management writing to the importance of project management as a means of implementing corporate strategy. Yet, in reality, there is a dearth of empirically based evidence on how this is accomplished. This paper reviews evidence from four case studies, together with questionnaire data from PMI Europe members, which shows that the processes, practices, and people issues involved in moving from corporate strategy to programs and projects is, in fact, accomplished in a much more systematic way than is generally recognized. The findings point to areas that future revisions of A Guide for the Project Management Body of Knowledge (PMBOK® Guide) should probably be looking at, not least project strategy itself, value management, and project leadership. In particular, it is shown that the role needed to develop and deliver projects requires a mixture of leadership and management, and that this surely is the role that the discipline ought to be filling.
Corporate strategy is a means of thinking through and articulating how an organization's goals and objectives will be achieved. This strategy is then typically operationalized at a “strategic” business unit [SBU] level.
Much of traditional management writing tends to cover only those elements concerned with the formulation of strategy at the corporate level; there is a dearth of writing about how corporate strategy gets translated into implementation, particularly through those key mechanisms – programs and projects. Yet, in practice, the two sets of activities are interconnected; projects and programs are, as we shall see, important ways for strategy to be implemented in the enterprise. We ought to better understand how this occurs.
Strategy management is a dynamic process. We can distinguish both deliberate and emergent strategy development: deliberate in the sense that strategy is planned and its formulation, review, approval and implementation follows well defined processes and schedules; emergent in that it, and events, emerge with time (Mintzberg and Quinn, 1996; Mintzberg and Waters, 1985). Project managers tend to be more comfortable in process-driven “control” environments, typical of “deliberate” implementation. Emergent strategy suggests a more incremental learning approach to implementation, where results are regularly appraised against benefits and changes are managed against the evolving picture of requirements. In such circumstances, implementation projects and programs often have an ambiguous relationship to the environment in which they evolve because they often stretch and change the context which the strategy is addressing (Lampel and Jha, 2004; Garbher, 2002). The very act of implementation may change operational reality, and ultimately even modify strategic intent. Hence, although there may be formal strategy planning processes and practices, strategy is rarely realized in as rigid and “deliberate” a manner as many planners assume.
Thiry (2004) has argued that emergence is more typical of program management, which this research suggests is indeed the case. But as the research will show, it is not restricted to programs: it often applies to project management too – certainly in the project definition stage, but even in some cases in execution (for example, as we shall see, in drug development). Leadership is important in all these cases.
Not all strategy implementation is one-way; that is, downward from the corporate level through portfolios to programs and projects. Just as in strategic planning, there is upward flow from SBUs, so in implementation there is management information and action bearing up from programs and projects onto portfolio, business unit, and corporate strategy. For example, a fundamental responsibility of project/ program management is to manage the resources needed to define and deliver its programs and projects effectively. We shall see (in the pharma case, for example) that resource management becomes a critical factor in moving from corporate strategy into project implementation.
It is important that organizations fully understand their business management context and, by corollary, the position of project, or program, management within it; hence, for project management to see how they sit alongside – and are perceived by – the business management functions. Research shows, for example, that one of the reasons that new product innovation projects often fail is because they lack wider organizational support (Wheelwright and Clark, 1992). We see a worrisome corollary in many organizations today: project management is seen by many companies as merely an execution activity of no central criticality to the business. As a result, the discipline is spread out over a variety of functions or lines, and best practice is allowed to dissipate and fragment (and with it, business performance). Unless project and program management can argue why it is important to business success it will be a tier-two or -three function. While project management practitioners may think that their function is central to the success of a company, it may have little meaning within the enterprise unless it is clearly established and embedded within the enterprise's structure and business management models and processes.
It is also important to recognize that different types of programs and projects may require different business management approaches. Artto and Dietrich (2004), for example, outline a number of different managerial practices for the strategic business management in multiple project environments. Crawford, Hobbs, and Turner (2002); Shenhar, Dvir, Lechler, and Poli (2002); and Youker (1999) also investigate project classification and different management approaches to different projects.
Hierarchy is usually important in any discussion of implementing strategy. A hierarchy of objectives and strategies can generally be formed as a result of using a strategy planning process; this can be a very effective means of structuring and managing strategy, and communicating it to the organization. One such model is Archibald's hierarchy of objectives, strategies, and projects, in which objectives and strategies are developed at the policy, strategic, operational, and project levels, and cascaded down, thereby ensuring alignment and continuity of strategy (Cleland, 1990; Archibald, 2003). Similarly, Kerzner (2000) shows a hierarchy where strategic plans are cascaded from corporate strategy to SBUs, and from SBUs to supporting plans.
Portfolio Management
A portfolio is a set of projects managed in a coordinated way to deliver benefits which would not be possible if the projects were managed independently (Artto, Martinsuo, and Aalto, 2001; Platje, Seidel, and Wadman,1994). A slightly different but widely accepted view is that a project portfolio is a collection of projects to be managed concurrently under a single management umbrella, in which each project may be related or independent of the others (Thiry, 2004; Martinsuo and Dietrich, 2002). Archer and Ghasemzadeh (2004) stress that portfolio management is preeminently about selecting – or prioritizing – the best projects or programs to proceed with. Project portfolio management, then, is predominantly about “choosing the right project,” whereas project management is about “doing the project right” (Cooke-Davies, 2002, 2004).
Archer and Ghasemzadeh (1999) have provided a general framework for project portfolio selection that demonstrates the need for strategy to be set at the corporate level and then to be filtered down to the project level. Subsequently, they emphasized the importance of aligning resource demand with resource availability to achieve a set of strategic goals (Archer and Ghasemzadeh, 2004). Knutson (2001) points out that the project portfolio management process provides a means of consistently and objectively evaluating each proposed project that is vying for a limited pool of resources, thereby aiding the process of making the most effective strategic use of resources.
Linking company strategy to portfolio development is critical, particularly when company strategy involves both a high degree of innovation and a high rate of growth. In fact, advances in portfolio selection and management practice have been notably strong in new product development (Archer and Ghasemzadeh, 2004; Cooper, Edgett, and Kleinschmidt, 2001). The top performing benchmark businesses display strong management support for portfolio selection and management, using formal portfolio management methods to manage their portfolio strategy within the context of the enterprise business strategy (Cooper, Edgett, and Kleinschmidt, 1999).
Portfolio selection is usually a committee process; while there are many possible methodologies that can be used in selecting a portfolio, there is little consensus on which are the most effective (Archer and Ghasemzadeh, 2004). Archer and Ghasemzadeh (1999) suggest a project portfolio selection framework that includes the development of strategy for the portfolio. Shenhar and Dvir (2004) propose a strategic portfolio classification framework based on the need to select projects based on their strategic impact and to form a policy for project selection. Archer and Ghasemzadeh (2004) identify risk and outsourcing as having a particularly strong impact on portfolio selection and management. They point out that a key criterion for successfully applying risk evaluation in portfolio selection is that risk assessment and quantification be uniformly applied across all projects and teams.
Program Management
Both portfolio management and program management focus on prioritizing resources and optimizing the business benefit. Program management is more involved in day-to-day management – unlike portfolio management, which is more periodic and strongly analytical. Program management is a powerful way of coordinating projects that have a shared business aim, and is an important method of ensuring that the organization gains the maximum benefit from integrating its project management activities. There is, however, quite a degree of confusion in the literature – and in practice – over just what is involved in program management. (The Organizational Project Management Maturity Model (OPM3) does a good job of clarifying the situation – PMI, 2004.)
Thiry (2004) defines programs as a collection of change actions (projects and operational activities) purposefully grouped together to realize strategic and/or tactical benefits (Murray-Webster and Thiry, 2000). Others define program management primarily as a collection of interrelated projects. Several perspectives exist on the optimal ways to configure programs to achieve strategic objectives and deal with change (Murray-Webster and Thiry, 2000). Some emphasize the technology base, as in platform projects (Wheelwright and Clark, 1992). Others, particularly those coming from Information Technology, emphasize in addition the importance of business benefit (OGC, 1999). Pellegrinelli (1997) has proposed the generic portfolio and program typologies of Goal-oriented, Portfolio, and Heartbeat. Murray-Webster and Thiry (2000) have proposed Strategic, Multi-Project, and Incremental.
Programs are often ongoing or long-term and are subjected to both uncertainty and ambiguity (Thiry, 2004). Programs and program management are frequently used in large organizations to implement strategic initiatives. The United Kingdom (UK) Office of Government Commerce [OGC], for example, considers the alignment of strategy and projects to be one of the main benefits of program management (OGC, 1999). They require a decision management paradigm that takes into account the appropriate strategic perspective. Whereas projects essentially involve “deliberate” (planned) strategies, programs combine both deliberate strategies and “emergent” (unplanned) strategies. “Benefits management” is increasingly recognized as a key formal activity within program management (Thiry, 2004; Ward and Peppard, 1997; OGC, 1999), and is clearly linked to value management: both must be linked to strategy and programs to be most effective according (Thiry, 2004a).
A program often has to strive for the achievement of a number of sometimes conflicting aims and has a broader corporate goal than projects, which aim to achieve single predetermined results (Wijnen and Kor, 2000). Implementing strategy through program management involves continuous re-formulation and adjustment. Projects, on the other, hand concentrate on achieving one particular result within set time and cost constraints (Görög and Smith, 1999).
Pellegrinelli, Partington, and Young (2003) see programs emanating from business strategies and initiatives with an iterative hierarchy of programs, projects, and business operations cascading from them. Youker (1993) illustrates a cascade to show how organizations position programs and projects to achieve their development objectives. As a result of the research reported here (Morris and Jamieson, 2004), the model has been modified to include business strategy and portfolios, as shown in Exhibit 1.
Source: The Handbook of Project-Based Management, 2nd ed.
J.R.Turner © 1999 Reproduced by kind permission of the
Open University Press / McGraw-Hill Publishing Company.
Adapted by Morris and Jamieson (2004).
Exhibit 1: Linking corporate and project strategy
Project Management
Projects, in distinction to programs, have a “unique” objective and follow a single development “life cycle.” There is a widespread view, unfortunately not tempered by A Guide to the Project Management Body of Knowledge (PMBOK Guide--Program Management Institute, 2000), that project management is largely about execution.
As a result, the vitally important period of front-end definition, and the role of management in this, is too often overlooked. If project management does not cover this portion of the project, why not? Is it not to be the discipline of managing projects?
Developing effective strategy for program or project implementation bears directly on the important front-end definition phases of project definition and assessment. It is often a complex activity, drawing on strategic elements from a wide range of project management practices, such as risk management, value management, and supply chain management. In addition, it incorporates some form of interaction with a whole range of other factors shaping the nature of the project: stakeholder requirements and technical definition, marketing, finance, and so on.
Achieving alignment of the project and the company's strategy may prove difficult because, as we have seen, strategy itself is frequently an umbrella that permits a range of options rather than a clearly and tightly defined set of goals (Mintzberg and Waters, 1985); and the very act of developing project proposals interacts with, and shapes, the organization's strategic options, as has been highlighted in numerous industry-specific case studies (Morris and Pinto, 2004; Morris & Hough, 1987; Morris, 1994). Artto and Dietrich (2004) address the way that multiple projects can be collectively aligned with business strategy in a manner that generates enhanced benefits for the whole business, and the role of specific projects in implementing, creating, and renewing business strategies.
PMI’s PMBOK Guide (2000) links the strategic plan of the organization, containing the strategic goals, to the project scope management processes (para 5.1.1.) (The early drafts of the revised PMBOK Guide [2004] would seem to show no modification in this.) However, while PMBOK Guide signposts the process connections between strategy and scope, it is short on detailing the substance. Turner (1999) is better, advocating the development of a comprehensive definition of a project at its start, with business plans aligned with project plans containing key elements of project strategy. Simister (2000) shows the development of business cases and strategic briefs as part of the project definition process. Morris (1994) summarizes the elements of project strategy.
The UK‘s Association for Project Management BOK (Dixon, 2000) gives fuller recognition to the business context within which the project resides, as well as recognizing portfolio and program management and requirements management. (The business and operating requirements of a project frequently affect project strategy significantly and for this reason the APM BOK identifies requirements as a key project management process (Davis, Hickey, and Zweig, 2004; Stevens, Brook, Jackson, and Arnold, 1997; Young, 2001).)
Work by Morris and Jamieson in integrating what the PMBOK Guide and the APM BOK have to say about the way strategy shapes project definition shows the large number of factors involved in creating project strategy at the front end of a project (Morris and Jamieson, 2004). This highlights the need for an effective way to manage project strategy creation, covering not only the front end of a project but the entire project life cycle. Though developing strategy obviously occurs at the front end of a project, it often encompasses the entire project life cycle: Integrated Logistics Support, Operations and Maintenance, and Whole-Life Costs, for example, may well figure prominently in the strategy (Kirkpatrick, McInally and Pridie-Sale, 2004). In fact, as the case studies reported below show, many companies have developed structured approaches for creating and managing project strategy that cover the entire project life cycle and are integrated with the business strategy development processes.
The research study
The literature on how corporate strategy gets implemented via portfolios, programs, and projects is thus diverse, patchy, and incomplete. While that on portfolio management is quite thorough, the treatment is primarily from an analytic viewpoint. There is little on implementation. The literature on program management is often quite confused (and confusing). There is a lack of detail in the APM BOK on how corporate strategy influences project strategy while the subject is hardly dealt with in PMBOK Guide. A research project was therefore initiated by the Center for Research in the Management of Projects – funded primarily by PMI but with additional support from UCL, UMIST, and the pharmaceutical company – to explore and illustrate in more rigorous detail how corporate strategy is implemented via project, program, and portfolio management.
Given the availability of funding and time, the research was designed to be exploratory. That is, it was recognized that only a limited number of case studies and survey data could be undertaken, and that the findings therefore could not, and should not, be taken as either exhaustive or conclusive. (There is much room for additional research in this area.)
Case studies were selected from four different areas: aerospace, financial, pharmaceutical and transportation/ construction (though, admittedly, all were from the sponsoring organization's perspective’ that is, from the perspective of the company making a capital investment).
Semi-structured interviews were conducted with senior managers using a questionnaire-based approach. The questionnaire covered topics discussed in the theoretical framework above, including:
- strategic management formulation and implementation processes;
- portfolio management processes;
- business enterprise models;
- business management processes;
- portfolio management processes;
- program and project management processes;
- program and project management practices; and
- program and project management people skills, knowledge, and behaviors.
The results and findings of each case study were validated by the appropriate company before a cross-analysis of all the results and findings was carried out.
The case-study data provided a rich, qualitative context in which to explore the way companies moved from corporate to program and project strategy. But the data sample was obviously small. To provide a bigger data sample, we carried out a survey of members in a number of PMI Chapters in European countries. A series of 32 multiple-choice questions were posed. Seventy-five responses (about 50% from the 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, information technology (IT), telecommunications, pharmaceuticals, retail, transportation, and publishing--as well as academia and consultancy. The response rate – about 2% – is too small for the results to be considered as statistically valid, but can be taken as indicative: the research is, as we have indicated, at best only “exploratory”
Survey findings
Boxes 1-5 summarize the analysis of the survey findings, and cover the following areas:
- Business management;
- Program management and portfolio management;
- Project management and project strategy;
- Value management; and
- Project management competencies
How business management models are used was the first area to be studied. 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).
Box 1: Survey findings - Business management
1. The extent to which a business model was used
| Model used | Generic | *Equivalent |
| Population % | 67 | 23 |
*Including project management processes
2. 80% of the organizations indicated that they were process-orientated organizations as follows:
| Level of process orientated | Extensively | Adequately | Inadequately |
| Population % | 40 | 40 | 17 |
3. Those extensively or adequately process-orientated indicated that they had processes for moving corporate goals and objectives to project strategy as follows:
| Level of processes | Extensive | Adequate |
| Population % | 50 | 33 |
4. The level of interconnection among the corporate, business, and project management processes for the organizations with extensive processes was as follows:
| Level of Interconnection | Extensive | Adequate | Inadequate |
| Population % | 40 | 50 | 10 |
5. Organizations having extensive processes/sub-processes for moving corporate goals and objectives to project strategy consider that continuity of strategy is achieved as follows:
| Level of continuity achieved | Fully | Well | Inadequate or poor |
| Population % | 20 | 55 | 25 |
6. Hierarchy of objectives and strategies developed and deployed for structuring strategy:
| Hierarchy span | Corporate through to project | SBU to project |
| Population % | 53 | 68 |
How organizations perceive and use program management and portfolio management and the extent to which they moved strategy through programs to projects was the second major area investigated. Essentially, 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).
Box 2: Survey findings – Program management and Portfolio management
| Population % | ||
| 1. | Program management was defined as the management of a portfolio of projects sharing a business objective of strategic importance, probably utilizing shared resources | 95 |
| 2. | Programs were considered to comprise: Groups of projects No. of separate projects Combination of both | 20 20 70 |
| 3. | Programs were used to implement change: | 85 |
| 4. | Some form of portfolio management was implemented: | 50 |
| 5. | Portfolio management was considered as: Selecting the right project quantitatively Maintaining a balanced portfolio Managing projects grouped around a common theme | 50 60 66 |
| 6. | Hierarchy of objectives and strategies were developed and deployed at program and project level; the levels deployed were as follows: Program Program and project Program, project and project team Program, project, project team, and individual | 75 90 60 45 28 |
| 7. | Program management was implemented, including the following: A. [i] Managing an integrated set of projects to achieve a common theme, aim, or common platform; [ii] Integrated project teams [iii] Managing resources in an integrated manner B. [i] and [ii] C. [i] and [iii] | 90 55 10 15 |
| 8. | Program management implied the management of business benefits of which: It was normal practice to formally identify a benefits process within the overall program management process. Those who do not incorporate a benefits process believed they should. Non-financial measures were used to track benefits in programs. | 75 70 60 70 |
| 9. | Program management implied the aggregation of risks of which: It is normal practice to formally identify risk aggregation as part of the overall risk management activity. Those who do not identify risk aggregation believed that it should be incorporated into program management. | 75 80 60 |
The third area investigated, project management, followed naturally from program management. The survey focused on identifying the key strategy inputs and some of the project management activities which were employed to create project strategy 85% used extensive or partial project management processes to manage project strategy; most (75%+) had specific strategy inputs into project management, while 65% did this in an “emergent” manner. 85% used a gate review process with clear sponsorship responsibilities. 65% upgraded strategy as the project progressed.
Box 3: Survey findings – Project management and project strategy
| Population % | ||
| 1. | Organizations had extensive or partially integrated project management processes to help manage project strategy, which contained: Project strategy management Requirements management, project strategy, project definition, and project scope management Requirements management, project definition, and project scope management. | Almost all 85 75 85 |
| 2. | Organizations had specific strategy inputs to integrated project management processes which included: Corporate strategy Corporate strategy and business strategies Corporate, business, and portfolio strategies Corporate, business, portfolio, and program strategies Portfolio and program strategies only Program strategy | Most 75 65 50 45 55 75 |
| 3. | The integrated project management processes delivered the following outputs: A project or program plan and strategy plan Other project management plans A project or program plan, strategy plan, and other plans | 50 75 45 |
| 4. | Organizations with integrated project management processes managed project strategy dynamically | 65 |
| 5. | The roles and responsibilities for developing, implementing, and updating project strategy were specified in: Project management procedures Project plans | 65 55 |
| 6. | Project plans were formally reviewed at project “gates” Those who did not and thought they should | 85 85 |
| 7. | Peer groups formally reviewed project plans Those who did not and thought it would be sensible to do | 75 65 |
| 8. | It was clear who approved and signed off project strategy | 75 |
| 9. | In broad terms, a project sponsor was the individual or group within the performing organization that provides the financial resources, in cash or in kind, for the project; and, as the owner of the business case, represents the funder's interests. The relationship between the project sponsor and the project management team was normally defined in project plans | 90 70 |
| 10. | Strategy was expected to be upgraded and reviewed: During the development of the project Systematically as projects develop from concept to execution And was systematically undertaken at project review gates | 65 55 85 |
The survey also explored two other areas
- Project value management and its link to project strategy. (55% had a process for optimizing the value of the project; 75% of this 55% combined this with risk management.)
- The extent companies define competencies to manage program and project strategy and incorporate them in competency frameworks and job descriptions. (80% had project management competencies defined of which 75% included those for managing the strategy development process.)
Box 4: Survey findings - Value management
| Population % | ||
| 1. | A process was used for optimizing the value of proposed project /program strategy of which: Value was expressed as benefit over resources used The process was formalized as value management Value management workshops were held at strategic stages in the life of the project. Those not using a process for optimizing the value of project/program strategy believed that they should. | 55 80 55 40 55 |
| 2. | Value engineering was practiced on programs and projects of which: Value engineering (optimizing the value of the technical configuration) was distinguished from value management. Those not practicing value engineering on programs and projects thought that they should. | 25 80 56 |
| 3. | The value optimization process was integrated with risk management Those who did not integrate risk and value thought that this should be done. | 75 40 |
Box 5: Survey findings – Project management competencies
| Population % | ||
| 1. | Project management skills and knowledge competencies required to manage programs or projects were formally defined and included: Those required to develop program and project strategy Linking the competencies to personal appraisal and development systems Linking personal objectives to project objectives | 80 75 80 65 |
| 2. | Those who did not formally define the project management skills and knowledge competencies incorporated the management of project strategy in job descriptions or job specifications. | 50 |
| 3. | Wide-wide behavioral competency frameworks were used Those who did not use them considered that they should. | 60 45 |
| 4. | Competency support programs for program and project managers were provided Which covered support for project strategy development. | 70 66 |
A full report on the research was published by PMI in the Spring of 2004 (Morris and Jamieson, 2004). This report also contains full details of the four case studies.
Case Studies
We shall briefly look at some of the key findings coming from the cases overall before dwelling on two of the studies for their implications on the role of leadership in project management.
Business Models
Two of the companies used business models that included strategy management, portfolio management, and program and project management processes.
The aerospace company had a very powerful business process model in which program management (and project strategy) played a prominent part. The international transportation company also had a strong business process model, although project management, as a formal discipline, had a less visible role. (It existed as an activity but was spread between “development management” and “project execution”) The pharmaceutical company had a process model that was dominated by the drug development process – this is not the same as a business model per se, but was clearly the major business process. Project and portfolio management (and, to a lesser extent, program management) are important aspects of this process. The financial services company had a high-level business process, but this was less visible than the business models in the other case studies.
Cascading Corporate Strategies into Projects and Strategy Plans
All the companies created corporate objectives, goals, and strategies using processes like the strategic management processes described by Mintzberg and others. As in Youker's model, these objectives, goals, and strategies were cascaded to the strategic business units [SBUs] or equivalent organizational entities, which in turn developed their own objectives, goals, and strategies, in some instances using additional processes which were fully integrated with the business strategy processes. The SBUs subsequently developed objectives, goals, and strategies with and for their respective program and project teams, again in some instances using fully interconnecting business and project management processes.
The importance of project portfolio management was recognized by all the companies. In all four cases, the program and/or project teams developed strategies that aligned with the SBU and corporate strategy containing the objectives, goals, and strategies. These included strategy plans, business plans, deployment plans, and project plans, the hierarchy of which, in most cases, was similar to Archibald's hierarchy of objectives, strategies, and projects.
Portfolio Management
The importance of project portfolio management was recognized by all the companies. Portfolio management was used primarily to select and prioritize, rather than manage, programs and projects. Corporate and business units assembled a strategic portfolio of programs and projects, or measured the strategic contribution of a program or project, using a number of strategic and project management processes, tools, and techniques. “Governance” adopted or rejected projects based on this information.
Program Management
Program management was practiced by all the companies, primarily in the sense of managing a group of high-value projects sharing a common aim and/or delivering regular benefits over a protracted period of time.
In the aerospace company program, management was positioned primarily as the manager of a number of interrelated projects. In the financial services company, there was much more emphasis in program management on managing multiple, interrelated projects for business benefit. In the pharmaceutical case, the emphasis was on “asset” management, in the sense that the program represented a basic chemical entity, a technology platform in Wheelwright and Clark's phrase (1992), which can be promoted as a brand. Program management in the transportation case was used to manage a large number of interrelated projects.
Program management and project management activities were carried out in all cases using the same set of common processes, variously called integrated program management, program management, or even project management. The development of program strategy and its alignment with corporate and business strategy was, as a consequence, achieved in a similar way to that for projects.
Project Strategy
The creation of business cases was a key element of the business and project management interface within all the companies. An outline project strategy was developed during this activity, and was aligned with corporate and business strategies. Subsequently, business strategy, in most of the companies, was translated into a comprehensive project strategy using project management processes. However, none of the companies documented project strategy in a single comprehensive document; rather, project strategy was covered by a diversity of management and project plans. Managers did not see the point – the benefit – of doing so and thus resisted another bureaucratic task.
Two of the companies used a very structured approach to create and manage project strategy. One had institutionalized a project strategy management practice that was equivalent to, for example, risk management or technical management. The other had identified specific project strategy-related issues for each phase and stage of the project management process and the project life cycle. Both companies assigned roles and responsibilities for managing the execution of these processes. The other companies used a less structured approach. Though they developed management plans for their projects, they tended not to summarize the plans or develop a single project strategy statement from them. Only one of the four companies used the term “project strategy” in their project management processes. Two of the four companies – the aerospace and pharmaceutical companies – managed project strategy for effectively the entire project life cycle and not just at the front end of a project.
The Transportation Company, the Pharmaceutical Company,
and the Issue of Project Leadership
The Transportation Company
The company's operations comprise a number of strategic business units at various sites in the UK, the USA, and elsewhere. An “Objectives, Goals, Strategy, and Measure (OGSM)” framework is used to cascade strategy down the organization and, through it, to set the strategic context for the whole company. Exhibit 2 shows how the framework cascades from the enterprise level to business units, and into projects.
Corporate, Business Unit, and Project Environments
Exhibit 2: Corporate, business unit, and project environments
A project board is responsible to project governance for the day-to-day running of the project, which it executes through a project leader and project team. The process for doing this is shown in Exhibit 3.
Exhibit 3: Project development process:
All the work justifying the business need for a project is undertaken during the “Define need” stage. The development manager develops a Statement of Need for the project, and the objectives for the project are set. The strategic and business risks are identified; these contextualize the strategy for the project. The development team determines the options to meet the stated need and the implications associated with the various options, and recommends a preferred solution based on the optimum business case developed during this process. Project Governance decides at the end of this stage whether the project can proceed to the “Define solution” stage.
The Project Board Chairman acts as primary sponsor and client for the project. He/she is responsible for ensuring the project meets the needs of the business and maximizes shareholder value, and that the strategic contribution, value-for-money [VFM] and uncertainty assessments are undertaken appropriately; and is accountable for ensuring the successful project delivery and the identification and reporting of risks and safety issues that may affect the project.
The project development team is the process owner for “Finding the Right Solution.” He/ she is responsible for reviewing the business need for the project with the business owner, and preparing: the Statement of Need for the project; a list of potential options the project can undertake to meet the business need; and a business case together with a financial analysis to support the solution to the business need. He/she also directs and implements the strategy approved by the project board, and documents the strategic contribution, VFM, and complexity/ uncertainty assessments.
The project execution team is the process owner for “Delivery of the best value solutions.” This team will work with the Development team in the “Finding the Right Solution” stages providing professional input on downstream execution issues and, when appropriate, directly managing activities on behalf of the development team.
Until recently, this team was headed up by a Project Manager. Recently, however, the title “Project Manager” has been dropped in favor of the term “Project Leader” in order to emphasize the importance of the project manager contributing to the overall asset development process by acting creatively and adding value. He/ she is accountable to the project board for the implementation of the project and meeting the approved project objectives and targets defined in the project execution plan, and is responsible for “red flagging” issues to the project board which could potentially affect project strategy and the delivery of the project.
Note, then, two key things from this case:
a) The importance of leadership at all stages of the project;
b) That the project execution function contributes, in a leadership capacity, in the front-end, development stages of the project.
The Pharmaceutical Case
Development of pharmaceuticals is a complex, lengthy, and very risky activity. It can take well over 10 years and cost over $800m to develop a product from the laboratory to delivering it in the market. Towards the latter stages of development, the organization of the development teams is especially large and complex, with people working in a virtual and matrix environment.
Perhaps uniquely in scientific and engineering-based projects, there is not really a product being designed in drug development (Foulkes and Morris, 2004). Rather, a chemical entity has been discovered and the project team is assessing its therapeutic efficacy and commercial attractiveness by performing tests (in the lab, on animals, in human beings). Generally, things don't work out quite as expected – particularly in the early stages of development – hence, there is a very high rate of attrition. Since there are usually more candidates available than resources to develop them, as this attrition occurs there is consequently a high degree of interaction between governance at the portfolio level and project management at the execution level, not least over the selection of which candidates to work on, the risks and opportunities these offer, and the availability of resources. Strategy is truly emergent, and interacts constantly with project management.
Most pharmaceutical project management organizations distinguish between a Project Leader (or Director) role and the Project Manager. (The differences are similar to those between The Director and The Producer in movies – as discussed in Foulkes and Morris (2004).) Typically, the former has a strong feeling for the science of the development; the latter with the operational management of the project. The Leader is primarily concerned with shaping the development strategy and, in this particular case, did not really see him- or herself as part of the project management community. The Project Manager, on the other hand, saw him- or herself as very much concerned with scheduling, resourcing, chasing, etc. The former was more concerned with effectiveness, the latter with efficiency. (This said, there were exceptions beginning to emerge on both sides.)
In practice, the precise sharing of responsibilities would seem to follow the characteristics, and wishes, of the two individuals filling these roles on any one project. The tragedy would surely be, however, if the project management professional were to persist in seeing his or her role as being excluded from strategic, value shaping activities, and the Leader/ Director were to persist in seeing his or her role as being excluded from scope, schedule, cost, resource, risk, people, and other project management-oriented issues. Ultimately, the really important thing is that the overall “management of the project” space gets properly filled on the project.
The split is reminiscent of Kotter's distinction between leadership and management (Kotter, 2000), and Kotter's work seems to be directly relevant to the way we do, and do not, perceive the role of project management today.
Kotter on Management and Leadership
Kotter differentiates leadership from management in four ways (Exhibit 4). The “management” dimension is exactly the “efficiency” model that underlies PMBOK Guide: planning, organizing, and controlling – consistency. Yet managing projects requires that directions should be established, value optimized, and upside opportunities created (“creating an agenda”); alignment is at the heart of managing today's construction, auto, and aerospace projects (“developing a network…”). Few projects are successful without motivation (“execution”) and, as we have seen, projects need to produce business change, as well as deliver predictable outcomes, in an orderly manner.
(Kotter's efficiency/ effectiveness characterization has more recently been taken up by Miller and Lessard and others working on the IMEC research into Large Engineering Projects (Miller and Lessard, 2000): “Efficiency, an internally oriented method of evaluation, focuses on costs, schedules, and technical performance; the project management measures of success…Effectiveness is overall utility…effective projects create their own value…and can generally survive their own inefficiencies” (pp 114-15).
The key point is that, while leadership is likely to be more to the fore in the front end of projects and in program management, both are needed, even in execution. Effectiveness and efficiency are important and are both required in the successful management of projects.
Exhibit 4: Kotter's distinctions between management and leadership
Conclusions
Clearly, project and program management is widely used as a means of implementing corporate and business strategy, and is a key business process. We can expect strategies to be aligned and moved from the corporate level through programs and projects in a systematic and hierarchical manner. There is a cascade of moving from corporate planning at the enterprise level through portfolio management into programs and projects, although there is flow up from projects to corporate strategy too (e.g., over resources, and as implementation alters the strategic landscape). Within this framework, project strategy is managed dynamically.
Project and program strategy is developed and maintained by project/program leadership teams and governance through project management processes, managed within the context of business strategy. Value management is widely used in optimizing the strategy, often in combination with risk management.
Project management is not divorced from enterprise-level management. Nor is it just an execution activity with no role in the front-end stages of project definition. Furthermore, it is not only a '"‘planning, organizing, controlling" activity; it also embraces leadership: setting an agenda, encouraging alignment, motivating, and inspiring – creating change – predictably.
Acknowledgement
I would like to acknowledge the enormous contribution of Ashley Jamieson, Research Fellow at the UCL Center for Research in the Management of Projects, to the work reported here and in the preparation of the text.
