Show Summary Details

Page of

PRINTED FROM OXFORD HANDBOOKS ONLINE (www.oxfordhandbooks.com). (c) Oxford University Press, 2015. All Rights Reserved. Under the terms of the licence agreement, an individual user may print out a PDF of a single chapter of a title in Oxford Handbooks Online for personal use (for details see Privacy Policy).

Subscriber: null; date: 18 October 2017

# Implementing Strategy through Projects

## Abstract and Keywords

The realization is growing that projects fail not only because of incompetent execution, but also, and frequently, because of a muddled strategic context, inadequate scope, or unarticulated—and thus unresolved—tensions and/or trade-offs among the project stakeholders. This realization has a straightforward message: project managers could benefit a great deal from expanding their activity to account for strategy alignment and organizational enablers. This article proposes that this view, although a step forward, still decouples project management from strategy-making. It implies that the business people set the outcomes and charter, and project management executes. Yet, this view misses the fact that strategy is not made only “at the top” and then cascaded down. In a world of increasing uncertainty, volatility, and interdependence across forms, industries, and countries, strategy is emergent; it has to adjust to events as they occur.

# Project management: strategy shaping or execution?

The linguistic root of the word project is the Latin word projectum, which means “something that is thrown forward.” This word suggests a forward-looking emphasis more than a tactical execution emphasis. Although many of the tools of project management were developed in the early US missile programs like Polaris, closer examination suggests that the Polaris program revolved much more around strategic choices than around project management techniques. In 1955, the Navy's Fleet Ballistic Missile (FBM) program aimed to “get a share of the ballistic missile ‘pie’ ” (Spinardi 1994: 25): Admiral Burke believed that “the first service that demonstrates a capability for this is very likely to continue the project and others may very well drop out” (1994: 26). The result was a clear prioritization of schedule over cost and specifications. (Indeed, the first two deployed versions of the Polaris missile had less than the desired range and explosive capacity.) The specifications were carefully differentiated from the competing Air Force systems, emphasizing the destruction of urban centers with limited required accuracy—as opposed to the Air Force's goals of destroying hardened targets, which required less power but more accuracy (1994: 34).

(p. 225) Even the PERT (Program Evaluation and Review Technique, a formal planning method developed by Polaris) served less for improving project control than for “offering technological pizzazz that was valuable in selling the program…. The image of managerial efficiency helped the project. It mattered not whether parts of the system functioned or even existed; it mattered only that certain people for a certain period of time believed that they did” (Spinardi 1994: 36). In summary, the operational definitions, priorities, actions, and even “efficiency” itself were repeatedly changed and subordinated to the Navy's strategic organizational goal: securing resources in competition with the Air Force.

This strategic dimension, however, has diminished within the project management (PM) discipline. Project management has shifted towards a focus on the execution of projects, assuming (usually) a “written in stone” mission and externally set goals (see Chapter 1 in this book). For example, the Project Management Institute's PMBoK Guide (PMI 2004) defined PM as the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. This involves balancing competing demands among scope, time, cost, and quality, and among stakeholders with differing needs and expectations, including identified requirements (needs) and unidentified requirements (expectations) (PMI 2004). Similarly, the definitions of two representative textbooks (Kerzner 2003: 3; Meredith and Mantle 2003: 9) exclude decisions about a project's scope from the definition of project management.

Thus, the historical evolution of project management contains a hint of irony: although the Polaris program is widely cited as having made an important contribution to the birth of project management, the discipline has divorced itself from the strategic types of action that drove the success of the Polaris development.

Recently, this “narrowing down” has begun to reverse. Several scholars have called for improving the link between project management and strategy. Morris (2006) characterized project definition and an appropriate embedding of the project in its environment as the “most important drivers of success.” Artto and Dietrich (2004) summarized project portfolio tools as a way of strategic management of projects. New textbooks devote space to the discussion of how projects are (or should be) embedded in strategy (cf. Pinto 2006); even the “conservative” PMI PMBoK Guide (PMI 2004) has begun to acknowledge that “projects are often utilized as a means of achieving an organization's strategic plan,” and that projects are “authorized as a result of…strategic considerations” (2004: 7).

Thus, the realization is growing that projects fail not only because of incompetent execution, but also, and frequently, because of a muddled strategic context, inadequate scope, or unarticulated—and thus unresolved—tensions and/or trade-offs among the project stakeholders (see Morris 2006 and Chapter 1 in this book). This realization has a straightforward message: project managers could benefit a great deal from expanding their activity to account for strategy alignment and organizational enablers.

(p. 226) In this chapter, we propose that this view, although a step forward, still decouples project management from strategy-making. It implies that the business people set the outcomes and charter, and project management executes. Yet, this view misses the fact that strategy is not made only “at the top” and then cascaded down. In a world of increasing uncertainty, volatility, and interdependence across forms, industries, and countries, strategy is emergent; it has to adjust to events as they occur (Mintzberg 1978). Strategy is therefore top down as well as bottom up. The discipline of project management cannot retreat and say, “We accept that we need to be informed about strategy so we can implement it better, but we leave the big decisions to the big people!” Project management should raise its sights to a higher-impact role by participating in strategy formulation itself.

# Top-down and bottom-up contribution of projects: search theory

Challenging organizational problems require complex projects to achieve a solution. The literature has abstracted them as optimizations of complex functions—(bold symbols stand for vectors) (Loch and Terwiesch 2007; Mihm, Loch, and Huchzermeier 2003; Rivkin and Siggelkow 2003):

$Display mathematics$

In this abstract formula, the vector x represents a set of decision variables. For example, building a new iron-ore-reduction facility demands designing thousands of components grouped in hundreds of sub-systems, for which design parameters must be set. Thus, the vector x = (x 1,…, x n) might consist of tens of thousands of variables. The function P represents the performance metric considered for the particular project (e.g. financial, technical, reputation). It represents the causal effects of the variables—for example, whether a variable increases or diminishes performance, and the interactions among the x i's. The shape of P could be influenced by a multitude of exogenous parameters, denoted by the vector a, that are not under the control of the project management team. These parameters may change over time in possibly unforeseeable ways (for example, a change in customer needs because of an economic change in a downstream industry, material characteristics, or a regulatory change). In principle, P maps every element of the set of problem solutions {x} to a real number (usually a dollar value) that can be used to perform comparisons. The choice of the “right” metric reflects the major dimensions of industry competition. Figure 9.1 summarizes this abstract representation of a project.

Fig. 9.1 A complex problem with interdependent sub-problems

(p. 227)

