Delivering Business Value From It Projects (Financial Times Itb)

Delivering Business Value from IT Projects FT Prentice Hall FINANCIAL TIMES In an increasingly competitive world, we...

Author: Colin Ashurst | Peter Murray

46 downloads 783 Views 500KB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Delivering Business Value from IT Projects

FT Prentice Hall FINANCIAL TIMES

In an increasingly competitive world, we believe it’s quality of thinking that will give you the edge – an idea that opens new doors, a technique that solves a problem, or an insight that simply makes sense of it all. The more you know, the smarter and faster you can go. That’s why we work with the best minds in business and finance to bring cutting-edge thinking and best learning practice to a global market. Under a range of leading imprints, including Financial Times Prentice Hall, we create world-class print publications and electronic products bringing our readers knowledge, skills and understanding which can be applied whether studying or at work. To find out more about our business publications, or tell us about the books you’d like to find, you can visit us at www.business-minds.com For other Pearson Education publications, visit www.pearsoned-ema.com

Delivering Business Value from IT Projects COLIN ASHURST PETER MURRAY

FT Prentice Hall FINANCIAL TIMES

IT B RIEFINGS ’ S ERIES EDITOR : S EBASTIAN N OKES

An imprint of Pearson Education London ■ New York ■ Toronto ■ Sydney ■ Tokyo ■ Singapore ■ Hong Kong New Delhi ■ Madrid ■ Paris ■ Amsterdam ■ Munich ■ Milan ■ Stockholm

■

Cape Town

PEARSON EDUCATION LIMITED Head Office: Edinburgh Gate Harlow CM20 2JE Tel: +44 (0)1279 623623 Fax: +44 (0)1279 431059 London Office: 128 Long Acre London WC2E 9AN Tel: +44 (0)20 7447 2000 Fax: +44 (0)20 7447 2170 Website: www.briefingzone.com

First published in Great Britain in 2003 © Pearson Education Limited 2003 The right of Colin Ashurst and Peter Murray to be identified as authors of this work has been asserted by them in accordance with the Copyright, Designs and Patents Act 1988. ISBN 0 273 65984 7 British Library Cataloguing in Publication Data A CIP catalogue record for this book can be obtained from the British Library. All rights reserved; no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without either the prior written permission of the Publishers or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1P 0LP. This book may not be lent, resold, hired out or otherwise disposed of by way of trade in any form of binding or cover other than that in which it is published, without the prior consent of the Publishers. 10 9 8 7 6 5 4 3 2 1 Typeset by Monolith – www.monolith.uk.com Printed and bound in Great Britain by Ashford Colour Press Ltd, Gosport, Hants. The Publishers’ policy is to use paper manufactured from sustainable forests.

About the series editor

Sebastian Nokes is Series Editor for the IT Management series within the Financial Times Prentice Hall Executive Briefings and has written and co-written several works on the subject. These Briefings are designed to provide concise, focused knowledge, concerning critical IT issues facing managers today. They deliver the information and insight needed to evaluate situations and make informed decisions. Sebastian is a partner at Kimbell Evaluation Ltd, a leading consulting and analytical firm. Kimbell Evaluation was co-founded by Sebastian and helps clients measure and manage value added by information technology, both in stable organizations and in business or divisional turnarounds. His consulting clients include international financial institutions and commercial corporations. Sebastian began his career in the IT and investment banking industries, and has been an employee of Credit Suisse First Boston and IBM. He was educated at London University, served in the 2nd KEO Goorkhas, and holds finance and engineering qualifications. Sebastian may be contacted via [email protected]

v

About the authors

Colin Ashurst qualified as a chartered accountant in 1983 and gained wide experience of IT in major organizations (M&S, B&Q, BP, Sun Alliance, etc.) working with Deloitte Haskins & Sells in London. He then spent six years at a major UK retailer in a variety of IT management roles. After a short period as IT Strategy and Planning Manager at telecommunications company Ionica he moved to Microsoft where as a senior strategy consultant he is in a small UK team spearheading the development of strategy consulting services for the global Microsoft Services Organization. Along the way Colin has gained an MBA. His IT experience covers business analysis, strategy & planning, systems development, project and programme management and service/operations management. He represents Microsoft in the Cranfield Information Systems Research Centre. Colin may be contacted at: E-mail: [email protected] Peter Murray has 28 years management experience and six years academic experience researching management topics. He is currently an independent consultant and a visiting lecturer at Cranfield School of Management specializing in information management, knowledge management, IS strategy and realizing benefits from IT investments. Peter worked for Tube Investments in production control, IT and supplies management. Subsequently he worked for ICI, later Zeneca Pharmaceuticals, as an IS executive initially in manufacturing and quality control then later in international R&D. His last two years at Zeneca were spent developing an IS Vision and Strategy for the global business. He has led many large projects across all business functions and acted as consultant to numerous UK and international organizations. Peter has an honours degree in Physics from Birmingham University and several management qualifications. Peter may be contacted at: [email protected] [email protected]

vii

Contents

List of abbreviations 1

Introduction

1

The issues of getting value from investments A context for deriving business value from IT investments The value route map

3 4 7

PART ONE: ESTABLISHING FOUNDATIONS FOR SUCCESS – KEY CONCEPTS 2

3

4

xii

Management issues in delivering business value from IT

11

13

Current constraints to realizing business benefits Where do the benefits come from? Outcomes vs. benefits Maintaining the link between business value and IT investment The investment portfolio – a proven IS planning technique

15 16 17 19 21

A learning perspective on value delivery

25

The need for a learning paradigm Levels of knowledge Types of learning Succeeding through people Technology – enabling success

28 28 37 39 47

Summary and action plan

51

Key issues for business managers Key issues for IT managers Dos and don’ts Action plan

53 53 54 55

ix

Contents

PART TWO: BEING SUCCESSFUL – GETTING THE BASICS RIGHT 5

6

7

8

x

57

Benefits management

59

Background to the benefits management process The BM process Steps for identifying and structuring benefits Driver analysis The benefits dependency network Stakeholder management Measurement of business value Conclusions

61 62 64 64 68 71 74 85

Project management for business value

87

The team Project start-up Project process Risk management Other aspects of project management Project management summary

90 95 96 104 106 110

Programme management

111

Programme planning Benefits management Programme team and roles Progress tracking and performance management Programme management summary

113 114 115 116 121


123

Key issues for business managers Key issues for IT managers Dos and don’ts Action plan

125 125 126 126

Contents

PART THREE: BUILDING ON SUCCESS 9

129

Innovation and continuous improvement

131

The story so far – key learning points Implementing the framework across the organization Looking ahead Final thoughts

133 134 135 136

Appendices

137

1 2

139 143

Exploring the investment portfolio Resources

References and further reading

145

xi

Abbreviations

xii

b2c

business to consumer

BM

benefits management

CEO

chief executive officer

CFO

chief financial officer

CIO

chief information officer

COO

chief operations officer

CRM

customer relationship management

DCF

discounted cash flow

DSDM

Dynamic Systems Development Method

ERP

enterprise resource planning

HR

human resources

IM

Instant Messaging

IS

information systems

IT

information technology

KM

knowledge management

MISP

Managing Information Systems Projects

MSF

Microsoft Solutions Framework

NPV

net present value

OGC

Office of Government Commerce

PMO

programme management office

R&D

research and development

TQM

total quality management

UAT

user acceptance testing

1 Introduction

■

The issues of getting value from investments

■

A context for deriving business value from IT investments

■

The value route map

3 4

7

1

Introduction

THE ISSUES OF GETTING VALUE FROM INVESTMENTS The potential for IT to transform the performance of businesses and industries by creating capabilities to do new things, to improve existing ways of working and to eliminate costly repetitious work is huge. IT can also make work more personally rewarding and fun. The pace of change driven by the Internet and the rapid innovation in computer and communications technology will only continue to accelerate. However, there still remains a huge gap to cross between the opportunity to deliver business value from IT investments and the reality of the benefits that are actually delivered. Repeatedly studies into the success of projects show that the failure rate is high and studies into the business value derived from expenditure on IT show little or no relationship between the level of expenditure and business performance. To quote from the Benefits Management: Best Practice Guidelines February 2000 from the IS Research Centre at Cranfield School of Management: Many inquiries have been made into what benefits organisations are getting from IT and a rounded average of these comes up with a ‘statistic’ that in 60–80% of IT projects no benefit was delivered. This may raise questions as to whether the desired benefits were adequately stated and understood by all at the beginning, but even in a recent KPMG survey where participants stated that an IT project had been ‘successful’ it turned out that they usually meant delivered to time and cost – when questioned further about benefits they had derived the rate dropped to the band above. Regardless of the precise percentages the key point is that IT projects are about delivering value to the business and not enough of them do. It is increasingly being recognized that the role of the IS/IT function is to enable the business to succeed in providing benefits: that is value to stakeholders – not simply providing technologybased solutions and services. This executive briefing provides the concepts and practical tools to make this goal a reality. It draws upon relevant research up to this year and on the experience of extensive use of the tools and techniques described in the briefing. Over 200 organizations have now deployed these tools in one form or another and some of them have made their use mandatory. By using the approaches described senior business and IS/IT managers involved with projects or programmes enabled by IT will be able to actually realize measurable business value. The briefing focuses on the big picture of IS/IT and the business working together because this is where the bulk of the problems occur, rather than on the specifics of software development or project management.

3


The perspective adopted is the business executive view. It is not another project management methodology – instead it provides a business benefits-oriented framework within which projects can be initiated and managed. It provides guidance on: ■

the sources and identification of business value;

■

the senior management role in IS/IT investments;

■

how to tell if things are going well – and typical danger signs;

■

how to manage a programme or project for success in business terms.

The briefing summarizes key lessons from a combined experience of over 50 years working and researching in a variety of roles with the aim of delivering business benefits from IT. The guidance offered is not technology specific and applies to virtually all organizations and projects regardless of size or technology. Although optimum results across an organization will require some changes to existing processes for systems development and project management, the approach set out in this executive briefing is a framework that can be used to enhance existing methodologies and does not require starting from scratch.

A CONTEXT FOR DERIVING BUSINESS VALUE FROM IT INVESTMENTS Investment in IT continues to run at high levels and many CEOs and CFOs have worries about it (‘For the cost of giving all our sales force laptops we could hire another two sales people’). Their concern, usually concentrated first and foremost on the cost, is arguably misplaced since cost itself is only one half of the value-formoney equation. If the value derived from a given IT investment is sufficiently high then a high investment cost may be justified. In the laptop case cited a mental tradeoff is being made between the extra revenue two sales people would probably generate (most sales managers could estimate this quite well) versus the cost of technology where no one can apparently say with certainty what value will result. In comparing the two options a skewed comparison is being made – the value of revenue from two sales people compared with the cost of acquiring technology. A sounder comparison would be return on investment from the extra staff with the return on investment from the IT expenditure. Here, however, is the rub – just what is the value derived from IT? Historically the answer was easy since for over a decade the first application of IT was automation of repetitive tasks, i.e. replacing the cost of people with the cost of a computer – but without necessarily improving the way the task was done. Now, however, examples exist where IS/IT is used to improve effectiveness, competitiveness and other areas of activity where

4

Introduction

improvement is hard to measure or even assess (e.g. just what is the business value of improved communications through e-mail and intranets?). Occasionally claims are made that IT creates completely new business models (e.g. the e-phenomenon). Some executives have become resigned to the situation that, like the telephone, IT has become part of the cost of doing business. Still, the costs appear to be increasing way above any accepted norms of business-as-usual. Even executives who don’t see IT as a way of improving business performance, who perhaps regard it as a necessary evil, seem nevertheless to be reluctant to take the decision to cease expenditure on IT. Most executives, as surveys in the UK and USA repeatedly show, are apparently convinced that IT can significantly improve business performance. The conundrum is not why IT costs continue to rise, but, given their belief in the potential benefits from IT, why, as the same surveys also show, executives feel they don’t get value for money from IT investments. The issue at the heart of the problem is all about the value from IT. Apart from straightforward cost savings it is not always easy to identify, realize and then measure the business value of an IT investment. And because of that difficulty there is a temptation to try and treat all IT projects as though they were cost-saving initiatives with sanctioning criteria heavily emphasizing the financial return. This is often masked as ‘tangible’ versus ‘intangible’ benefits with a rule that all benefits must be tangible, whereas it really means financial versus non-financial benefits. (See in Chapter 5 a discussion of this unfortunate practice which precludes benefits that may be quite important such as customer service or improved health care – difficult entities to assess by financial criteria alone.) The emphasis on cost rather than value often comes to a head at the annual budget setting event: the IT spends requested are totalled and first of all compared with the previous year’s IT total spend. On the one hand the sheer size of the requested spend causes the CEO/CFO to appeal/demand that it be reduced while on the other individual directors and general managers argue strongly for a larger slice of the IT cake. Experience of such events shows that they never seem to leave anyone pleased even when budget figures have been ‘agreed’. Often all that has been decided is how much will be spent on IT, sometimes not even what it will be spent on, let alone what business value will result from the investments. Some CEOs and CIOs sense the need to put the expenditure into better context and a frequent question that we get asked is: ‘In our industry what is the typical spend on IT?’ They are mainly seeking reassurance that they are not out of line and that in industry terms their sanctioned spend is defensible. But the approach is still flawed in that it starts with the total IT cost. It is irrelevant to add up the cost of IT in an organization, since it tells you so little and offers only a single control device that lacks any sensitivity towards business value. This briefing asserts unequivocally that the context for deciding upon IT expenditure must begin on the value side of the equation and the cost justified or

5


not depending on the normal rules of business investment – i.e. the value returned. Of course if the whole programme subsequently adds up to a sum that cannot be afforded then something must give. But that is a case for prioritizing according to the amount and nature of benefit delivered, not a case for, say, arbitrarily reducing all departments’ IT budgets by a percentage that will bring the total back into line. Before leaving the negative side of this examination there is one further point to be made against the totalling of IT costs to be used as a control and it is a most important one – it inhibits and prevents managers from managing their units and departments. This is because the technology is never used entirely on its own, but always in conjunction with people and other equipment. If expenditure is running too high it is reasonable to ask a manager to make a percentage cost reduction in the running of the department/unit, but only at that level. To focus arbitrarily on one element of his/her cost make-up is wrong. In taking, say, 5 per cent out of the cost of running a unit a manager may decide to spend nothing on IT – or to double it in order to save costs in the whole process. The choice is surely theirs; all that they must ensure is that the required level of cost reduction is achieved within their domain of control. Value is always contextualized and should be assessed first in terms of that context and then by the cost of achieving it. Investments usually occur in several different functions in an organization, each in a differing context, so the assessment of an IT proposal begins with the value introduced into the relevant unit, process or activity set in that part of the business. Successful IT enables an activity to be improved in some way, normally cost, speed or quality. The value is derived from the context of the process/activity it helps to improve. If, for instance, an IT investment will reduce time-to-market for new products or services by, say, three months then the senior marketing executives will have the best view on value of the reduction and they are best positioned to say whether the cost of the investment is worth it, however high it is. This is not an argument for IT costs having reduced control mechanisms; in fact it is the opposite since it proposes a value filter on each investment with the operating criterion that no money will be spent at all unless the benefits resulting are understood and agreed by the relevant business managers. This briefing provides an examination of the generation of business value for and within an organization and a value route map is offered. There are a number of start points to the examination – entry points as it were into the route map – all of which allow executives to identify, plan and commission investments that result in meaningful improvements to business performance. Value generation is concerned initially with what needs to be done, not how. Technology is only ever a ‘how’ but such a potent one that it can distort assessment to the point where initiatives are undertaken not because they should be, but because the technology allows them (many intranets and desk-top

6

Introduction

publishing initiatives fall into this class). The implementation of the technology is nevertheless important since if done badly, little or no benefits will appear. The traditional mechanism of implementing IT is the project and Chapter 6 addresses project management for business value. As stated earlier surveys and research collectively point up that the biggest risk in IT projects is not that they won’t work or are insecure (the traditional areas for risk assessment) but that they don’t deliver the expected benefits. IS functions invest heavily in project work, project teams and project methodologies so that projects get done in the right way, but from a business value perspective the issue is more of whether the right projects are being done in the first place. From what has been said so far the ‘right’ projects are clearly those that successfully deliver the correct benefits or business value, and this raises two points. One is identifying the right business value improvements needed for the organization’s current situation, and the other concerns resourcing and prioritizing. Given that resources are not unlimited what priorities should be set across the whole investment programme? Additionally, as can happen in large organizations where large projects are usually considered only in their own terms, there is risk of duplication and overlap of initiatives. This introduces the need for portfolio management – the high-level management of the total set of investments so that they complement each other in a resource-efficient way.

THE VALUE ROUTE MAP The value route map charts the potential opportunities for value-adding enabled by IT and follows a top-down approach starting with the widest context – the environment of the industry of which the organization is a part. Value is added to a process/activity usually by improving the cost, speed or quality of the process. In terms of what value improvements might be obtained, these tend to fall into three classes: doing new things, doing things better, or eliminating the doing of certain things. The levels are: ■

Level 1 – industry, its current drivers, threats, problems and opportunities – shared more or less by all players in it.

■

Level 2 – organization, its own internal and external drivers, its current competitive position, product leadership, operational excellence, its capabilities and competences. In large organizations this may apply at the level of major business units.

■

Level 3 – process, the performance of the primary processes (R&D, manufacturing, sales, distribution, etc.) and the secondary support processes (accounts, HR, IS, etc.).

7


■

Level 4 – activity, general activities that take their characteristics from the way the organization chooses to do its business.

Seeking value at each of these levels involves answering the same questions: Where is value currently generated? Do we have to do anything to maintain the value creation? Can we increase the value generation? Can we remove or reduce non-value adding activity? Can we identify and realize new sources of value? There is a difficulty in that most of us when asked what we are doing answer by describing how we are doing it. A consultant visited a company that had laboratories where their discoveries were developed until they were marketable whereupon they sought buyers for them. Asked to describe what they were doing the consultant was shown the research laboratory where the original ideas were conceived and tested, then the two development laboratories named ‘Heavy Development’ and ‘Light Development’ – products were largely allocated according to the size of the engineering work needed during development. This sounds like a ‘what’ but, as he pointed out, what they did was to market innovation – the threelaboratory arrangement was how they had chosen to implement their process. The problem this throws up is that it is much harder to change or even recognize anything fundamental if the thinking is only taking place around the ‘how’. Until challenged by the consultant the innovation organization, if asked to improve, would almost certainly have sought improvements within the processes and activities of the three-laboratory set-up. This briefing concentrates mostly on value at the organizational level and below since the approaches and tools described were developed at those levels. However, the use of IS/IT at Level 1, the industry level, is worth considering, and especially so if the industrial environment is changing (e.g. through new competition, governmental action or technology such as e-) because an organization that is first to solve an industry issue may well have a strategic advantage. For instance, recent research by Breu and Hemingway at Cranfield School of Management in conjunction with Microsoft has shown that there is a correlation between IT and workforce agility. The latter is a major consideration in times of change, mergers, take-overs, etc. Porter’s five-force model still seems to stand the test of time for analysis of an industry position. Level 1 perspectives, with their emphasis on the environment of the organization, also usefully reassert that much value is derived by improving the channels to the outside world (customers, suppliers, regulators, etc.). E-initiatives are currently out of favour in general but if e- is to contribute it is in creating channels or improving existing ones, so IS/IT has a distinct business value role here. Only when the potential value-increasing opportunities are mapped out does the issue of how they might be delivered get addressed. Technology is an enabler – a ‘how’ – but occasionally a technological development occurs which throws up new

8

Introduction

opportunities. Nevertheless those opportunities still have to be contextualized to the organization’s situation, drivers, strategies and plans. The benefits approach to technological opportunities is fully developed in Part 2. Part 1 establishes a formal framework for identifying and structuring business value in an organization’s own particular situation, and develops a case for a greater emphasis on a learning approach towards project activity.

9

Part one Establishing foundations for success – key concepts

■

2

Management issues in delivering business value from IT 13

■

3


■

4


25

51

This part covers key concepts that provide the foundations for the practical guidance that follows. The goal here is to build up a usable framework of understanding and a set of tools for identifying, structuring and delivering business value. The chapters in this part address two key topics that lie outside conventional project methodologies: the involvement of senior business managers and the place of learning in delivering successful investments. A summary chapter and suggested action plan concludes the part.

11

2 Management issues in delivering business value from IT

■

Current constraints to realizing business benefits

■

Where do the benefits come from?

■

Outcomes vs. benefits

■

Maintaining the link between business value and IT investment 19

■

The investment portfolio – a proven IS planning technique 21

15

16

17

13

Management issues

This chapter exposes some of the historical constraints that currently operate to hinder successful investment and then goes on to describe proven frameworks and management tools to address the problems and opportunities.

CURRENT CONSTRAINTS TO REALIZING BUSINESS BENEFITS Analysis of the way IT has been used to improve business performance in the past 30 years shows some recurring patterns of approach – unfortunately most of them turn out to be obstacles to successful management of the investments. There seem to be three main mindset constraints that converge strongly when executives approach the issue of managing IT investments: ■

The management of information technology is about automating things and as such is a technical issue, not the province of business managers.

■

The cost of building and implementing an IT system should be justified by a significant direct effect on the financial bottom line.

■

Functionality from IT is a benefit in itself.

They are all largely historical and erroneous and will take some time to dislodge. However, in fairness to busy business managers, the IT supply industry strongly sells its wares using variations of the above. The idea that IT is only about automating is a historical hangover from the late 1960s and early 1970s when various repetitive tasks (e.g. wages calculations) were replaced by computer systems that mimicked the task (albeit faster and more accurately) but did not inherently improve it. The typical outcome of such automation was that clerical staff could be shed as a result. Since the justification was a saving on the cost of clerical effort, that led to the ‘direct effect on the bottom line’ criterion for justifying IT systems. While financial benefits are important – and if they are there to get then they should be taken – focusing purely on cost savings can obscure other kinds of benefits, e.g. timeliness, responsiveness, quality, effectiveness. The legacy of this ‘perspective constraint’ is the expenditure proposal or expenditure justification procedure. These are frequently elaborate, sometimes byzantine, hurdles normally based solely on financial criteria and aimed at preventing the parting with money on IT if it will not give a proper and fairly immediate return on investment. A survey done on this topic by Cranfield School of Management shows that in the face of these procedures the traditional response is to overexaggerate the financial benefits in order to get expenditure approval. Forty-five per cent of those responding in the Cranfield survey admitted that they

15

Part 1 Establishing foundations for success

did this, and since only one in five said that they checked whether they had got the desired benefits, that situation looks set to continue. There are numerous examples of the same software package being implemented in different organizations with widely different results so the idea that software functionality equals business benefit should not have credence, but for the present it persists.

WHERE DO THE BENEFITS COME FROM? Technology is only ever an enabler. There are no direct benefits from information technology – an IT system enables or creates a capability to realize benefits. This is not really a surprising statement and has been articulated in other ways before, but its implications do not seem to have been fully incorporated into management thinking yet. The relationship between technology investments and derived benefits is this: benefits only come from a new, improved way of working. The role of the investments in IT systems is to enable this new way of working. To put it in change management terms: Performance only improves when people start doing things differently. Once stated it is obvious but so many large-scale failures (the ones that get exposure tend to be in the public sector, e.g. the London Ambulance Service, Wessex Health Authority) show that fundamentally no account was taken of the impact of the technology on the ways of working. The paradigm shift required is that benefits are always derived by and through people and the way they work. The word ‘benefit’ is defined in the dictionary as: ‘An advantage on behalf of an individual or group of individuals’. This means that for a benefit to be realized in an organization, some person or persons must perceive and agree that they now have advantages over the previous way of working. Such a person will henceforth be referred to as a stakeholder and it follows that beneficial systems will have been designed from the stakeholders’ views or visions of what constitutes a benefit. Thus to ensure delivery of benefits, what is needed, in addition to soundly implemented technology, is an appreciation of the capability that is being delivered/enabled, how it can be used to introduce better ways of working; identification of all those who will benefit (or otherwise), and change management processes to put the new way of working into practice and subsequently drive out the benefits. This perspective raises the importance of training and education. The training element of IT projects is generally served badly, both in the funding to do it and in managers’ reluctance to let people have the time to be trained. Even when it is done ‘adequately’ the focus is invariably on the technology and hardly ever

