CHAPTER 1

Moving Strategy From Corporate to Projects—What the Literature Has to Say

As strategy flows through an organization, it crosses a number of functional boundaries (disciplines), such as business management, strategy management, and project management.

The focus of our research is on the processes, practices, and people factors involved in moving from corporate strategy to project strategy. The literature rarely does this in separate steps, but considers them collectively within the context of the movement of strategy at corporate, business, portfolio, program, and project levels.

Developing Corporate Strategy

Corporate strategy is created as a means of considering and articulating how an organization's corporate goals and objectives will be pursued and achieved. This strategy typically cascades through strategic business units (SBUs), then ends up being represented as collections—or portfolios—of programs or projects. These become the vehicles for implementing the approved strategic initiatives. (This will become more evident in the case studies; more precise definitions of portfolio and program will also be given.)

Various processes are employed for effecting this translation. Highly structured business management models are used by some organizations; these models identify the major value delivery processes and/or key business processes that enable the organization to operate effectively.

Much of traditional management writing tends only to cover the strategic management processes that formulate and implement strategy at the corporate level; there is a real dearth of writing about how corporate strategy gets translated into comprehensive program or project management strategies. Yet, in practice, the two sets of activities are well—interconnected, and the associated processes are the main means by which strategy is moved and aligned through the corporate, business unit, and project/program levels. The processes often work less well, however, in terms of feedback and adjustment as events unfold and as the program or project definition must be realigned (or vice versa, as the project or program definition creates new situations that, in turn, impact on the enterprise's strategic intent, thereby requiring the process to iterate!).

Positioning Project Management Within a Business Management Context

To understand the way corporate strategy is translated into project strategy, it is important to consider the business management context and the position of project management within it, as well as how the business management functions perceive project management. While project management practitioners may think 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 processes. An indication of the position, and the relative prominence given to project management, can be gauged from the business management models used by organizations.

Watson (1994) gives McKinsey credit for developing the generic business enterprise model shown in Figure 1.1. This model shows the structure of an organization in terms of processes—rather than in the traditional structural form, such as a functional, project, or matrix structure—and serves as a process framework for an organization.

This model also identifies what are considered to be the major processes of the value delivery system of a company and the key business processes that enable them; this model also implies a high level of connectivity between the two. As a result of the findings of this research project, we believe that the management of projects is a key business process, and have modified Figure 1.1 accordingly.

Creating Corporate and Business Strategies

The strategy management process has been extensively dealt with by numerous authors. Most include the concepts and processes associated with strategy analysis, strategy creation (formulation), strategy evaluation, and strategy implementation. Few, however, explicitly connect corporate and business unit strategy with project strategy. Few suggest that it should be taken into account during the internal and external analysis processes at the strategy formation stage, or when determining the capability of the organization at the strategy implementation stage. (Why this should be so is an interesting question. Although we don't have firm research data to explain it, we suspect it is largely because of the operations management profile that project management has in most business schools and the consequent failure to perceive the strategic dimension of project formulation—the misperception, in other words, that project management is merely a form of operational execution.)

Strategy management is a dynamic process: Mintzberg and Quinn (1996) show that emergent strategy is a key factor—namely, strategy that becomes evident as it, and events, emerge with time—in influencing the way strategy is realized in practice. Strategy is rarely realized in as rigid and deliberate a manner as many planners have assumed.

Hill and Jones (2001) demonstrate how emergent strategy can influence intended strategy through components of the strategic management process, as, for example, those shown in Figure 1.2. This figure indicates that strategy formulation flows from an organization's mission and goals through its functional, business, and corporate levels. But as described in much of the strategic management literature (e.g., Mintzberg, Ahlstrand, and Lampel's 1998 publication, which notes that there are hundreds of different strategic planning models), Hill and Jones (2001) do not explicitly take account of the influence or impact of projects or project management activities on the creation and implementation of strategy, although this is clearly implied.

The findings presented in this research, however, show that most of the components of the strategic planning process—such as internal analysis, strategic choice, organizational structures, and control systems—have strong links to project management processes and activities; these factors, therefore, strongly influence intended corporate and business strategies.

Partington (2000)—in distinguishing the three levels of strategy as corporate, business, and operational—suggests that operational-level strategies tend to focus on programs and projects. We are suggesting that the linkage starts, or can start, even higher.

The availability of resources is a major factor in deciding the strategy of an organization. Figure 1.3 shows a schematic used by Andrews (1999) to analyze strategy as a complex pattern of interrelated decisions and serves to indicate some of the key activities involved in the formulation and implementation of strategy. One of the key activities undertaken during the strategy formulation stage is determining the material, technical, financial, and managerial resources of the organization. For organizations involved in managing significant projects, project management resources are an integral element of managerial resources; these can and do strongly influence corporate and business strategies. The main activities that determine the implementation of strategy, identified in Figure 1.3, are organizational structure and relationships, organizational processes and behavior, and leadership, all of which contain major elements of the project management function and similarly influence strategy.

Corporate resources are made up of distinctive competencies, which form the enterprise's unique strength (Hamel and Prahalad 1994). These, together with the enterprise's financial, managerial, functional, and organizational capabilities, allow it to achieve superior efficiency, quality, innovation, or customer responsiveness, thereby creating superior value. Capabilities refer to a company's skills at coordinating its resources and putting them to productive use. (We shall distinguish between competencies and capabilities later.) These skills reside, among other things, in the enterprise's internal processes, but are more generally a product of its organizational structure and control systems (see Figure 1.2).

A fundamental responsibility of project management is to manage the resources needed to define and deliver projects effectively. A company's skill at managing projects, and therefore its project management capability, is an essential managerial resource that can and does strongly influence corporate and business strategies. This is especially the case in companies that see themselves in dynamic change situations where agility is important or that are driven by major projects (as in aerospace, construction, new product development, etc.).

Hierarchy of Objectives and Strategies

A hierarchy of objectives and strategies can 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, used by Cleland (1990), is Archibald's hierarchy of objectives, strategies, and projects, shown in Figure 1.4 (Archibald 2003). This model maps out in detail the structure and relationship of objectives and strategies at the policy, strategic, operational, and project levels. Specific objectives and strategies are developed at each level from higher level ones and cascaded down, thereby ensuring alignment and continuity of strategy. Projects and their objectives, strategies, and project plans are shown at the operational level.

Hierarchy of Strategy Plans

The corporate and business strategies created by organizations using a strategic planning process are incorporated into a hierarchy of strategy plans. Kerzner (2000) provides an example of a typical hierarchy as shown in Figure 1.5.

This model shows typical strategic plans cascading corporate strategy to SBU level from a single corporate strategic plan, and it shows supporting plans cascading business strategy from each SBU. Another example of a hierarchy of strategic plans is the Stanford Research Institute's (SRI's) system of plans shown in Mintzberg, Ahlstrand, and Lampel (1998).