The variables that determine the project performance may “interact in non-simple ways [such that] given the properties of the parts and the laws of their interactions, it is not a trivial matter to infer the properties of the whole” (Simon 1969: 195). Then the performance landscape that results from the mapping P is rugged; that is, it exhibits many local maxima. (A local maximum is a solution x from which no small deviation along any decision x i offers an improvement.) When the performance function P is rugged, local search through small modifications cannot find the global optimum, the overall best solution. In addition, the different decision variables, x i, may require various domains of expertise to assess them and meaningfully choose new values. Typically, no “mastermind” holds all these competences and understands the overall performance function P well enough to be able to “optimize” on all dimensions (Kavadias and Sommer 2009).

As a response to such problem-solving challenges, organizations typically resort to two main search strategies: (i) the distribution of the necessary tasks across multiple actors (delegation and distributed problem-solving) and (ii) the establishment of iterative processes that enhance the ability to quickly find a better (according to the given metric) solution.

Search is usually distributed across many actors, because the deep knowledge about sub-problems and components is held by specialists (Simon 1969; Loch and Terwiesch 2007). In our formal abstraction, the overall performance P results from “smaller” pieces: $P=∑iPi(x1, … ,xN,ai;d)$. Each sub-problem P i is delegated to an actor i, such as a sub-team or a specialized subcontractor. The parameter vector d represents repeatedly executed analyses, tests, component designs, management coordination activities, etc., which are institutionalized in formally established “rules” (also known as processes) that ensure effectiveness at the organizational level (Nelson and Winter 1982). For example, subcontractors are often subject to (p. 228) detailed contractual agreements about the deliverables and specifications that ensure their proper contribution towards the overall performance. Well-known processes, such as the project life cycle (or the corresponding stage gate process in product development projects), are precisely this: institutionalized sets of rules that dictate how to proceed towards a solution, that is, the steps from a current solution x to a new one y.

Processes are also needed to ensure coordination and/or communication given that sub-problems usually depend on one another (represented by the interdependence lines with cross-partial derivatives in Figure 9.1), and thus organizations consist of more or less tightly coupled groups (Cyert and March 1963).

In summary, search theory characterizes project work as a sequence of successive iterations of sub-problem trial solutions that converge towards a system solution. For such complex projects, search theory has produced relevant insights:

• Senior management does not perform detailed problem-solving. Sub-problem (component, module) decisions should be delegated down to the lowest possible level, along with the right front-line problem-solving structure (Rivkin and Siggelkow 2003; Mihm et al. 2010).

• Senior management channels and checks the solutions produced at the front line for their contribution to overall performance: it sets in place the necessary structures (sub-team communication and coordination mechanisms, alignment checks between lower-level solutions and top-level priorities, and deadlock-resolution rules). Top management needs to empower; over-control from the top reduces the quality of the solutions produced (Rivkin and Siggelkow 2003).

Thus, search theory suggests an effective allocation of decision rights when it comes to project management tasks: since senior management does not know what the right execution decisions are, these decisions need to be taken at the front line, with full knowledge of the operational context. However, senior managers do have the oversight to determine what the right performance metrics are, and to identify effective institutionalized processes and rules—these, of course, are also subject to modifications and emerging changes as the environment shifts and the organization learns. In other words, there exists a second search process that happens in parallel at the senior management level. This top management search process constrains the operational (project-level) search process, but is itself changed by the operational-level results as they produce learning about effectiveness in an evolving environment. Through these two interlocking search processes, top-down and bottom-up management are intertwined, and they need to be considered simultaneously.

A body of theory is available to characterize and understand the two search processes, namely hierarchically nested evolutionary cycles, as in evolutionary biology and anthropology (Sober and Wilson 1999; Boyd and Richerson 2005). We summarize this view with our terminology in Figure 9.2 (adapted from Loch and Kavadias 2007).

Click to view larger

Fig. 9.2 Two-level evolutionary view of projects in the organization

(p. 229)

Figure 9.2 shows two levels of search processes, or evolutionary cycles, each consisting of the three stages of evolution: variation, selection, and retention to the next generation. The lower-level operational cycle operates at the project manager level. This is where “content” problem-solving occurs: novel solutions are created for problems facing the organization, through “creative” (partially random) idea combinations from differing areas of expertise and knowledge, shaped and constrained by the institutional process above it. The transformation of ideas into outcomes (products or production processes), is well known to exhibit the evolutionary steps of creative search, namely idea generation, selection (based on pre-determined metrics that reflect the strategic objectives), and retention in artifacts or prototypes, or even through an explicit technology database (e.g. Hargadon and Sutton 1997; Thomke 2003; Fleming and Mingo 2007).

At the higher level in Figure 9.2, we find the institutionalized processes and routines that govern project work and reflect “the way the organization does things.” Such processes may arise within the organization in ways that are not always fully conscious (Nelson and Winter 1982). They may emerge from trials within existing projects (a bottom-up effect) or arise from the imitation of outside benchmarking examples or professional practices. Processes are selected by their performance, (p. 230) which is often difficult to measure (success is stochastic and causally ambiguous and can be assessed only in the long term), so selection is noisy. It does happen in organizations that processes are chosen or eliminated based on spurious outcomes, after assigning erroneous causal links. Processes that are “selected out” may be officially discontinued or fall into disuse, but processes also have strong inheritance persisting over time.

The two levels of evolution interact: the lower level “makes up” the higher level (e.g. the process landscape of the firm is made up by the practices within the projects), and in turn, the structure of the higher level influences the creation, selection criteria, and inheritance of the lower level. The levels may contradict one another: what is adaptive at the lower level may not be adaptive for the higher level (Sober and Wilson 1999: 27). At the same time, the bottom-up interactions between the two processes depend heavily on the “openness” of senior management to allow successful practices to “bubble up” from the lower ranks of the organization, integrate them, and eventually shape its subsequent direction and performance.

Figure 9.2 highlights two key implications: progress accumulates iteratively, not by executing toward a fixed and well-known goal, and strategy-making and project execution are one system and must be managed in an integrated way. These implications echo previous observations about the differences between induced and emergent strategy (Mintzberg 1978; Burgelman 1991). Therefore, projects are more than mere “aligned mechanisms to execute strategy”; they need to play an integral part in “strategy-finding.”

In the remaining two sections, we first present widely used tools for strategy-cascading and project alignment, and then we provide an overview of (necessary but less widely used) tools that help to use projects as strategy-making devices.

Several tools and methods allow project managers to create and maintain the link between strategy and project execution. Here, we briefly present three distinct categories of tools that have proven useful in practice: (1) strategy-cascading tools, which facilitate translation of the business strategy into specific project objectives; (2) project portfolio diagrams, which facilitate the explicit identification of trade-offs during the allocation of resources across projects and also enable more accurate valuation of individual projects; and (3) formal tools for influencing stakeholders and negotiating, which facilitate the identification and negotiation of friction points during project execution. No specific tool gives “an answer” (in the sense of an (p. 231) optimization algorithm). Tools help to establish a common language within an organization, a language that consistently articulates the relationship between operational goals and strategic objectives. This allows actors to exchange information efficiently and to act in a coordinated fashion.