16

Management issues

addresses education in the use and exploitation of the new system on behalf of the business’s objectives. That this is common is really surprising since the investment in training and education is the last hurdle between all the prior investment in the technology and the realization of business benefits. If staff are inadequately educated and trained in the new ways of working performance is unlikely to improve irrespective of the size of the IT investment.

OUTCOMES VS. BENEFITS Frequently the terms ‘benefits’ and ‘outcomes’ are confused with each other. The outcome is a capability resulting from the introduction of an IT-enabled system; the benefits are what the business subsequently derives when/if managers exploit the new capability. An example will illustrate the difference: many expenditure proposals claim a headcount reduction as the business benefit. Headcount reduction as such is an outcome; the benefits depend on what managers do with the reduction. For example, if personnel leave the organization then the benefit would be a cost-saving in the salary budget; if a manager saves a number of backoffice administrative personnel and moves them into a front-office customer-facing role then the benefit should be improved customer service at no extra employee cost; if the manager replaces, say, half of the number saved with personnel of a different ability or calibre then the benefit is the ability to tackle the tasks that the previous staff could not handle plus some salary savings, and so on. What should be clear from this example is that it is only with the conscious intervention of managers that an outcome becomes a business benefit. IT only enables an outcome – it is managers who choose how to turn that outcome into a benefit. One of the weakest but frequently unchallenged benefit cases is the saving of staff time. If a group of workers can, as a result of introducing IT, do the work in less time then the benefit is actually what is done with that time, since clearly if managers do not make moves to utilize the time available then no benefit will materialize. Saving everyone in the organization half an hour a week might mean under flexitime arrangements they just go home earlier on a Friday – or more likely the time taken to do the work will expand to fill the time available. Without a management process to drive out benefits they don’t appear. Figure 2.1, which shows results of deploying a management process to drive out benefits, was based on work done by one of the authors at Astra Zeneca around

17


the time of introducing benefits management (a tried and tested management process for managing a project with a focus on delivering measurable business benefits). Approximately 60–70 per cent more benefits were derived when using a benefits management process compared to where there was no process – when cost and benefit more or less balanced out. As shown the benefits do not come free, but the extra cost is not a project cost, it is business managers’ quality time. However, notwithstanding that management time is a high cost, experience has shown that meaningful involvement of business managers not only ensures that benefits arrive but also that the IT costs of a system can be reduced. This is because managers can: ■

keep the business focus predominant in the project work;

■

avoid inclusion of nice-to-have functionality (i.e. seriously apply the 80/20 rule, i.e. 80 per cent of the benefits can be realized with the first 20 per cent of the effort);

■

stop projects that have little or no business benefit (this is perhaps the best use of all of an executive’s time).

A significant part of this briefing is about the process that will facilitate managers to actually obtain the potential benefits that can arise from IT investments. It covers the necessary concepts, frameworks, tools and techniques as well as stakeholder management and the measurement of benefits. Fig. 2.1

Benefits management – the value of the process

Management cost

Cost

Benefit

Without benefits management process

18

Possibility of lower IT costs

Cost

Benefit

With benefits management process

Management issues

MAINTAINING THE LINK BETWEEN BUSINESS VALUE AND IT INVESTMENT An IT strategy is a supply-side necessity, covering how the technologies will be planned, resourced, managed and deployed. It needs to be linked to, and driven by, a demand-side information systems (IS) strategy that reflects and embodies the business plans and strategies. Put basically: IT is the ‘how’ and IS is the ‘what’. The business plans and strategies provide the navigation, i.e. the ‘where’ and the ‘why’. Laying out the relationship as in Figure 2.2 exposes two other important considerations: value for money from IT, and ownership/roles in IS/IT investments – the two are actually closely related. In pursuit of value-for-money it needs to be recognized that the value is added in the Business–IS area (i.e. information systems used by the business for its goals, etc.) and the cost is incurred in the IS–IT area. In trying to achieve value-for-money many organizations have concentrated (mainly at the behest of the budgetary control system) almost solely on the money side. As mentioned in Chapter 1 the cost of IT is often an ongoing and irritating debate with budgets set by reference to last year’s spend only. This is also reflected in the various expenditure proposal procedures that exist which try to force the justification for IT cost into a direct effect on the financial bottom line. Since this can never be the case from the earlier arguments, IT managers frequently overstate the benefits in order to get over ‘the justification hurdle’. In this piece of legerdemain they are almost always supported by the business executive who wants the new system – a conspiracy of lies is operating. This is nothing more than the clash between a financial control procedure focusing on the cost of the proposed investment, and a grouping of business and technical managers focused on the value side of the equation. The way out of the conundrum is a better articulation of the benefits in business value terms thereby facilitating an informed decision to be made whether the investment costs are worth sustaining. Consideration of ownership in the Business–IS–IT schema shows why most of the problems described so far continue to persist. In Figure 2.2 clearly the senior management own the business plans and strategies, and IT managers own the IT supply strategy. Ownership of IS is problematic. Reflection will lead to the conclusion that it belongs to the business – assisted by their IT management colleagues. In practice it is more muddled. First, many business managers don’t recognize the distinction between IS and IT so feel that the ownership belongs to the IT managers (why have a dog and bark yourself?). Second, any joint ownership of IS is always going to be harder to manage effectively. So, like many ‘partnerships’, often it just doesn’t get done. When an ‘IS vacuum’ occurs the typical response to filling it is for the IT function to second-guess the ‘what’ because they need it in order to get on and deliver systems and services. They will nearly always fail since

19


they generally don’t have a seat at the business table and therefore are unclear about the ‘where’ and the ‘why’. Also by training and nature they want to avoid ambiguity and unclearness (systems ultimately have to work precisely at every level) whereas business managers are used to dealing with fuzziness as a matter of course. There will be a tendency for technical managers to make simplifying assumptions to introduce more certainty into the system’s requirements. Fig. 2.2

The relationship between business, IS and IT strategies

IS/IT industry, business and organizational impact and potential

■ ■ ■

BUSINESS STRATEGY Business decisions Objectives and direction Change

Supports business

■ ■ ■

■ ■ ■

Direction for business

IS STRATEGY Business based Demand orientated Application focused

Infrastructure and services

Where is the business going and why

What is required

Needs and priorities

IT STRATEGY Activity based Supply orientated Technology focused

How it can be delivered

Source: Ward and Peppard, 2002

A subsidiary point, which also relates to ownership but more to mutual understanding, is that of language. Many business managers, in order to obtain the benefits from IT that they are convinced exist, feel they must learn the specialist language of IT (they are in effect trying to go straight from business strategy to IT strategy missing out IS). This leads to time-wasting debates on technical subjects such as client-server architectures, etc. by executives who don’t really know what is being discussed and who shouldn’t have to. The language of IS plans is business English, which all should understand. Thus, for example, with no reference to technologies, an IS requirement might be: ‘A system that tracks and analyses the price movements of ten key commodities in all of the major European markets’. The benefits management approach concentrates on the added-value business benefits side, ensuring first that the benefits are directed to the business needs and thereby also enhancing the chances of true business ownership of the project and subsequent system. Once a project ‘descends’ into the IT-only area it becomes

20

Management issues

technology-led, then its success criteria and ownership are no longer in accord with the business managers’ aims. The tools and techniques in this briefing are all targeted at giving business managers the necessary handles to keep the project as a business project – enabled by IT. It is worth noting that Figure 2.2 is not only a ‘top-down’ approach. Increasingly opportunities can surface from the IT domain, and significant exploitation of IS may cause executives to want to modify the next steps in their business development plans.

THE INVESTMENT PORTFOLIO – A PROVEN IS PLANNING TECHNIQUE A very powerful benefits-oriented technique for successfully describing IS plans that business managers can relate to and will be comfortable to own is the investment portfolio. This describes the investments in applications and services (those already in place, those planned and future possible applications) not in terms of how they are supplied but in terms of their role and contribution to business performance. Basically there are four classes of contribution to business performance (see Figure 2.3). Key operational systems are those where the IS is so embedded and necessary that if the system failed the organization would suffer extensively, e.g. an airline booking system. In any given industry or sector the organizations in it will have more or less the same key operational portfolio. This is because, first, to lack a major level of system support would place a business operationally at a competitive disadvantage, and, second, the sales forces of the IT suppliers will ensure that you are aware of any gap that spending money with them will fill. Support systems are nearly all efficiency improvement applications and their failure does not have far-reaching consequences, e.g. training records unavailable for a week. Eventually, of course, if the records remained unavailable for a significant period troubles would occur. Strategic and high potential systems are quite different – they both concern themselves with the future which in itself makes them more problematic since considerations of lack of knowledge and hence increased risk are more dominant. Strategic systems are not just very big systems – they are those that genuinely contribute to the business’s future plans and strategies. When these are implemented people will then work in very different ways – ways that will confer a competitive advantage for instance. The system does not deliver the strategic benefit – that comes from the change in the way business will be done – but the system is nevertheless crucial to the business change, e.g. integrated international supply chain systems needed for truly global operation.

21


Fig. 2.3

Information systems investment portfolio

STRATEGIC

HIGH POTENTIAL

Investments in IS/IT applications which are critical to sustaining future business strategy

Investments in IS/IT applications which may be important in achieving future success

Investments in IS/IT applications on which the organization currently depends for success

Investments in IS/IT applications which are valuable but not critical to success

KEY OPERATIONAL

SUPPORT


High potential applications are the R&D of IS activity – prototypes, pilots, etc. of ideas that may confer large benefits but, because the certainty is insufficient to justify large sums of money being laid out, some preliminary business experimentation is required for proof of concept, i.e. to demonstrate that the benefits really exist. In a business value sense the portfolio grid charts the benefit lifecycle of an IS investment: a promising idea is tested for proof of benefits in high potential activity; if it is worthwhile it is implemented and confers strategic advantage. Because it is good it becomes copied by the industry and thus is classed as key operational. In time, as better IS offerings emerge, the application may migrate to support status. Most organizations’ portfolios consist of a large number of support systems and a smaller number of key operational systems. Some have no high potential or strategic systems, which means in business-IS terms they are always in catch-up mode with their competition. This portfolio structure can be an important part of the business planning cycle – with business managers debating and deciding the value and contribution of the systems, assisted by IS planning managers. Appendix 1 summarizes the attributes and implications of the quadrants of the investment portfolio. Experience (now with over 200 organizations) shows that it takes about half a day for business managers to review their portfolio. Frequently projects are removed because their business value contribution is agreed as being low, even zero, or duplicated elsewhere (the commercial managers of one large business found they had seven projects underway all called ‘Document Management’).

22

Management issues

Removal allows scarce resource to be focused on what is really required by the business. Most organizations have vast numbers of projects underway – often over 100 – with no one in the business charged with taking an overview of the collective impact. (It is worth remembering that 100 new systems translates into 100 changes to the way the business works, 100 demands on managers’ time to make the changes and 100 potential causes of disruption.) The nature of the source of the benefit differs according to its position in the classification. Since the nature of the benefits is different in each of the quadrants (see Figure 2.4) then the manner in which the projects will be set up and managed also differs. Driving out a strategic benefit which will involve fundamental new ways of working and hence entail a business risk is a much different programme to contemplate than, say, driving out unit cost reductions in a support project. The level and number of people involved and affected will differ considerably as will the scope and extent of the ‘ripple through’ effects of the system (huge in strategic, contained in support). It follows that at any one time the number of strategic projects must be manageably small – two, three or four at the most – since they each represent major disruption to the business. Fig. 2.4

Generic sources of benefit for different investments

STRATEGIC

HIGH POTENTIAL

Business innovation and change

Creating opportunities for business change

Business process restructuring

(Proving the benefits of applications)

Business effectiveness

Business efficiency

Process rationalization and integration

Process elimination and cost reduction

KEY OPERATIONAL

SUPPORT

Research and practical experience shows that the classification described allows more appropriate approaches to be taken for the investments – instead of a onesize-fits-all approach the project and change management can be tuned according to the business value being derived. For example, IT project methodologies were designed for key operational applications where avoidance of failure is crucial.

23


While such a heavy-duty approach is entirely appropriate to key operational it is over-engineered for support or high potential – the benefits could still be obtained with a lighter touch. In fact standard methodologies may inhibit the ideas of high potential activity surfacing. The acceptable risk profile varies with each quadrant (from almost zero risk in support to acceptance of failure in high potential as a legitimate outcome to an experiment). The portfolio also assists prioritization and resource allocation because it has been constructed around business performance impact. If there are gaps or serious maintenance requirements in key operational, then unless there is spare resource those will take precedence. If, notwithstanding the urgency of key operational needs, the top team considers a strategic application is essential (by definition all strategic systems are owned by the top team) then as a matter of business strategy resources will have to be found either by diverting them from support and high potential or by separate acquisition. The point is that all such decisions are taken in the context of business value criteria. The portfolio is a consistent reference point for managing benefits and the programmes that will realize them. Twice-yearly each strategic business unit in the organization should spend a day reviewing and updating their portfolio, not just in terms of progress but also in terms of changing business priorities and plans. Many large projects that run for years end up addressing requirements that have gradually become out of date. The above reasoning applies to the portfolio of all the IS/IT investments underway or planned.

24

3 A learning perspective on value delivery

■

The need for a learning paradigm

■

Levels of knowledge

■

Types of learning

■

Succeeding through people

■

Technology – enabling success

28

28

37 39 47

25


The focus of this briefing is on delivering business value. The concepts and techniques covered address the key problem areas experienced by many organizations. However, sometimes the problems are at a more basic project level, and the briefing asserts that these will not be solved until an approach that centres on learning from project experience is adopted. Successful project management is fundamentally about enabling people to work together effectively and to learn from all experiences to improve their ability to deliver business value. This chapter includes notes on some basic and common misconceptions. They are short illustrations of what not to do which represent excellent learning examples taken from experience working with project teams over a number of years.

An example of some basic project problems: ‘Where’s the “buy” button?’ The organization wanted to start selling directly over the Internet. Their project team had spent a long time and a lot of money with the creative agency coming up with a cool concept for the website and working on the user interface development. We persuaded one of the business sponsors that it would be a good idea if a usability expert spent a day having a look at the site while it was being tested. The primary issue, among many that were highlighted by the usability review, was that it was next to impossible to find the ‘buy’ button. It was next to impossible to find out how to start the process of trying to buy what was on offer! Fortunately, as a result of our input to earlier projects, we had made sure the user interface was easy to change without any impact on the underlying business process. In a few days the site looked totally different – and you could actually find the ‘buy’ button. Key learning ■

Value-adding systems must be usable systems and creativity is not the same thing as usability. Make sure that on any web project – and particularly a business-to-consumer (b2c) project – that the team includes someone who really understands usability.

■

Ensure that the user interface is easy to change. There will be a need for continuous improvements and it must be as easy as possible to make changes.

■

There are a lot of people and organizations out there who will take any work they can get regardless of the real skills they have to offer – make sure there is clear ownership for getting individuals with the right skills onto your project teams.

27


THE NEED FOR A LEARNING PARADIGM At the most basic level there is a right way and a wrong way to approach projects, particularly those that involve any significant degree of business change. For many organizations a paradigm shift is required in the approach they take to enable them to consistently realize the potential business value of IT. The required paradigm shift is a focus on learning. This is a more complex and less-well-defined area than the investment portfolio and will be explored from a number of angles to build up a rich picture of the concepts and approaches that are fundamental for success. It is not the detail of any of the specific models that is important; rather it is that the learning paradigm becomes a core part of the mindset and values that underpin action to derive business value from IT investments. The virtues of iterative development through versioned releases are well known. The approach requires that the overall requirements are broken down into a number of chunks and a series of projects are used to deliver the overall solution in stages. This has many virtues, not least that it reduces complexity and risk by breaking the overall project down into smaller and inherently less risky projects. It also results in an earlier delivery of a first phase of the system, giving the opportunity to start getting the benefits sooner. A further and crucial benefit of this approach is that it enables learning from the first version of the system to be captured and to inform and improve work on later phases. There is learning: ■

by the project team during the detailed design and development work;

■

from the customers or business users who the system has been designed to help as they start to use the system.