If this roughly is how corporate strategy is created from an organization's mission, goals, and objectives—and how this strategy is used to create business unit objectives and strategies—the next stage is to consider how business unit strategy is moved through portfolios and programs into projects.

Moving Business Strategy Through Portfolios, Programs, and Projects

Turner and Simister (2000) points out that the majority of projects take place as part of a portfolio of several projects. Program management is the way of coordinating projects that have a shared business aim (Thiry 2004). Both portfolio management and program management focus on prioritizing resources and optimizing the business benefit (Kerzner 2000). Portfolio management tends to be about the selection and prioritization of projects or programs (Archer and Ghasemzadeh 1999). Program management is about the day-to-day management of programs (variously defined for example as products, platforms, brands, or multiple projects) to deliver business value (Office of Government Commerce 1999; Wheelwright and Clark 1992).

Turner (1999) illustrates how organizations undertake programs and projects to achieve their development objectives. As a result of this research, we have adapted this model to include business strategy and portfolios, as shown in Figure 1.6, and to indicate that a portfolio may comprise groups of programs and/or groups of projects.

Developing effective strategy for programs or projects from corporate and business strategies can be a complex activity. Artto and Dietrich (2004) discuss it extensively in their book The Wiley Guide to Managing Project. It involves key project management activities such as project definition and includes strategic elements from a wide range of project management practices, such as risk management, value management, and supply chain management. And although it obviously occurs at the front end of a project, it often encompasses the entire project lifecycle. Integrated Logistics Support, Operations, and Maintenance, and Whole-Life Costs, for example, may well figure importantly in the strategy. Grundy (1998) has proposed a number of techniques that enterprises can use to move corporate strategy into portfolios, programs, and projects, such as scenario planning, force-field analysis, stakeholder analysis, and attractiveness/implementation difficulty analysis.