We present three strategy-cascading tools: the ratio tree, the balanced scorecard, and Markides' five-questions strategy framework.

The first tool is the financial ratio tree developed in 1985 by Richard Foster and colleagues. It draws on the famous DuPont financial ratio tree developed by F. D. Brown, a DuPont engineer, as early as 1914. The elegant idea is that the firm's key financial return on investment (from R&D) can be broken into a “technical performance” part and a “commercialization” part. Technical progress is measured by improvements in operating performance (e.g. product features, or process efficiency or quality) and commercialization success by returns (e.g. market share and price earned) from a given offering (see Figure 9.3).

Click to view larger

Fig. 9.3 Generic financial ratio tree cascaded to operational measures

Source: Adapted from Foster et al. (1985).

The R&D return tree is an elegant conceptual tool that contributes to a clear understanding of cause and effect, especially in conceptually separating the entangled effects of R&D versus commercial activities. Although it is well known and (p. 232) often cited, it is only rarely used because (a) the measures are very difficult to obtain (and easily the subject of endless interpretation battles), and (b) its complexity mounts as one expands the tree to more and more operational measures.

The second tool is the widely used balanced scorecard (see Figure 9.4) introduced by Kaplan and Norton (1996, 2000). It evaluates a (sub)organization's activities according to financial, customer, business process, and “learning” or competence-building goals. The scorecard offers a comprehensive summary of four types of organizational goals, and it allows for the possibility of breaking them down to lower levels of the organization.

Click to view larger

Fig. 9.4 The balanced scorecard strategy-cascading tool

Source: Adapted from Kaplan and Norton (1996).

The balanced scorecard tool has two key limitations. First, due to the “generic” nature of the sets of criteria (financial, customer, processes, and learning), the tool very easily reverts into a standardized measure mechanism. In principle these criteria should be adjustable, but in practice they often become standardized (as in “best practices” of customer and process metrics, which end up being just the ones most commonly used) and thus fail to capture the individual organization's true strategy. Second, the scorecard is typically implemented with a strong top-down flavor, neglecting the bottom-up feedback cycle emphasized in this chapter. In principle, responses to both objections can be incorporated into the tool, but only at a significant cost in increased complexity. This is why there are fewer implementations of (p. 233) the balanced scorecard in project management than in sales or manufacturing, where performance is easier to measure.

A third tool, related to the balanced scorecard but less widely applied, adapts the five questions of a generic framework introduced by Markides (1999) to a project management context (see Figure 9.5). In contrast to the balanced scorecard, this tool adopts an explicitly strategic view and begins by articulating the business unit's strategy via five straightforward questions:

1. 1. What products are we offering? Answering such a question is far from trivial; it requires answering tough related questions such as: Do we offer support services? Why or why not? Do we offer a solution or a product/component? And so on.

2. 2. Who are the customers that pay? Answers to this question may reveal a distinction between customers (parties that pay for the product) and end-users (parties that actually use the product and may influence the purchasers) as well as a better understanding of which project specification addresses which party's requirements.

3. 3. How is our organization able to deliver the product/service? This question aims to elucidate the organization's core processes (i.e. activities based on core competences and knowledge). Projects may represent one of the core activities—for delivering solutions in some organizations, for executing change in others.

Click to view larger

Fig. 9.5 The five questions of the strategic position cascading tool

(p. 234)

4. 4. Why do customers buy from us rather than from the competition or not at all? This question seeks a clear articulation of the value proposition of the product/service offering.

5. 5. What if the environment changes? Will the competitive logic change the required market offering and/or the processes used in the organization?

The project strategy then articulates what the project contributes in business terms: what scope to offer, what “customers” to satisfy, what PM methods and processes to employ, what specific value does the project contribute to any of the firm's priorities? Finally, what changes may force the project team to modify its scope or approach later?

The business strategy places demands and financial constraints on the project scope. In turn, the project strategy places feasibility constraints on—while also offering new opportunities or modifications to—the business strategy. The Markides framework is able to capture a productive top-down and bottom-up dialogue. This tool is somewhat more complicated than the balanced scorecard, but it lends itself more easily to capturing the precise business strategy an organization is following. At the same time, it facilitates the articulation of the rules and processes d in our introductory evolutionary framework. Loch and Tapper (2002) described a detailed application example in the advanced development department of a small diamond company.

In summary, all three strategy-cascading tools emphasize the importance of alignment. Misalignment is responsible for the pursuit of technical feats (by engineers who infamously dither with over-designed, “gold-plated” solutions), for running after the competition's innovations without ever catching up, and for faking the business numbers (“chasing the hockey stick”: the breakthrough revenue explosion is always two years away). Project team members who are not knowledgeable about strategy are thus unable to articulate the consequences and value of their decisions; as a result, they may lose motivation and no longer contribute all their knowledge, or they may start pursuing their own personal goals rather than supporting the organization.

The key benefits of explicitly articulating a project strategy extend far beyond its use as a “control tool.” Indeed, which tool is used matters less than whether management strives to use it to foster dialogue and motivation. The benefits of strategy cascading can be broadly summarized as clarity, guidance in assessing trade-offs, and motivation and empowerment of project workers (Loch 2008).

## Portfolio views

A key element of turning any strategic vision from hopeful statement into concrete plan of action is the effective allocation of resources across initiatives and tasks that aim to fulfill the strategic objectives. Portfolio views offer a holistic perspective on the organization's efforts to promote evolution of the business strategy. Portfolios are (p. 235) acknowledged in some project management textbooks (e.g. Meredith and Mantel 2003; Pinto 2006), but only qualitatively or with financial ratios (such as returns or cash flows). An important perspective missing from these accounts is that a project's value in terms of contribution to the firm often depends on the entire portfolio and is not merely a project-level feature (Girotra, Terwiesch, and Ulrich 2007).

Project managers can better communicate their projects' performance when they are armed with a deep understanding of the entire collection of projects. Recognizing project interactions enables better knowledge of an individual project's contribution to strategy as well as more focused and reliable execution. The portfolio embodies how the organization is pursuing its strategic objectives. The project team should clearly understand what strategic domain its project covers, what its role is, whether there is a duplicate or backup, and what interdependencies exist with other projects.

There are many portfolio representation tools and frameworks; here we offer two widely used visual tools (Figure 9.6) as examples. We argue that the portfolio should be customized to the organization and should not be restricted to standard views (Hutchison-Krupat and Kavadias 2009). The left diagram of Figure 9.6 emphasizes project novelty (and hence risk) in terms of technology used and markets addressed. The right diagram classifies projects by market segment and the firm's competitive position within those segments.

