Strategy Implementation And Project Management

Pergamon

Internattonal Journal of Project ManagementVol. 16, No. 1, pp. 43-50, 1998

~: 1997 ElsevierScienceLtd and IPMA. All rights reserved Printed in Great Britain 0263-7863/98 $19.00 + 0 00 PIh S0263-7863(97)00016-1

Strategy implementation and project management Tony Grundy* Cranfield School of Management, Cranfield, BedJbrd, MK44 OAL, UK

To date, strategy implementation and project management have largely developed quite separately and independently. But there are many opportunities for cross-fertUisation which are currently under-exploited both in theory and in practice. A number of tools from strategic management, value management and from organizational change can he imported into project management to enrich traditional techniques considerably. These tools are particularly powerful when applied to complex, multi-functional projects which are entailed when attempting to turn business strategy into implementation. These tools can also be imported into mainstream project management practice. ,© 1997 Elsevier Science Ltd and IPMA

Over the past few years there has been increasing interest in project management as a vehicle for strategy implementation. This interest has resulted in significant advances in: a) our understanding of how strategy can be more effectively implemented; b) our notion of what 'project management' can, and should, stand for. Dealing first with (a), it has been recognised for many years that implementation is frequently the graveyard of strategy.' But although implementation is touched on by core texts on strategic management (for exampleZ), implementation rarely gains the prominence which it deserves. Arguably strategic management should achieve its very own 'paradigm shift '3 by moving from a 90:10 concern with strategy formulation relative to implementation to at least a 50:50 concern with each. Turning next to (b) the role of project management, project management's core concern is to deliver a specific result in a particular time and at a particular cost. Traditional project management 4 focuses on deliverables (or 'outputs'), on scheduling and co-ordinating tasks, and on mobilising resources. Principally, traditional project management deals with 'hard' taskbased business issues, as opposed to 'softer', less tangible factors, except perhaps for defining the role of project manager and the project team. The 'design' theory of strategic management promotes the notion of a neat strategic analysis-choiceimplementation process. However, the 'alternative' *Tel. 01234 751122.