Methods and frameworks such as Microsoft Solutions Framework (MSF) (http://www.microsoft.com/msf) and DSDM (Dynamic Systems Development Method) (http://www.dsdm.org) make this development model a reality. However, there are some deeper issues that underpin this approach and provide further insight into its importance and how to fully exploit it. Two models are explored in this chapter to illustrate the ‘learning paradigm’: first ‘levels of knowledge’ and second ‘types of learning’.

LEVELS OF KNOWLEDGE Taken at its most general level a process is a course of action or a series of operations with an overall purpose. Business processes are the procedures and activities carried out by the enterprise. They are usually expressed as a sequence of work activities carried out in a coordinated way and involve people, procedures,

28


machines and software. The level of knowledge about a process will vary from process to process and also between activities within the process, for example: ■

Low knowledge of the process is categorized as ‘awareness’, knowledge as an art – which is largely tacit knowledge which resides in people’s heads.

■

High knowledge of the process is ‘know why’ – scientific knowledge of the process which can be written down as formulae and algorithms.

Consider baking a loaf of bread as an example of a process. A master baker probably has knowledge at a low level. Much of it is based on experience, learned through an apprenticeship and lots of practice at making bread. In contrast the knowledge of the process at the factory making sliced bread will be higher in ‘scientific’ terms. There will be precise instructions for ingredients, mixing and baking times. The changes required to get a different outcome will be well documented. Also many of the staff will have had a different sort of training; typically it will have been more about how to follow the agreed process, operating the machinery as required. They will have less discretion about how they go about their tasks. Note that the level of knowledge does not refer to the quality of the outcome. In a business the concept of levels of knowledge can be applied to processes where the outcome is either a product or a service. Different business processes are at different levels of knowledge. For example, the ‘process’ of defining the business strategy is much more an art than the process of paying invoices. Also the same process can be handled in a number of different ways. Consider a call centre and the often heated debates about the relative virtues of: ■

using a highly scripted, tightly defined process, probably with staff with limited training;

■

providing powerful tools and information to well trained staff and giving them freedom to meet the customer’s needs.

A key insight from the levels of knowledge model is that the best way of managing a process varies according to the level of knowledge, the higher the level of knowledge, the closer the process is to ‘science’ and the more formally it can be managed. For example: ■

If there is a high level of knowledge about a process we may be able to either automate it effectively or use unskilled workers adhering to strict procedures.

■

If there is a low level of knowledge this requires experienced and skilled people who use their own judgement throughout the process.

Further implications of the model include the following: ■

Matching skills with the level of knowledge of the process. This means matching the complexity and ease of use of the application to the experience of the users

29


and also acknowledging if our understanding is at the level of ‘art’ or ‘science’. If it is at the level of ‘art’, a sophisticated system trying to enforce a prescriptive, step by step the process is likely to be expensive and fail. On the other hand, a system designed more to provide ‘tools’ to help the skilled worker may work. ■

Locating the knowledge in the right place/format at the right time. Recognize that, depending on the level of knowledge, very different approaches are required to training and documentation. The levels of knowledge model suggests that we rush far too quickly into detailed procedures before we really understand the process – and how to get the benefits.

The implications for getting business value from IT are very significant. We need to consider the implications for both the business processes that IT is being used to improve or automate and the IT processes themselves.

Applying the model to business processes In cases of significant change to business processes there is a need to adapt traditional approaches to enable learning to occur during the development and deployment process. A traditional approach would involve the piloting of training material and procedures in final user testing prior to a short pilot and rollout. Often this material is largely fixed at an early stage either before or after the testing stage. The intentions of this approach are good. It delivers the new system as fast as possible into the business. However, in terms of overall effectiveness in delivering benefits, it is not the best approach in these situations of major change. A much better approach recognizes that the initial user procedures will only provide a starting point and that the goal of the period of the pilot is to discover how to maximize the benefits in operational use. This requires the training and procedures to be left flexible and will probably require project team involvement in working on the pilot to help with the learning process. When the pilot has shown how to deliver the benefits the procedures and related training can then be amended and finalized for rollout. The overall process to deployment of the software will probably take longer than in the traditional approach but the time to realization of benefits will be shorter, and that is what counts.

A case study in learning: sales-based ordering A large supermarket chain wanted to make major changes to the in-store process for ordering stock. There was a general drive to give much greater responsibility to stores, to free them from detailed control by ‘head office’. The new sales-based ordering system was to be part of this business change. Continued … 30


The forecast business benefits were very high. There was a lot of pressure to get the system in place and rolled out across the chain as quickly as possible. The project was approached in all the right ways. The project manager was very experienced both as a project manager and in the business issues of ordering and stock control. There was a programme ‘director’ to handle the politics. The core team was a mix of in-house IT staff and well-qualified contractors and there was extensive involvement from the stores including a number of the best people seconded onto the project. Joint application design workshops were used to ensure the system would meet the needs of the users and the delivery of the system was phased to reduce risk. The building and testing of the system went largely to plan and the team managed to tackle the various issues and challenges that arose with the new hardware and software environment without any significant impact on the schedule. The system passed user acceptance testing (UAT) and then went into pilot in the first store. Because of the need to get the system rolled out quickly to get the benefits, and also because user acceptance tests typically test not just the system but the training and the procedures, the procedures and training material were all prepared ready for the UAT and work was already going ahead training the teams that would rollout the system to the first group of stores after the initial pilot. All was going well as the first few product lines went onto the system. But then the problems started … The first pilot store and then other pilot stores were under a lot of pressure to take on all the planned products and switch over to the new system. But as the volumes built up the store staff found they just could not cope with the new way of working and the workload involved. The project team got more and more drawn into running the ordering process in the pilot stores. It became clear that this was not sustainable and that the original aggressive rollout programme had to be rethought. The overall cost to the business – in lost benefits based on the original benefit projections and rollout schedule was around £30 m. The costs of training materials and training courses that did not lead to implementations were also very substantial in relation to the actual software development costs. There were technical issues – but they were not the real problem. The project team did all the classic things right – based on broad experience before and since they were a very strong team. So what went wrong? Looked at in the light of the learning paradigm there were a number of factors adversely affecting the success of this major project: ■

Learning by using. The system worked well in UAT but as the store staff took it on and as the volumes increased there were problems with the Continued …

31


overall success of the new ordering process. The store staff, some of whom had never used a mouse before, did not find the system as quick and easy to use as the core team who had been some of the best people in the stores and who had lived with the system for months right from the initial design. Also the UAT had not simulated the 101 other things that were going on in the store – perhaps they could have coped if ordering was all they had to do. The processes and training had effectively been frozen before the pilot and so there had not been the opportunity for ‘learning by doing’. The project team found that the store staff, i.e. the customers, had wanted to use the system in a different way from the developer’s intentions. ■

Levels of knowledge. The procedures and training had been developed by people with a good knowledge of the stores and the system. But because of the desire for speed it had been done before the system and processes had been put to the test in the real world of the store. This and the handover from the project team to a less experienced store team, who also had less time available, meant there was neither the opportunity nor the capability to be flexible and innovate to make the system work as troubles were encountered. The system had been managed as if the stage of knowledge of the process was a lot higher than it actually was.

Given the business pressures to deliver the benefits it would have taken very strong leadership to plan a different approach to the project. With the power both of hindsight and the insight of the learning paradigm a much better approach would have been to get the first version into a pilot store more quickly by reducing the effort on procedures documentation and training material while still ensuring the software was robust. Then a core of the project team could have been seconded into the store and allowed to use the ordering system to run the ordering for the store. They could then have evolved procedures that delivered the benefits. When this was working a next step could have been implementation of the system in a very small number of stores to iron out issues and see if new teams could also get the benefits – with plenty of support. Then at this stage, with a greater level of knowledge procedures documentation and training material could have been developed. A further step would have been to plan for ongoing learning and improvement in the use of the system to deliver benefits. Far too often for political reasons the outcome of a project is declared a great victory and everyone moves on to the next project regardless of the real achievements. The result of this is that the focus required to deliver the benefits in the weeks and months after the system goes live is forgotten.

32


Levels of knowledge and IT processes There are a lot of processes within the IT function. Two of the key high-level processes are systems development and service or operations management.

Systems development There are two basic approaches to systems development: ■

Type 1. Recruit good people. Provide them with training, the right resources and good leadership. Enforce a minimum of controls and encourage them to share good practice and learn.

■

Type 2. Focus on process and documentation. Try to succeed by controlling in detail both what the teams deliver and how they deliver. Work exclusively with business analysts. Do not worry too much about the developers and other technical people. Ensure there is full and detailed documentation of the requirements and intended design of the solution before the developers and other technical staff are involved.

The second approach can seem attractive. It involves talking to lots of nice people who speak in business terms – and avoids lots of hard discussions with technical people who do not always seem to be speaking the same language. But it does not work – if it ever delivers anything it will take a lot longer and cost a lot more than following the first approach. Do not be fooled into thinking the Type 1 approach is more expensive. It may be necessary to pay slightly higher rates to what will be a smaller team of high-calibre people – but the key is to focus on value not cost.

A case study in approaches to project processes: an example of a Type 2 project A major organization wanted to start selling online as well as through its traditional channels. It was the height of the e-commerce boom and although market research suggested that consumers would not be ready to buy this sort of product online for some time they felt that they had to experiment to test the market and to demonstrate their e-business credentials – to support the share price. In this situation, as it was a ‘high potential’ project, speed was of the essence. The key was to get a working solution released, learn from consumers and assess the benefits. The organization took a Type 2 approach. They employed a (expensive) team including ‘e-commerce solution architects’ from a major systems integrator. The team did not have much technology knowledge (and knew even less about the Continued …

33


chosen development platform). After about six months they had produced a business case, a project plan and lots of requirements and system documentation. Now they decided it was time to get some developers on board. Another part of the IT function gathered a development team together, including a few from a recently finished project using the same technology to meet similar requirements, and some contractors with good skills who wanted to be involved in a major e-commerce project. The developers took one look at the system documentation, decided that the solution architects had not understood the issues and had not provided them with a sound starting point for development, and promptly started working directly with the users to design and build the system which, although not trivial, was essentially reasonably straightforward. In essence they reverted to a Type 1 approach. Unfortunately six months and a lot of money had been used up by then. Too many people are trying to turn systems development (sometimes called software engineering) into a step-by-step process with all the predictability of a civil engineering project or a manufacturing process. It is not. It is more an art or craft skill – and as such it requires managing in a different way as the levels of knowledge model indicates. This has major implications for the management of IT projects. A key implication is the importance of getting the resourcing right – and this is not easy. In part this can be because in many companies the senior people in the IT function have got to be the most senior because they are best at communication and politics. Of course this is important, but there must also be some people who understand the technology and they must be allowed to have an influence – unfortunately at the Type 2 organization, if the people who really understand the technology have not already left they are probably keeping their heads down – and not taking the risk of trying to force their voices to be heard so that they can influence the critical early stages of projects. A group calling themselves the Agile Alliance is one of the champions of this people-centric approach to projects focusing on collaboration and learning. Their ‘Manifesto for Agile Software Development’ is a good summary of many of the key issues.

A Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ■

individuals and interactions over processes and tools Continued …

34


■

working software over comprehensive documentation

■

customer collaboration over contract negotiation

■

responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. Principles: the Agile Alliance We follow these principles: ■

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

■

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

■

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

■

Business people and developers must work together daily throughout the project.

■

Build projects around motivated individuals.

■

Give them the environment and support they need, and trust them to get the job done.

■

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

■

Working software is the primary measure of progress.

■

Agile processes promote sustainable development.

■

The sponsors, developers and users should be able to maintain a constant pace indefinitely.

■

Continuous attention to technical excellence and good design enhances agility.

■

Simplicity – the art of maximizing the amount of work not done – is essential.

■

The best architectures, requirements and designs emerge from self-organizing teams.

■

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

See: http://agilealliance.org/

Levels of knowledge in service/operations management Operations management is a part of the IT function where the stage of knowledge is higher than in development and more prescriptive processes are required.

35


Mistakes here can bring the business to a halt in seconds. Full consideration of the impact of learning and knowledge on operations management is outside the scope of this briefing but here as with the development function learning and knowledge management are essential elements of the successful management approach. One area that must be covered briefly is the help desk and other activities related to supporting an application. A key element of getting the benefits from a new system is making sure that the system is reliable, robust and easy to use. As with the user procedures, issues relating to the help desk, support and computer operations are not going to be fully understood before the system goes live. It is clearly important to get a good focus on these areas during the planning, development and testing processes but in the context of learning a key issue is to plan for further learning once the system is live. The help desk and operations staff need to be briefed and trained – but there must also be provision for capturing learning and ensuring action is taken to continue to improve processes.

An example of misconceptions about planning: ‘you cannot plan more than three months ahead’ This was said at the height of the dot com bubble, so in some senses it is right. But from a senior IT manager it is a complete abdication of responsibility. From the technology perspective Microsoft is working actively now on products that will be released next year and in two or three years’ time. The product groups are also working on what will come after that, and in Microsoft Research teams are working on issues and technologies that we may see in five to ten years’ time. When you add onto that the technology adoption curve and see how slowly even breakthrough products like Windows 2000 and Windows XP penetrate the huge installed base it seems clear that at least a two to threeyear technology planning horizon is feasible. Yes, there are uncertainties and there will continue to be surprises but that just makes life interesting. The harder bit is working out what business opportunities will be enabled by the new technology. Key learning ■

There must be an overall vision beyond the completion of the next project. Make sure there is a technology roadmap for the business as a foundation for programme and project planning and delivery. Use projects to test out the assumptions in the roadmap and to learn about how to get the most out of the technology for the business.

36


TYPES OF LEARNING There are different types of learning. For success in delivering benefits a key type is learning from the customer, i.e. learning by using. The IT industry folk wisdom provides a good summary of the implication of learning by using: Customers invariably use technological systems in ways different from how they were designed or produced. If correct this strikes at the heart of the approach we take to developing IT systems. The implication is that a system cannot be designed to fully meet users’ needs, however much they are involved in design workshops etc., because they do not know exactly how they will use the system until they use it for real in the operational environment. The idea of prototyping goes some way to address this but falls short of a full operational trial.

Managing Information Systems Projects Managing Information Systems Projects (MISP) is one of a number of valuable courses run by the Information Systems Research Centre team at Cranfield. MISP, which has been developed by Roger Elvin, Andrew Davies and others, outlines a new approach to IT projects which is particularly relevant to strategic projects. The starting point for MISP is an analysis of the causes of failure of IT projects. This leads to the identification of a number of in-built assumptions in many (traditional/waterfall) approaches that are false. MISP provides a new approach that is particularly valuable for strategic situations where there are substantial business changes. MISP identifies a number of assumptions that are implicit in most approaches to projects and are major contributors to failure: ■

A complete, comprehensive and stable set of requirements for the ‘IT solution’ can be gathered prior to its design.

■

Design of business activity is an incremental enhancement of the status quo.

■

The organizational context of the project is static so that: – completion of the project plan will satisfy the project intent; – once requirements have been specified the business can withdraw until implementation; – project management can be directive/hands-off. Continued …

37


The implication is that a new paradigm is required for project management, one that reflects the real-world scenario that learning and change are going to be occurring during the life of the project and should be recognized and exploited. See: http://www.som.cranfield.ac.uk/som/isrc/ At Microsoft, in the Office group for example, there has been a lot of research into how to improve usability and provide better guidance for users trying to find out how to do something. The well-known paperclip and Rocky the dog who were ‘front men’ for the Office Assistant help feature are only one example. Unfortunately, however much people are asked what they need and are employed to test new features, it is very hard to be sure the solution is right – they may not know what they want. It may take some time of using what has taken so much hard work to produce before they realize that what they asked for was not really what they needed. In a sense powerful software products such as Office XP or Biztalk provide new organizational capabilities. Although they work well and can deliver substantial value from the day they are first released, new opportunities for advantage and new ways of using the capability provided by the software emerge over time as people use the products and learn from using them. Using the investment portfolio as a guide and understanding the context of the project is vital. The development approach needs to be tailored to the type of project. Particularly where there is substantial business change – as in a strategic or high potential project, the implication of ‘learning by using’ is that the iterative, rapid development approach is the only way to work. It is essential to get the solution out into the real world and learn from how the customer uses it. The Managing Information Systems Projects (MISP) work done by Cranfield arrives at much the same conclusion in a different way. This is just another and hopefully a final nail in the coffin of the waterfall paradigm that is still the driver for so much wasted effort and so many failed projects.

Waterfall paradigm This is a traditional model of IT systems development. Each stage is completed with formal documentation of the results before a handover to other members of the team, with different skills, for the next stage of development. Stages might include requirements definition, systems analysis, design, build, etc. The drawbacks of the approach are that the members of the team with different skills do not work together at the same time and the interaction of business requirements and technology possibilities is not fully recognized.

38


In summary, the right way to approach IT investments is based on the learning paradigm. Other approaches might work in certain circumstances – but do not bank on it.

An example of applying the 80/20 rule: ‘we must have a “best of breed” solution’ The team wanted a content management system. It had to be the best, so they scoured the market and evaluated lots of products. When they got down to a shortlist of two they asked all the different groups who wanted to make use of the system for their top five requirements so a list of critical features could be agreed to drive the final decision-making process. After about six months a final decision was made. There are a few problems here. A basic one is that you work out your list of critical features in order to come up with the shortlist first, not afterwards. It is one of the first things to do, not one of the last. A second is that when you are aiming to deliver solutions in three to four months taking six months to select a tool is a little bit too long, about four to five months too long. The more fundamental problem is that knowing what is ‘best’ is a bit of a challenge. Given that there was no existing content management system in the business there just was not the practical experience of what was required to come up with what would be a ‘best of breed’ solution for that organization in the longer term. Key learning ■

Remember the 80/20 rule. Make a choice of a good solution from a shortlist of those that are a good fit with the IT infrastructure/technical strategy.

■

Make the choice quickly. Get a solution in place and start getting the benefits.

SUCCEEDING THROUGH PEOPLE Increasing focus on people is the real key to success. Frameworks, methods and processes are just tools that people use to succeed with technology. Taking input from the investment portfolio it is clear that a one-size-fits-all approach does not apply. Changes to a key operational system must not be

39


approached in the same way as a high potential project. But far too often all projects are treated the same. Appropriate processes and controls are vital. However, for many projects the emphasis is far too much on science and process rather than skills and people. This is particularly true of high potential and strategic projects where innovation and time to market are crucial.

Clear evidence of significant productivity differences Studies of productivity differences between IT development teams and individual developers have produced some startling results. Typical results include the following: ■

In individual tests the best people outperform the worst by 10 : 1.

■

In tests those who completed with zero defects in the finished product actually took less time, on average, to finish than the rest – i.e. they won on both quality and speed.

■

The number of years of development experience was not a significant factor in performance.

■

Studies also indicate that there is a 5 : 1 difference in productivity among groups with different backgrounds and experience. This falls to only 2.5 : 1 for groups with similar background and experience!

A crucial factor is that the results vary by organization not just by individual. There is something in the work environment, culture and way of working that is leading to 10 : 1 productivity differences between organizations – not just between people. Which end of that 10 : 1 difference are you at? A key factor in the differences in performance seems to be in the office environment. This included big differences in workspace, ability to work in peace and private, uninterrupted by people or calls. Many organizations are still making systems development teams work in unsuitable conditions. Many aspects of IT project work and particularly systems development, are complex and require high levels of concentration – quite a challenge in busy, noisy and often cramped open-plan offices. The evidence also undermines false assumptions about the quality and time trade-off. In part because quality is built in from the start, for example with wellstructured code and with a consistent approach to trapping and handling errors, life is easier and time is saved. Getting some of these basics right upfront and sticking to good practice will save large amounts of time later on, for example by making it much easier to track down and correct any errors found in testing.

40


An example of attention to quality: get it right from the start At a recent post mortem review of a project the development team was defensive. There had been major problems after going live causing the new ecommerce site to be withdrawn for weeks. The main problem was that there was no error reporting so that initially there was no way to identify what was going wrong. Changes had to be made to the application to produce the information required to investigate the problem. The main defence from the team was that they had been too busy to build in error handling. But all that was required was one line of code! If only they had included it! Key message ■

Building quality in from the start is vital.

Focus on the people to make a difference Major improvements in productivity and quality are driven by a balanced approach that focuses on getting the right people and creating an environment for them to succeed. Process improvement at the level of the individual is vital. Ongoing improvement and innovation are crucial. At this level it is about creating an environment where learning is encouraged and valued. Much of this is a product of a healthy team environment, while other aspects are facilitated by knowledge management approaches such as ‘communities of practice’ which will provide a basis for learning and for sharing that learning outside the individual teams. It is far better to get to the position where people do the right thing automatically and build in quality than rely on processes and controls to make it happen.

Communities of practice Communities of practice are informal networks of people that are dedicated to sharing professional knowledge. They are a key enabler of sharing knowledge and transferring skills in an enterprise. Foster an environment where people can take pride in their work and where the teams are able to establish an effective way of working. The culture and way of working that is going to be most effective is the one that gets the right balance between people and procedure. System development requires a lot of creativity from a multidisciplined team. It is not a manufacturing process.

41


Management are responsible for a number of key factors that can make all the difference between success and failure. The points below are about how to create the right environment for project teams to succeed. ■

Working environment. Workers on the Microsoft Campus in Redmond have individual offices – all of them. IBM has done a similar thing for some of their development and research teams. It is a great way to provide an environment in which people can concentrate. The goal is to make sure the team is together in one work area and has plenty of space for individuals, equipment, storage and both formal and informal meetings. It does not have to be grand, but do make it an environment where people want to work and can work.

■

Meetings. Cancel them. Minimize meetings and formal reporting, for example to review status. Minimize administration of any kind. Make sure there is a good reason for any meeting or any administration – ensure it cannot be done in another way. Good techniques to minimize meeting time include: – maintaining a risk and issues log that is contributed to by all the team and actively managed by the project manager; – planning for tasks with clear deliverables from each team member at roughly weekly intervals – team members report completion of tasks and the project manager can chase individuals where there is a problem.

■

Workshops. Use them. Make good use of workshops to enable people from different disciplines to work together to explore a situation, carry out design work or solve a problem. Build strong facilitation skills in the team to ensure these sessions are successful.

■

Expectations. Starting a project with the wrong expectations is a big cause of trouble. There will be a few surprises along the way – the team cannot have perfect knowledge of the requirements or design at the start of the project. The key to success is to manage learning, issues and changes positively and effectively. In particular project time and cost estimates are just that – estimates. The margins of error are actually quite high. Recognize this – do not demand spurious accuracy or react angrily when problems occur. If necessary, and if it can be done without causing delays to projects, use a two-stage funding approach – get funding for the first 10 per cent of the project and then for the rest on completion of the first stage. Be prepared to make trade-offs between time, resources and quality – typically a time-boxed approach (i.e. where the primary goal of the project is to deliver to an agreed timetable, and if necessary features are cut thus reducing the scope of the system delivered) will be right for strategic and high potential projects. It is better to go live with a working solution on time with slightly less functionality.

42


■

Empowerment. Empowerment is ‘a good thing’, but what does it mean? Partly it is about expectations, but it is also about trust. The team wants to do the best job it can. It is important to trust them when things go a little wrong – an issue is not always a disaster. Allow them to solve the problem or help them if possible but do not cause panic. Allow the team to manage the problem. The management role is to concentrate on dealing with the politics – do not try and manage the problem for them or cause them so much extra work communicating about the issue that they cannot get on and resolve it.

■

Quality. Set high standards. A good team will set its own standards high so do not undermine them. Quality includes being fit for purpose for the business as well as in technical terms.

■

Key processes/controls. Make sure key processes and controls are set up from the start of the project and that they are owned by the team. These will include: – project planning and tracking; – risk and issue management; – change management.

■

Learning. At the start of the project there will need to be time to learn – about the business, about any new technology, about other members of the team and about processes. The team will need to take time to manage this – it must be treated purposefully as part of the project, but if well handled this time is extremely valuable. Continue the learning through the life of the project – create a climate where people want to, and can, learn how to do things better. A key enabler is to be able to admit to problems or mistakes. If necessary defend the team from a negative/aggressive corporate culture and allow the team the freedom to make this happen just within the team.

■

Get the right people. Make sure there is clear ownership for getting new people on board – from both internal and external sources. Take the time to do this – it is probably better to have to wait than to take the wrong person. The key is to get the core team right and then not build up the full team too fast. Keeping the team small in the early stages will help them make faster progress and put them in a better position to know what skills they need, and to own bringing the rest of the team on board at the right times. Also be very careful about making false assumptions. The two most effective developers on a recent project were both among the youngest – one was on placement from university. Aptitude and attitude can count for more than years of experience. Be very careful about contractors and staff from suppliers – some are very good and some are not!

■

Listening. It can be surprising how little listening goes on. A key success factor is the added value that will come from the debate among a team with different

43


areas of expertise. If the team has the right people on it they will be a mixture of people with different expertise and working styles so it will take some time to build a team where they value the different approaches and contributions. Help this to happen and allow them to use their skills! Listening is essential – and not only to good news. ■

Invest in the people. Unless this is the only project they will ever do training and development of the people is important. As people are ‘our most important asset’ we need to invest in them and treat them as an investment. If this happens there is a strong likelihood that there will still be a team for a second project and that they will be even more effective than on the first one. One aspect of treating them as an asset is not to set unreasonable deadlines or to expect ridiculous hours and regular weekend working. Although necessary sometimes for short periods in the long run it is not effective. It is interesting to note that as a result of some work done on project estimating the sample of teams where no formal estimates were done and deadlines were not set actually finished first. The typical development team is very highly motivated and does not need artificial deadlines to make it work hard.

■

Create opportunities for success. Build a climate of success – provide early opportunities for the team to succeed. Key ways to do these are include keeping projects small and using milestones and interim milestones to focus effort and to track progress.

■

Senior management commitment. Commitment from senior management is vital in many ways. It is essential to get the senior business managers who want the project involved. However, their involvement needs to be channelled into the right places and must not undermine the empowerment of the project team. (See the box below.)

Success factors in change management The need for senior management commitment and high-level sponsorship of a major project is clear. But what do we actually need senior management to do? Research suggests that although a number of widely recommended senior management actions do not do any harm, they do not have any discernible effect on project success either. Common recommendations which do not appear to have any direct impact on success do not require a high level of involvement from senior management: Continued …

44


■

The goals of the change are clearly defined.

■

Senior management publicly express their commitment to the change.

■

The change is backed by a strong champion.

■

The change is run by an experienced project manager.

■

A detailed plan is prepared to manage the change.

Recommendations that do appear to have a direct impact on success tend to require a greater level of input from senior management: ■

The agreement is gained from the people affected by the change within the organization.

■

Management create a clear structure to manage the change.

■

Senior management accurately estimate the amount of resources needed to implement the change.

■

The senior management team create specific lines of authority and responsibility to link it to the change programme into the existing top level management structures.

■

Motivation. There will be a wide range of types of people in the team and in particular the business and IT specialists are likely to be very different. They will need managing/communicating with in different ways – we are not all the same.

■

Invest in the ‘infrastructure’. It is very easy just to focus on the bare minimum to get the current project done. It is essential to be able to look at the bigger picture, and make some level of investment in the infrastructure that will contribute to the success of the next project as well as the current one. Things in this category include automated testing and system build processes. Building tools and processes in areas like these are just as much a part of the project as building the specific functionality required by the users – and subject to similar ‘build vs. buy’ considerations. The right balance will vary considerably from project to project. Always consider the need to invest in the ‘infrastructure’, to increase the capability to develop the next release more effectively.

■

Keep it simple. Simple is good in an IT system. The 80/20 rule helps – focus on what really matters. Make simplicity a guideline for the technical aspects of the design of any system. The payback comes both in the initial development and in the reduced costs and complexity of longer-term operation, support and enhancement of the system.

45


Diary of an executive in a change situation Extracts from the diary of a business sponsor responsible for a number of e-business projects. Monday

Following a quick review of last week’s sales performance through the new Dashboard [a Microsoft web-based management information system], made quick visits to colleagues in Operations and Finance to remind them of the benefit workshop on Wednesday and check if there are specific areas they want to focus on.

Tuesday

Benefit review session for version 1 of the new Campaign Planning Toolkit. It has now been live for 30 days so it was time to examine the progress on benefits. It was a good session. The business team liked the results and had found the toolkit a big help in planning two campaigns. We agreed some areas to focus on and what actions they can take to get the most out of the toolkit in the next three months. We will then meet again to review the benefits achieved. The IT team made some good suggestions about how to improve on version 1, but we agreed not to pursue them until we had got more experience. I met Anne from the product data management team at the coffee machine. I asked how things were going and she mentioned an idea she’d had to help the team deal both with the rapidly increasing workload as we move the business online in more European markets and also to make a big step towards our longer-term ambition of dynamic pricing. I suggested she speak to Jenny, the solution architect, and her team manager to explore the suggestion and then come back to me on Friday.

Wednesday

Spent all day in the second benefit workshop for a key marketing project. The session went well. The case we had put together in the first workshop had been developed by the team and we were able to spend most of the time on how to manage the business changes we would need to achieve our objectives. I made a note to review the succession plans at the next business team meeting – we’re going to need to pull out two or three of our best people to work on this one. Finance and Operations are getting the hang of Benefit Management now – the Financial Controller said she wanted to introduce it for all projects.

Thursday

Things have been going too well … I got an e-mail from the project manager for the new shopping site. We had decided to try and take a big step with this project, but they’ve run into trouble with the mainframe integration and won’t make the next milestone. I e-mailed the CIO and asked if there is anything that can be done from the mainframe end to raise the priority and get the issues resolved. I asked the team to focus on this and try and crack the problems. We will meet early next week and review our options – we’ll

Continued …

46


need to assess if we put back the launch or if there are options to cut features to regain time. Friday

Anne came back to me as promised. They had a first look at a Content Management system that seemed to offer big benefits for the data management team and help us tackle some long-term issues. We agreed to kick off a High Potential project with the target of a pilot in 30 days so we can start to assess the benefits. Anne will lead from the user side and we can use some of the team that has just finished the Campaign Toolkit System. I made contact with the Services Manager at Microsoft and agreed to get two consultants engaged to work with us on the proof of concept to help us get up the learning curve at top speed. Great insight by Anne – this could end up being one of next year’s Strategic projects.

Key messages ■

Risk management – empowering the team.

■

Priority given to projects – allocating best people.

■

Listening – opportunities coming from the team.

■

Business involvement in benefit management.

TECHNOLOGY – ENABLING SUCCESS One key focus of a project will be how the use of technology can produce benefits for the business. It is also important for the project team to take advantage of the opportunities to use technology as a tool to help them succeed. A critical factor in ensuring a project succeeds is locating the project team in one place so that it is easy to communicate and work together. To some extent this reduces the reliance on technology for the day-to-day working of the project team. But in reality there will always be members of the overall team who are not fulltime members of the co-located, core team. In fact, the wider team is increasingly likely to involve people from a number of organizations in a number of locations. Getting the technology right so that these people can participate as effectively as possible in the team is crucial. Using the right technologies in the right ways can also be a huge help for the core team to maximize their effectiveness in working together as a team to deliver the project. From a programme or departmental level there are other issues to handle, for example where is the latest information on a range of projects or a view on how all the projects are doing? Also, what projects have faced similar issues to those now being faced and how is learning best shared across multiple projects? From this

47


perspective success is not about individual projects, it is about the whole portfolio, about learning, reuse and about a continuously improving development capability. These are crucial issues for the CIO and for others managing the whole project portfolio. There are a number of elements to the solution and they can be hard to get working really well, particularly without imposing a bureaucracy which stifles innovation and effectiveness. Key elements of the solution involve using the technology well and an effective approach to collaboration and knowledge management. The core requirements for the day-to-day technology environment are best met by applications such as Microsoft® Office, i.e. Word, Excel, PowerPoint, and also Outlook®, Microsoft® Visio and Microsoft® Project 2002. It is vital to have good skills in the full range of these tools and to have someone on the team with a clear leadership role in using the tools effectively. It is frequently said that ‘knowledge workers’ only use a low percentage (15–20 per cent) of the rich functionality of these products. It is not so often said that of the 80–85 per cent of the functionality not used there is a lot that would increase effectiveness if it was! This is not someone else’s problem – it is an issue for every manager and worker. It would not be very impressive if David Coulthard or Jacques Villeneuve said on unexpectedly loosing a Grand Prix: ‘Well, they gave me a new version of the gearbox – I know there were more than four gears but I never found time to try the others out so I just stuck to the first four.’ Do not get carried away and over-complicate things but follow the 80 : 20 rule and take responsibility for getting the most out of the power available. ■

Use the document collaboration features in Word and the other Office packages to track changes and manage comments and feedback from reviewers.

■

Use e-mail and Instant Messaging (IM) to supplement the telephone – develop a clear etiquette about how to use these communication tools so that people are able to use and manage their time effectively. This may well mean minimizing the use of the phone, batch processing e-mail and using IM when it is urgent.

■

Use Windows Messenger to provide a rich collaborative environment with remote workers – sharing documents and using the webcam/voice facilities.

■

Build up skills in all the relevant tools, for example Visio – they can make life a lot easier.

■

Ensure there are standard templates for the key documents required by the team.

■

Agree, and stick to, a simple document management process – ensure key project documents are subject to version/change and make it easy to find key project documents as well as all the latest working documents.

In addition to using these basics use an application such as Microsoft Project 2002 incorporating Microsoft SharePoint™ Team Services or SharePoint™ Portal Server

48


to provide a collaborative environment for the project team and a portfolio management capability. The virtual teamwork space, including calendar, document management, notice board, task-list, etc., makes a big contribution to effective communication and teamworking. Getting the right discipline in place around the site will cut down on a lot of e-mail and help the team to communicate effectively and work together on a common set of information. It is not difficult and it is not expensive to use this technology to help the team work effectively. Do not cut corners here as it will be false economy. It is essential to break down the barriers to asking for help and advice, and get a focus on learning how to work more effectively. If this is achieved the big payback is that it will help develop a team that is agile and innovative and is expert in getting value from technology – which will be a great asset to them as they focus on using technology to achieve the business goals of the project they are working on. Recent work by Karin Breu and Chris Hemingway at Cranfield ISRC on employee agility is providing some valuable new insights into the key factors that create an agile workforce. This provides a good starting point for taking action to improve knowledge worker effectiveness and employee agility.

49

4 Summary and action plan

■

Key issues for business managers

■

Key issues for IT managers

■

Dos and don’ts

■

Action plan

53

53

54

55

This chapter provides a summary of the key messages from Part One of the briefing and sets out an initial action plan.

51


KEY ISSUES FOR BUSINESS MANAGERS ■

Technology is going to continue to change rapidly. There will continue to be new opportunities for investing in IT to get significant returns for the business from: – doing new things; – doing things better; – stopping doing things.

■

Too many IT investments fail to deliver benefits to the business. In most cases this is nothing to do with the technology but with management capabilities and processes in both business and IT functions.

■

It is possible to make a dramatic improvement in the success of IT investments by adopting a number of tried and tested techniques and making a number of changes in approach that together represent a paradigm shift in the management of IT for business value. Focus business attention on the information systems strategy – to identify where, in business terms, information technology can enable positive business changes. Adopt the portfolio approach to the planning and managing of IT investments. Establish a framework for managing IT investments that focuses on the outputs and allows innovation in how the teams deliver the results. Successful project management is essentially about building effective teams and good collaboration. Encourage and plan for learning: – Deliver major programmes in small chunks to maintain flexibility and allow for learning – Plan for high potential projects to investigate the benefits of new business opportunities – Use technology to enable the sharing of learning across the business. Engage with the IT function throughout the life of projects. Allocate the time and resources of the business teams to manage the business changes that the IT investments are enabling.

KEY ISSUES FOR IT MANAGERS ■

The IT function has unprecedented opportunities to contribute to the business based on new and maturing technologies that are opening up new opportunities to provide new products and services, not just the automation and cost reduction of earlier IT eras.

53


■

The poor track record of IT in successfully delivering benefits from investments is a major barrier to more effective engagement with the business and a greater ability to influence the business.

■

It is possible to make a dramatic improvement in the success of IT projects by adopting a number of tried and tested techniques and making a number of changes in approach that together represent a paradigm shift in the management of IT for business value. Focus engagement with the business around the information systems strategy – the key is to understand where there are opportunities to use the technology to enable business changes and to realize business benefits. Manage the information technology strategy separately, i.e. how the IT function will deliver the business requirements. Adopt a portfolio approach to IT investments/projects. Ensure project approaches, resourcing, etc. are appropriate for the different types of project. Encourage and plan for learning: – Plan for learning/development of staff as part of projects, e.g. through appropriate mentoring/coaching. – Encourage a climate where learning from all experiences – both good and bad – is encouraged. – Deliver major changes through a series of short projects – providing the opportunity for learning and change. Make the versioned release/incremental approach a core way of working. – Provide appropriate training and learning opportunities. – Review lessons learned at key milestones and at project completion and ensure they are acted upon.

DOS AND DON’TS ■

Do put time into recruiting the best people and developing a team with real expertise in specific areas.

■

Do focus on an 80 : 20 solution.

■

Do allow the team the freedom to do the job.

■

Do adopt the investment portfolio as a key element of planning for investments in IT.

■

Don’t panic when issues arise – let the team fix them.

■

Don’t let the bureaucrats take over – keep the minimum of controls, and make sure there is a clear purpose for any paperwork and for every meeting.

54


ACTION PLAN Review all current projects and consider: ■

Is the approach being taken appropriate in the context of the investment portfolio?

■

Are any projects scheduled to go live in more than six months’ time? Review carefully and consider splitting up or stopping.

■

Have any projects already been running for longer than six months? Review carefully – be prepared to take some tough decisions.

■

Do any projects involve substantial business changes? Plan for learning by ensuring the plan will deliver a version to the business quickly and then plan for further development. Ensure there are clear objectives and target benefits and that there is a strong team. Plan for an early release and plan to manage the learning.

■

If required, split up projects so that each project is in one quadrant of the portfolio.

■

Review projects that have been completed in the last three to six months to assess the benefits delivered and identify opportunities for further benefits.

■

Review the investment portfolio every six months to reassess the continuing relevance of projects and plans to ensure an appropriate balance of resources.

■

Review personal objectives. Consider the likely impact on incentives for teamwork and learning.

■

Use projects to provide specific learning opportunities for both business and IT staff. Use them to test out and give experience to ‘high fliers’.

55

Part two Being successful – getting the basics right

■

5

Benefits management

■

6


■

7


111

■

8


125

59 87

In this part the emphasis switches to practical guidance for business managers on ensuring that specific investments do deliver business value and that the enabling projects and programmes are run successfully. Key areas covered include: ■

benefit management – a tried and tested management process for managing a project with a focus on delivering measurable business benefits;

■

project management – key aspects of project management that should be the focus of senior management attention;

■

programme management – a simple framework for succeeding with programme management.

57

5 Benefits management

■

Background to the benefits management process

■

The BM process

■

Steps for identifying and structuring benefits

■

Driver analysis

■

The benefits dependency network

■

Stakeholder management

■

Measurement of business value

■

Conclusions

61

62 64

64 68

71 74

85

59

Benefits management

BACKGROUND TO THE BENEFITS MANAGEMENT PROCESS The benefits management process was evolved over a three-year period through applied research done by the IS Research Centre at the Cranfield School of Management and the active participation of 12 major UK organizations who sponsored the research. Subsequently it has developed further through monitored usage in over 200 organizations some of whom have made it mandatory for IT investments and a few who have made it mandatory for all investments for change. The background was simply a concern that despite huge investment in IT the potential benefits were not being fully realized (an averaging of surveys on this topic shows that around 70 per cent of IT projects do not deliver the expected benefits, so there was much scope for improvement). The set of challenges that the sponsors felt they faced are charted in Figure 5.1. It is not to be interpreted as ‘left column is wrong, right column is correct’ but rather as a spectrum with organizations deciding where best they should lie. Some of the activities on the left are essential anyway and should be done with as much professionalism as possible but the firm belief was that even if all the left-hand column entries were done optimally that was insufficient and most organizations wanted to be more in the right-hand column. Fig. 5.1

The benefits management challenge

From

To

■

Technology delivery

■

Benefits delivery

■

Value for MONEY – low level task monitoring

■

VALUE for money – benefits tracking

■

Expenditure proposal – loose linkage to business needs

■

Business case – integration with business drivers

■

IT implementation plan

■

Change management plan

■

Business manager as onlooker/victim

■

Business manager involved and in control

■

Large set of unfocused functionality

■

IT investment which is sufficient to do the job

■

Stakeholders ‘subjected to’

■

Stakeholders ‘involved in’

■

Trained in technology

■

Educated in exploitation of technology – talent harnessed

■

Do technology and project audits

■

Obtain business benefits then review with learning – leverage more benefit

Some of the challenges listed are self-explanatory but a few are worth commenting on further. In the value-for-money issue it was agreed that most executives would,

61

Part 2 Being successful

if the benefit set was fully and properly explained, know what costs they were prepared to sustain to get those benefits. A marketing director, for instance, would have a clear view on how much the value of a reduction in time to market of, say, three months would be. Therefore one of the emphases of benefits management is to unpack and articulate the value set in terms that make sense to the stakeholders. A clearer linkage to the drivers in the business was considered essential. One of the truisms emerging from the research was that it was only when people worked differently that performance improved, therefore in terms of realizing benefits there had to be change management plans that would translate the capabilities delivered by the technology into new and better ways of working. While all projects like to be considered as ‘business-led’ the research considered just what degree of management involvement and control is necessary. Lastly many organizations consider themselves ‘learning organizations’ but in a survey of 62 UK blue-chip companies done as part of the research only one-quarter of them said that they formally reviewed whether they had got the benefits from their IT projects. Not only does this start to explain why some people can put exaggerated claims into an expenditure proposal (no one will ever check whether the benefits actually appeared) but how will the lessons from both failure and success ever be communicated if they are not even evaluated? There was also a strong belief that planning the realization of further benefits from implemented systems or services was too informal or non-existent and that easily achievable increases in returns on investment were being missed. There now follows a description of the process, tools and techniques that arose from the research in order to address the benefits challenges just described.

THE BM PROCESS The benefit management (BM) process model, which is based on TQM (total quality management), has five major identifiable sub-processes (see Figure 5.2).

Identifying and structuring benefits The proposed benefits are identified (this includes the rationale for the benefit as well as the nature of the benefit and its location in the organization), and for each one suitable measures are developed – both financial and non-financial measures can be included. The benefits are structured in order to understand the linkages between technology effects, business changes and business objectives. At this stage, it becomes possible to assess the overall business benefit set and its dimensions including the identification of disbenefits.

62

Benefits management

Fig. 5.2

Process model of benefits management

Identify and structure benefits

Potential for further benefits

Plan benefits realization

Review and evaluate results

Execute benefits plan

Benefits planning The benefit plan is the set of change programmes that will cause the benefits to appear. It is separate from the technical implementation plan but of course depends on the latter to introduce the enabling technology. Frequently IT-enabled projects have detailed planning charts that terminate on the day the system is implemented. The benefits plan necessarily includes the dates when the benefits will appear and the resources, success measures and accountabilities for making sure that benefits do appear. It is strongly suggested that no expenditure proposals are approved unless they include a robust benefits delivery plan.

Execution of the benefits plan This stage is principally change implementation with business managers owning the benefit stream(s) and driving through the change programme that will deliver them. During the execution the prime directive is that value is being added. (Cf. technology being installed or projects being delivered – the standard goals of technology projects.)

Evaluating and reviewing The benefits plan must detail the appropriate measurement and benefits tracking mechanisms, and as part of the execution of the plan those mechanisms need to be in place and functioning. Review is not of the project progress (dealt with by

63


the project procedures) but of the realization of benefits. Benefits rarely appear on Day 1 of a system, and some accumulate over quite long periods. In multi-phase projects the early phases often lay in capabilities that will be exploited in the later phases. The review should ensure that these capabilities have been achieved – it often happens that the technical wherewithal is closely monitored but the attendant changes in the business (e.g. provision of a new skill set) get far less attention and the project proceeds in an unbalanced and therefore risky manner.

Potential for further benefits Further benefits can be identified at any time but should in any case be formally explored at the review stage. Often at the end of a project the organization has at its disposal a team who now know more about the topic than anyone else has ever known recently. Instead of disbanding that team it could be usefully employed to derive further return on investment. The experience of working the model has shown that the more time and effort spent in getting a high quality start then the easier the subsequent stages become. Conversely if the benefits are not understood well or not identified with enough clarity, and not structured sufficiently so that it is unclear who all the stakeholders are, then the project becomes primarily a technical one since that is the only aspect known with certainty.

STEPS FOR IDENTIFYING AND STRUCTURING BENEFITS The approach for identifying and structuring benefits that has worked well is a sequenced set of questions (see Figure 5.3) which, if answered sensibly and well, will allow benefits planning to be carried out and also will naturally facilitate the writing of the business case for the system and its expenditure. (It may also show of course that there is no case or only a weak one.)

DRIVER ANALYSIS Driver analysis is a structured way to investigate ‘Why do we want the improvement?’ In other words what are the drivers in the organization that are causing it to seek changes and hence improvements? The rationale for analyzing the drivers is that: ■

the beginning is the best place to stop bad projects (weak or insufficient rationale);

■

it sets out how the investment should link into business plans both in terms of project objectives and scope;

64

Benefits management

■

it reveals strength of ownership at senior levels in the business and identifies the sponsor(s) and their interests;

■

at a high level it determines how success will be recognized;

■

it locates IT expenditure proposals as an investment in the future of the organization’s capability – not merely a parting with money to acquire modern technology.

Fig. 5.3

The dimensions of benefit management

Why do we want improvement? What improvement do we want/could we get?

Where will it occur?

Can it be measured?

Can it be quantified?

Can a financial value be put on it?

Who is responsible for its delivery? What changes are needed?

Who will be affected? How and when can changes be made?

BENEFIT DELIVERY PLAN

Benefits achieved? More benefits possible? Further actions?

A driver is something that is causing the organization to change in some way. Responding to drivers is the domain of the senior management team and so ‘driver’ is defined as: A view held by senior managers as to what is important in the business, in some given timescale, such that changes must occur. Having decided the changes that need to occur, some investment of management time, effort and resources will be needed to effect the changes. If IT is seen as a potential enabler of the changes then typically a project will be set up. The project takes as its aim the objectives of the investment that the senior manager(s) have determined are required to make the changes. The benefits to the organization will arise from the changes to the ways of working and they must always support and link into the investment objectives in a close fashion. The project team should be ever alert to preventing the project evolving its own separate objectives – which are often more related to what is functionally available from the technology than

65


what is desirable in a business benefits sense. Without careful measurement there is a high risk of blurring ‘functionality’ and ‘benefit’. Driver analysis aims to understand the drivers, the required changes that have been decided, and then the consequent investment objectives for the project that will ultimately enable the changes. The term ‘investment objective’ is to be taken as a high-level statement of the desired end state, i.e. just where the finishing-line is in the race. It doesn’t cover what has to be done to get there, or how – those choices can be delegated to stakeholder managers, project managers and other specialists who are equipped to help exploit the technology. It is worth noting that by their nature drivers cannot be changed or made to go away – they exist independently of any kind of programme or project. The investment objectives represent what an organization chooses to do about the drivers.

Points to consider in driver analysis 1

The issues being addressed: – survival; – success; – prosperity.

2

The degree of change being contemplated: – elimination – improvements by removal of procedures, activities, cost, etc. – business as usual – managing a stable situation (even stable set-ups need maintenance investment); – targeted incremental improvement – improvements within existing resource and management frameworks; – radical change – improvements from doing something in a completely new way.

The business risk increases from top to bottom as the degree of change being contemplated increases. Use of the above two lists to engage business managers in a useful dialogue can help focus as much as possible the objectives, scope and likely success criteria for the investment. A successful outcome of that dialogue will be: ■

a clear written statement from senior managers as to what the drivers are;

■

a clear statement of the desired changes and how senior managers see them being beneficial;

■

an agreed set of investment objectives for the project that everyone agrees will assist the changes and the response to the drivers.

66

Benefits management

These statements should make reference to the investment portfolio thus showing how the investment is contributing to overall business performance and also how it relates to other investments. There is a need to be reasonably persistent at the driver analysis stage since this is the point where it is best to rescope projects or kill those that should never have started in the first place. The competitive analysis technique has proved very successful in helping to structure the discussions around drivers and what needs to be done about them. It attempts to set the drivers into the context of the organization’s environment, especially its marketplace. The technique also has the virtue that it is easily understood and quickly applied.

Competitive analysis The competitive analysis approach asks managers to assess where they are in relation to their competition according to three factors: product leadership, customer intimacy and operational excellence. Managers are asked to ‘score’ by placing their business or business unit on each of the three axes (see Figure 5.4). In the diagram the heavy circle is equated to ‘adequate’, i.e. you are alongside the competition. Inside the circle is read as ‘behind’ the competition with well inside placing the business in survival mode. Outside the heavy circle is ‘ahead’ in the marketplace so prosperity can be contemplated. Fig. 5.4

Analysis of competitive position

Advantage and disadvantage: dimensions of competence

Customer intimacy Prosperity

Success Survival

Product leadership

Operational excellence

67


Projects addressing ‘survival’ are usually copying the rest of the sector or industry in order to catch up. Those on the circle are either ‘business as usual’ or incremental improvement. Those designed to take the business ‘ahead’ may have a radical change aspect to them since by definition no one else in the industry is doing things this way. It is worth paying attention to the combinations since ultimately they interact, e.g. good customer intimacy cannot be sustained for long if operations are below average and there is no clear product leadership. Also the positioning is relative, and sometimes by doing nothing competitive activity moves the organization inside the circle. Typically IT-enabled changes help operational excellence the most but recent years have seen IT making real contributions in all three domains.

THE BENEFITS DEPENDENCY NETWORK Having established the investment objectives in relation to the organization’s drivers the next step is to determine what improvements or benefits need to be delivered from the investment that will cause the objectives to be met. The key questions are: ‘What improvement/benefits can we get?’ and ‘Where will the improvement/benefit happen?’ A benefit is defined as: An advantage on behalf of a stakeholder or group of stakeholders. These stakeholder advantages must of course be contextualized to the drivers by linking them to the investment objectives. So starting with the declared objectives a network of dependencies is built up. The elements in the network are (see Figure 5.5): ■

investment objectives

■

results or primary benefits

■

business changes

■

enabling changes

■

enablers.

Business changes, i.e. new ways of working, can rarely be introduced without some enabling changes happening such as new processes to design, new job descriptions, new reward structures. Enabling changes (training, acquiring new expertise, etc.) are by nature ‘one-off’ and usually can be started immediately or as soon as some IT enabler is functioning, whereas new ways of working depend on the enabling changes and enablers, are enduring and take time to introduce.

68

Benefits management

Fig. 5.5

Benefits dependency network Externally facing

D R I V E R S

Internally facing

IS/IT enablers

Enabling changes

Business changes

Business benefits

Investment objectives

In summary: ■

the drivers say why the investment is being made;

■

the objectives define the end point or state what the investment is aimed at;

■

the objectives therefore define the benefits set – not the other way round;

■

the benefits are what will appear in the business;

■

the rest of the network (changes and enablers) describes how the benefits will appear.

The enablers that we concentrate on are IT-related but could cover other important non-IT enablers such as recruitment/development of a particular kind of skill. The network is constructed right to left, i.e. starting with the desired end-state (objectives) and logically working back to the enabling technologies. In practice it is not easy to do since most of us naturally think left to right and certainly implementation will occur that way. When done successfully the following advantages accrue: ■

IT investments are linked to high-level business objectives.

■

The changes needed to achieve the objectives are all charted.

■

Ownership starts to become clearer: – Senior managers can own objectives and primary benefits; – middle managers can own the business changes;

69


– supervisors and personnel can own the enabling changes; – IS/IT managers can own the (IT) enabler set. ■

The linkage and interdependencies of all of the above are made clear.

■

Everyone starts to understand ‘where they fit in’.

■

A basis for benefits planning is established.

■

A useful communication device is created.

In addition, two important extra attributes can be developed which will help ensure success and certainty that it has been attained. Since each element in the network constitutes an improvement over the current situation two questions can be usefully posed: ■

‘How will we know the improvement has occurred?’ – the answer constitutes high-level success criteria.

■

‘What is the name of the person who will ensure that the improvement occurs?’ – this establishes accountability for beneficial change. Note the stress on obtaining an individual’s name.

Like the other techniques being described the most important added value deliverable is the managerial consensus achieved through discussion and debate that occurs during the creation of the benefit network. The approach to use is a facilitated workshop with the following practical caveats: ■

Ensure all the entries on the network are improvements – just putting ‘standards’ in implies the absence of any standards. Instead, deliberately record the improvement in the standards that are needed (quality, currency, relevance, distribution, enforcement or whatever).

■

Remember that a ‘benefit’ must be perceived as an advantage to someone.

■

Be very firm about linkages being true enabling links – linking ‘document management’ directly to ‘improved productivity’ is avoiding the issue. Someone has to use the improved documents in a different way that demonstrably increases their productivity, so the missing element is a description of the use of the documents in an improved way of doing something.

■

Remember also that ‘things only get better when people start doing things differently’. So, for instance, faster, more accurate, more accessible, better formatted, more current data is never a benefit – it can only be an enabler.

■

Entries that cannot have a measure assigned to them or a responsibility should be removed or more work done until that clarity can be established.

It will be noted that in the description of the benefit network and its usage there is much more reference to the people involved than in a typical project methodology. That aspect is now examined more fully.

70

Benefits management

STAKEHOLDER MANAGEMENT Stakeholder management analyzes the issues around ‘Who is involved and who is affected?’ Stakeholders are defined as two groups of people: those whose active participation is essential if the benefits are to be realized; and those who will be affected by the introduction of the system and the changes. Some may of course belong to both groups. Identification of all the stakeholders and analysis of their perspectives and attitudes to the changes implied by the project is essential since no benefits will emerge if their involvement is not correctly managed. The following needs to be done: ■

All stakeholders have to be identified.

■

Their perceptions on benefits, disbenefits and resistance, if any, need to be understood.

■

Any changes that are needed by them must be made explicit.

■

Their commitment to the project should be established together with an appreciation of whether it needs to be changed or embraced in some other way.

One approach which has shown itself to be effective is the structured use of the form in Figure 5.6. Fig. 5.6

Stakeholder group

Stakeholder analysis Perceived benefits (disbenefits)

Changes needed

Perceived resistance

Commitment (current and required) Anti

None

Allow it Help it to happen happen

Make it happen


Each group of stakeholders is identified and their perceived benefits (or disbenefits) are established. Any changes that the group itself must undertake for the benefits

71


to appear are documented, as is their perceived resistance to those changes. The last five columns are an aid to assessing the stakeholders’ commitment and hence the amount of managing that has to be done to get the right degree of involvement. For each group a ‘C’ (= current commitment) is marked in the appropriate column (e.g. ‘anti’) then an ‘R’ (= required commitment) is marked in the column where the stakeholder ‘needs to be’. Clearly the further apart the C and R are the greater the amount of change intervention is needed. Experience shows that any stakeholder who is one column to the left of where they ‘should be’ can usually be influenced by their manager to make the transition (e.g. from ‘anti’ to ‘none’ or ‘allow it to happen’). Where the change in commitment is two or more columns then there is an explicit change management task to be addressed. It must be addressed or otherwise the new working and hence the benefits will not come about. Where the transition needed is three or more columns the stakeholder’s position is likely to be more of a ‘hearts and minds’ issue and should be treated so. Very firm instruction will not work since the recipient is responding less from the head and more from how strongly he or she feels about the changes; they may feel very threatened and confused so rational debate cannot be the first step. It also follows that any ‘two or more column shifts’ should be entered in the dependency network as enabling changes. Most workshops in creating benefit dependency networks find it relatively easy to identify ‘hard’ enabling changes such as ‘rewrite standards manual to meet ISO 9000’ or ‘design new procedure’. However, the ‘softer’ people-oriented issues either get missed or dismissed sometimes under the easy catch-all of ‘culture and politics’ which technical personnel can regard as outside their domain or interest. Some points to consider in stakeholder analysis are as follows: ■

It is usually wise to focus on those stakeholders who will experience the most changes. However, those who will get a lot of benefit but experience little change need managing as well since they can become impatient with other stakeholders and try to force unreasonable rates of change progress, causing adverse reaction and sometimes disruption.

■

New benefits should not appear at this point. If discussion shows there may be more, then the network activity needs revisiting. Appearance of more benefits could indicate that the attendees at the initial workshops were not representative enough.

■

Remember it is perceived benefits and perceived disbenefits that matter here since ultimately stakeholder reaction always boils down to one question: ‘What’s in it for me?’ – a question that should always be answered even if the answer is unpopular.

Success in stakeholder analysis can be judged by the following:

72

Benefits management

■

All stakeholders are identified, informed and involved to an appropriate degree.

■

All perceptions and commitments are documented and agreed as representing the current situation.

■

Managers agree how the commitments improvements will be tackled.

■

Disbenefits are properly discussed and documented, and a management response is given or a date when the response will be forthcoming.

■

There is sufficient clarity and agreement of the changes needed so as to form the entries in the benefits plan for explanation to and discussion with the sponsor.

■

The completed chart and change responsibilities are documented as part of the project documentation.

It is not uncommon for senior business managers to discover at this point that they have a key role (especially where the commitment change is more of a ‘hearts and minds’ change since no amount of rational explanation will alter things in that case), and that this is a surprise to them. The surprise comes from an assumption that ‘the project will deliver it all’. The initial stakeholder groups should emerge from the network and structuring workshops. More may appear as the benefits set is understood in more detail.

Accountability for value One of the underlying causes of the failure of IT investments to deliver business value is the confusion of roles and resulting lack of accountability. Benefit management addresses this and ensures there is clear accountability for value. The whole process helps to clarify accountability by ensuring that the benefits are measurable and that their delivery is owned. The key principles of benefit management emphasize this: ■

ownership – every benefit stream must have a benefit owner;

■

measurement – unless a benefit can at least be observed it does not exist;

■

improvement – performance only improves when people do things differently.

The final principle emphasizes the accountability of the business – the IT solution can enable the business to achieve benefits but it is the business managers who must make the changes that will deliver them. One-on-one interviews that expose concerns etc. should be followed up with a plenary session of key stakeholders (or their representatives) to avoid suspicions of ‘hidden agendas’, especially in contentious changes. Besides accountabilities being assigned at the network development stage mention was made of measurements of success. This is now developed further.

73


MEASUREMENT OF BUSINESS VALUE During their execution technology-based projects (especially large lengthy ones) can display an unwelcome characteristic, namely the habit of gradually modifying their goal set until the aim of the project becomes almost exclusively the implementation of the technology. Success then becomes delivery according to project criteria (typically ‘to budget and on time’ and to internal methodology performance levels) instead of business value criteria (i.e. something that improves business performance).

Case study A manager from an international microchip manufacturer approached us saying that for three years they had been implementing SAP (an Enterprise Resource Planning (ERP) system) throughout their European plants and he wasn’t sure if they were going to get all the benefits from the package. When asked to recount their reasoning as to why they were implementing SAP throughout Europe he paused for some time then replied that he had forgotten. It was worse, he continued, because all the managers who had initiated the programme three years earlier had moved on. They were implementing SAP ‘because they were implementing SAP’. The really bad news was that the project was now entirely technology-led, there were no business managers involved any more, and the sole aim had become to implement the software. The example just quoted usually creates amusement when retold, but most executives acknowledge any laughter is the laughter of recognition. When a project is lengthy and technical it is all too easy for busy executives to hand over control to the project methodology mechanisms. Careful management of measurement can prevent that slide towards business non-relevance and firmly place organizational benefits as the prime aim of an IT investment. There are also two other crucial and neglected roles for business value measurement, namely the presentation of a robust defensible business case when proposing technology investments, and change management.

Stages of measurement Measurement plays a key role in investing for business value at three stages of the investment programme: 1. at the time of the business case proposal; 2. as the investment starts to impact on the current way of working; 3. when the desired business value results are delivered (or otherwise).

74

Benefits management

Conceptually these are best approached in reverse order. Measurement is fundamentally part of the navigation and control system for an investment programme and since it always pays to know where the journey’s end lies before committing to investment in some technology to get there faster, the business benefit measures are considered first. Experience and research at Cranfield IS Research Centre shows that, in addition to the involvement of business managers, measures of business benefit are the best way of maintaining focus in an investment programme. Creating measures in a proposal document that are relevant and which can also be substantiated is quite difficult and discussion of those measures is tackled last. At the approval stage there are several mindset traps around as well as a number of games that regularly get played out in creating investment proposals. These are worth examining since they throw light on what is genuinely required before investment funds are committed.

The desired end-point Value is always contextual and an investment programme must have clear objectives that relate to the wider business drivers. As stated earlier ‘driver’ here is taken to mean something which is causing the business to have to change, e.g. competition, regulation, the euro, the shareholders’ attitude, etc. The current use of the term ‘objective’ unfortunately covers many things and so lacks useful precision – in this briefing it is meant to be a description of the end-state that senior executives want the business to be in so as to have addressed the drivers. In other words ‘investment objective’ is a high-level delineation of just where the finishingline is in the race. It doesn’t cover either what has to be done to get there or how – those choices can be effectively and economically delegated to stakeholder managers, project managers and those others equipped and sufficiently clever to exploit the technology. As much precision as possible in formulating objectives is crucial, and the more useful measures that can be attached to an objective, the better will be the understanding and commitment of all of the stakeholders and hence their willingness to adopt new ways of working that will deliver the benefits. It is hard to over-emphasize the importance of this last assertion, and our research and consultancy experience indicates that it is a critical factor. Thus the prime measurement for an investment is the one that answers the question: ‘How will we know that we’ve met our business objectives?’ If, for instance, market pressures have driven the business to lower its unit costs then (hopefully) the cost accounting system can provide the measures of changes in unit cost. If, however, the objectives are declared as ‘to make the sales force and customer service units more flexible, more responsive, and be able to cope better’ then how would anyone know whether that had happened? The sales director

75


might claim that measures aren’t needed since he or she would know if the flexibility etc. was now there or not. This is, however, too vague in a number of ways. Just how much more flexible, responsive, etc. do they need to get? And by when? Will a point be reached when they stop trying to be more flexible? The main omissions are a lack of any clear guidance to the project team or the salespeople as to where they are aiming and the absence of any certainty as to how they will know whether they’ve got there. With such fuzzy open-ended objectives it will be sadly all too easy, after the IT system is implemented, for some to say it has been successful and others to claim it has failed. In practice stakeholders and project managers will invent their own, more precise ‘sub-objectives’, such as faster flow of data among sales people and customer service personnel, which while not unreasonable in itself has no direct link to a business driver. Reflection will show that the stated objective is not an objective according to the definition outlined above since it describes a change in personnel’s activities but doesn’t articulate to what end the new responsiveness and flexibility will be addressed (i.e. no end state is described). Presumably the unstated driver is that the competition is currently far more agile and is winning business because of it – if so then the objective is in fact to rectify that competitive disadvantage and take business back from the competition. This is more of an objective for sales managers to address, armed with the new systems, than an objective for the project (as noted before, IT only enables an outcome – it is managers who choose how to turn that outcome into a benefit). The invented data flow sub-objective is even further removed from a desired end-state since it represents an improvement in input to the sales activities. A framework is described below which solves the issues regarding lack of clarity of measurement, allows meaningful output-oriented measures to be developed and additionally exposes new sources of benefits. It begins by treating the area of the business needing improvement as a process. Established process improvement techniques are then applied with close reference to the contribution that IT can make. In this approach any area (or subset) of an organization can be thought of as a process with inputs, a set of related activities and some outputs. Improvements to a process will generally be to cost, speed or quality. Thus it is possible to set up a three-by-three matrix (see Figure 5.7). This matrix is worth completing for any investment since it unpacks generalizations about benefits. The output column should contain at least one entry, i.e. a beneficial outcome. Typically IS/IT investments tend to be justified in terms of improving the cost and speed of inputs (a historical hangover), but contributions from IS/IT can exist in all nine cells. For each improvement a relevant set of success measures can be developed. If a meaningful measure cannot be stated then the benefit should be struck out because even if it did occur no one would know, or could show, it had. Experience shows that analyzing the gaps (i.e.

76

Benefits management

reasons for any empty boxes) is very worthwhile and can lead to useful widening of the scope of impact of an investment. Fig. 5.7

Measuring process change

IN

OUT ACTIVITY

IN

ACTIVITY

OUT

Cost

Speed

Quality

Case study A major pharmaceutical company installed software to automate the handling of the vast amounts of data generated in the drug development laboratories during the toxicological testing phase. The main objective from the laboratory managers’ perspective was improvement of efficiency of working (less time spent processing data by scientists equalled more time at the bench doing ‘real science’). When the form similar to Figure 5.7 was filled in, the bottom two cells in the output column were empty. Analysis showed that the automation could improve speed of handling to the extent that the drug could go forward into the last stage of development (clinical trials) three months earlier. Besides a cost saving (it typically costs around £15,000 per hour for a drug in development) a reduction of three months in time-to-market is a huge gain – earlier therapeutic benefit to patients, earlier market penetration, as well as three months’ protected sales while under patent. In terms of the investment portfolio the investment had moved from key operational/support to strategic. Subsequently the business pull-through for the systems to be implemented became justifiably immense and the chief success measure moved from an internal productivity gain to become ‘Reduction in time-to-market by three months or more’.

77


Experience shows that the matrix, while appearing somewhat straightforward, is both a subtle and powerful technique. It has the obvious practical virtues of representing the whole benefits set (with appropriate derived measures) on a single sheet, can be readily understood in a very short time and can promote synergistic debate among stakeholders and stakeholder management. It also usefully deflects any of the sweeping assertions of technology providers away from minor or nonrelevant ‘improvements’ (usually efficiencies on inputs) and can increase the focus of project activity onto what really matters. Some business priority can also be put on the sequence of implementation of the benefits in the matrix (e.g. ‘improve the quality and speed of customer service first, then when that has been firmly established take out cost’). One subtlety to note is that an improvement in one input row may result in an improvement in activity or output in a different row. For example, consider a monthly planning cycle where it takes around a month to assemble and refine the plans for the following monthly period, i.e. each month is a planning cycle for the next month. Improvements in speed due to IS could if sufficiently large mean that the planners could do two runs of the assembly/refinement cycle in the month prior to the month being planned. By facilitating more refinement and allowing several scenario comparisons this could well result in a higher quality plan. Thus a speed improvement on the input side results in an efficiency gain in activities (two planning runs with no extra staff) which translates into a quality gain on the output side. The matrix also allows detailed confirmation of the nature of the investment according to the investment portfolio categorization (role and contribution to business performance). Figure 5.8 shows how the two charts work together. Fig. 5.8

The investment portfolio and measuring process change IN

OUT

IN Cost

Speed

Speed

Quality

Quality

IN

78

ACTIVITY

Cost

ACTIVITY

STRATEGIC

HIGH POTENTIAL

Investments in IS/IT applications which are critical to sustaining future business strategy




KEY OPERATIONAL

SUPPORT

OUT

IN

Cost

Cost

Speed

Speed

Quality

Quality

ACTIVITY

OUT

ACTIVITY

OUT

Benefits management

Earlier reference has been made to change management and the need to recognize that benefits only flow from changes to the way business is done. The matrix establishes and communicates what changes are required (the ‘Activity’ column) and furthermore defines how they relate to meaningful business value gains (the ‘Output’ column) thus creating understanding as to why the changes are needed. The associated measures not only establish relevant success criteria but also communicate with clarity just what senior executives see as important. Output- and activity-oriented measures based on business benefits are more motivating than efficiency input control measures. For example, ‘Growth in customer’s business due to our products and services’ or ‘Number of new products/services introduced to customers’ or ‘Increased quality time spent with customers’ will clearly generate more commitment and job satisfaction than ‘Keeping the average call-time with customers to less than 90 seconds’.

Measurement at the time of implementation At the time that the system is implemented the changes to activities and outputs together with their associated measures need to be clearly articulated and understood by all stakeholders as part of the change plans. The likelihood is that as time has progressed in system development much will have become clearer and several assumptions tested and so on. It is therefore appropriate to consider reviewing and revising the success measures in the light of that updated knowledge. Other things may have changed as well during that time – some of the drivers may even have altered. We now return to the stage that is chronologically first – the business case at the proposal stage.

The role of measurement in the business case When the business case is being developed uncertainty is greatest since nothing has yet physically happened so hard data is difficult to acquire. Furthermore, the traditional mechanism usually in place to address this – the expenditure proposal procedure – is generally viewed with some professional disdain by those seeking investment funds and especially so by technical managers. The latter profess dismay at the hurdles placed in their way involving the arcane niceties, for instance, of DCF (discounted cash flow) or projected NPV (net present value). When the disillusionment they feel towards the procedure is coupled with their own certainty of the innate value of their proposition, it becomes easy to duck the task required of them (which in reality is only clearly stating what measurable desired business benefits will arise at what cost). They are then vulnerable to playing games and can arrive at a position of writing down whatever it is that will allow them to get

79


approval for the funding – after which they return to ‘the real job’ of the project as they see it. Such proposals if approved (and many are) start life without any sound measures of success (most of them have been made up or are not relevant) and thus it is very difficult to monitor the project outcomes in business terms. Instead control is then passed (but not in a transparent way) to the control mechanisms of a project methodology. Such methodologies tend to emphasize technical soundness, budget and completion on time as success criteria. The business navigation system can almost disappear – to be replaced with technical delivery goals and aims. Scrutiny of many expenditure proposals has shown what can appear in such proposals if the mindsets above are predominant: ■

The features of the system are listed, not the benefits (e.g. ‘the date and customer name will only have to be entered once’). Some IT sales people and consultants gently encourage this weakly comforting approach.

■

Outcomes are substituted for benefits (saving time, for example).

■

Input improvements are stated as benefits (e.g. ‘Communications with our overseas offices will be at least 50 per cent faster’ – but so what?).

■

Targets are confused with demonstrable benefits (e.g. ‘We’ve been told that the system must save £7 m per annum – the finance director has already taken the money out of the budget, so that’s the benefit that has to go in the business case’).

■

An anodyne proposal is offered with no numbers at all (e.g. ‘With our new echannel we’ll sell more, cost less, and make people happier’).

■

An endless bullet-point list is provided covering just about everything possible in the hope that somewhere a ‘hot button’ will be turned on. A variation is to ensure that the proposal apparently addresses the current top driver (e.g. if, in a call centre, the main driver is to reduce call-handling time then that will appear in most expenditure proposals, even those whose impact is quite distant from call-handling activity).

From the business accountancy side a relatively common semi-abuse of terminology which masquerades as an investment criterion can also appear. A distinction is drawn between ‘tangible’ benefits and ‘intangible’ benefits, the subtext being that ‘intangible’ benefits are not allowed in business cases. The reality is that what is really meant is ‘financial’ and ‘non-financial’ with the latter excluded (the historical hangover of bottom-line impact as the only permitted justification for IT expenditure). The rule ought to be, first, that all benefits must be tangible – in the sense that they must at the very least be observable so as to receive any consideration let alone investment – but that benefits can legitimately be classed as financial or nonfinancial. Sales managers, for instance, do see improvement in their sales force’s agility as important, and hospital trust managers would see improvement in patients’ quality of life as very important.

80

Benefits management

Avoiding all of the above can be hard work but is essential if top teams are to be presented with sound business case proposals that can be properly assessed in business benefit terms. There now follows a proven technique for achieving this that has the added merit of occasionally throwing up a bigger range of benefits than first contemplated and even causing organizations to usefully rescope an investment. It emphasizes the importance of substantiating all measures stated in the proposal and classifies them according to how explicit they can be made – at this early stage where uncertainty is at its highest.

Grading the certainty of measures in a business case The approach adopted is to be formally but constructively pessimistic about putting claims forward in an investment proposal. This is to ensure that the case submitted is robust and defensible. In preparing the case all benefits should be classed as to how explicit they are at this point in time by ranking them as: observable, measurable, quantifiable or financial (see Figure 5.9). Fig. 5.9

Structuring benefits

Degree of explicitness

Do new things

Do things better

Stop doing things

Financial

Quantifiable

Measurable

Observable

The minimum requirement to meet before a benefit can be listed is that it should be observable. If nothing can be observed then arguably it does not exist. It follows that such observable-only benefits need at least a precise form of words to allow understanding and subsequent assessment of achievement. Benefits such as ‘improved company image’ or ‘increased international team morale’ will need to be made more specific to the organizational context. If a benefit is clearly observable the next test is whether it will be ‘measurable’ or not. This is simply a binary question to which the answer is either yes or no and separates qualitative benefits from quantitative benefits.

81


If a benefit will be measurable the next business case test to be applied is whether actual numbers are available now for submission in the proposal document. These are not targets; they are figures that can be logically justified at the time of presentation of the case. Where numbers are known then the benefit is classed as ‘quantifiable’. Lastly if a benefit is quantifiable and the figures can further be expressed in monetary terms then the benefit is classed as ‘financial’. An illustrative example might be an investment that will improve the yield of a process. The benefit should be observable. Before it is classed as such the question ‘Will it be measurable when it appears?’ is asked. In the chosen example this should be true so it ‘moves up’ in explicitness terms to ‘measurable’. The answer to the question ‘What improvement figures can we put in the business case?’ may be more difficult to achieve. If the investment is innovative to the extent that the approach has never been used before then the answer may well be ‘no’, in which case the benefit remains classed as ‘measurable’. If, however, visits to reference sites or earlier trial work can point to a yield improvement of, say, between 8 and 11 per cent then the benefit rises in explicitness to become ‘quantifiable’ and the percentage gains can go forward as part of the case. Lastly, if the yield improvements just quoted can be translated into some financial gain – cost reduction perhaps – then the benefit is so explicit as to be called a ‘financial’ one and the sums of money to be saved can justifiably go in the proposal. However, do not force measurable and quantifiable benefits into the financial box. In many organizations there is great pressure to turn any sort of measurement into a measure of bottom-line financial impact. The argument goes: ■

If we improve customer satisfaction we improve customer retention.

■

If we improve customer retention we improve the lifetime value of a customer.

■

The impact on profitability of this is £x per customer.

There are two main problems – first that a huge number of assumptions are required, and second that the link between the measure and the actual business change required is lost. The measures that drive the change project need to be in terms that can be owned by the line managers involved and can be related to the desired business changes. Note that the terms observable, measurable, quantifiable and financial are here applied not to indicate the nature of the benefit but how explicitly it can be described at the time of proposal submission. Thus even if a benefit will ultimately be purely financial but the actual sums of money cannot be stated with any accuracy in the business case then the benefit at that stage is ‘measurable’. From the perspective of the approval body it is easier to fund cases where the financial benefits are clear and sufficiently large at the proposal stage. However,

82

Benefits management

not all benefits need be financial and the nature of the changes being leveraged through the technology investment may well mean that the proposers cannot be explicit at this stage. In fact consideration will show that the more strategic an investment is, the less likely it is that concrete figures can be put forward, since the investment is (a) in the future and (b) by definition takes the organization into areas it is has not been before. An added refinement that improves the process of assessment of the proposal is to assess the benefit in terms of the organization’s current activities. Is the benefit going to allow: ■

the business to do something new, i.e. something it has never done before? (This need not necessarily require the use of new technology.)

■

the business to do what it currently does but do it better?

■

the elimination of certain activities?

The two modes of classification are brought together in Figure 5.9. There are several advantages from using this benefit classification approach: ■

Top teams like it enormously – the split into ‘stop’, ‘better’ and ‘new’ is attractive. First, cost savings (regarded as the most tangible aspect of a proposal) are clearly identified, and second, most executives want to know what is new – either because it could confer some advantage in the market, or, in change terms, represents the most risky part of the proposal. Also the ‘honesty’ of being explicit about how hard is the benefits data is reassuring.

■

It has a merit of putting all the benefits on one sheet of paper or overhead. This has more impact and facilitates discussion and debate.

■

The formal pessimism around measures generally causes project teams and stakeholders to be more realistic about the benefits and clearer about what they actually are in business terms. This can lead to small pieces of work being done to establish harder figures (e.g. visits to reference sites, trials, modelling or simulation, analysis of existing data banks, or in large organizations finding out whether it has already been done elsewhere in, say, one of the overseas units).

■

In practice it encourages debate among stakeholder managers – assumptions are challenged and quite frequently more benefits are identified.

■

In a similar vein it can multiply benefits. For example, an intranet the aim of which is to improve the speed and quality of exchanges between HQ and overseas offices can also reduce stationery and stationery handling costs, courier charges, telephone bills, etc.

■

It confirms or otherwise the location of the system in the investment portfolio since strategic systems tend to produce most entries in the ‘new’ column, key operational in the ‘better’ column, and support in the ‘stop’ column.

83


■

Also it provides justification for high potential projects in the following way. Suppose a proposal has no entries in the top two rows, i.e. there are no numbers at all in the investment case. This could mean that, first, there are no benefits worth pursuing, or that more work needs to be done before the proposal can be submitted. But it also could mean that some prototyping or pilot work is needed because the nature of the proposal is so innovative that proof of concept is needed before serious investment can go ahead. In this case the proposal has now to be made in two stages – first a proposal to do some ‘R&D’ in IS/IT to show whether or not a benefit does exist, and then later, assuming the prototyping has revealed there are benefits, a second fuller proposal for investment, this time with entries in the top two rows.

Measurement for change management It is commonplace to assert that people don’t like change. This is rarely challenged even when there is much evidence of people asking for change. The latter is especially true in the wider social scene where changes to education, health, law and transport infrastructure are constantly demanded. The resistance tends to occur not around the change itself, but because the individual does not know how he or she will be affected by the change. Attempts to counter this sometimes founder because of language. Senior executives tend to use ‘aspirational strategic’ language, middle managers use the language of resources and change procedures, while those directly affected talk of the problems that need to be overcome in working differently. However, if all parties can agree on a set of measures for success then the language barriers can be largely dispelled. Note that there are measures for change transformation activity as well as measures for the new ways of working. Additionally measures facilitate clearer target-setting for the changes. A hierarchy of measures needs to be set up starting with success measures at the investment objective level, e.g. ‘To win back two major accounts and five mediumsized accounts from the competition, raise our market share by 5 percentage points in the next 18 months, while not increasing cost of sales by more than 2.5 per cent.’ At the next level measures are developed relating more to the changes in activities that are required so as to hit the investment objective. From these, success measures can be developed for the contribution from supporting systems and other enablers or for enabling changes such as improvements expected in customer service from training and education. Measures also have a communication and motivational role as well as being a control mechanism, and their choice can cause staff to raise their sights or, conversely, to behave confusedly or resentfully.

84

Benefits management

Case study One top team invested considerable energy and time to get across the message that throughput had to increase dramatically and everyone was going to be measured henceforth on throughput indices. The message was too onedimensional and they were surprised that staff went on to interpret the communication as meaning they could forget about quality. Single measures almost always fail, and at worst invite people to play the system.

CONCLUSIONS The description supplied throughout this chapter provides a framework and tools for any investment in change – several of the original sponsors of the BM research report that they have used it successfully in non-IT situations; one mortgage bank has used it to assess the benefits of a reorganization for instance. The question sometimes arises as to the relationship between BM and project management. Some business managers have warily asked if it is just another layer of IT-bureaucracy designed to delay even further the delivery of systems. BM overarches project management, the logic being that projects shouldn’t be started until there is a benefits case and that benefits appear and accrue after the project has completed. Perhaps more importantly, BM provides the business value navigation to a project, and experienced project managers cite instances where they chose from optional paths in the project work by simply assessing which choice gave the best chance of delivering the required benefits (cf. technical excellence as a discriminator). Each organization will find a way suited to its own style of operation that blends BM and their current project methodology. One trap to avoid though is to incorporate BM into the IS function’s standards manual – that is a sure way of burying it. BM is a business managers’ technique and as such must be owned by them.

85

6 Project management for business value

■

The team

■

Project start-up

95

■

Project process

96

■

Risk management

■

Other aspects of project management

■

Project management summary

90

104 106

110

87


Benefit management is a key area that will make the difference between success and failure in the overall goal of delivering business value from IT investments. This section covers other fundamental aspects of successful project management. It provides a very short introduction, from a business manager’s perspective, to some of the practicalities of project management and the key issues that typically make the difference to the timeliness, costs effectiveness and quality of the business solution.

Project frameworks and methodologies In this briefing Microsoft Solutions Framework (MSF) is used to illustrate best practice in IT project management and solution delivery. MSF was developed to share the combined experience of the Microsoft product groups developing ‘shrink-wrapped’ software and the consultants in the Microsoft Services Organization working with hundreds of customers and partners on commercial IT development projects. Although MSF was originally developed some years ago the key principles set out are very much in line with the latest thinking, for example on agile development methods. One of the major advantages of MSF is that it is a framework, not a methodology. The term framework encapsulates three broad areas: roles and responsibilities, individual and team behaviour/culture, and process and discipline. MSF has been described as IT project team best practices for success. MSF is a collection of principles, practices, processes, roles and responsibilities, milestones, deliverables, templates and examples that collectively provide structure and guidance to both large and small project teams creating IT solutions. As a framework and not a methodology the MSF focus is on the concepts, culture and way of working required for success. It recognizes that the key to success is to get these factors right. MSF avoids the trap of a ‘methodology’ that can be over-prescriptive and stifle the learning and innovation that will drive ongoing improvement in the IT solution and business benefit delivery capability. There are many choices of project management and systems development frameworks and methodologies. Some of them, for example PRINCE, focus on project management and have little to say in terms of what really determines success in an IT project; others, for example the Rational Unified Process, focus much more on the software design and delivery aspects of a project and are not within the scope of this briefing. PRINCE and Rational do not by themselves address the challenges considered in this briefing.

89


THE TEAM Successful IT projects depend on the capability of the project team. The team and the people who form it are the crucial area. The first thing to focus on is getting the right people. A core of the team needs to be put in place from the beginning of the project – individuals with the right attitude, aptitude and experience. Individuals should be selected for what they can offer and also for their ability to work with others. Just as with other roles, getting the right people may be difficult. It will need plenty of effort and a well thought through approach. Do not make (too many) compromises. The second goal is to start building a team out of the collection of individuals. This briefing will not cover this in any detail but a number of techniques relevant to IT projects are as follows: ■

Provide the team with an area where they can all work together and have space for informal meetings and necessary equipment – this is a prerequisite.

■

Ensure there are early opportunities to succeed – by managing the work as a project from day one and having clear early milestones the team can start to build up a habit of succeeding.

■

Use workshop activities to provide the opportunity for the team to work together – this is a crucial approach in any case in the early part of the project lifecycle.

■

Establish a team identity through project code names and through social events.

■

Allow the team leads to play a major role in the selection of the rest of the team.

MSF identifies six team roles. In a small project this does not imply six different people but it is crucial that all the roles are represented in the project team and that they are covered from the beginning of the project. A core of the team must be in place and covering these roles right from the start. This contrasts with a more typical approach that might see only the project manager and a business analyst involved from the start. The coverage of the full range of roles provides the insight from all the key disciplines that will ensure that momentum is gained early, and that the initial work is of high quality thus avoiding costly rework later on. It is equally important to avoid the opposite mistake of bringing too many people on to the team too soon. This distracts the core team into managing the others, making sure that they have things to do, and distracts their energy from understanding the business objectives and coming up with the solution concept. The fact that the team needs people with different expertise and skills will probably also mean that they have different working styles. It is important to recognize this and not focus on getting a set of ‘clones’ that have the same style. It is also important to work hard to encourage the whole team to value and benefit from these differences, not see them as a problem.

90


When the MSF team model is used as the basis for setting up a team for a specific project it may result in a structure that on paper does not look very different from a traditional team structure. The way of working is, however, very different. The emphasis on the ‘team of peers’ is a healthy reminder that the project manager is only ‘first among equals’ and is not the expert in all matters related to the detail of the project. It is a leadership role, not a controlling, hierarchical management role.

Team model Teams organized under the MSF team model are small, multidisciplinary teams in which the members share responsibilities and balance each other’s competencies to focus tightly on the project at hand. They share a common project vision, a focus on deploying the project, high standards for quality and a willingness to learn. The team model prescribes no single leader: the members work together as a team of peers, each member having his or her own defined role or roles, with each role taking the focal point at different points in the process. The model is comprised of six clearly defined roles. Unrestricted communication is critical: ■

Product management articulates a vision for the product or service, acquires and quantifies customer requirements, develops and maintains the benefit plan and manages customer expectations.

■

Program management drives the critical decisions necessary to release the right product or service at the right time, and coordinates the required decisions to deliver it in a manner consistent with organizational standards and interoperability goals.

■

Development builds or implements a product or service that meets the specification and customer expectations, delivering a system that is fully compliant with the negotiated functional specification.

■

Testing ensures that all issues are known before the release of the product or service, that the user interface has been exercised and that the new software has been integrated into existing systems.

■

User experience maximizes user experience through performance solutions and training systems. It also reduces support costs by making the product easier to understand and use.

■

Release management ensures a smooth rollout, installation and migration of the product.

In practice the program management role will often be split into project manager and solution architect. The project manager takes on the traditional Continued …

91


scheduling and coordination aspects of the role and the solution architect addresses the end-to-end solution and its consistency with wider business and technology directions. The roles also map onto the goals for success of a project: ■

satisfied customers;

■

delivery within project constraints;

■

delivery to specifications that are based on user requirements;

■

release after addressing all known issues;

■

enhanced user performance;

■

smooth deployment and ongoing management.

The benefits of the team model are as follows: ■

It gives each team member a stake in the success of the product or service.

■

It creates a culture that encourages clarity, efficiency, participation, commitment and team spirit.

■

It improves accountability for all roles.

■

It results in a customer-focused product or service.

The team will almost certainly have strong user involvement. Normally this will be as full members of the project team. The product and user experience areas in particular will need business involvement. Source: Reprinted with permission from Microsoft Corporation. © Microsoft Corporation.

The project team structure and management reporting lines should be designed so that the team can be empowered to deliver the project working for the sponsor and project board. Recognizing that the project is about business change makes it clear that there will be many occasions when they will not have the direct authority to get things done and they will rely on the business sponsor and senior IT management for backup and for ‘air cover’. The project structure must be designed to manage the business change and focus on the delivery of the desired benefits.

Case study Get the management structure right! An organization had launched a number of websites including a corporate site and various sites to allow customers to browse their catalogue. When the first Continued …

92


transactional site went live they decided it was time to set up a business intelligence (metrics) project so that they could start reporting the performance of the various sites that had been established over the previous 15 months. The team they ended up with for the metrics project was as follows: A. Systems development manager – with overall responsibility for the project to the business sponsor. B. Project manager – a member of the business-facing team of the IT department managing this along with one other (larger) project. C. Project manager – a contractor from the marketing agency working full time on the project. D. Project manager – part time from the IT Development function, responsible for the systems development. E. Team leader – part time from the IT Development function. F. Two developers. The developers, along with the team members C, D and E were based in an IT building about ten miles from the business team. Status meetings with the business sponsors only included team members A, B and C. The project worked very much as a hierarchical organization – A talked to B who talked to C etc. Unfortunately due to cost constraints the business area could not provide anyone to work on the project even in a part-time role. None of the team had experience of business intelligence projects. The aim was to get a first version in place as quickly as possible so that the business users could learn from the initial solution to get a fuller understanding of what information was available and would provide the greatest insight into the performance of the various sites. After ten weeks the team produced a first version of the system. The review session was the first time the developers had met the sponsor. The data was incomplete and the solution did not meet the business sponsor’s requirements. The project was abandoned. Business intelligence is a specialist area for both business and IT staff. The OLAP technology at the heart of a solution is extremely powerful and relatively easy to use but is outside the experience of most developers. An experienced team would have had an 80/20 solution to the fairly simple requirements of the first version in its heads. The main work should have been finding the data from the various websites. They would probably have delivered a good initial solution in four to six weeks. Continued …

93


Key learning ■

The team structure was a key cause of problems. It put far too much distance between the developers and the business sponsor. It was also far too top heavy and expensive.

■

The skills of the team were insufficient. There was no one with experience of business intelligence. Two specialists might have been more expensive per day (although the rates actually paid were not cheap) but they would have achieved more than the entire team.

Underlying issues included the lack of trust that had prevented a simpler team structure being put in place and the focus on process rather than expertise that had allowed the lack of skills to occur.

Team model principles The MSF team model is built upon certain underlying practices and principles. The following are some, but not all, of the best practices and principles that have helped make the team model a success: ■

Team of peers. It is not an overstatement to say that the team model could not function without a team of peers in place. It relies on having each of the six roles filled by a person or persons accomplished at the tasks of that role. The team model only works if each member of the team is trusted to do his or her part of the job and, in turn, feels responsible for doing his or her job.

■

Shared project vision. A project’s success depends on the ability of project team members and the customer to share a clear understanding of the project’s goals and objectives. The vision should be formalized as a statement that describes both what the project is and is not, enables decisions, motivates the team and is achievable.

■

Product mindset. Having a product mindset means being more focused on what is being delivered at the end of the project and less focused on the process of getting there. It means having all of the team focused on the whole solution – not just their part of the work. MSF advocates creating project identities that enable members to clearly identify their team, their goals and their contribution to the project. For example, the team may use project code names to represent itself and the work.

■

Zero-defect mindset. A zero-defect mindset is a commitment to do work of the highest quality possible and to organize a project so as to identify and eliminate as many defects as possible. It does not mean having the unrealistic Continued …

94


goal of shipping a product with absolutely no defects at all. If each team member does his or her best job, the overall quality of the product will be raised. This is important in the long run because it makes for a better product, and because the product will have fewer defects and take less time to reach stability, it will be easier to predict when the product will ship. ■

Customer-focused mindset. Having the customer actively participate in and offer feedback throughout the project lifecycle enables the team to better manage customer expectations and achieve better alignment with customer needs.

■

Willingness to learn. Learning has to be made an explicit activity – for example, by dedicating time in the schedule – for it to have the desired effect.

Source: Reprinted with permission from Microsoft Corporation. © Microsoft Corporation.

PROJECT START-UP The work already carried out to develop the benefit plan is a crucial starting point and will enable the project to be aligned to clear business goals. There needs to be continuity between the work on the benefit plan and the project. In particular key business stakeholders will become part of the overall project or programme management framework. At the early stages of the project there should be good opportunities for the team to work together to encourage the building of the team. One approach that works extremely well is to get the core team, with input from relevant business stakeholders, to work together to establish the project vision and scope, preferably at an offsite location free from the distractions of day-to-day business. Depending on the size and complexity of the project this might need one to two weeks. It will build on the benefit plan and will result in output including a refined statement of the business benefits, functional requirements, an overview of the architecture and an overall project plan. The workshop can include input on the development framework and process that will help establish a common language and understanding of how the team will work together. This is particularly important if the team members have not worked together before and, as is often the case, come from different organizations. Using the workshop approach is also a good way to address another objective – that of building momentum quickly. Many projects only really get focused when they go into the actual development phase. By this stage a lot of time can have been wasted. It is possible to start working to clear goals and build momentum right from the start. This does not mean closing down all the options and just planning the system around the first solution idea, but it does mean giving real focus to that initial creative period.

95


With the right preparation, the workshop approach can compress many weeks of interviews and meetings into a very much shorter period of time. But it can only be successful with the right business involvement and the core of the future project team.

PROJECT PROCESS There has to be enough process and it has to be a good enough process. There is strong evidence to show that getting a good enough process in place right from the start is a major contributor to success. What this implies will vary from organization to organization depending on the maturity of IT development processes. Most organizations still face significant issues with their processes at the high level that is within the scope of this briefing. Getting this level right is the key area for top management to focus on. The key elements of the process that must be in place are: ■

managing project trade-offs;

■

versioned releases – each managed on a time-boxed approach;

■

major and interim milestones;

■

living documents.

The same overall framework applies to all types of projects. However, the specific approach to be adopted for a specific project will vary considerably according to a number of factors. The investment portfolio provides the key basis for varying the approach. Appendix 1 provides a summary of the implications of the portfolio for running projects.

Project trade-offs Projects are inherently risky and they are managed in the context of a rapidly changing environment. An explicit approach to managing the various trade-off decisions required during the life of a project is essential. Figure 6.1 shows a typical trade-off matrix. The schedule, i.e. time to market, is typically the key factor. Using the time-boxed approach compromises on features will often be accepted to meet the target release date. Resources are constrained – this controls costs but also forces greater creativity and often better solutions when the option of throwing resources at a problem is taken away. Trade-offs should be agreed in the context of the overall benefit plan. For example, does cutting a feature mean that delivery of key benefits will be undermined? Quality is not one of the elements of the matrix, although it is in some other variants of this approach. Including quality increases the risk of seeing quality as

96


something that can be added in at the end, for example through testing. Quality must be built in from the start, for example by establishing the team with a ‘zero defect’ mindset. The right approaches to quality will mean the team will be more effective and will be able to save time or deliver more so quality is another dimension, not something to be traded off with time.

Project trade-off matrix

urc e so Re

le du

he

Sc

s

Fig. 6.1

Features

Optimize

Accept

✓

Resources

Schedule

Constrain

✓

Features

✓


The team model works well with this approach to project trade-offs. The alignment of the team roles with the attributes of project success and not just delivery of something on time and budget means that there will be an informed debate prior to any trade-off decisions that will result in much better decisions than the traditional hierarchical project management process.

Versioned releases The overall development approach should in most cases be based on a time-boxed approach and aim to deliver the overall objective incrementally through a series of versioned releases. The requirements are prioritized and then allocated to the releases. Deliverables to the business will be targeted for every three to six months, but the overall development process will include planning across a series of releases. The design approach is to allow maximum independence between the features so that if a feature cannot be ready for a release it is dropped then considered for inclusion in future releases. The time-boxed/versioned release approach is highly successful when there is a good, modular design and also when priorities are set appropriately. In particular key ‘infrastructure’ features must be balanced with the main user features, in fact it is likely that a large part of the effort in early releases may be to establish a

97


strong foundation, but clearly there must be enough user functionality to justify deployment and to provide worthwhile benefits.

Milestones The key to controlling the development process is to use a series of milestones. MSF uses five main milestones. The key is to use a small number of milestones as the basis for control. The same basic process applies to any project although the detail of deliverables and expectations at each milestone will change according to the size of the project and where it fits into the portfolio. By focusing tracking and control on the main milestones it is possible to manage all projects within the same overall framework regardless of size or type. The major milestones provide the basis for synchronizing the various streams of business and IT activity. The principle question to be answered at each review is ‘are we on track to deliver the benefits?’ Where the recommendations for rapid development are being followed and projects have been planned to deliver within three to six months the main pauses for thought and assessment of the need for further investment are between versions. The milestones are not to be used to bring all activity to a halt prior to approval and moving onto the next stage, but there should be a formal review and decision to proceed at each stage. The project should not be allowed to continue simply through its own momentum. A key part of initial project planning is to identify the major and interim milestones and agree the deliverables required at each. This will determine who needs to be involved at each stage. There will be a range of people to be involved in sign-off at each stage and also a much wider range of people to keep informed. The frequent interim milestones provide a real focus for the activity of the project team and a great opportunity to succeed and to build up a culture of success. The team model, along with thinking through the deliverables, enforces the involvement of the different roles/disciplines right from the start of the project. Two areas that prove the point are testing and release management. A traditional, waterfall approach may leave these areas to much later in the lifecycle when it is too late to do anything but cope with whatever problems have been planned and built in.

Case study The right way and the wrong way – contrasting approaches Background The retailer wanted to start introducing shopfloor systems based on a Pocket PC and wireless in-store network. The initial application needed to access information held centrally on the mainframe. The wide area network connecting the stores to central systems, including the mainframe, was nearing full capacity. Continued … 98


The waterfall approach Development of the system was outsourced to a third party. To tackle the risk of the network capacity being inadequate this was flagged as a risk in the project initiation document and the team worked on an assumption that adequate bandwidth would be made available – neatly passing one of the critical project risks back to the customer. A similar approach was taken with the need to get information from the mainframe where the risks were also high due to capacity constraints. All the main functionality for the initial store pilot was planned to be delivered in one release that would then enter the testing process. A test lead would be brought onto the team just in time to get test plans in place. Although the user interface design was important given the new client device, the number of users and the rate of staff turnover in stores, there was no user experience lead on the team. Although there was board level sponsorship and a £1m budget had been approved there was no clear benefit plan and no identification of what would need to be changed in store. The project seemed to be going well. But the key risks, and with a very high probability they would undermine the final solution had been ignored. The project team was making progress largely by leaving the difficult areas until later in the project. The MSF approach A benefit plan was established with agreed measures of success before the budget was approved. All the team roles were represented in the initial project team. It was clear from the start that network bandwidth and mainframe capacity/response times were the key technical issues. The lead developer immediately got to work to build a cut-down solution to validate the highlevel technology design and then worked with the test lead to get an accurate indication of the viability of the proposed solution. The user interface design was a second critical area and the user experience lead immediately started work with the users in the pilot store to prototype the design. The leads worked together closely and by the time they reached the vision and scope approved milestone had got feedback on the initial user interface prototypes. They were able to change the overall design to make much more use of the processing power on the Pocket PC to reflect the learning from the technology validation work. As a result the team was well placed to proceed with the rest of the project. Continued …

99


The forward plan showed the team rapidly building, testing and reviewing with users a number of quick interim releases. Their approach would maximize the learning from the users and ensure that there was a usable system as early as possible.

Project milestones A small set of major milestones provides the basis for management control of projects. Given that a project should be planned to take no longer than six months this provides sufficient granularity for management control. Additional, interim milestones will be used by the project team to focus their activity and manage their progress. The project is not stopped at the milestones but they are key points for management review and synchronization of activity. At each stage the fundamental question to be answered is: ‘Is the project contributing to achievement of the objectives of the business and will it provide measurable benefits to relevant stakeholders?’ Milestone

Deliverables

Project initiation approved

Benefit plan and project initiation document – approval to proceed with the project and funding for the envisioning phase of the project which delivers the vision and scope.

Vision and scope approved

Vision and scope document incorporating the: ■ ■ ■ ■ ■

revised benefit realization plan business requirements design goals high-level solution concept risk assessment.

Funding approval for the planning stage or the remainder of the project (subject to continued review of the benefit plan). Project plan approved

■

■

Scope complete

■

■

■

Functional specification including the overall solution design. Master project plan setting out the approach to each aspect of the project and the project schedule. Functionally complete solution ready to enter the later phase of testing and use acceptance. Initial baselined user materials (training/procedures, etc.). Detailed plans for the next phase including test plans/scripts.

Continued … 100


Release readiness

■

■

Software tested and ready for operational use along with related procedures and training material. Detailed implementation/changeover plan.

Deployment complete

Live operational solution.

Benefits delivered (typically two to three months or more after deployment)

■

■

Assessment of project success in delivering the benefits. Action plan to deliver additional benefits.

Like the benefit plan the risk assessment is kept under continuous review and is a key part of each milestone review.

Living documents The final key aspect of the overall process is to use ‘living documents’. This approach reflects the reality of learning going on through the life of the project and reduces the risk of ‘analysis paralysis’. A small number of key documents are deliverables at the major project milestones. The approach is to use standard templates for these and to produce a baseline draft as early as possible after the start of the project or stage. This gives a real focus to any areas where further work is required and, on the 80/20 rule, saving a great amount of time and effort. The approach is also to ‘freeze late’, i.e. to remain flexible to changes as long as possible. This is a huge contrast with the hierarchical, waterfall approach requiring attempts to understand the full detail at every level before imposing strict change control and moving on to the next stage. The living documents approach of baseline early, freeze late also reduces the number of documents required as one evolving document addresses a number of needs during its life. In many projects an iterative approach to the project lifecycle will be appropriate. After the initial work on the benefit plan and vision and scope, the project team may progress rapidly through a number of cycles of ‘project plan approved’ and ‘scope complete’ as initial versions of the system are defined, built and reviewed with users.

Process model The MSF process model differs from traditional development models in the following ways: ■

It emphasizes vision/scope rather than requirements. Continued …

101


■

Milestones are customer-oriented rather than development-oriented. Each milestone is a synchronization point where the team is recalibrated to customer expectations. Milestones are managed using the known trade-offs of resources, features and schedule.

■

It uses versioned releases, rather than including every feature the first time. With rapid changes in technology, versioned releases allow businesses to leverage their investments in computing environments.

This process model produces better decisions, less rework, higher morale and a higher quality product. And, by addressing support and performance issues as part of the development process, it can lower the risk of rolling out new solutions and lower the cost of ownership. Project trade-offs The variables in any project are resources (people and money), schedule (time) and features (the product and its quality). As the team develops a product, it will inevitably have to make trade-offs among the project variables. The key to project success is finding the right balance among resources, schedule and features. Those variables can be viewed as having a triangular relationship. After the team has established the triangle, any change to one of its variables (or sides of the triangle) requires a correction to at least one of the variables to maintain project balance, including, potentially, the same variable in which the change first occurred. A project can only be successful if the customer believes that the team has made the right trade-offs, so the team should ask the customer about priorities early and often. Living documents In order to bridge the gap between thinking about a project and doing the project, MSF uses living documents. IT projects may run the risk of getting caught in ‘analysis paralysis’, a condition of endless planning with no action. Living documents offer direction and specifics to begin the project, but can be changed in response to new information or circumstances that may surface during the course of a project. Creating living documents enables a team to arrive at a balance between too little and too much planning. Living documents are built on the process of determining a baseline for the document early, but freezing it late: Continued …

102


■

Baseline early. To baseline early means that project teams should create a draft document that will be the basis for the complete document as soon as possible and move on to developing the solution, even if that means leaving some questions unanswered.

■

Freeze late. To freeze late means that as long as the team considers documents to be dynamic and subject to change, it can add answers and details along the way.

Living documents allow project teams to begin developing, even if every detail has not been addressed. The project team members can move on as soon as they have addressed enough details to facilitate moving forward. Major and interim milestones Milestones are formal checkpoints to measure progress and agreement on project direction. The MSF process model uses major and interim milestones. Major milestones mark the transition from one phase to another and signal the transition of project responsibility from one role to another. Major milestones are times when all team members synchronize their deliverables (physical evidence that the team has reached a milestone). Achieving a major milestone represents team and customer agreement to proceed. Interim milestones indicate early progress and segment large work efforts into workable and manageable pieces. The major milestones are defined by the MSF process model. The project team will determine appropriate interim milestones. Milestones are used as: ■

review and synchronization points, not freeze points;

■

an opportunity for the team to assess progress and make mid-course corrections – areas often discussed are: what went well, what didn’t go well, what we could have done better, and what we can document from this milestone that will help future milestones and future projects;

■

a way to represent team and customer agreement to proceed when a milestone is achieved.

Versioned releases Versioned releases are a fundamental project technique that divides large projects into multiple versioned releases, where the first release delivers the core product, and later releases add features incrementally until the product matches the project vision. Continued …

103


By using versioned releases, teams can provide the most critical pieces for a product in a shorter time frame because the team does not need to include every desirable piece in the first release. Versioned releases also enable a project team to respond to changes in scope, schedule and risks during product development. Versioned releases are advantageous because they: ■

force closure on project issues;

■

set clear and motivational goals for all team members;

■

manage the uncertainty and change in project scope;

■

encourage continuous and incremental feature delivery;

■

enable shorter time to delivery or release.


The key principles of the process model, i.e. managing project trade-offs, versioned releases, milestones and living documents, all support the benefit management process in helping the project team to follow the 80/20 rule – getting 80 per cent of the benefits for 20 per cent of the effort/cost.

RISK MANAGEMENT Risk management will appear as part of every project management approach. A risk schedule is often prepared as part of project planning. However, it is rarely used effectively as a management technique. It could be that risk has such negative connotations when the team is focusing on being successful that it is not pleasant to have to shift focus to all the things that could go wrong. Yet as most of the causes of project failure result from things that were inherent from the beginning and could have been addressed, risk management is a technique that if used, and used in the right way, can have a big impact. It may be more acceptable to call risk management ‘benefit assurance’ or ‘delivery assurance’. The key is to use the technique proactively to increase the chances of the success of the project.

Risk management model Risk can be defined as the possibility of loss or injury or, in the terms we are considering, non-appearance of the benefits that the investment was made for. Every project a team undertakes involves risk. Therefore, managing risk successfully is crucial to the success of the project. The MSF risk management model sets forth a discipline and environment of proactive decisions and Continued … 104


actions to continuously assess what can go wrong, determine which risks must be dealt with, and implement strategies for dealing with them. Characteristics of risk MSF identifies these characteristics of risk: ■

Risk is inherent in every project. Risk is a fundamental ingredient of opportunity and is inherent in every project. It is the possibility, not the certainty, of bearing a loss. The loss could be anything from diminished quality of an end product to increased cost, missed deadlines or project failure.

■

Risk is neither intrinsically good nor bad. Risk is not something to avoid, especially because it is inherent in every project. MSF believes that a risk identified is an opportunity identified, and therefore risk is neither essentially good nor bad.

■

Risk is not something to fear, but something to manage. Successful teams deal with risk by recognizing and minimizing uncertainty and by proactively addressing each identified risk.

Principles of successful risk management Risk management should be a part of every project. Risk involves not only technology, but also people and processes. Successful risk management includes the following principles: ■

Assess risks continuously throughout the project lifecycle. Successful risk management is more than just identifying risk factors at the start of the project; it requires the constant assessment of risk throughout the life of the project. This is because new risks are revealed during the life of a project, while previously identified risks change by becoming either more or less probable or more or less severe. Ongoing risk management of a project introduces a degree of resilience to change.

■

Use risk-based decision making. Successful risk management requires that all decisions be made within the context of their risk. The team’s actions are prioritized in relationship to the status of the risk – the highest risk items are dealt with first.

■

Establish some level of formality. Successful risk management requires a process that is understood and used by the team. This does not mean that the process must be a strict methodology, but that a reasonable amount of discipline and process is required. If the process of managing risk is too difficult, risk management will not occur. If the process is not structured, it will not be useful. Continued …

105


■

Cover all key people and processes. Successful risk management requires the team to look for risk almost everywhere in the project. The team must ensure that the key persons and processes are covered, or it is likely that significant risks will be missed.

■

Treat risk identification as a positive. For risk management to be effective, team members must be willing to identify risk without fear of punishment or criticism. The identification of a risk means that there is one less surprise waiting for an unsuspecting team. When risk is identified, the team can then prepare for the risk and perhaps prevent it from occurring altogether.

The results of risk management from each project need to be incorporated into future risk management to improve organizational learning about risks and to improve effectiveness in risk identification and analysis for future projects. Source: Reprinted with permission from Microsoft Corporation. © Microsoft Corporation.

Risk reviews should as a minimum take place during project planning and the preparation for each major milestone. The goal is to identify and focus on the top five to ten risks and the action required to reduce or avoid them, reduce their possible impact, etc. Risk management must not become a search to identify and classify every conceivable risk – it is only a means to the end of making sure the projects is successful. Risk management is the responsibility of all the project leads but the project manager takes primary responsibility. Standard lists of risks help make the process effective and provide a basis for capturing accumulated learning.

OTHER ASPECTS OF PROJECT MANAGEMENT There is a lot more to project management than the areas covered here. Other aspects, for example issue management, work breakdown structures, estimating, etc., are covered in the books referred to in Appendix 2. The areas covered here are the key factors that will make or break a project and that should be the focus of senior management attention.

Focus on quality Quality is about delivering a fit-for-purpose solution that enables the business to achieve the desired benefits. It is about meeting the functional goals as well as the need for security, usability, availability, etc. Continued …

106


Successful project teams focus on quality. This is embodied in the MSF concept of the ‘zero defect mindset’. The whole approach to the project including the team and process models is designed to ensure that quality is built in from the beginning.

Operations and support Future operation and support of the system are critical issues to consider from the beginning of the development project. Figures from Giga (the IT industry research firm) suggest that 75 per cent of IT budgets are spent on keeping things running and only 25 per cent on new developments. The decisions made during development will have a major impact on the ease and cost of operations and support and the quality of the system as experienced by the users. The release management role in the project team, however it is labelled, provides a focus for planning for operations and support and is the primary interface to the IT teams responsible for these areas. As with the other roles this is a specialist area. The perspective of these IT teams will be very different from that of the developers and if they are involved at the right times they can make a major contribution to the overall success of the project. All too often operational issues are addressed far too late and as a result the operations teams are seen as obstructive – when in fact they are working to protect the production systems. For strategic projects it may be necessary to make special arrangements for the infrastructure and operational processes, for example there may be a need to use technology that is not yet supported in the standard production environment. In this case the input of experts in the operational and support areas will be particularly crucial. With high potential projects it may be possible to take some short cuts, for example with the project team providing support, but it will still be necessary to ensure that existing production systems are not put at risk. For both key operational and support projects adherence to technical standards and consistency with operational processes is critical.

Suppliers Outsourcing of IT remains a popular remedy for organizations that see themselves as failing to achieve the value they want from their IT function. Benefit management highlights that in many respects this model cannot address the real issues of getting business value from investments in IT as it is not possible to outsource changing and improving the business. Intelligent use of third-party vendors and partners is valuable and when done in the right way can add a lot of value.

107


Strategic and high potential projects are not suitable for outsourcing. It may be appropriate, or indeed helpful, to bring in external resources to be part of the team. As with internal resources, it is important to ensure that the people put forward by the supplier have the skills needed and also that they fit into the team. The standards set should be higher than for internal staff – this is not an opportunity for these people, that are costing a lot of money, to learn. If it is essential to bring people in it must be an opportunity for the internal team to learn from experts. There are two common weaknesses in this area. First, not enough care is given to making sure the individual consultants or contractors are the right people. Second, not enough use is made of bought-in resource to carry out the normal jobs of internal employees and to free them to work on the project. This lowers the cost of the bought-in resource and also ensures that internal staff gain the experience – this will have a big payback as the team moves forward into future development cycles. The technical aspects of key operational and support projects are more suitable for outsourcing. With support projects it will be valuable to have skills in the specific package or solution involved as there will be substantial benefits from not having to go through the entire learning curve and re-learn lessons that have been learnt elsewhere. Key operational systems may also include packages and the same considerations apply in this respect as for support systems. However, the level of integration into other systems, as well as the level of business reliance, will almost certainly mean that internal staff must be involved in the IT aspects of these projects. The business changes that are required to deliver the benefits cannot be outsourced although there may be an opportunity to make some use of specialist resources in specific areas.

Meetings and reporting A key objective is to keep meetings, for example for reviewing progress, to a minimum. Too often they are a waste of time and the project manager can keep up to date on progress in other ways. Each team will work out its own approach. The challenge is to be ruthless with meetings and make sure that each one is essential and that it continues to be effective in meeting its objectives. The same is true about progress reporting – keep it simple and make sure it is adding value. If the team is properly focused on the plan and there are well-defined interim milestones the basics of progress reporting should be easily managed by the team leads and project manager.

Project progress report – an outline Project progress reports should be largely forward looking but they also need to reflect the achievements of the team. Continued … 108


Areas to cover include: ■

achievements this period – should be specific deliverables, milestones or issues resolved;

■

major risks and issues;

■

key deliverables due for the next period;

■

due date of the next milestone;

■

key entries from the change log: changes approved and awaiting approval;

■

forecast live date and cost to complete.

The report should also include more static information including the sponsor, stakeholders, target benefits and dependencies. Reporting can be driven by a standard template or through a web dashboard, for example using Microsoft Project 2002. The key is to focus on progress towards the delivery of benefits and not just the technology.

Case study Unreasonable expectations? A colleague in marketing asked for my advice recently. He wanted some guidance on whether the issues he had with some work being done by an external consultancy were valid or if his expectations were too high. What do you think? ■

Six weeks into a four-month project he had not seen an end-to-end project plan.

■

The consultancy had made a number of changes to its team members.

■

There were no regular progress reports – and consequently no understanding of the time spent or the work delivered.

■

The team of three consultants did not consistently turn up to the progress meetings that were arranged.

This was not Joe’s Wild West Consultancy Services (Cowboys) Limited. It was a large consultancy firm. Key messages As senior managers and business sponsors there are a number of basics it is right to expect and demand from project teams, whether internal or external. The checklist at the end of this chapter gives some specific guidance. Do not accept anything less – from your own project team or from a supplier. Any firm can do shoddy work; do not let them get away with it when working for you.

109


PROJECT MANAGEMENT SUMMARY The approach to project management outlined in this chapter is generally applicable to a wide range of IT projects and is directly relevant to strategic and high potential projects where there are high levels of business change. Support projects should normally rely on packages or ‘out-of-the-box’ solutions and the approach will vary slightly because of this, with the emphasis on getting a solution in place rapidly making good use of the available functionality. Key operational projects will often involve a higher level of changes to, or integration with, existing systems. The same basic approach applies but the attitude to risk and the trade-offs made will be different as the day-to-day operation of the core business is at stake if things go wrong. The two key points to remember are: ■

Focus on delivery, then learn and improve in the next release.

■

Remember the 80/20 rule: focus on the most important things and do not goldplate the solution.

Key principles for success – the MSF foundation principles

110

■

Expect things to change – stay agile.

■

Work towards a shared vision.

■

Focus on delivering business value throughout the lifecycle.

■

Invest in quality.

■

Learn from all experiences – good and bad.

■

Foster open communications.

■

Adopt accountability, shared responsibility.

■

Empowered team members make commitments and deliver them.

7 Programme management

■

Programme planning

■

Benefits management

■

Programme team and roles

■

Progress tracking and performance management

■

Programme management summary

113 114 115 116

121

111


Succeeding with one project is hard enough. But in the real world most projects are just a part of a much wider activity. As a minimum a single project is one of a series of versioned releases. In general, however, a project will be part of a wider programme that involves business changes (i.e. business projects) as well as IT application and infrastructure projects. Individual projects should be completed within a three to six-month period and deliver clear benefits but transformational business change will take longer than this and will need to be addressed by a programme of activity. Programme management is the coordinated management of a portfolio of projects that create change to achieve benefits of strategic importance. Programme management is a good reflection of the learning paradigm in action. Although the programme will be undertaken with clear goals in mind there will be changes at some level due to the learning along the way as well as broader changes in the business climate and direction. Successful management of a programme does bring major challenges. However, with the approaches already defined for portfolio management, project management and benefit management the foundations are in place and the main requirement for successful programme management is to get a small number of additional processes and roles in place, to have good experience in the team and to follow the guidance in this section.

PROGRAMME PLANNING The programme, for example customer relationship management (CRM) knowledge management (KM) or e-business, is likely to be a major business initiative arising from the annual planning cycle, a strategic review or a response to competitive pressures. The first stage is to use benefit management to determine the business changes required to deliver the benefits which will realize the investment objectives. Identifying the required business changes is the starting point for identifying what projects are required. At this stage the impact of existing systems and current projects as well as any infrastructure constraints and developments can be taken into account. The difference between the current ‘as is’ position and the future ‘to be’ position shows the changes that need to be made both in the business and to the application and infrastructure technology. This enables a second-pass view of the projects required to be developed, allowing a programme-level benefit plan and business justification to be prepared for approval prior to further more detailed work on the programme.

113


BENEFITS MANAGEMENT Benefits management has already been covered in detail. The project-level processes already defined still apply. The main additional element is that the benefit approach is used at a programme level as part of the initial planning process and for periodic reviews. At the programme definition and planning stage BM helps focus on the business changes required to meet the investment objectives and address the business drivers. The business changes then determine in outline the IT solutions required as enablers. Benefits management is then used as normal to develop the business case and benefit realization plan and to kick off each project.

Case study: measuring the benefits The b2c (business to consumer) programme was going to involve a number of projects delivering a mixture of transactional and information sites. Benefits management was adopted as a key element of programme processes. The business management team and programme management knew that there would be a great deal to learn during the programme and wanted to ensure that they had sound information on which to base their decisions. The only existing business intelligence solutions at the company were financial and customer information; there was no general management information system that addressed the operational management information that would be required to assess the business performance of the web solutions. Therefore, it was agreed to establish a business intelligence stream of activity in the programme. Business intelligence is a specialist area from both business and technical perspectives. It is also an area where rapid, incremental development is possible. A team of three was put in place as a metrics team: one with relevant analytic skills from the commercial finance team and two IT specialists. The team worked with the projects from the beginning to address the whole spectrum of management information needs: ■

business metrics – with a particular focus on the measures related to the project benefits;

■

website usage measures – for example, to gain insights into how to improve the content and user interface;

■

operational systems performance measures – for example to assess the system response times and capacity of the hardware.

Any additional development work to capture the required information was planned into the projects from an early stage. Development of the metrics Continued …

114


solution took place alongside the other projects so that as each new system went live there was reporting in place to assess both the system’s performance and the delivery of benefits. Initially the metrics team produced weekly analysis reports, and then very rapidly they incorporated the results into a web dashboard so that the business and programme management teams could access the information directly through the Internet. The approach enabled clear accountability for the benefits and provided the information to continuously improve the business performance of the b2c area.

PROGRAMME TEAM AND ROLES The guideline principle for establishing the programme organization is to keep as much resource as possible in the individual project teams and minimize the programme level team. The aim is to keep as many of the team as possible actively involved with the delivery of specific projects and avoid a gap between theory and practice rather than simply to minimize resources. The structure will depend on the size and nature of the programme.

The structure of the programme team The structure of the programme team builds on the project team model. The key roles are represented in each project team and a number of additional people form the programme level. These will often include: ■

programme director;

■

programme office – handling all the admin of planning and progress reporting;

■

solution architect.

Initially the senior role leads will also play a programme-level role in ensuring consistency and providing guidance across all the projects. As the size of the programme increases it will be necessary to have separate individuals for the programme-level roles. The detail of different options for structures and the related advantages and disadvantages is not covered here. What is most important is to follow the underlying principles of the team model, and in particular to ensure that the different specialist roles have a voice at the programme level.

115


PROGRESS TRACKING AND PERFORMANCE MANAGEMENT The milestone approach is the key technique enabling programme-level management of progress. The key for programme-level control is to focus on the milestones for each project and to leave the detail up to each project team. On this basis the programme-level plan will contain the small number of key milestones that are being used for each project. The second element is a programme-level view of risk and issues. It is important to note that this is not the same as looking at a project-level view of the risk for each project and then simply picking out the most important ones. The programme-level perspective is almost certain to bring out issues that are not clearly visible from the perspective of the individual projects. This is a key area for the programme-level team to add value. The top programme-level risks and issues will form an important part of the agenda for programme board meetings. Getting the milestone tracking and risk/issue management in place and working well is critical. Other areas can then be tackled, always from the view that any additional administration/bureaucracy must have a clear value. It is well worth having periodic reviews to ensure that any processes are continuing to add value. Areas that can be addressed will include: ■

getting standard templates in place for the deliverables at each milestone;

■

establishing a central repository of key project deliverables;

■

developing standards and guidelines to establish common practice in key areas – this will normally be a mixture of best practice guidance from the wider IT function or from other sources, which is added to based on the experience of the teams working on the project.

A common project management tool such as Microsoft Project 2002 can easily be used to support this sort of tracking. It is also possible to establish a programme dashboard that provides a management view of key information, for example: ■

project progress against the key milestones;

■

risks and issues at project and programme level.

Do not under any circumstances let anyone try to establish a central plan to show in detail who is doing what when and who will be doing what for the rest of the project. The detail of the end-to-end project plan should be developed and evolved as the project progresses. Team leads or the project manager on small projects should manage tasks of about five days for each individual. Anyone who suggests doing this at programme level should probably be working somewhere else as soon as possible.

116


One hard lesson to learn is that it will sometimes be necessary to stop projects, for example when you recognize that a project is no longer the right response to a business issue. It must be possible to do this without reflecting badly on the project team.

Programme-level progress reporting – an outline The programme board should focus its attention on two main areas for tracking progress: ■

major milestones;

■

regular reviews of risks, issues and progress.

The focus of the project can be maintained by ensuring that the achievement of benefits remains the primary goal. A programme-level progress report should include: ■

top risks and issues with recommendations for action;

■

milestone status: milestones achieved/missed and milestones due in the next period;

■

change summary: any significant changes to scope or dates – both approved and requiring approval by the programme board;

■

benefit delivery: as solutions are deployed benefit measures are tracked and reported;

■

project RAG status (red/amber/green) and status against budget.

In addition a key programme-level document is a programme-level view of benefits which shows the alignment of the projects to business objectives and initiatives and shows the main stakeholders and benefits by stakeholder for each project.

Architecture Architecture is a trendy IT concept. Despite this, if approached in the right way it will add a lot of value and make a major contribution to the success of the programme. In many ways the analogy with architecture as in buildings and town planning works well. The systems architecture is about establishing a vision for the end state of the technology that is aligned with the business vision. It is a guide for moving in a coherent way from the current state of an organization to the future state. The architecture helps to identify which projects (application or infrastructure) need to be done and which need to be done first.

117


Systems architecture is not static. It is evolved and developed through a series of versions as IS and programme planning is carried out and as projects are delivered. Each version of the architecture will cover a number of areas: ■

The standards for which technologies and products will be used and a roadmap for how this will evolve in a managed way as new versions and new technologies are introduced. There will be a major influence from any corporate IT standards, but regardless of what standards are in place it is crucial to get a clear position for the programme so that these decisions are not taken at a project level. A coherent technology architecture is a key driver of simplicity which enables rapid delivery, simplifies resourcing and the build-up of deep expertise, and also has a big impact on operational and support costs.

■

A functional or service view of the system. This will show the main blocks of functionality that are required by the programme and provide a basis for planning how these will be delivered, whether built or bought, and what projects will be used to deliver them.

■

Infrastructure services that are required across a range of systems/projects. For example, content management, user authentication and business intelligence may well be best handled as common services.

■

The implications of the architecture for resources and skills and also for processes.

Modern architecture approaches are an aid to the design and systems build process – they are not an end in themselves as many earlier approaches became in practice. The style is ‘planning while building’ in the sense that an architecture/systems design plan is established prior to development work but it is recognized that this is just the first release. The architecture is intended to evolve through the programme in response to business changes and greater understanding about the business problem and the best technology solutions. Using architectural planning in this way new technologies can be evaluated and tested out in projects in a managed way with an appropriate balance of risk and innovation. It is also possible to use risk-driven scheduling in a powerful way. Riskdriven scheduling means that you tackle the difficult and risky areas early so that if there are major problems the impact can be managed more effectively, for example by taking a different approach, using other technology, etc. At the programme level the risk can be balanced across projects. Often early releases will need to include significant effort to establish key ‘infrastructure’ components or services. Later releases will then have a greater focus on user functionality – as well as an evolution of the ‘infrastructure’. Typically the architecture will be updated every three to six months depending on the strategy, the lifecycle of the programme and the volatility of the technology and business requirements.

118


The decisions made in establishing the architecture will have a major impact on every project. The programme architect is a key contact for the business sponsor and senior managers. Taking time to work with the architect and understand the implications of the architecture and confirm that the trade-offs made and other implications are right in the context of the business goals will be well rewarded. There may be some jargon involved but a good architect will be able to explain the architecture, the assumptions made and what the implications are in terms the non-technical audience will understand. The programme architect will need strong communication skills and should also have a good knowledge of the specific technologies involved – although no one person can be expected to be an expert in everything. They will need real-world experience so that they can judge what will work in practice rather than just provide a ‘textbook’ view. Depending on the size of the programme and the resourcing requirements it may well be possible and very beneficial if the programme architect also acts as project architect for some of the key projects. This will involve working with the lead developer on the technical design/architecture for the specific project. This helps ensure continuity between the overall architecture vision and plan and what is actually delivered in the project. The risk to be avoided is that the architect role becomes detached from the reality of what is happening in the project teams – this is all too easy and the architect will need to be able to add sufficient value to the teams to be accepted and influential.

A project or a programme? A European company invested in a new corporate website for use by consumers. The goals of the project were to communicate the brand values and to use personalized content to create a dynamic and engaging site that generated many return visits. The site was then intended to evolve to become a gateway to a range of transactional sites for various group product lines. A lot of investment went into the site to enable content to be personalized based on usage patterns on the site. The personalization was driven by a range of rules that were to be managed by a system owner/administrator. The site was duly delivered with the planned sophisticated personalization capabilities and in the very short term was reasonably successful. The project had been treated as a stand-alone project by the team and there were one or two things missing from the overall business solution required to deliver the business benefits: ■

Due to budget issues no system administrator was appointed so there was no one to manage the site. (Although there was money in the project budget there was none in the marketing cost centre budget.) Continued … 119


■

No site analysis capability had been developed to allow detailed monitoring of the use of the site or of the success of the content and rules that were put in place.

■

The content on the old site had been fairly static and also quite out of date. There was no mechanism to ensure a steady flow of new content to the new site.

Key messages One way to look at this is that a benefit realization plan would have clearly shown that the project was not worth doing without actions agreed to address the issues set out above – they were all foreseen at the start of the project. Another way to look at this is that a technology project succeeded in delivering the required technology but not the intended business benefits because it was not managed as part of a programme. To succeed in business terms the programme should have included: ■

a business intelligence project – to deliver the capability to analyze the usage and performance of the site;

■

a business change project – to establish new content creation and management processes;

■

organizational changes – to clarify ownership of the site and the content and to get in place the site administrator to manage the site day to day on behalf of the owners.

In most cases, apart from limited proof of concept work, it will be best for the common ‘architecture’ components to be developed as part of a specific project rather than as separate deliverables by the architect or an architecture team. This helps ensure the components are solving the real problems. The architecture plan will show whether the architecture deliverables are embedded in specific projects.

Reuse Reuse is another fashionable idea and has been a goal of IT functions for some time. The basic aim is to get more effective solutions to market more quickly and/or reduce costs by using code that has been previously written and is tried and tested. Making reuse work in practice is still a challenge. The new move to XML web services as implemented by Microsoft in .NET is the next step in making reuse a reality.

120


In developing a reuse strategy it is vital to note that reuse is about more than programme code. It also includes processes, techniques, design concepts, etc. – code is only the tip of the iceberg of the reuse activity. The architecture is the core driver of reuse. Without a clear architecture – and even with one if you are not careful – it is all too easy for each project to build everything its solution needs. The architecture identifies the common requirements that enable reuse. Reuse also involves having the programme and project architects as well as the lead developers having a very good knowledge of the key technologies being used. Taking the example of Microsoft technology there is a huge amount of functionality in Windows 2000 as well as in other .NET server products such as Biztalk, Commerce Server and Content Management that can be leveraged by the developers, avoiding the need for bespoke code. Reuse in this sense also brings in the build vs. buy decision. This is a large area and the answer in a specific situation will depend on a wide range of factors. It is, however, very important not to introduce different technology simply to accommodate a bought-in solution. Keeping the simplicity of the technology platform for the programme will have a much bigger impact on time to market, operational costs and other benefits than a particular application solution that runs on a different platform. The exceptions to this are very, very few. Reuse, and certainly reuse of code, is not such a good thing that it must be done on every occasion. At times the effort involved is more than doing the work again – but at least the opportunity should be taken to learn the lessons from the previous attempt. In many respects reuse in its broad sense becomes a key aspect of knowledge management for the programme and the wider IT function.

PROGRAMME MANAGEMENT SUMMARY Management of a programme is the general problem that must be addressed by senior management. The techniques of benefit management and project management adapt well to the programme level.

Diary of a busy programme director Monday

The week always gets off to a flying start with the weekly CIO/COO programme review based on the progress report we issue on Friday p.m. The sessions work well; it’s a great way to keep everyone

Continued …

121


informed and to get any big issues resolved. No big issues this week – we took the opportunity to review the last milestones and consider the main lessons learned so we can make further improvements. The afternoon was taken up with meetings with two of our key suppliers. I made it very clear that the standard of people they’ve put forward isn’t good enough. We need skilled people who are able to share their knowledge and I don’t want to waste our time when we go through the interview process. Tuesday

Series of fortnightly one-to-ones with the project managers and role leads. With the portfolio management system in place and working well it means we don’t need to use these sessions to talk about the basics – we can really explore the key issues. I learn a lot and can help cross-project communication and also have an opportunity to coach some of the project managers.

Wednesday

Major briefing session today. The COO and his direct reports did a great job of bringing their teams up to date on the progress of the projects and how they contribute to the wider business goals. Our team did well – the systems demonstrations worked very well – it was worth all the effort.

Thursday

All-day workshop session at Cranfield. We’re working on a revision of the programme plan and architecture. This was one of a series of sessions to get new insights into business trends and the opportunities web services are providing. The session was very useful – the team gets a lot out of these sessions. Today we identified two or three things that we can work up into high potential projects.

Friday

Focus for the day is getting the progress report out on time. I haven’t been around as much as normal but as everyone is using the portfolio management system we’ve got good information to work with. The benefit tracking coming from the metrics system is also crucial – we can follow through projects until the benefits are realized. Louise has really got to grips with the PMO [programme management office] role so we are able to take our time and really drill into the issues. We both chase round the leads and business managers and work through our proposals for action to be put to the Monday meeting.

Key messages ■

Work closely with senior business and IT management.

■

Take time to communicate with users affected by the projects.

■

Achieve a balance between focus on success of the current projects and planning ahead.

■

Get strong processes in place to make time to identify and manage the real issues.

■

122

Focus on learning and improvement.

8 Summary and action plan

■

Key issues for business managers

■

Key issues for IT managers

■

Dos and don’ts

■

Action plan

125

125

126

126

123


The practical guidance in this part is aimed at senior management. It provides a toolkit to succeed in gaining business value from IS/IT investments. The concepts and tools provided may be utilized in any type of project and should be applied to the wider project activity across the business.

KEY ISSUES FOR BUSINESS MANAGERS ■

Benefit management provides a tried and tested process for shifting the focus of IT project activity from technology delivery to business change.

■

Stakeholder analysis should be used to identify the key players who will make a project succeed or fail and to understand the actions required to gain the required level of commitment to the project.

■

Projects should only proceed on the basis of a benefit plan with agreed benefits and related measures. Business managers must commit to the changes required to deliver the benefits.

■

Many traditional approaches to project and programme management have serious flaws, particularly in circumstances of major business or technology change where there are the greatest opportunities and the highest risks.

■

Adopt an agile approach to project and programme management that addresses: – teams: a balanced set of roles for the project team to give ownership of the key drivers of project success; – process: a framework based on key milestones that can be applied to all projects; – risk: a proactive approach to risk management.

KEY ISSUES FOR IT MANAGERS ■

IT must take responsibility for ensuring that there is proper business sponsorship and involvement in every project.

■

Projects should not be started without a benefit plan with business ownership of the benefit realization.

■

Effective management of the entire project portfolio can be achieved quickly. The first steps are to: – establish an agreed set of project milestones and related key deliverables; – start to track progress based on the milestones; – ensure there is a benefit plan for every project.

125


■

Ensure there is a review of the project portfolio with the business units every six months to ensure that the portfolio continues to be aligned with business priorities.

DOS AND DON’TS Based on the Benefits Management: Best Practice Guidelines for Cranfield School of Management, Information Systems Research Centre: ■

Do start benefit management on day one of every project – ideally before.

■

Do involve all potential and known stakeholders early in determination of benefits.

■

Do make sure all disbenefits are exposed and understood – ensure they are a price worth paying.

■

Do carry out a pilot or prototype if benefits are uncertain to determine what benefits are achievable and how to realize them.

■

Do ensure that all changes that affect the plan are interpreted in terms of the benefits and the benefit plan.

■

Do publicize benefits that have been achieved.

■

Do use benefit management to stop bad projects.

■

Do not expect to be able to predict all benefits in advance – many will only be understood after implementation.

■

Do not stop managing the benefits when the ‘project’ is finished.

ACTION PLAN The action plan provides a brief summary of key actions for management. It covers three broad areas: ■

ensuring any current projects are successful;

■

ensuring new projects are set up with the maximum chance of success;

■

establishing consistent, effective processes for project and programme management.

Current project review Review all current projects according to an agreed set of priorities and agree any remedial action required. Stop projects where appropriate. Consider: ■

Is the project clearly aligned with business priorities?

■

Is there a valid benefit plan, i.e. with measures of the benefits and clear business ownership? If not, get one in place or stop the project.

126


■

Are there agreed milestones for controlling the project?

■

Is there an appropriate management structure for the project – with business involvement and involvement of team members covering the key project roles?

■

How are third parties being used – is it appropriate and are they providing value?

■

Where is the project in the investment portfolio? If it covers more than one area break it up so it doesn’t.

■

Is the approach being taken to the project appropriate for its position in the portfolio? Where projects are scheduled to last longer than six months, can they be broken up into smaller chunks?

■

Introduce milestone-based tracking of all projects to a consistent set of milestones.

■

Introduce milestone reviews to monitor projects through to completion – ensure these include post-live reviews to assess benefit realization.

New projects ■

Approve new projects on the basis of: – business alignment – to the strategy and a business change programme; – a benefit realization plan with agreed owners for benefit delivery; – alignment to the IT strategy and architecture and as a part of a coherent IT programme.

■

Use project start-up to introduce new ways of working.

■

Ensure suppliers are used in appropriate ways, i.e. to provide specific expertise or to free up internal staff to contribute to the project.

Consistent approach ■

Establish an effective project and portfolio management framework – in most organizations significant changes will be required. Evaluate Microsoft Solutions Framework either to supplement or replace existing processes.

■

Agree deliverables at each milestone and put in place templates and guidance.

■

Introduce programme and portfolio management to gain top-down management control over all systems. Introduce Microsoft Project 2002 as a basis for portfolio management and to enable much improved collaborative working on projects.

■

Establish an overall business and IS planning process that will enable top-down planning for IT development programmes clearly aligned to the business strategy.

■

Develop a supplier strategy and agree a shortlist of preferred suppliers. Make good use of niche suppliers with specialist skills.

127

Part three Building on success

■

9


131

In this final part two main areas are covered: ■

a summary of the key learning points;

■

guidance on how to make the recommended approach a standard way of working across the organization.

A brief indication is also given of the areas to tackle next once the organization has gained some success with individual projects and programmes.

129

9 Innovation and continuous improvement

■

The story so far – key learning points

■

Implementing the framework across the organization

■

Looking ahead

135

■

Final thoughts

136

133 134

131


THE STORY SO FAR – KEY LEARNING POINTS The elements of the framework that has been introduced include: ■

the investment portfolio which provides a framework for classifying projects based on their business contribution, providing vital insights into how to justify and manage different types of projects;

■

benefit management which is a critical management process that focuses business and IT activity through the project lifecycle on the delivery of business value;

■

project and programme management techniques which are crucial for success, in particular emphasizing collaborative project management and succeeding through people. The learning paradigm was also introduced to provide a focus for the new approach.

Together these concepts and tools enable the successful delivery of business benefits from IT investments. They form the basis for a new approach to succeeding with projects. Table 9.1 summarizes the changes involved. Table 9.1

Focus on business value: changing to a new model to succeed with projects

From

To

Commission an ‘IT project’

Construct and lead a business change project enabled by IT

Stakeholders on periphery

Stakeholders actively involved throughout the life of the project

Accountability for delivery to time and budget

Accountability for business value

Perception that technology delivers the benefits

Realization that people empowered through new IT enabled capability improve business performance

Project finished and team disbanded when system installed

Completion signified by benefit delivery with ongoing measures in place and review of learning for further benefits

Always jam tomorrow from the ‘big project’

Manageable set of small, do-able projects, delivering benefits and residing in a change programme

Initiatives continuously launched without reference to each other

Programmes of change managed on a portfolio basis by senior management

Each project a piece of work in its own right

Learning from every project fed into further work, avoiding mistakes and capitalizing on successful project execution

133

Part 3 Building on success

From

To

Driving improvements based on greater definition of procedures and stronger management control

Establishing a clear framework and focusing on enabling effective teamwork and collaboration and improvement through learning

The traditional model of a successful project manager or programme director is of someone who agrees a clear scope for the project and focuses on delivery of specific outcomes. This is a special skill and projects can certainly fail due to its absence. But in today’s environment a lot more is required to address the wider goals outlined above. The success of each project needs to be judged in a wider context than simply the delivery of the direct outcomes of the particular project. For example: ■

Did the project succeed in terms of delivering measurable business benefit and not just defined IT functionality to time and budget?

■

Did the project succeed in terms of addressing the original business goals – and not simply the tightly defined objectives actually agreed for the project? Some of the most risky and potentially valuable areas are often defined as out of scope to increase the probability that the project will actually ‘succeed’.

■

How did the team involved in the project improve their capabilities to be able to be more successful in the next project?

■

How do the deliverables from the project contribute to the success of future projects either from providing reusable application services or by providing reusable project ‘infrastructure’ (test environments, detailed development standards, etc.)?

■

How does the project contribute to the wider business and IS systems visions for the organization?

The team model for a project, as exemplified by MSF, establishes clear accountability for the team members and ensures they are focused on specific drivers of the overall success of the project. This creative tension is a major factor in enabling the team to succeed. In a similar way the team model established at a programme needs to include roles that are accountable for the wider success measures of that programme.

IMPLEMENTING THE FRAMEWORK ACROSS THE ORGANIZATION The concepts outlined in this briefing should be applied to the challenge of introducing the proposed new ways of working across the organization. This implies two fundamental aspects to the implementation plan:

134


■

Start small – apply the concepts to a pilot project or programme. Get an early success and learn about the challenges that have to be addressed to succeed.

■

Apply benefit management – get a clear view of the benefits required and the business changes needed to enable them.

The first step is to get some early wins with specific projects and programmes.

LOOKING AHEAD Once the fundamental challenge has been tackled and the organization can consistently ensure that IT projects succeed – and succeed in terms of delivering measurable benefits – the next steps are to tackle a number of broader challenges. These include: ■

ensuring that IT projects are planned and resources allocated to get the maximum benefit from investments in IT and to take advantage of the opportunities offered by new technology to stop doing things, to do things better or to do new things;

■

ensuring that there is effective control over the full portfolio of IT investment projects;

■

driving continuous improvement of business and IT capabilities to successfully deliver benefits from IT-enabled business change programmes and to manage the effective use of IT within the organization;

■

ensuring that individual projects contribute to a simple, flexible, coherent set of systems that enable the business to innovate and adapt in a rapidly changing world;

■

enabling individuals in business and IT functions to share insights and good practices into: – opportunities for business value from IT; – systems development and service management processes; – how best to deploy specific technologies;

■

transferring the approach to other areas of the business – the concepts and tools outlined are suitable for tackling a wide range of creative endeavours within an organization, for example much of the work of a marketing function is project based.

The concepts already outlined provide a good foundation for tackling these wider challenges.

135

Part 3 Building on success

FINAL THOUGHTS The potential for IT to transform businesses and industries through creating opportunities to do new things, to improve existing ways of working and to reduce costs is huge. IT can also make work more rewarding and fun. The pace of change driven by the Internet and the rapid innovation in computer and communications technology will only continue to accelerate. However, there is a huge gap to cross between the opportunity to deliver business value from IT and the reality of the benefits that are actually achieved. Although the concepts and tools described here have not been pulled together in this way before, they have been in the public domain for a number of years. There is clearly a major barrier blocking many organizations from tackling their problems with exploiting IT. One aspect of this is that the generation of management in charge of many organizations did not grow up with the PC and is not comfortable with managing IT. In fact there is no mystique in succeeding with IT – it requires leadership and straightforward management practice. It does not require senior management to have a detailed understanding of the technology – that is the job of the IT function. Senior management does, however, need to put IT clearly on the board agenda and invest time in understanding how IT can transform companies and industries. Senior management also needs to devote more time to driving through the business changes that will produce the benefits enabled by IT.

136

Appendices

■

1

Exploring the investment portfolio

■

2

Resources

139

143

137

Appendix 1

Exploring the investment portfolio

139

External links

End user development of user/IS team

Technology strategies

Complex applications built in increments on and some times on top of key operational systems

Rapid low-cost iterative development

Determine next stage of development

Technology interception planning

Tailor ‘packages’ to needs

Isolate risky systems

External technology influence

Tested disaster recovery plan

Tested disaster recovery plan

Peak demand capacity

Application evaluation focus or general use evaluation

Peak capacity planning

Flexible architecture

External skills/knowledge transfer

Careful technology selection – IT veto

Mandatory standards

Application packages – enhanced

Incremental technology

Quality/change control

‘Ideal’ technology – new skills

R&D control – separate activity

Integrated architectures

Incremental development

Executive support

Limited package applicability

Evolving or creating a new business process

IS and users’ skills and knowledge high during development, package integration and support

Strict change control procedures

Industry-specific packages

Sustain quality and efficiency

General purpose application packages – unmodified

Low priority contingency plans

Avoid obsolescence

End user support – ‘approved’ technology solutions

Disinvestments – facilities management etc.

Capacity plan on average requirements

Evolutionary technology

Efficient/low risk

Integration not vital

Compromise business needs rather than modify package

Skills – package selection and implementation/essential interfaces/vendor management

Minimum maintenance

Minimum intervention

Efficient, robust, long life Complex, integrated and based on corporate model

Standard packages

Support

Well designed

Key operational

Prototype developments

Focused pilots/broad potential

New skills/skills transfer

Good interconnectivity with key operational systems and external data

Close partnership between users and IS professionals/ new skills

Independent – integration and data management not appropriate

Business ‘champion’

Fast and flexible development approach

Evaluate technology or business idea

Development approaches and characteristics

Strategic

High potential

Investment portfolio

Rapid evaluation of prototype

Critical requirements

Identify the next step/best way to proceed

Avoid wasted effort/resource on failures

R & D project to explore potential value and cost – fund from R & D budget risk money

Quantified performance improvement

Disadvantage/risk if not done

Process rationalization and integration

Increased business effectiveness

Avoid a business disadvantage

Integration/rationalization to speed up business processes

Improved effectiveness of existing business activities (speed, accuracy and economics)


Key operational

Most effective use of IS/IT funds and resources available

Net cost reduction through quantified savings

Process elimination and cost reductions

Business efficiency

Legislation

Improved productivity/ efficiency of specific (often localized) business tasks


Support

High-quality, long-life solutions Low-cost, long-term solutions, with effective data management therefore often packaged solutions requiring a Costs balanced with benefits compromise to the and business risks capabilities of the software Flexible system that can be available adapted in the future as the May use objective feasibility new business evolves study to determine best Objective cost/benefit analysis approach/package to reduce financial risk and Probable requirement to partner/ therefore control costs link to associated business

Rapid development to meet the business objective and realize the benefits within the window of opportunity

To enable the achievement of business objectives via explicit critical success factors

New market areas

Business process restructuring

Proving the benefits of applications and technology

Demonstrate the value or otherwise of new idea or initiative

Business innovation and change

Business objectives, success factors and vision of how to achieve it

Achieve business change, obtain an advantage and then sustain it

Market requirements, commercial pressures

Investment in IS/IT applications which are critical to sustaining future business strategy

Strategic

Creating opportunity for business change

Support individual initiative through product championing

Create change

Investment justification

Business benefits

Innovative business idea

Business drivers

New technology opportunity


High potential

Definition

Systems development


Crossed fingers and an expectation to rework with user experience

Hand over system

Contract out and assume packages

Avoid undue effort

Limit to essential needs and possibly to isolation of the system in hand

Let the user manage the project

Use external services if possible

Support

With great care!

Minimize effort and ensure user self-sufficiency

Plug in and run?

Exhaustive with bias to Assume it works? technical efficiency and system Otherwise minimal effort

Aim for efficiency

Contract out or use packages

‘Big bang’ may be the only way Parallel run will probably be best Lots of education

With great care!

Well planned and meticulous, biased to end users’ needs

Limited prototyping

Based on work by the Cranfield Information Systems Research Centre and specifically on Ward and Griffiths (1996).

Informal

Use peer reviews to identify weaknesses and firm up ideas

Innovative but carefully planned and rapid

Work efficiency

Reviews

Rapid and iterative

Attention to interfaces

Carefully document work

Use prototyping to establish ideas

Contained but thorough

Creative and broad in scope

Exploratory and informal

Test system

Build system

Analysis of requirements

Meticulous project management

Strategic tools for the job

User-led

Tight definition of standards

Broad brief

Cost limits rather than firm objectives

Technically led team

Strong manager-led team

Loose and open

Key operational

Project definition

Strategic

High potential


Appendix 2

Resources CRANFIELD INFORMATION SYSTEMS Much of the latest thinking on the successful management of IT comes from the Information Systems team at Cranfield. There is a range of valuable courses that tackle in some detail many of the areas covered in this briefing. We strongly recommend these for senior IT managers. For those wanting to explore the strategic management of IT further and learn more about IS/IT strategy and the investment portfolio the key resource is: John Ward and Joe Peppard (2002) Strategic Planning for Information Systems, 3rd edn. Wiley. For organizations that want to go further in understanding and adopting these techniques the Cranfield Information Systems Research Centre and IT Directors’ Forum are also extremely valuable resources.

Information Systems Research Centre The overall purpose of the ISRC is to understand how information systems can contribute the maximum business benefit. More and more organisations are becoming critically dependent on their Information Systems for success. At the same time the pressures of an increasingly competitive environment, combined with rapidly changing technology, mean the issues to be managed and the factors influencing success with IS are becoming more demanding and complex. It will not become any easier in the future unless we understand these issues and find new ways of addressing them. The work of the Information Systems Research Centre (ISRC) focuses on meeting this management need. The emphasis of the Centre is on working in partnership with organisations to deliver relevant research and develop new practical approaches of direct value to members. (http://www.som.cranfield.ac.uk/som/isrc/)

143

Appendix 2

IT Directors’ Forum The IT Directors’ Forum provides you with the opportunity to: ■

Participate with forward thinkers in exploring leading edge IT management approaches and ideas

■

Undergo professional development in a non-mechanistic way

■

Keep abreast of what is happening in the industry

■

Network and share practical experiences with IT directors facing similar issues

■

Build relationships with your peers. (http://www.som.cranfield.ac.uk/som/itdf/)

OFFICE OF GOVERNMENT COMMERCE The resources provided by the Office of Government Commerce (OGC) are also valuable. See the OGC website at: ■

144

http://www.ogc.gov.uk/

References and further reading

Breu, Karin and Hemingway, Christopher (2002) ‘Workforce agility: The new employee strategy for the economy knowledge’. Journal of Information Technology, 18. Chatham, Robina and Patching, Keith (2000) How the IT Manager Gets Streetwise. Butterworth Heinemann. Cranfield School of Management, IS Research Centre (2000) Benefits Management: Best Practice Guidelines. DeMarco, Tom and Lister, Timothy (1999) Peopleware: Productive Projects and Teams, 2nd edn. Dorset House. Maguire, Steve (1994) Debugging the Development Process. Microsoft Press. McCarthy, Jim (1995) Dynamics of Software Development. Microsoft Press. McConnell, Steve (1998) Software Project Survival Guide. Microsoft Press. McConnell, Steve (1996) Rapid Development. Microsoft Press. Ward, J. and Griffiths, P. (1996) Strategic Planning for Information Systems. John Wiley & Sons. Ward, J. and Peppard, Joe (2002) Strategic Planning for Information Systems, 3rd edn. Wiley.

145

For where to go, who to read and what to know in the world of IT. If you’re looking for books on IT then visit: www.it-minds.com, the place where you can find books from the IT industry’s leading IT publishers.

[Choice of publishers]

Infinite choices for the IT Minded

IT-Minds is home to some of the world’s leading computer book publishers such as Sams, Que, Addison-Wesley, Prentice Hall, Adobe Press, Peachpit Press, Cisco Press and Macromedia Press.

[Choice of ways to learn] We publish for those who are completely new to a computer through to the most cutting-edge technologies for the IT professional and our products offer a variety of ways to learn. IT-Minds offers you tutorials, handy pocket guides, comprehensive references, exam guides, CD based training materials and Executive Briefings.

[Choice of subjects] We also cover the A-Z of computer subjects: From ASP, Bluetooth, C++, Database, E-Mail, Flash, Graphics, HTML … to Windows XP, XML, Yahoo and Zope. As an IT mind you also have access to: ● News from the IT industry ● Articles written by our featured authors ● Free weekly newsletters ● Competitions to win prizes ● Testing and assessment products ● Online IT training products

[Custom Solutions] If you found this book useful, then so might your colleagues or customers. If you would like to explore corporate purchases or custom editions personalised with your brand or message, then just get in touch at www.it-minds.com/corporate.asp

Visit our website at:

[www.it-minds.com]

Delivering Business Value From It Projects (Financial Times Itb)

Delivering Utility Computing: Business-Driven IT Optimization

ROI for Technology Projects: Measuring and Delivering Value

Financial Turnarounds: Preserving Enterprise Value (Financial Times Prentice Hall Books)

Achieving Business Value From Technology

Delivering Successful Projects With TSP

Modelling Financial Times Series

Benefits Management: Delivering Value from IS & IT Investments (John Wiley Series in Information Systems)

Value Creation from E-Business Models

IT Projects CoursePrep ExamGuide

IT Times (5.11)

IT Times (5.12)

Shared Service Centres: Delivering Value From Effective Finance And Business Processes (Management Briefings Executive Series)

Leading IT Projects: The IT Manager's Guide

IT Financial Management

Market Leader: Business English with the ''Financial Times''

Financial Times Guide to Business Start Up 2009, 22th Edition

Financial Turnarounds: Preserving Enterprise Value

IT Portfolio Management: Unlocking the Business Value of Technology

Harvard Business Review on the Business Value of IT (Harvard Business Review Paperback Series)

Aligning Business and IT with Metadata: The Financial Services Way

Financial Ratios: How to use financial ratios to maximise value and success for your business'

Exploiting IT in Business

IMC, The Next Generation : Five Steps For Delivering Value and Measuring Financial Returns

Financial Ratios: How to use financial ratios to maximise value and success for your business'

Shareholder Value: A Business Experience

IMC, The Next Generation : Five Steps For Delivering Value and Measuring Financial Returns

Executive Accountability: Creating the Environment for Business Value from Technology

Financial Times Guide to Using the Financial Pages, 5th Edition

The Network Experience: New Value from Smart Business Networks

Capital Budgeting: Financial Appraisal of Investment Projects

Delivering Business Value From It Projects (Financial Times Itb)

Delivering Utility Computing: Business-Driven IT Optimization

ROI for Technology Projects: Measuring and Delivering Value

Financial Turnarounds: Preserving Enterprise Value (Financial Times Prentice Hall Books)

Achieving Business Value From Technology

Delivering Successful Projects With TSP

Modelling Financial Times Series

Benefits Management: Delivering Value from IS & IT Investments (John Wiley Series in Information Systems)

Value Creation from E-Business Models

IT Projects CoursePrep ExamGuide

IT Times (5.11)

IT Times (5.12)

Shared Service Centres: Delivering Value From Effective Finance And Business Processes (Management Briefings Executive Series)

Leading IT Projects: The IT Manager's Guide

IT Financial Management

Market Leader: Business English with the ''Financial Times''

Financial Times Guide to Business Start Up 2009, 22th Edition

Financial Turnarounds: Preserving Enterprise Value

IT Portfolio Management: Unlocking the Business Value of Technology

Harvard Business Review on the Business Value of IT (Harvard Business Review Paperback Series)

Aligning Business and IT with Metadata: The Financial Services Way

Financial Ratios: How to use financial ratios to maximise value and success for your business'

Exploiting IT in Business

IMC, The Next Generation : Five Steps For Delivering Value and Measuring Financial Returns

Financial Ratios: How to use financial ratios to maximise value and success for your business'

Shareholder Value: A Business Experience

IMC, The Next Generation : Five Steps For Delivering Value and Measuring Financial Returns

Executive Accountability: Creating the Environment for Business Value from Technology

Financial Times Guide to Using the Financial Pages, 5th Edition

The Network Experience: New Value from Smart Business Networks

Capital Budgeting: Financial Appraisal of Investment Projects

Recommend Documents