Portfolios

Project portfolio management is not to be confused with more general portfolio management (which is primarily concerned with managing diversification and acquisitions) or product portfolio management. Jobber (2001) refers to portfolio planning as the process of managing groups of brands or products; however, in our experience, this is often subsumed within the more general subject of portfolio management. Project portfolio management has been described as the activity of aligning resource demand with resource availability to achieve a set of strategic goals (Archer and Ghasemzadeh 2004).

Project portfolio management is predominantly about choosing the right project, whereas project management is about doing the project right. Crawford (2001) believes that making the conceptual leap from the tools-and-techniques-focused variety of project management to portfolio management (and, indeed, program management), with its broader focus on business strategy and enterprise-wide integration, is a special challenge and one that many now face with little in the way of standards, best practices, or other generally accepted knowledge to guide them.

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 use of the resources. She presents a generic portfolio management process model, as schematized by us in Figure 1.7. This model is suitable for small and large organizations dealing with internal and/or external project clients and as an implementation plan for establishing a portfolio management system within an organization.

• The solicitation stage of the process ensures that the potential program or project being evaluated has a credible strategy that it is aligned with the organization's objectives and strategy. A business case for the project, containing these details, is produced as an output of the solicitation phase. The relative value of the project and its overall synergy with the organization's strategy is evaluated during the selection process. If a project is selected, the next step is its prioritization.
• During the prioritization stage, a scoring system is used to determine the priority of the project with respect to other projects (see also Archer and Ghasemzadeh 2004).
• Subsequently, depending upon availability, resources are allocated to the project to allow it to proceed.

Archer and Ghasemzadeh (1999) also provide a general framework for project portfolio selection that demonstrates the need for strategy to be set at a corporate level and then filtered down to a project level. Archer and Ghasemzadeh (2004) focus, in addition, on the special problems at the portfolio level of risk management and resourcing, including outsourcing. Other examples of portfolio management practice employed by a diversity of major companies are given in Cooper, Edgett, and Klienschmidt (1998).

Programs

Murray-Webster and Thiry (2000) suggest that the discipline of program management is emerging as a fundamental method of ensuring that an organization gains the maximum benefit from the integration of project management activities. They suggest that program management can be characterized as more iterative than single shot project management and that it involves more strategic reflection. Thiry (2004) emphasizes the importance of learning, namely that program strategy is shaped as the organization learns from the projects it delivers.

There is quite a degree of confusion in the literature—and in practice—over just what is involved in program management. Some define it primarily as a collection of interrelated projects and 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, also emphasize the importance of business benefit. Pellegrinelli (1997) has proposed the generic portfolio and program typologies of Strategic and Incremental. Pellegrinelli, Partington, and Young (2003) emphasize that programs and program management are frequently used in large organizations to implement strategic initiatives. In such cases, program management transcends the management of related projects and involves managing the ambiguities of strategies.

The United Kingdom (UK) Office of Government Commerce (1999) considers the alignment between strategy and projects to be one of the main benefits of program management. The program management process they propose comprises the following stages:

• Identifying, defining, and establishing a program;
• Managing the portfolio;
• Delivering benefits;
• Closing the program¹

OGC perceives the environment of program management to be that shown in Figure 1.8, which indicates programs emanating from business strategies and initiatives, with an iterative hierarchy of programs, projects, and business operations cascading from them.

The objectives and strategies for the programs are created and aligned with the objectives and strategies of the enterprise, and the objectives and strategies for individual projects are created and aligned with their respective programs. We will next consider how project strategy is created within projects.

Projects

To translate business strategy into project strategy most effectively, whether a project interfaces directly with business units or indirectly through portfolios and programs, there needs to be a coherent set of processes that integrate the two areas.

We examined what was proposed by the project management bodies of knowledge to see what was said about how this should be done. The result is the schematic shown in Figure 1.9, which draws on sections of PMI's PMBOK® Guide (2000) and the APM BOK (2000). Figure 1.9 is, frankly, very project-centric (i.e., it focuses on the inputs to the project and what has to happen in the project management process). There is little of the iteration that we have seen in program and portfolio management, little of the balance between emergent corporate strategy and resultant project activities. Although it may not be perfect, and it utilizes a degree of simplification, the model shown in Figure 1.9 is useful in showing the state of play, as readily available to the profession.