process-based school of strategic management stresses the primacy of: • Incremental management (over and above bolder, bigger strategies. 5 • Cycles of deliberate and emergent change--as opposed to linear strategy development. 6'7 • Implementation and strategic thinking as inseparable vs discrete phases of strategic analysis and strategic action/ By blurring the boundaries between strategic analysis and action we now see a much more central role for project management in strategy implementation. This is especially the case where we are dealing with major cross-functional projects like TQM and Business Process Re-engineering (BPR). Increasingly, project management is being applied outsides its core domain of improving the "competitive hardware' of businesses to their 'competitive software', 7 and to the process of implementing strategic change, s Project management in the arena of strategy implementation needs therefore to embrace a number of more complex, interdependent and fluid factors in order to be genuinely effective. Managers are, in many cases, only beginning to learn how to process change issues effectively and to turn them into projects. This article addresses how they can actively do this in a systematic way. In this article therefore I outline a number of implementation analysis tools which have been developed in the context of implementing strategic change. These tools provide a coherent and robust framework for dealing with strategy implementation projects. But they can also be applied to the more mundane, but no less important field of operational projects. We illus43

Strategy implementation and project management: T Grundy trate both with reference to examples, for instance from Cellnet (a U K cellular telecommunications company), Dowty Communications and Hewlett Packard (UK). To explore how strategy implementation processes can inform project management (and vice versa) we examine the implementation framework: enriching project management. This is explored as follows: • • • •

Project definition Project diagnosis Project planning and implementation Lessons and conclusion.

The implementation framework: enriching project management Project definition Before we look at an overview of the implementation framework we should first examine the issue of project definition. Not only is this rarely self-evident with operational projects but it is even harder to define for major strategy implementation projects. To begin with, these strategy-related projects may be poorly scoped or time bounded. Paradoxically strategy implementation projects should actually be defined with much more rigour than usually is the case. But at the same time there needs to be some latitude in terms of fluidity of scope and focus within the project definition. Strategic implementation projects need to be refined and steered continually. In effect these projects need to be guided much more sensitively towards their target relative to the more traditional, 'fixed' notion of a project. (Here our mind-set should be moving from the Scud-missile type of project to the Cruise-missile.) Just as strategic management has had to come to terms with this greater fluidity and ambiguity so must project management. Indeed, the notions of "deliberate' and 'emergent' strategy in strategic management can be applied in an extended way to strategy implement a t i o n - a n d to project management. 9 Not only do these terms apply to project strategy but also to project value--which can be partly deliberate, and partly emergent. Figure 1 displays an analytically useful (and manager-friendly) approach to understanding project strategy. 7 Project strategy may start off as deliberate but rapidly move through phases of being emergent, submergent, 'emergency' and possibly even detergent

~ e r g e n t ~

mode. These phases of the strategy (and equally project life-cycle) are characterised thus: • Deliberate strategy: where the project has welldefined end goals and a clear and specific means of achieving these goals. • Emergent strategy: where the project's end goals (and intermediate goals) are necessarily fluid, and also where the means of achieving these goals can change in new and sometimes surprising ways. • Submergent strategy: where the project is losing its way--its original goals now seem distant and unrealisable, and project activities are beginning to fragment. • Emergency strategy: where the project is truly fragmenting into near-random actions and where the project as a whole appears to be overtaken by events. • Detergent strategy: where the project is recognised as off-course and by now being steered back onto its original track, or onto a new track. The 'strategy cycle' is not intended to be a deterministic series of phases destined to always go around clockwise. Indeed, projects may alternate between deliberate/emergent modes as they are guided to (an often moving) target. But more frequently an emergent phase decays into submergent/emergency when the project goes wrong. Even then projects may continue to fly off-course rather than being grasped firmly once again in the 'detergent' mode. Next we take a look at the definition of projects, particularly to map out their interdependencies with other strategy implementation programmes. We should also at this stage be very explicit in defining the strategic objectives of projects. Where these are left fluid, or taken-for-granted, there is carte blanche to organizational confusion. Also, it becomes even harder to perform meaningful financial analysis of the project within a business case--particularly of the anticipated benefits. 8 Figure 2 now explores a decision path for deciding at what level to analyse the project. Where there are many and complex interdependencies between the project and other projects, and where these interdependencies are hard to cost/benefit analyse we should look at the wider set of projects as our desired unit of analysis. This is sometimes called the 'strategic project set'. Projects do often have value in virtue of their membership of a group or set. This is sometimes likened to a collector's set of scarce bone china: even to break the milk jug will have a disproportionate effect on the overall value of the set. Obviously when dealing with

~ '

SIMPLE

.'NO~ ._I I W HATINTER- II 5"6; EN~';~C,[E-S- t co,,p,...I ~kSSESS- I--I 1 ~ ~1-1[ TS [

I BENEFIT/COSTS?I I I UNITIS J n I STRATEGIC NOI.~ PROJECT I SET

Figure 1 The five forms of strategy 44

Figure 2 What is the unit of analysis

Strategy implementation and project management." T Grundy organizational projects, few projects are actively irreplaceable. But quite often the potential value of the set is undermined simply because certain things which you would anticipate as being there are actually absent. For very major strategic implementation programmes there may be so many interdependencies between project clusters that we go up a level more to find the appropriate level at which to appraise the project. In this situation, we may have to evaluate the effect as the business unit strategy itself. 8 One key issue is to what extent it is appropriate to target the economic value of strategy implementation projects. We hold the view that wherever possible, benefits (however soft and less tangible) should be targ e t e d - - a n d preferably in economic (or financial) terms. 7 This does not mean that projects should be exactly evaluated (in financial terms)--but one would want to see potential benefits illustrated financially. Although evaluating at the strategy or programme level may seem to cut across prevailing wisdom in financial theory about incremental cash flow-based project analysis, this apparent conflict can be recognised and addressed. For example, the U K cellular operator Cellnet 7 appraised its Business Process Reengineering programme in the context of: a) linking with other planned strategic change programmes: here Cellnet mapped out the key interdependencies rather than seeing BPR as standalone; b) analysing the 'with investment' case: Cellnet targeted itself at a number of stretching, competitive breakthroughs in terms of service, product time-tomarket cost, and flexibility; c) analysing the 'without investment' case: this consisted of 'more of the past'--Cellnet came to the view that this would inevitably result in competitive erosion. Project definition thus raises even at this early stage the important issue of how to evaluate (and value) projects. Project definition may also lead to unbundling the project activities within a strategic project set into discrete projects. Or it may involve re-bundling interconnected projects together to create a greater

Resolve Channel Conflict

Strategic Turnaround

Closed Management Style

Informal Communication nfe

Untargeted~~ ~ / / Poldlckmg

Important news filtered out

leverage and critical mass, and thus a greater economic value. Project definition also requires a relatively intensive diagnosis process prior to detailed planning and certainly prior to commencing implementation. This diagnosis process assesses the real or underlying nature of the opportunity/threat which the project aims at addressing, as opposed to its symptoms or more superficial definition. This takes us into the core of our implementation framework (Figure 2).

Project diagnosis Project diagnosis can be greatly facilitated by a small number of implementation tools. First, 'root-cause' analysis (sometimes known as 'fishbone analysis') helps managers to understand the underlying cause of a particular problem. (Root cause analysis is a tool imported from the quality management literature.) An example of root cause analysis is shown in Figure 3. This deals with a typical analysis of comm u n i c a t i o n - t h i s is typically a weakness in many organizations and often a prime candidate for a strategic breakthrough project. Notice the complexity of even surface root causes: these would need to be pursued further back to their ultimate cause beneath this still relatively general level of analysis.

Project planning and implementation Further tools for fleshing out project plans include ' H o w - H o w ' analysis and ' F r o m - T o ' analysis. 7

Refocus Distribution Channel Re-train Sales Force

I

Drop Channel "Push" Marketing Strategy Product Parts Simplification

Process Simplification

Process Automation

Reduce Working Capital

Just-in-time Systems

Reduce Manufacturing ~ Sites

Figure 4

H=erarchtal Structure

Symptom =poor Commumcat~on"

Figure 3 Root cause analysis

Product Range ~ Simplification

Reduce Cost Base

Formal Communlcabonng=d

Focused Manufacturing Strategy

How-How analysis: strategy implementation at Skil Corporation (in the USA) 45

Strategy implementation and project management: T Grundy H o w - H o w analysis can be used to work through the detailed implications posed by strategy implementation. F o r instance, in a now famous Harvard Business School case study, Michael Porter describes how a US corporation, Skil, a power tools business, tried to achieve a turnaround (or detergent) strategy. This strategy had two main planks: refocusing distribution channels and reducing Skil's cost base in an attempt to become market leader. Implicitly, Skil management worked out the logic of implementation unconsciously using a " H o w - H o w ' approach. The key ingredients of this implementation strategy can now be depicted through the H o w - H o w methodology (see Figure 4). H o w - H o w can act as a very fruitful brainstorming tool to encourage managers to think through (in a progressive degree of detail) the implications of the strategy. Next, ' F r o m - T o ' analysis is a simplified version of the organizational paradigm, 1'2 or analysing 'how we do things around here'. ' F r o m - T o " is perhaps a more manager-friendly approach as it can be readily tailored to managers' view of their w o r l d - - a n d couched in their terms (and thus not in more academic language). ' F r o m - T o ' (or ' F T ' analysis) focuses on some of the key shifts which one is trying to achieve in progressing a particular strategy implementation project. FT analysis adds value through: • Capturing in a much richer way the broader sometimes less tangible) shifts implied by the ject. • Focusing not merely on concrete organizational puts but also shifts in processes. • Analysing not merely 'where we want to be' but ultaneously 'where we are now'.

(and prooutsim-

FT analysis can also be used to track progress in both implementing strategic change generally, and in progressing specific projects. One way of operationalising this is to score different aspects of the F r o m - T o on a 1-10 and then drawing up a profile of "where we are now' vs future vision. This highlights key gaps (see Figure 5 for an example of organizational structure change).

Implementation forces Implementation forces (IMF) analysis is derived from the original notion of 'force field analysis' from Lewin (1935). Implementation forces analysis can be defined as follows: FROM

Structures* Goals* Behaviours* Cost base*

Responsiveness* * You need to identify shifts relevant to you

Figure 5 46

Using 'From-To' (FT)

;-

TO

T

Enabhng Forces

Constrammg Forces

~°eW~¢ t 'reSentun

ommunlcatlons

B~g differences nnculture

l New MD installed Case's strategic I posrtaon l~m~sunderstood

Figure 6 Dowty case communications

' Tnghter T finanoal / controls

/ Case's rewards I system ~dafferent

Integrabon deferred

force field analysis

Implementation forces analysis is the diagnosis and evaluation of enabling and restraining forces that have an impact on a project. I M F analysis is a tool which brings to the surface the underlying forces which may pull a particular change forward or which may prevent progress, or even move the change backwards. These 'forces' can be separately identified as 'enablers' or 'constraints'. But neither set of forces can be adequately identified without first specifying the objective of the strategy implementation project. Put simply, enablers are the influences on the project which makes it easier to implement, and the constraints are those influences making it more difficult. Turning back now to I M F analysis, the most effective way of evaluating the forces enabling or constraining achievement of the strategic development objective is to do so pictorially. This picture represents the relative strength of each individual change force by drawing an arrowed line whose length is in proportion to that relative strength. A horizontal version of I M F analysis is depicted in Figure 6. Note in this case that, on balance, the enabling forces appear less strong than the constraining forces. This particular analysis is of Dowty Communications strategic plan for the early 1990 s. It shows that although m a n y of the plans, processes and programmes had been put in place, it was nevertheless difficult to envisage implementation being a complete success. Subsequent events suggest that implementation difficulties at Dowry Communications were very severe. As a rule of thumb, one would wish to see the enablers outweighing the constraints by a factor of at least 1.5 to 2 overall. Otherwise we should be concerned and potentially worried that implementation droop will set in. Also, any stoppers really must be addressed, otherwise implementation really won't happen. During (and before) implementation the key implementation forces should be continually monitored to ensure that none threatens to 'go critical' and become a stopper. A number of pitfalls need to be avoided in the use of force field analysis, which include: • Focusing primarily on tangible (as opposed to less tangible) implementation forces. • Missing our major constraints because the team wishes to paint an 'ideal' rather than a realistic picture of the change (we return to these issues in a moment).

Strategy implementation and project management: T Grundy • Failing to identify a 'stopper': that is, a change which has such a powerful impact that it is likely to stop the change in its tracks. 'Stoppers' should be drawn either as a thick black arrow or, alternatively, as an arrow which goes right to the bottom of the implementation forces analysis and 'off the page'. A stopper can be defined as an influence or change which will effectively put an end to the initiative either through direct confrontation or passive resistance. (Many strategy implementation initiatives may fail because of 'limpet m a n a g e m e n t ' - - j u s t as one constraint is loosened another reasserts itself.) Also, there may be cases where a specific enabling force can be made strong and prove decisive in moving the change forward. This kind of force may be described as an 'unblocker' and can be drawn as a very long (or thick) positive line on the I M F picture. There may also be instances where a negative and constraining force can be flipped over to make a positive force, and in so doing transform the picture. For instance, if an influential stakeholder (who is currently negative) can be turned around in favour of the change, this can provide a major driver in the strategic development process. I M F analysis should not be used simply to reflect, but also to re-shape strategy implementation projects. At the diagnosis stage not only should it be used to m a p the existing pattern of implementation forces, but also to identify what pattern of forces is required in order to move the projects forward at an acceptable pace.

Some do's and don 'ts of I M F analysis D o ' s include: • Brainstorm all the key tangible and less tangible forces impacting on the project. • Include key forces drawn from your ' F T ' analysis (see section later), and the stakeholder analysis (see the next section). • Do the initial I M F analysis on an 'as is' b a s i s - show the warts and be prepared to be provocative. • Where a major constraint exists, draw this in as a stopper (that is as a very long downward arrow) to draw attention to its role in braking the change process. • Use the tool throughout the strategy implementation process as the forces impacting on projects will change over time. Don'ts include: • Confuse I M F analysis with simple cost-benefit analysis. Benefits should only be included as a force if they are perceived by and owned by key stakeholders. Often, these benefits are in the eye of the p r o g r a m m e initiator and are neutral in driving the change process forward. • Just use I M F analysis as a tool to describe the current position rather than how the various levels can be re-shaped.

Stakeholder analysis Stakeholder analysis is our next tool for analysing strategy implementation projects. Stakeholder analysis

Coalition building

FOR

/~Wm A~ude

NEUTRAL

~

.

AGAINST

~

[ ~

Leave alone

. a . oo, o,°,a. Distract

over/ coalition building ~ ~ a

/ J | Winning r d

(

orfragment

LOW ~n~4~l s ,sbased~ eaa*erv a ~ s b~P,er~(19e9)

MEDIUM

HIGH

Influence

Figure 7 Stakeholder analysis has entirely reshaped the way in which strategic development has been implemented. L7'~° Stakeholder analysis is the systematic identification of key stakeholders and appraisal of their influence on, and posture towards implementation. It may also involve creating a strategy to reshape the influence of these or new stakeholders. Stakeholder analysis is our second type of organizational radar which helps guide strategy implementation projects. The tool used is as follows: • First, identify who you believe the key stakeholders are at any phase of the process (the 'stakeholder brainstorm'). • Second, evaluate whether these stakeholders have high, medium or low influence on the issue in question. (You need to abstract this from their influence generally in the organization.l°) • Third, evaluate whether at the current time they are for the project, against it, or idling in 'neutral'. The above gives a good 'first cut' of the pattern of stakeholders. The cluster of stakeholders depicted on a stakeholder grid (see Figure 7) should then be assessed to see what the overall picture looks like, particularly: • Is the project an easy bet? • Or is it highlighting a long slog? • Or, finally, does this seem like 'mission impossible'? Following the first-cut analysis managers can then move on to the next phase: • First, can new stakeholders be brought into play to shift the balance or can existing players be withdrawn in some way (or be subtly distracted)? • Second, is it possible to boost the influence of stakeholders who are currently in favour of the change? • Third, is it possible to reduce the influence of antagonistic stakeholders. • Fourth, can coalitions of stakeholders in favour be achieved so as to strengthen their combined influence? • Fifth, can coalitions of stakeholders antagonistic to the project be prevented? • Sixth, can the change itself, in appearance or in substance, be reformulated to diffuse hostility to the project. • Seventh, are there possibilities of 'bringing on board' negative stakeholders by allowing them a role or in incorporating one or more of their prized ideas? 47

Strategy implementation and project management." T Grundy FOR

"~

HIGH

~ MEDIUM Attdude NEUTRAL

©

LOW

AGAINST

EASY LOW

MEDIUM Influence

HIGH

Figure 8 Stakeholder analysis--Dowty communications • Eighth, is the pattern of influence of stakeholders sufficiently hostile for the project to warrant re-definition of the project? An example of stakeholder analysis in use is contained in Figure 8. This is again based on the position as assessed by internal managers of key stakeholders at Dowty Communications. Stakeholder analysis can invite as m a n y questions as it yields answers. These questions can be used by managers to track potential positions of stakeholders (and their agendas) in specific meetings and chance conversations. Often a particular stakeholder may be difficult to position. This may be because his/her agendas might be complex. It is quite c o m m o n to find that it is only one specific blocker which has made a stakeholder into an influential antagonist. Where there are very large numbers of stakeholders at play on a particular issue, this may invite simplification or even dissolution or re-formulation of the project.

Attractiveness and implementation difficulty N o w that we have led you through the three key tools of implementation analysis, it only remains to look at the trade-offs between attractiveness and difficulty. The three implementation tools tell us little, if anything, about whether a particular strategic implementation project is beneficial. The tools are concerned purely with the implementation process. Benefits are only relevant in terms of shaping implementation forces insofar as they are perceived and shared by key stakeholders in the organization. Only if that is the case can they legitimately be introduced as enabling or constraining forces. It is perfectly possible, for instance, to find a strategy implementation project which is attractive and which also has clear benefits, and yet where the implementation difficulty is extremely great. Alternatively, a project may be relatively easily implemented, but not particularly attractive or beneficial. The attractiveness/implementation tool ('AID" grid) enables these trade-offs to be achieved. Pioneered in conjunction with Hewlett Packard, this tool enables a portfolio of possible projects to be prioritised. Figure 9 illustrates a hypothetical case. Project A is seen as being both very attractive and relatively easy to implement. This project is non-contentious and will probably be given the go ahead. Project B is somewhat more difficult. It is only medium-attractive and is difficult. Project B requires a 48

DIFFICULT Implementation difficulty

VERY DIFFICULT

Figure 9 Attractiveness/implementation difficulty (AID) analysis

good deal of testing (a) of the net benefits (is it really that attractive--would it be much harder than we currently think?). Project C is relatively e a s y - - i t will probably end up being zapped unless it can be reformulated to make it both a lot more attractive and easier. Project D presents the biggest dilemma of all. Although it appears to be very attractive it is also very difficult to implement. Yet managers will tend to focus on the attractiveness of the project rather than its actual difficulty. And that can occur even though they have gone through the I M F and stakeholder analysis thoroughly. When piloting the A I D tool at Hewlett Packard this happened on two occasions. Quite separately, two ' D ' type projects were identified and as managers spent more time analysing them, commitment to action levels built up. Although neither of the projects went a h e a d - - i n their existing f o r m - - b o t h myself and the internal facilitator Stuart Reed, had to be relatively strong to convince the teams that some further refinement was necessary. Stuart Reed reflected at the time: I had gone through with them (the managers) both the implementation forces and the stakeholders. Although it did seem to be an attractive project our two organizational tools were telling us 'it is not going to happen'. I think because the managers were going through the analysis tools for the first time (and hadn't actually tried to implement the project) they hadn't quite realised that it really wasn't going to happen.

Scenarios Finally, we turn to the use of scenarios for steering implementation. Scenarios are: • Internally consistent views of the future. • Which focus on discontinuity and change (not on continuity). • Which also involve exploring how the underlying systems in the business environment may generate change. • Views of how the competitive players (existing and new) might behave. Just as 'strategy' is frequently defined as a pattern in a stream of (past and current) decisions, so a 'scenario' is equally a pattern of future events and of the inter-

Strategy implementation and project management." T Grundy

action between customers, competitors and other key players both outside and inside the company. Scenarios are not static and comprehensive views of the future. Scenarios are in many ways more like a video film--they are of necessity selective but contain a dynamic storyline. Scenarios thus contain a series of views (pictures) of the future. The scenario contains a storyline which enables these pictures to hang together. The story can be run (again like a video film) forward or, alternatively, backward. By replaying the story you can work backwards from a particular scenario to see what events might bring about a particular outcome (or 'transitional events'). Scenarios are not therefore an excuse to make broad or vague generalisations--as they are pictures they have a clarity about them which will enable recognition. Managers need to know which world they are entering i n t o - - t h e resolution thus has to be sharp, not fuzzy. In AnsotVs terms, LI they are ways of picking up, amplifying and interpreting weak signals in the environment (external or internal). Project-based scenarios, like all pictures, will thus have a foreground and a background, some features of central interest, and others which are more peripheral. To begin to construct a project-based scenario it is especially fruitful to explore the key assumptions (explicit or implicit) which have been made in believing the project will be a success. This invites the use of the 'Uncertainty/Importance' matrix. Here some of the critical assumptions are brainstormed. They are then positioned in the four quadrants in the current certainty/importance matrix. Then, where they are perceived to be 'less important' managers can test why they think this is the case. Equally, where the assumption(s) is considered to be 'relatively certain', once again this can be challenged. Once this testing has been done, specific assumptions may emerge in the danger-zone or South-East of the grid. These can now be used to generate project-based scenarios where perhaps one or more assumptions are not met to explore what might happen. This analysis can then be used to: • Generate contingency plans. • Identify project 'hot spots' which need to be very closely monitored.

Certain

• Drive risk and (financial) sensitivity analysis--for the business case. • Ultimately, to decide whether or not to go ahead with the project (perhaps it is simply too risky). Figure 10 gives a live example of the uncertainty/importance grid. Here we see how at Cellnet certain assumptions underpinning its major business process re-engineering programme turned out to be considerably more uncertain and important than had previously been recognised. Uncertainty/importance analysis thus provides a most valuable tool for Everyday Scenario Planning (or ESP). This should prove to be an indispensable addition to the project manager's arsenal. In order to prioritise strategic implementation projects it may also be advisable to prioritise their importance and urgency (see Figure 11. (This grid was discovered spontaneously during change management work with ICI Colours during 1990. Interestingly, the Burton Group (Management Page, Financial Times, November 8 1995) also used a similar approach in its massive store restructuring programme. Naturally, the 'importance' and 'urgency' grid invites the question of 'important to whom and why?' (hopefully to the business). It may also result in questioning the degree of perceived urgency. Once again, this grid can be linked in closely to stakeholder analysis. Finally, importance and urgency analysis can be used to map separate projects and their interdependencies pictorially--as a prelude to planning the critical path(s) within a complex strategic change programme.

Integrating the tools It is possible to interrelate the various tools. For instance, stakeholder analysis can be used to generate assumptions about specific stakeholder positions in order to provide input to the uncertainty/importance analysis. Also, IMF (implementation forces analysis) can be used to dig down into the particular agenda of a specific stakeholder--thus exposing factors enabling vs constraining support for a project. Managers will no doubt find new ways of spontaneously combining and applying the tools. Figure 12 now shows how the various tools can be integrated. Although it is not always necessary to use them all (and certainly not all at once), it is impossible to have available the whole set for use at different phases of any complex, strategy implementation project.

\ % % 4

Least important

ID

I

HIGH

Very important

x%

"5

IMPORTANCE

Uncertain LOW

Figure 10 Uncertainty/importance of assumptions--cellnet BPR project

LOW

URGENCY

HIGH

Figure 11 Prioritisations--tensions 49

Strategy implementation and project management." T Grundy SCENARIOS

- Why Is It a problem/opportunity ROOTCAUSEFISHBONE I

- Key process PROJECT MANAGEMENT E

I [

HOW - How - Evolve strategy

~

PUSHv PULL STRATEGY - Evolvestrategy

AID-ATFRACTIVEN IMPLEMENTATION DIFFICULTY -

Overall

--TO - Express strategy

STAKEHOLDER ANALYSIS - Ascertain&

evaluatton

and

create VlSrOn

F LD - Overalldtfficulty & reshape plans

major organic, business development, acquisitions, business process re-engineering, structure and culture change, quality management and continuous improvement projects. These techniques are particularly well suited to cross-functional projects. It is hoped that writers in mainstream project management can carry these techniques forward--and also to develop these further. Strategic management and project management have very much a common enemy overcoming the constraints posed by strategy implementation.

reshape agendas

References Figure 12 T o o l s ~ h a t to use and when

1. Grundy, A. N., Implementing Strategw Change. Kogan Page,

1993.

/ Figure 13

PRIES~~

Strategy and projects

the hierarchy

Lessons and conclusion Strategy implementation projects form an increasingly important and high profile application of project management. McElroy ~z has previously highlighted a hierarchical model of aims-strategy-programmes projects (Figure 13). What we have contributed to is the evolution of strategic thinking at both the project level and at the strategic project-set level. In due course a number of strategic project-sets become these ~programmes'. At this level major strategic projects often call for a somewhat different mix of tools to traditional project management. These tools can also be of major benefit to more tactical and everyday projects. We have therefore brought together a number of tools and techniques from strategic management, value management and from organizational change to complement existing project management techniques. This toolkit can be applied to a variety of projects including

50

2. Johnson and Scholes, Exploring Corporate Strategy. Prentice Hall, 1989. 3. Kuhn, T. S, The Structure of Scwntil~e Revolutmns. Chicago University Press, Chicago, 1962. 4. Turner, J R., The Handbook of Proleet-Ba,~ed Management. McGraw Hdl, 1993. 5. Quinn, J. B., Strategies Jor Change Logwal hwrementalism. Richard D Irwin, Illinois 6. Mmtzberg, H. and Westley, F. Cycles of orgamzational change. Strategic Management Journal 13, 1992, 39 59. 7 Grundy, A. N , Breakthrough Strategw~ /or Growth. Pitman Publishing, 1995. 8 Grundy, A. N., Corporate Strategy and Financial Decisions. Kogan Page, 1992. 9. Mintzberg, H., The Rise attd Fall o/ Strategic Planning. Prentice Hall, 1994. 10. Piercey, N Diagnosing and solving Implementation problems m strategic planning. Journal o.["General Management 15(1), 1989 11. Ansoff, H. I. Managing Strategic Surprise by Response to Weak Signals. Cah/'ornia Management Review XVIII(2), 1975, 21 331. 12 McElroy, W., Strategic Change Through Project Management. APM, 1995. Dr TotO' Grundy ts Senior Lecturer m Strategic Management at Crw~eld School o/ Management, and Director. Cambridge Corporate Development. He has ii'orked with BP, 1CI and KPMG, and ts author oJ several books on strategy, finance and change management, mchuhng Breakthrough Strategies [or Growth (Pitman, 1995).