Click to view larger

Fig. 9.6 Two project portfolio diagrams

In the left diagram of Figure 9.6, projects with low novelty on both dimensions (technology and market) represent “continuous improvement” efforts (e.g. support or upgrade projects for the customer) or Six Sigma improvement projects inside certain organizational processes. Continuous improvement projects are often important for the organization: software upgrades can generate a lot of money; customer support projects earn substantial revenues in engineering services and (p. 236) build brand equity; and internal continuous improvement projects drive productivity growth, the lifeblood of margin protection. Such projects also exhibit very low risk. Yet they suffer from a low “glamour factor” and thus attract minimal attention from top management, which results in a control-focused “autopilot” approach. Moreover, formalized professional project management methods may be too heavy-handed for such projects: for example, a Six Sigma project may involve four person-weeks of effort spread over a team of five people. In this situation, at issue is not formal coordination and tracking of milestones, which are quite simple. Instead the challenge is motivating operations people to be engaged and to offer their ideas and tacit knowledge. An exaggerated emphasis on control may squeeze such initiatives to death.

Projects in the middle zone of the left diagram are the challenging projects one typically encounters in project management stories and examples: they address new customers and/or locations (although within similar segments), which increases the risk of misunderstandings and resultant tensions with customers, and they embody some novel technologies, which increases the risks associated with timely delivery and system integration. These projects pose substantial risks, and it is in this area where professional and disciplined methods for planning, requirements negotiation and “freezing,” monitoring, and risk management offer value.

Finally, some projects break into fundamentally new territory for the organization. New territory can mean addressing a new category of customers (e.g. a fluid-bed reactor engineering contractor who has worked with metal reduction and who now addresses chemical companies about designing chemical reactor vessels). It can also mean incorporating radically novel platform technologies into a project (e.g. integrating a continuous variable transmission [CVT] powertrain into an SUV and altering an entire product category). Such projects offer the potential of high returns but are also quite risky. Moreover, the effectiveness of established formal project management methods comes into question.

The right diagram in Figure 9.6 places projects in the organization's market segments and the strategic role of those segments. With reference to our fluid-bed reactor engineering, the diagram shows two segments, metal and chemical, as well as a standard commodity (existing business) versus a high-end customization (new business) sub-segment within each. Looking at the organization's projects in this matrix illuminates two key strategic decisions. First is the de facto prioritization of the business segments: which one should receive more resources to fund more initiatives? Which segment has unfulfilled market demand or unpursued growth opportunities? Second, does the project “defend” the ongoing business objectives or does it rather aim to generate new business? The answers to these questions determine the risk profile, since adapting previous approaches is less risky than entering a new market. In that context, our previous CVT SUV example could be viewed as a project that meant to position a firm at the forefront of performance within the SUV segment. Once more, the objective is to assess not the attractiveness of (p. 237) individual projects but instead whether the initiatives combine to address the organization's markets and support its business strategy.

Such portfolio views prompt senior management to ask questions of balance: are we undertaking too few (or too many) innovative, high-risk projects? The benchmark is fewer than 10 percent in most organizations, since undertaking more would pose excessive risks overall. Are we investing enough of our project management resources in continuous improvement projects? If we do too little, our organizational methods and processes may not be improving aggressively enough to achieve productivity goals and cost competitiveness. If we focus on this category too much, we may become too incremental and too oriented towards the short term. In other words, portfolio tools should ask questions about the prioritization of resource investments in project initiatives, with responses articulating how the projects contribute to the business. The left-hand portfolio in Figure 9.6 asks: How much do we want to invest in improvement of current products and processes, next-generation projects, and breakthrough projects, and how much risk are we willing to take? The right-hand portfolio asks: On which market segments are we focusing our efforts, and what balance are we striking between current business growth and new business development?

In addition, the holistic perspective of portfolio tools allows the evaluation of individual projects not only in absolute terms but also relative to one other. Project rankings based on standard financial metrics may favor some initiatives, but this in itself does not imply that those initiatives should be in the portfolio, because the organization may have decided to break ground in another market. The major limitation of a bottom-up approach to portfolio management is that it risks including “attractive” projects that do not support the organization's strategic interest. Put differently, the whole portfolio should be more valuable than the sum of the parts [projects] as seen individually. It is senior management's responsibility to set the desired balance of improvement, next-generation, and high-risk innovative projects. No method can actually “derive” the right portfolio because senior management sets the business priorities. However, project managers must actively participate because it is their detailed knowledge that's needed when appraising the potential of proposed projects.