The model consists of two stages, with a number of key project management activities or processes within each stage.

1. Translating business strategy stage:
   • Strategic framework;
   • Requirements management;
   • Project scope management;
   • Project definition.
2. Creating project strategy stage:
   • Project management planning and integration processes;
   • Project plans development process;
   • Generic project management knowledge and competencies;
   • Elements of project strategy.

We will now look at each of these two stages in turn.

Translating Business Strategy in Projects

Strategic framework

What sort of topics will the project strategy cover? It includes project control elements such as work, scope management, and resource management, but more importantly, it includes elements from all the project management control, technical, commercial, organizational, and people topics, some of which are shown in the “Creating project strategy” box in Figure 1.9. Thus, most of the activities of a project will be reflected in the project strategy.

Requirements management

Requirements management covers the process of defining the user/customer business and technical requirements in a solution-free way. The requirements should be specified in a manner allowing the solutions that are subsequently proposed to be traced back to the requirements in a structured manner and to be tested against the requirements. The technical requirements of a project frequently affect project strategy significantly, and for this reason it is identified as a key project management process (Davis, Hickey, and Zweig 2004; Stevens, Brook, Jackson, and Arnold 1997; Young 2001). Briefing—the term used more in construction—would be covered by this section too.

Project scope management

PMI's PMBOK® Guide (2000) recognizes the strong links between project scope management processes and corporate and business strategies. In its initiation process, the project is linked to the ongoing work in the performing organization with authorization following demand/business need. The inputs to the initiation process include the strategic plan of the performing organization, which is also used in project selection decisions and is seen as providing the link through which the project strategy is aligned to the organization's strategy. The output of the initiation process reflects the organization's strategy and is fed as an input to the second process of project scope management: scope planning.

The output of scope planning is the project scope statement. This contains the project justification, product, deliverables, and objectives. All of these are seen as key elements of project strategy and are inputs to the scope definition process. Thus, the scope of the project is driven by the key elements of project strategy that are directly linked to business strategy.

Project definition

The project definition process is an essential part of developing project strategy from corporate and business strategies. Turner (1999) builds on a model for the strategic management of projects developed by Morris and Hough (1987). This model indicates that projects are subjected to seven forces as follows:

• Definition
• Attitudes
• People
• Organization
• Systems
• Sponsorship
• Context.

The two forces that most relate to project strategy are identified as attitudes and definition.

Turner (1999) advocates developing a comprehensive definition of a project at the start of the project. This is achieved by:

• Setting the project objectives;
• Defining the scope through a strategic or milestone plan;
• Setting the functional strategies for assessing technical risk;
• Carefully managing the design process;
• Managing resources and the context.

Through the project definition process:

• The vision of the project is created;
• The purpose of the project is defined;
• Project plans are aligned with the business plans;
• The basis of cooperation for the project is agreed-upon²

Simister (2000) provides a flowchart for the early definition of a project, which concentrates on the proposal, initiation, and feasibility stages of a project. This shows the development of business cases, strategic briefs, and feasibility reports as part of the project definition process and demonstrates how complex and expensive the process of producing a comprehensive project definition can be.

Creating Project Strategy in Projects

Figure 1.9 shows project requirements, scope, and definition inputting to the PMBOK® Guide's (Project Management Institute 2000) “Project management planning and integration processes” box in the “Creating project strategy” stage. Outputs from this box are supplemented by the strategic framework processes and the more detailed and specific “Elements of project strategy” boxes to develop the project plan. Doing this is likely to enhance the quality of the inputs to the processes from which project strategy is created and ultimately, the quality of the project strategy.

The project plan development process also takes the outputs from the planning processes from other project management knowledge areas not shown in Figure 1.9 (such as resource plans, risk plans, and procurement plans, to name a few) and subsidiary plans (such as scope management and schedule management plans), and incorporates them in a consistent, coherent project plan document or set of documents. A summary of the contents of these key documents and management plans is incorporated into the project plan. (Such is the best practice we are hypothesizing and which we will test in the case studies and survey questionnaires that we will report on later.)

A Structured Approach to Creating and Moving Strategy Within Projects

Figure 1.9 shows the large number of factors involved in creating project strategy at the front end of a project. This highlights the need for organizations to have an effective way to manage the whole process of project strategy creation, covering not only the front end of a project but also the entire project lifecycle. Our research will show that companies have indeed developed structured approaches for creating and managing project strategy which do cover the entire project lifecycle and which are integrated with business strategy development processes. Figure 1.10 is an example of an actual structured approach of a major manufacturing company. It comprises:

• A business process model;
• The managing major projects process;
• The project management process.

The project management process in this company comprises five stages covering the entire project lifecycle. The key tasks undertaken during each of the process phases are stipulated in the supporting documentation and reflect many of the front-end elements shown in Figure 1.9. Defining project strategy is one of the key tasks undertaken in all of the phases and is done in accordance with a list of topics by those working on the project. This approach enables the evolving project strategy to be managed throughout the lifecycle of the project—by all those involved—in a manner that is rigorous, comprehensive, dynamic, and highly visible.

Competencies, Roles, Responsibilities, and Accountabilities for Moving Strategy

Moving strategy by means of rigorous, sophisticated processes, such as those shown in Figure 1.10, requires an extensive range of competencies, a highly skilled staff, and a clear definition of their roles, responsibilities, and accountabilities. Following Boyatzis (1982), several definitions of competency (and capability) have been offered. For us, competency is role-specific and covers the knowledge, skills, and behaviors needed to perform the role.

Armstrong (1999) points out that competency frameworks define the competency requirements that cover all the key jobs in the organization or all the jobs in a job family. Marchington and Wilkinson (2002) have observed that a competency framework provides a set of performance criteria at organizational and individual levels and that such a framework identifies the expected outcomes of achieving those criteria.

While competency frameworks are generally company- and, indeed, role-specific, consider the UK Institution of Civil Engineers’ competency framework structure (Maxwell-Hart & Marsh, 2001) as an example of a generic approach in a project/technical area. This framework comprises twelve key management roles and approximately 140 associated competencies. The key roles are:

• Corporate management
• Business management
• Financial and management systems
• Promotion and business development
• Communications and presentations
• The client and relationships
• Respect for people
• Project management
• Professional, commercial, and contractual practice
• Information and communication technology
• Health, safety and welfare, quality, and environment
• Construction profession in society³.

Elements of strategy management are covered in both the corporate and business management roles. The key purpose of the project management role is described as “the multi-faceted responsibilities necessary to programme [sic] (i.e., organize and schedule), monitor and control all aspects of the project from conception to successful handover in line with clients’ requirements, one's own organizational objectives and the implementation of best practice,” (Maxwell-Hart & Marsh, 2001, p. 3) and implies responsibility for project strategy.

Armstrong (1999) reports that a survey of 126 companies shows the most common behaviors sought by the organizations, one of which is strategic capability. Crawford (2000) reveals some of the knowledge, skills, and personal attributes of project managers, including that of strategic direction. Examples of core competencies related to project strategy are provided in the case studies section below.

Roles and accountabilities are slightly different from competencies: they are more prescriptive, describing the duties and tasks to be performed and what the incumbent will be held accountable for. In project-oriented organizations, processes and the documentation identifying roles, responsibilities, and accountabilities are formatted in different ways, are often extensive, and all too often are not very user-friendly. It is essential, therefore, that roles and responsibilities are identified and formatted in user-friendly ways and are bought into by those affected. Examples of roles and responsibilities—as well as formats—are given in the case studies section below.

We can now look at the findings of the case studies of four major organizations in the following chapters to see how they, in practice, move corporate strategy into project strategy. The companies include:

• A global aerospace manufacturing company
• A group within a global financial services company
• A division of a global pharmaceutical company
• An international transportation facility owner/operator.

---

¹Office of Government Commerce, Managing Successful Programmes (Norwich, UK: The Stationary Office, 1999), p. 11. © Crown copyright material is reproduced with the permission of the Controller of HMSO and Queen's Printer for Scotland.

²J. R. Turner, The Handbook of Project-Based Management: Improving the Process for Achieving Strategic Objectives. 2^nd ed. (Maidenhead, UK: McGraw-Hill, 1999), pp. 70 and 82. © 1999. Reproduced by permission of the Open University Press/McGraw-Hill Publishing Company.

³G. Maxwell-Hart and G. Marsh, Management Development in the Construction Industry, 2^nd ed. London: Thomas Telford 2001, 3-4. © 2001. The Institution of Civil Engineers.