Unfortunately, most organizations—even the sophisticated ones that employ project portfolio tools—use “generic” portfolios that have been offered in the literature (e.g. Wheelwright and Clark 1992; Artto and Dietrich 2004; Kavadias and Chao 2007); examples include risk versus return and market growth versus market size (the classic Boston Consulting Group's strategy portfolio). It would be appropriate for two different organizations to use the same generic portfolio only if the organizations had the same strategy. For example, an engineering contractor that competes by offering fast, low-cost implementation of standardized facilities should not have the same project portfolio as one that deals with customized high-tech facilities.

## (p. 238) Negotiation and stakeholders

Stakeholders are the various parties who may not necessarily have an official role but nevertheless have an interest in the direction of a project. As we argued at the start of this section, both the overall business strategy and the individual project strategies tend to be compromises among relevant trade-offs; it often happens that stakeholders (inside or outside the boundaries of the organization) may have different interests or perceive these compromises in different ways, because of interest conflicts, but also because they are driven by different “thought worlds” (Dougherty 1992). For example, the government may aim to subsidize the development of a new “green” technology or a major infrastructure project in order to increase social welfare, whereas the project subcontractors undertake the effort with the objective of making a profit.

Two widely used tools that enable the formal representation of stakeholder interactions are stakeholder maps and power/interest matrices (Freeman 1984; Elias, Cavana, and Jackson 2002; Winch and Bonke 2002). A stakeholder map, or a list of all stakeholders with their interests, indicates for whom the project causes problems (opponents) or offers something attractive (proponents). The power/interest matrix offers a categorization of the stakeholders that suggests in which order they should be approached (Figure 9.7).

Click to view larger

Fig. 9.7 Stakeholder power/interest matrix

The power/interest matrix acknowledges the relationship networks that exist in organizations (Rowley 1997). No one decides in isolation; we all ask people whom we know and trust for advice. Thus, a stakeholder strategy must account for the influential (p. 239) “brokers” in the stakeholder network. If you can get influential stakeholders on your side their network will “work for you”; this dynamic represents a non-linear feedback process that can result in an “epidemic of support” (or of resistance).

According to this social network logic, the power/interest matrix suggests the order of approach: network-central, and thus influential, stakeholders who happen to like the project are natural early allies. Once they are willing to speak up for the project, the “critical mass” of less influential but positive stakeholders can be mobilized, and they then pull along the slightly negative players in a “social contagion” (Rowley 1997; Krackhard and Hanson 1993). Each of these stakeholder categories requires its own attention and approach.

Whereas the stakeholder map and the power/influence matrix offer a comprehensive representation of the stakeholder network and its members' intentions, they consider only one underlying source of those intentions, namely the rationally driven “conflicting interests”; however, two additional sources of stakeholder intentions are relevant here: the less conscious and more subtle issues of culture and/or emotional aspects of social transactions (the lower-level gray layers in Figure 9.8).

Click to view larger

Fig. 9.8 Levels of influencing stakeholders

The layer below the network influence layer is the cultural layer of “what is appropriate.” Culture refers to the socially learned routines and assumptions of (p. 240) social integration and problem-solving that successive generations of a group's members inherit (Schein 2004; Boyd and Richerson 2005). In our previous terminology, this means that the rules/processes d are not always consciously derived by some kind of optimization, but arise as cultural habits and unspoken assumptions. Thus, changes may also arise in unconscious cultural shifts, and rules may be enforced not only by official incentives and sanctions but also by social norms and peer pressure. Examples abound across different types of projects: does your project usurp an activity that, within a particular country, the government or a local power broker “owns”? Does it sufficiently consult local people so they feel respected? Project specifications must sometimes be adjusted in order to locate the project within the range of socially acceptable configurations and outcomes.

Even deeper lies the layer of emotions. Specifically, when status feelings, and an associated desire to “win,” creep into interactions, stakeholders may harden their positions and demands; if, however, a relationship can be built, or a feeling of “we” based on some kind of common identity can be emphasized, people become more cooperative. Such behavioral influences are robust and often economically large (Loch and Wu 2008). In stakeholder management, this implies that individuals may find the project fundamentally beneficial yet still resist or impede its progress simply because the project manager did not ask for advice at a critical juncture, did not invite them to the milestone ceremony, or did not refer to them in an interview with the local press. The attitude of local inhabitants toward a project may be swayed by making the effort to engage local experts on the steering committee or on the project itself (thus giving respect and building a relationship). Once people see the project as “theirs,” they may naturally swing toward support, regardless of the objective project specifications.

The two lower layers in Figure 9.8 cover the underlying bases of understanding stakeholder interests and the political influence landscape; understanding sources of strong emotions may help the project manager mobilize support in some situations.

# Shaping strategy: projects as strategy creation tools

In this section we discuss three examples of bottom-up strategy-finding roles that projects can play, as we discussed in Figure 9.2. They can be categorized on two dimensions: the type of search at the front line (incremental or radical) and the extent of bottom-up initiatives allowed. The type of search processes/actions that (p. 241) drive highly novel solutions has been classified in two main categories: parallel searches (ecologies of experiments) and trial-and-error iterations (Loch, Pich, and De Meyer 2006). Based on this categorization:

• We discuss how an ecology of small parallel emerging projects can cumulatively result in a business strategy shift.

• We show how large projects that develop significantly novel solutions and through which significant strategy changes emerge should be managed.

• We give an example of a radical project that in itself represented a major emergent shift in the strategy of the organization.

## Managing change through small projects

We saw earlier that high-performance organizational search projects should contribute to strategy, shaping it rather than merely executing given targets. This can be done even in manufacturing organizations (often characterized by little tolerance for bottom-up initiatives) if the individual projects are small and relatively simple. Sting and Loch (2009) studied strategy deployment in six manufacturing organizations and found that strategy was shaped by the collection of improvement projects.

Click to view larger

Fig. 9.9 Strategic improvement projects at six manufacturing companies

(p. 242)

For example, each organization had about ten to twenty “strategic” improvement projects that were driven and followed up by senior management (in addition to many smaller projects driven at the line or department levels). Figure 9.9 categorizes these projects by problem domain and shows that many of them originated at the bottom of the organization, not the top. Significant (manufacturing process) technology investments were so expensive that they were initiated at the top (right bar in the figure), but product/market and organizational projects came from the bottom to some degree.

In addition, four of the six organizations were flexible in their strategic targets, willing to adjust them depending on the results. For example, one organization changed its technology trajectory because of inputs from a workshop that brought together product and process engineers and experienced manufacturing craftspeople. Another organization put in place an experimental production line staffed by older workers, initiated by a department manager triggered by the observation in a senior management meeting that the workforce was getting older, which threatened productivity goals. The production line personnel developed, entirely bottom up, an integrated system of ergonomic, work schedule, and health management support actions that brought productivity up to the level of a young workforce; this system was adopted by the company as a whole and thus changed the company's HR strategy (Loch et al. 2010).

The key to these organizations' ability to shape strategy through projects from the bottom lies in their willingness to articulate problems at the top, but to allow initiatives to “bubble up,” monitoring only for coordination across departments and for the existence of results. These results are allowed to be useful in unexpected directions. The individual projects are relatively small (usually less than one person-year), but collectively they add up to emerging strategic effects.

## Iteration and parallel trials in emerging uncertain projects

Larger, complex projects with the ambition to contribute to strategy must accept a higher level of risk internally to the project (for example, a new technology or a new market). Worse, such projects must accept that risks may arise that are unforeseeable at the outset. The following quote from Drucker (1985: 189) illustrates this idea well:

When a new venture does succeed, more often than not it is in a market other than the one it was originally intended to serve, with products and services not quite those with which it had set out, bought in large part by customers it did not even think of when it started, and used for a host of purposes besides the ones for which the products were first designed.

Economists have called this “unawareness” or “unforeseen contingencies” (Modica and Rustichini 1994); scholars in public policy term it “wicked problems” (Rittel and Webber 1973); project management professionals have used the term “unknown unknowns,” or “unk unks” (Wideman 1992). When a project develops a new technology or tackles a new market, unknown unknowns are rampant (Loch, Pich, and De Meyer 2006).

When unk unks are so fundamental that the project goal and path are themselves fundamentally unknown, risk management and local flexibility are insufficient. Any plan will run into major surprises, and the project team will be required to abandon assumptions and look for solutions in non-anticipated places (Miller and Lessard 2000; Loch, Pich, and De Meyer 2006).

Of course, the project team should attempt to convert unknown unknowns into risk by performing careful upfront feasibility and risk analyses—competent risk management and project planning are still required and should be used as much as possible. However, in novel or breakthrough projects, this is simply not sufficient, no matter how hard one tries. The necessity for adopting a flexible mindset can indeed be identified at the outset of the project: while the unk unks themselves cannot be foreseen, the situation that bears their presence may well be diagnosable. For example, discovery-driven planning (McGrath and MacMillan 1995, 2000) proposes to explicitly acknowledge that unknown unknowns exist and to uncover them with analyses such as assumptions checklists. Similarly, Loch et al. (2008) illustrated with the example of a start-up venture project how the presence of unknown unknowns can be diagnosed by systematically probing what one knows about the project, and where one has the intuition of being on unsafe ground.

Two fundamental approaches exist for this level of unforeseeable uncertainty: trial-and-error learning and selectionism (Pich et al. 2002; Leonard-Barton 1995).

Under trial-and-error learning, the team starts moving towards one outcome (the best it can identify), but is prepared to repeatedly and fundamentally change both the outcome and the course of action as new information becomes available. Exploratory experiments, aimed at gaining information without necessarily contributing “progress,” are an important part of this approach; failure of such experiments is a source of learning rather than a mistake. It is therefore important to track the learning and reduction in knowledge gaps rather than tracking only the progress towards a target. The approach has been described under various names by numerous authors in technology transfer, new product development, engineering projects, and new ventures (for an overview, see Sommer and Loch 2009).

Alternatively, the team might choose to “hedge” and opt for selectionism, or pursuing multiple approaches in parallel, observing what works and what doesn't (without necessarily having a full explanation why) and choosing the best approach ex post facto. Examples of this approach abound, including Microsoft's pursuit of several operating systems during the 1980s (Beinhocker 1999), Toyota's “set-based engineering” (Sobek, Ward, and Liker 1999), and “product churning” by the Japanese consumer electronics companies in the early 1990s (Stalk and Webber 1993).

Click to view larger

Fig. 9.10 When to choose trial-and-error learning versus selectionism

(p. 244)

In a large-scale empirical study of sixty-five new venture projects, Sommer and Loch (2009) showed that the best combination of learning and selectionism, as measured by their effect on project success, depends on the level of unforeseeable uncertainty in the project and the complexity of the project (Figure 9.10). When both uncertainty and complexity are low (lower left quadrant), planning and standard risk management are up to the task and the most efficient. When unforeseeable uncertainty looms large, be flexible and apply trial and error. When complexity is high, use parallel trials and narrow the field down to the best as soon as possible. The hardest situation is in the upper right quadrant, where unforeseeable uncertainty and project complexity combine. It turned out that the highest success level was associated with parallel trials if they could be kept alive until uncertainty had been reduced to the point that all important risks were known. Otherwise, trial and error performed better. Of course, in any large project, trial and error and selectionism can be combined and applied differently to different sub-projects.

## Shaping and evolving the project's strategic mission: an example

Finally, we discuss an extreme example of a project, in which the events in the project led to a change in the organization's strategy. This example illustrates that a project's mission is rarely objective, and that the strategy the project is supposed to support does not exist or is in flux because the environment is changing. Although (p. 245) the specifications are articulated in technical terms, one begins always with a social construction that reflects a “wish” that is in some way shared by stakeholders (and that can be explained to support the organization's strategy). This strategy is often emergent and evolving over time, and it sometimes depends on fickle and fleeting alliances among multiple players. Projects in the public domain are especially prone to such ambiguity, but projects in large organizations can also reflect this level of emergent goals (Rittel and Webber 1973). For such emergent strategic projects, where stakeholder priorities are fluid and may shift before the project is completed, the organization is often faced with a delicate question: Does the organization attempt to enforce the preset compromise between stakeholders or is renegotiation inevitable, putting the project's benefits at risk?

The answer is that stakeholder shifts may be unavoidable: the project goals may drift to reflect changing social consensus and alliances. The organization can rarely force stakeholders to stand by prior compromises; it must allow the goals to drift but should try to steer or nudge this drift toward a configuration that continues to support (albeit in a possibly modified way) the organization's strategy. This task is difficult and requires as much diplomacy and political skills as traditional project management, and it certainly requires the full support and detailed involvement of the organization's senior management. Thus, for emergent projects a key ability of the organization is maintaining a disciplined focus on the strategic role of the project for the organization.

Consider the recent example (Loch and Mihm 2008) of Eurocontrol, the European agency for air traffic control. The agency reports to the Council of European Transport Ministers and, with its 2,500 employees, coordinates traffic control across the European Union (EU). The agency's task is complex because each of the thirty-five member countries owns part of the European airspace; moreover, air traffic control in each country is performed with local systems that are mutually incompatible. Personnel certifications and policies also differ from country to country. This complexity makes air traffic control in Europe more expensive than in the United States and also vulnerable to flight delays due to coordination failures.

Click to view larger

Fig. 9.11 Evolution of the RDC's ATC project

Source: Adapted from Loch and Mihm (2008).

Since the mid 1990s, various parties have informally discussed frameworks for system configurations of a Europe-wide compatible ATC system. In 2001, RDC (Eurocontrol's R&D and system simulation organization) started a project to develop an “operational concept” of European ATC for 2020 and beyond. An operational concept is a high-level description of the flows and processes used to guide planes but without any technical description of how the functionality would actually be achieved. The project had two rationales: (1) such a concept was a genuine part of RDC's mission to move ATC forward, and (2) the RDC wanted to place itself more centrally in the network of relevant stakeholders (governments, national ATC providers that were half public and half private, airlines, airports, and ATC equipment manufacturers). The RDC formed a research consortium together with some equipment manufacturers and national ATC providers, and they obtained research funding from the European Commission as part of its five-yearly (p. 246) framework R&D fund. In 2004, the consortium delivered a first-stage high-level concept. This project, called CATC (Collaborative ATC), is shown on the left-hand side of Figure 9.11.

However, stakeholder coalitions evolved over the course of these three years. The national ATC providers and airlines decided that CATC was too important to be left to R&D people—particularly under the auspices of Eurocontrol and RDC, a central body representing the EC rather than national constituencies. A broader consortium was founded, one driven by business people rather than R&D people; the RDC managed to become a member of this consortium so as not to be left out. The new consortium quickly rejected the CATC operational concept as too inflexible. They dubbed their effort SESAR (Single European Sky Advanced Research), which by 2008 became the unifying term for the attempt to restructure European air traffic control. SESAR set out to produce an improved operational concept by 2006. Yet no advancement occurred until mid-2007, and the effort largely reproduced CATC—evidence that technical criteria were not the only ones in play.

The SESAR project is shown on the right-hand side of Figure 9.11. It would receive two billion in funding over twelve years from the EC and Eurocontrol, and it would (p. 247) be run by a new entity (a project steering committee) known as the Joint Undertaking. Although the technical goals of the SESAR project were not much different from those of the original CATC, the project had assumed a different mission and was run differently. The RDC would be working for the Joint Undertaking in a role that was still to be defined: possibly as an operational project manager that would coordinate various players and work packages, as a subcontractor for certain R&D and simulation work, or some combination of both.

How should the RDC respond to this changed project context? Its original strategic vision was no longer valid. However, the RDC could still contribute to the greater whole, while extracting value for its own organization, by advantageously placing itself in the stakeholder network. The value proposition to the RDC's constituencies—as well as the strategic role of the project for the RDC itself—would have to change. Despite the radical changes, there was still a strategic role to be played in this project by the RDC: to establish the RDC as a “thought leader” on the concept for 2020; as a project manager with the capacity to coordinate partners as different as national ATC providers, airlines, and equipment manufacturers; and as an impartial arbiter that could help stakeholders identify win-win compromises. If played right, the new project (because it was broader) might help the RDC even more than the original project. However, this would require RDC's senior management to become explicitly involved in order to steer SESAR activities in this direction. This was not a project with deliverables but rather a strategic initiative that might change the organization's size, structure, and external position.

In summary, this example shows that the classic approach to project management—where “specifications” are taken as given and changing them is viewed as a catastrophic disruption—may paralyze an organization involved in large, novel strategic projects. In such projects, the goals may be a social construction born out of consensus rather than a “technical solution to a defined problem.” As a result, top management must be involved in guiding the emergent process of “morphing” the consensus mission over time. If this is done well (even at the cost of operational project management inefficiencies due to changes), the project may become a great strategic asset, as we see in the example of SESAR. If the organization does not see this opportunity, the project may become a lost opportunity, or worse, a failure that hurts the organization's credibility and standing. The Eurocontrol project is a vivid showcase of the importance of senior management's “openness” to emergent (unforeseeable) influences in major projects, and of the importance of monitoring not simply progress but also governance, priorities, and the project's position in a changing environment. Monitoring must include key stakeholders—only if they agree on how to view the changes can the project evolve in ways that further the organization's strategy rather than cause strife and conflict.

This last point is linked to the strategy framework in Figure 9.2. The “what if” contingency dimension of strategy is not only a high-level search for new macroeconomic trends but is also informed by events within the projects themselves. (p. 248) That is, an organization's projects can and should be used as sources of warning signals about emerging changes in the behavior of customers, stakeholders, competitors, and markets.

# Conclusion

Traditionally, a project's scope, objectives, and specifications have been viewed as a mandate with which project managers must operate and succeed. Newer work in project management has rediscovered the systematic use of projects as implementation “vehicles” for an organization's strategy. Three strategy alignment tools are widely used and being integrated into project management; we have provided an overview of these tools:

1. 1. A systematic translation of the business strategy into project targets with cascading tools.

2. 2. A portfolio-level assessment of the organization's projects. Projects interact in their effects on the business, and the portfolio view clarifies existing priorities.

3. 3. A thorough understanding of the “map” of stakeholders and their respective objectives. This is an integral part of strategic alignment.

However, projects also create and shape strategy from the bottom up. As organizations do not optimize strategy but search for acceptable solutions, projects play an integral part in this search. Examples of bottom-up strategy shaping include:

1. 1. A portfolio of small improvement projects that can change and enhance strategy if senior management is willing to accept useful but unexpected results.

2. 2. Larger projects that have the ambition to contribute to emerging strategy but which must accept unforeseeable uncertainty as part of their mission. This requires trial-and-error and selectionism (parallel trials) project management.

Project management has a larger role to play in organizations as the vehicle for strategic trials and change. To fulfill this role, the bottom-up tools sketched in this chapter need to be formalized and consistently applied.

## References

Artto, K. A., and Dietrich P. H. (2004). “Strategic business management through multiple projects,” in P. W. G. Morris and J. K. Pinto (eds.), The Wiley Guide to Managing Projects. London: John Wiley & Sons Inc., 144–76. (p. 249) Find this resource:

Beinhocker, E. D. (1999). “Robust adaptive strategies,” Sloan Management Review, 40/3: 95–106.Find this resource:

Boyd, R., and Richerson, P. J. (2005). The Origin and Evolution of Cultures. Oxford: Oxford University Press.Find this resource:

Burgelman, R. A. (1991). “Intraorganizational ecology of strategy making and organizational adaptation: theory and field research,” Organization Science, 2/3: 239–62.Find this resource:

Cyert, R. M., and March, J. (1963). A Behavioral Theory of the Firm. Englewood Cliffs, NJ: Wiley Blackwell.Find this resource:

Dougherty, D. (1992). “Interpretive barriers to successful product innovation in large firms,” Organization Science, 3/2: 179–203.Find this resource:

Drucker, P. F. (1985). Innovation and Entrepreneurship. New York: Harper Collins.Find this resource:

Elias, A. A., Cavana, R. Y., and Jackson, L. S. (2002). “Stakeholder analysis for R&D project management,” R&D Management, 32: 301–10.Find this resource:

Fleming, L., and Mingo, S. (2007). “Creativity in new product development: an evolutionary integration,” in C. H. Loch and S. Kavadias (eds.), Handbook of New Product Development Management. Oxford: Butterworth/Heinemann, 113–34.Find this resource:

Foster, R. N., Linden, L. H., Whiteley, R. L., and Kantrow, A. M. (1985). “Improving the return on R&D I,” Research Technology Management, January–February: 12–17.Find this resource:

Freeman, R. E. (1984). Strategic Management: A Stakeholder Approach. Boston: Pitman.Find this resource:

Girotra, K., Terwiesch, C. K., and Ulrich, T. (2007). “Valuing R&D projects in a portfolio: evidence from the pharmaceutical industry,” Management Science, 53/9: 1452–66.Find this resource:

Hargadon, A., and Sutton, R. I. (1997). “Technology brokering and innovation in a product development firm,” Administrative Science Quarterly, 42: 716–49.Find this resource:

Hutchison-Krupat, J., and Kavadias, S. (2009). “Organizational enablers for NPD portfolio selection,” Georgia Tech Working Paper.Find this resource:

Kaplan, R. S., and Norton, D. P. (1996). The Balanced Scorecard. Boston: Harvard Business School Press.Find this resource:

—— —— (2000). “Having trouble with your strategy? Then map it,” Harvard Business Review, September–October: 167–76.Find this resource:

Kavadias, S., and Chao, R. (2007). “Resource allocation and new product development portfolio management,” in C. H. Loch and S. Kavadias (eds.), Handbook of New Product Development Management. Oxford: Butterworth Heinemann Elsevier.Find this resource:

—— and Sommer, S. (2009). “The effects of problem structure and team expertise on brainstorming effectiveness,” Management Science (forthcoming).Find this resource:

Kerzner, H. (2003). Project Management: A Systems Approach to Planning, Scheduling and Controlling, 8th edn. Hoboken, NJ: Wiley.Find this resource:

Krackhard, D., and Hanson, J. R. (1993). “Informal networks: the company behind the chart,” Harvard Business Review, July–August.Find this resource:

Leonard-Barton, D. (1995). Wellsprings of Knowledge. Cambridge, MA: Harvard Business School Press.Find this resource:

Loch, C. H. (2008). “Mobilizing an R&D organization through strategy cascading,” Research Technology Management, September–October: 1–9.Find this resource:

—— and Kavadias, S. (2007). “Managing new product development: a framework,” in C. H. Loch and S. Kavadias (eds.), Handbook of New Product Development Management. Oxford: Butterworth Heinemann/Elsevier, chapter 1.Find this resource:

—— and Mihm, J. (2008). “Eurocontrol's experimental center,” INSEAD Case Study. (p. 250) Find this resource:

—— and Tapper, U. A. S. (2002). “Implementing a strategy-driven performance measurement system for an applied research group,” Journal of Product Innovation Management, 19: 185–98.Find this resource:

—— and Terwiesch, C. (2007). “Coordination and information exchange,” in C. H. Loch and S. Kavadias (eds.), Handbook of New Product Development Management. Oxford: Butterworth Heinemann/Elsevier, chapter 12.Find this resource:

—— and Wu, Y. (2008). “Social preferences and supply chain performance: an experimental study,” Management Science, 54/11: 1835–49.Find this resource:

——Pich, M. T., and De Meyer, A. (2006). Managing the Unknown: A New Approach to Managing Projects under High Uncertainty. Hoboken, NJ: Wiley.Find this resource:

—— Solt, M. E., and Bailey, E. (2008). “Diagnosing unforeseeable uncertainty in a new venture,” Journal of Product Innovation Management, 25/1: 28–46.Find this resource:

——Sting, F., Bauer, N., and Mauermann, H. (2010). “Mobilized productivity knows no age,” Harvard Business Review, March: 99–104.Find this resource:

McGrath, R. G., and MacMillan, I. (1995). “Discovery driven planning,” Harvard Business Review, July–August: 44–54.Find this resource:

—— (2000). The Entrepreneurial Mindset: Strategies for Continuously Creating Opportunity in the Age of Uncertainty. Cambridge, MA: Harvard Business Press.Find this resource:

Markides, C. C. (1999). “A dynamic view of strategy,” Sloan Management Review, Spring: 55–63.Find this resource:

Meredith, J. R., and Mantel, S. J. (2003). Project Management: A Managerial Approach. Hoboken, NJ: Wiley.Find this resource:

Mihm J., Loch, C. H., and Huchzermeier, A. (2003). “Problem-solving oscillations in complex engineering projects,” Management Science, 49/6: 733–50.Find this resource:

—— —— Wilkinson, D., and Huberman, A. (2010). “Hierarchical structure and search in complex organizations,” Management Science (forthcoming).Find this resource:

Miller, R., and Lessard, D. R. (2000). The Strategic Management of Large Engineering Projects: Shaping Institutions, Risk and Governance. Cambridge, MA: MIT Press.Find this resource:

Mintzberg, H. (1978). “Patterns in strategy formation,” Management Science, 24/9: 934–48.Find this resource:

Modica, S., and Rustichini, A. (1994). “Awareness and partitional information structure,” Theory and Decision, 37: 107–24.Find this resource:

Morris, P. W. G. (2006). “Initiation strategies for managing major projects,” in P. C. Dinsmore and J. Cabanis-Brewin (eds.), The AMA Handbook of Project Management. New York: AMACOM, chapter 4.Find this resource:

Nelson, R. S., and Winter, S. G. (1982). An Evolutionary Theory of Economic Change. Cambridge, MA: Harvard University Press.Find this resource:

Pich, M. T., Loch, C. H., and De Meyer, A. (2002). “On uncertainty, ambiguity and complexity in project management,” Management Science, 48/8: 1008–23.Find this resource:

Pinto, J. K. (2006). Project Management: Achieving Competitive Advantage. Englewood Cliffs, NJ: Prentice Hall, Pearson Education.Find this resource:

pmi (2004). A Guide to the Project Management Body of Knowledge (PMBOK Guide), 3rd edn. Newton Square, PA: Project Management Institute.Find this resource:

Rittel, H. W., and Webber, M. M. (1973). “Dilemmas in a general theory of planning,” Policy Sciences, 4: 155–69.Find this resource:

Rivkin, J. W., and Siggelkow, N. (2003). “Balancing search and stability: interdependencies among elements of organizational design,” Management Science, 49/2: 290–311. (p. 251) Find this resource:

Rowley, T. J. (1997). “Moving beyond dyadic ties: a network theory of stakeholder influences,” Academy of Management Journal, 22/4: 887–910.Find this resource:

Schein, E. H. (2004). Organizational Culture and Leadership. San Francisco: Jossey-Bass.Find this resource:

Simon, H. A. (1969). The Sciences of the Artificial, 2nd edn. Cambridge, MA: MIT Press.Find this resource:

Sobek, D. K.,II, Ward, A. C., and Liker, J. K. (1999). “Toyota's principles of set-based concurrent engineering,” Sloan Management Review, 40/2: 67–83.Find this resource:

Sober, E., and Wilson, D. S. (1999). Unto Others: The Evolution and Psychology of Unselfish Behavior. Boston: Harvard University Press.Find this resource:

Sommer, S. C., and Loch, C. H. (2009). “Project management under high uncertainty,” in V. K. Narayanan and G. O'Connor (eds.), Technology and Innovation Management Encyclopedia. Oxford: Blackwell.Find this resource:

—— —— and Dong, J. (2009). “Managing complexity and unforeseeable uncertainty in startup companies: an empirical study,” Organization Science, 20/1: 118–33.Find this resource:

Spinardi, G. (1994). From Polaris to Trident: The Development of US Fleet Ballistic Missile Technology. Cambridge: Cambridge University Press.Find this resource:

Stalk, G., and Webber, A. M. (1993). “Japan's dark side of time,” Harvard Business Review, July–August: 93–102.Find this resource:

Sting, F., and Loch, C. H. (2009). “Where top-down and bottom-up meet: a study of strategy deployment at five manufacturing organizations,” INSEAD Working Paper, August.Find this resource:

Thomke, S. H. (2003). Experimentation Matters. Cambridge, MA: Harvard Business School Press.Find this resource:

Wheelwright, S. C., and Clark, K. B. (1992). Revolutionizing Product Development. Boston: Harvard Business School Press.Find this resource:

Wideman, R. W. (1992). Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities. Newtown Square, PA: Project Management Institute.Find this resource:

Winch, G. M., and Bonke, S. (2002). “Project stakeholder mapping: analyzing the interests of project stakeholders,” in D. P. Slevin, D. I. Cleland, and J. K. Pinto (eds.), The Frontiers of Project Management Research. Newton Square, PA: Project Management Institute, 385–403.Find this resource: