1. Trang chủ
  2. » Kinh Doanh - Tiếp Thị

Project management for information systems

400 330 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 400
Dung lượng 16,84 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Telecommunica-Patrick Manning, managing director of Galileo Consulting, is a managementconsultant specialising in the commercial aspects of project management andadvising senior managers

Trang 2

Independent consultant and Associate Client Director, Henley Management College

An imprint ofPearson Education

Harlow, England London· New York « Boston San Francisco Toronto Sydney Singapore Hong Kong

Trang 3

Essex CM20 2JE

England

and Associated Companies throughout the world

Visit us on the World Wide Web at:

www.pearsoned.co.uk

First published 2001

© Pearson Education Limited 2001

The rights of James Cadle and Donald Yeates to be identified as

authors of this work have been asserted by them in accordance

with the Copyright, Designs and Patents Act 1988.

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 publisher or a licence permitting restricted copying

In the United K'lngdom issued by the Copyright Licensing Agency Ltd,

90 Tottenham Court Road, London WH 4LP.

Trademark notice

Many of the designations used by manufacturers and sellers to distinguish their

products are claimed as trademarks Pearson Education has made every attempt to

supply trademark information about manufacturers and their products mentioned

in this book.

The following designations are trademarks or registered trademarks of the

organisations whose names follow in brackets:

Joint Application Development (JAD) (International Business Machines Corporation); Microsoft Project (Microsoft Corporation); PRINCE, PRINCE2 (CCTA); Project Workbench (ABT) ISBN 0 273 65145 5

British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Cataloguing-in-Publication Data

A catalog record for this book can be obtained from the Library of Congress

Trang 4

v

Trang 5

4.7 The traditional approach to systems development 58

Trang 6

7 Project planning: estimating

7.1 Estimating for information systems projects

7.2 Estimating in engineering disciplines

7.3 Estimating methods compared

7.4 Estimating for supporting activities

7.5 Human factors affecting estimating

7.6 Practical experiences with estimating

115115116117127133134137137138139

141141141148150151154156158158159

165165165169171177178178179

180180181

Trang 7

10.3 Possible corrective actions10.4 Implementing corrective actions10.5 Change control

10.6 Change control and configuration management10.7 Summary

10.8 Questions10.9 Case study

11 Reporting progress

11.1 Introduction11.2 Recipients of progress reports11.3 Frequency of reporting11.4 Report content and format11.5 Reporting in PRINCE11.6 Summary

11.7 Questions11.8 Case study

12 Quality

12.1 Introduction12.2 Quality concepts12.3 Total quality management12.4 National and international initiatives12.5 Quality management systems

12.6 The cost of poor quality12.7 Inspection versus testing12.8 The management of software testing12.9 Metrics and statistical quality control12.10 Supporting activities

12.11 Configuration management12.12 Managing quality with PRINCE12.13 Summary

12.14 Questions12.15 Case study

13 Risk management

13.1 Introduction13.2 Outline of the risk management process13.3 Risk identification

13.4 Risk assessment13.5 Risk actions13.6 Risk management planning and control13.7 The risk register

182187188190i90190191

192192192193194198199200200

203203203205208211213215217218220221222223224224

225225225226231233234235

Trang 8

13.8 Risk ownership

13.9 Other risk concepts

13.10 Risk management in PRINCE

15.2 Buying and buyers

15.3 The selling process

17.2 Setting up the contract

17.3 Monitoring supplier performance

17.4 Quality control and subcontractors

17.5 Summary

17.6 Questions

17.7 Case study

235236236237237238

240240242246246

247247248251254257258258

260260260261265268270276277277278279279280282284285286286

Trang 9

19.6 Performance improvement through coaching 315

20.2 Job descriptions and person specifications 323

Trang 10

22 The project manager

369372374377

Trang 12

It gives us great pleasure - and not a little relief - to bring this third edition

of Project Management for Information Systems into your hands As with vious editions, we have had three groups of people in mind when preparingthe book:

pre-• Practising systems analysts who find themselves responsible for managing tems projects. Newcomers to this activity will find much that will be ofhelp to them; we also hope that older hands will find some new ideasthat help them to tackle the job with renewed vigour

sys-• Students of information systems and project management. Not everything can

be learned from books Oscar Wilde said that 'experience is the nameeveryone gives to their mistakes', and throughout the book we haveincluded advice based on experience learned the hard way

• Part-time developers. Many people are drawn into the development ofapplication systems and have no need to understand all the duties of theproject leader Selected reading can, however, help you in understandinghow your activities fit into the whole scheme and will, we hope, lead tobetter project management

The principal changes from the second edition are:

• An enhancement to Chapter 1 (Managing Change) to address the issue oforganisational culture in more detail There is also an analysis of whyinformation system projects fail and what can be done to make successmore likely

• Chapter 3 (The Organisational Framework) has a new section on gramme management and the discussion of the PRINCE®method has beenrevised to accord with PRINCE2®

pro-• New sections have been added to Chapter 4 (System DevelopmentLifecycles) on object-oriented approaches, on component-based develop-ment and on projects which are selecting or implementing a packagedsolution

• The discussion of project initiation in Chapter 5 (The Profile of a Project)has been expanded and there is a new section on investment appraisal ofpotential projects

xiii

Trang 13

• In Chapter 8 (Project Planning: Scheduling and Resourcing), node' scheduling has been substituted for ' activity-on-arrow' as the for-mer is more commonly used today and is the basis for popular projectplanning packages such as Microsoft" Project.

,activity-on-• A short discussion of the role of risk management in a PRINCE2® projecthas been added to Chapter 13 (Risk Management)

In addition to these changes, a running case study has been incorporatedinto the book This is fictitious but based on real project issues and the idea

is to show how the concepts described in the text can be applied in practice.Not all chapter subjects lend themselves to case study illustration (particu-larly those towards the end of the book on issues such as the working envir-onment and project management competences) but, where a case studyillustration might prove valuable, it will be found at the end of each chapter.The bibliography has been revised and there is a new set of web referenceswhere further information on project management topics can be found.The acknowledgements are to the contributors to the second edition Thecommon thread between all of these people - perhaps not so evident now -

is that at one time or another we have all been involved with project delivery

or training for Serna pIc, one of the world's leading information technologyservices organisations We think we can fairly claim that the ideas offered inthis book are the result of many years of hard-won experience

Some more specific acknowledgements in respect of the third edition: we'dlike to thank Elvina Culver for her assistance in typing parts of the book andalso our respective 'other halves' for their understanding as we have toiledaway in our studies at nights and weekends Also, we would like to thankAlison Kirk, Laura Graham and Tina Cadle of Pearson Education for keepingour noses to the grindstone in the nicest possible way as well as Jill Birch,freelance project editor

James Cadle Donald Yeates London, 2001

DisclaimerThe publishers and authors do not accept responsibility in any way for thefailure of any project carried out based on ideas in this book or followingyour reading of this book Whilst the ideas and good practices are based onhard won experience, they need to be applied with skill and understandingand take account of project circumstances Good luck!

Trang 14

This book is a revised and expanded version of the second edition launched

in 1996 Although it has been changed considerably, it still owes much to theoriginal band of contributors without whose efforts it would not be in yourhands now The team included:

David Archer, an independent management consultant specialising in changemanagement, helping organisations to deal with the changes resulting fromthe implementation of new systems

Dick Barton, Training Manager for Gemini Consulting, with 12 years' ence of developing projects and project management training He also con-sults in human resource management and organisation development.Christine Donaldson, an independent trainer and consultant working in thefields of human resources and psychometrics

experi-Jill Freinberg, an independent training consultant specialising in humanresources issues, customer management and psychometrics

John Koenigsberger, the Quality Manager of Sema's Mobile tions Division, has 30 years' experience of project development and qualitymanagement in the UK and overseas John is also a consultant to the Inter-national Management Centre in Buckingham

Telecommunica-Patrick Manning, managing director of Galileo Consulting, is a managementconsultant specialising in the commercial aspects of project management andadvising senior managers on business development issues

Alan Paul, a project manager with 20 years' experience of systems ment and project management in both the public and private sector, includ-ing the formulation and management of information system strategies.Debra Paul, a director of Assist Knowledge Development and a managementconsultant and trainer specialising in business and systems analysis Debra isalso a member of the Information Systems Examinations Board's BusinessSystems Development Board

develop-xv

Trang 15

Finally, the editors After nearly 40 years in information technology and ing management, Donald Yeatesnow works for himself instead of for others.

train-He likes to think of himself as reasonably good at managing projects andpeople and also works as an Associate Client Director for Henley ManagementCollege James Cadle has been involved in management services work for 25years and is a director of Assist Knowledge Development and a consultantand trainer specialising in the fields of project management and business sys-tems analysis

We are grateful to the following for permission to reproduce copyrightmaterial:

Figures 4.1 and 4.5 from Computer, © 1988 IEEE, with permission from The

Institute of Electrical and Electronics Engineers, Inc., May 1988; Figure 4.3

from NCC STARTS Guide, reproduced with permission of the National

Computing Centre Limited, Manchester from the STARTS Guide which wassupported by The Department of Trade and Industry, 1987

Whilst every effort has been made to trace the owners of copyright material,

in a few cases this has proved impossible and we take this opportunity tooffer our apologies to any copyright holders whose rights we may have un-wittingly infringed

Trang 16

Managing change

1.1 INTRODUCTION

All new information technology (IT) systems bring a range of associatedchanges with them These may be changes to business processes and proced-ures, new roles and responsibilities, organisational restructuring, new equip-ment or facilities, or new skills to learn All of these involve people, and it isthe people within any organisation who are the key to the success of any ITimplementation No matter how well designed the new system and how wellplanned the implementation, without proper consideration of the 'peopleissues' your project will fail Managing change is all about dealing with thepeople issues, and about involving people at every stage in the project to helpensure it realises the full business benefits Information systems are only tools

to enable people to take better decisions, so getting the commitment of thepeople who will use the system is central to the success of your project.Managing change means being proactive in identifying and planning forthe changes that need to take place within the business to support the newsystem Many post-implementation problems are caused by users not havingbeen adequately prepared for the change - for example, a lack of training orcommunication, or failure to get support and commitment to the changesfrom key users These problems can be avoided by planning a change pro-gramme at the start of the project and running the programme throughoutthe life of the project and for some time beyond it

Organising the project so that there is a user project manager with a ibility for managing the change can be a great help in enabling these peopleissues to be tackled

respons-Key considerations for a change programme are:

• Plan the change programme in the same way as you plan the ment and implementation of the system itself - these processes are integ-ral and not separate

develop-• Ensure that the change programme includes communication and training,but also considers the impact of the change on the users: the timing andmethods used to implement the system should be planned to make thetransition as easy as possible for the user

1

Trang 17

• Phase the introduction of change to ensure that people are not bombardedwith too many changes at once, and allow for periods of consolidation toenable people to become comfortable and confident with new respons-ibilities, processes or environments.

because they understand the issues in the user community: this will help

to ensure that those in the business are in control of the change, and aremanaging it, rather than being helpless bystanders to something that isimposed on them

This chapter explores some of these issues in more detail, and gives somepractical advice on how to plan and run your change programme

Business change is all around us and the pace is ever increasing The time tomarket for new products is decreasing year on year, privatisation has broughtradical change to public institutions, and increased globalisation in manysectors has brought the challenge of managing across national boundariesand cultures Organisational change is now commonplace and, given this, youmight be tempted to suppose that some universally applicable rules wouldhave emerged to guide you when planning a new IT project within a chan-ging business environment However, on closer examination the main lessonseems to be that there is not one easy prescription for managing change -there are many complex influences on the way people react to change and inany given project their behaviour is not easy to predict Fortunately there aresome patterns that can be found buried in the mystery of organisationalchange

The first thing to look for is the business context for your project: what isreally driving the investment of all this time and effort in delivering new ITsystems? There is further discussion about this in the next chapter, but it isenough for now to note that there are four broad reasons for organisations

to invest in large-scale corporate IT development programmes:

• Business survival

• Improved efficiency

• Potential competitive advantage

• External factors, such as legislative change, privatisation, merger and soon

The business context will have a major influence on your tactics for takingpeople with you throughout the project lifecycle, and on how you prioritisethe efforts of your project team Let us examine each of the four differentreasons

Trang 18

In some situations the increase in operational efficiency may come from thedesign of the system itself - through decreased processing time, for example

- but these situations are rare In most cases it is people's making better agement decisions based on the information provided by the systems thatresults in increased efficiency In this context you have to take people withyou and to be sure that they know what abetter decision is, are able to accessand interpret the data which informs that decision, and are motivated to take

man-it Management information systems (MISs) and office systems are often theproducts of this sort of business context

The key here is to encourage innovation and new ideas throughout the ject lifecycle If the way forward were clear at the start of the project thenprobably most of the competition would have thought of it too and so therewould not be much advantage in producing it Rapid prototyping and end-user solutions are tactics that often have value in this context

pro-Here, where the specification is not under your own control, you need to beever mindful of the external stakeholders who have to be satisfied by whatyou are doing Involvement is a key process here to ensure that all of the keyplayers, internal and external, are taken along every step of the way Youneed to avoid unhappy surprises at the implementation stage but be readywith contingency plans for when the ground rules change under you It isnot enough to comply with the letter of the law but rather to continually testthat all parties have a common understanding of what is required It isunlikely in these circumstances that firm requirements specifications will beavailable and it is therefore essential that users and computer people movetogether flexibly towards the target system Risk profiling techniques are par-ticularly useful tools here Risk is covered in more detail in Chapter 13.Once you have established the business context for your work, the next pri-ority is to be clear about the pace and the scale of the change that is requiredfor a successful completion of the project Simply, this means looking at howmany people are affected, how radically they have to change their attitudesand behaviours, and how long you have to bring about this change Againthe answers to these questions will point to very different tactics for man-aging the people side of the project Programmes that have to deliver radicalchanges in short time-scales usually require changes to staffing either throughhiring and firing or through the acquisition of new organisations that containthe needed skills.If timescales are longer, but the changes are still large andfar-reaching, then you can look at fundamentally re-engineering business

Trang 19

Type of change

Radical

Incremental

Short-term (3-9 months)

Restructuring and redeployment of staff Process automation and refinement

Long-term

(7 year+) Business Process Re-engineering TQM, innovation schemes

Figure 1.1 Time and change matrix

processes to deliver the potential of the new systems and have the time todevelop existing staff to run the processes

Ifthe scale of change is incremental or affects only small numbers of peoplethen tactics borrowed from the total quality management (TQM) world areoften appropriate (see Figure 1.1) Quality circles or focus groups can bothincrease buy-in and also generate ideas for process improvements They can

be used throughout the design and development phases and, particularly afterimplementation, to manage the requests for enhancements to the original func-tionality However, our experience shows that it can take more than two years

to set up these mechanisms, embed them into the culture and really ate returns on this basis

gener-Having looked at some large-scale strategic issues which you need to bear

in mind when planning the project, the next section focuses on the personalissues What does it feel like to an individual user who may be part of thetarget audience for your system, and what might be their reactions to theproject?

The Chinese ideogram for change is actually made up from two symbols:one which represents danger, the other opportunity And that is one of theparadoxes of change: any new situation contains within it some danger, someloss, but also the potential for new opportunities Daryl Conner and othershave done work in developing questionnaires to classify people as D-type ora-type: Danger people or Opportunity people Not surprisingly, most pro-ject leaders and business managers are a-type, they have got to their current

Trang 20

Confidence

Launch Communication Education Exploitation

Figure 1.2 The phases of change

position by seizing on new opportunities But the majority of users who aretargets for a new system are probably D-type people, and they may well seethreat in the change and seek to find ways of resisting it

Resistance to change can be active or passive If it is active, the resistance

is '::Aplicit and obvious For example, when a dairy introduced a new puter system designed to improve the way milkmen recorded their deliver-ies, some milkmen put diesel fuel into the milk to sabotage the project Themost obvious way some other workers express resistance to a new project is

com-to go on strike Passive resistance com-to change is harder com-to recognise but canhave effects just as devastating on information system (IS) projects as activeresistance People involved in the project might agree to functional specifica-tions and then argue later that the system is not what they wanted Staff sit

in meetings, agree solutions and then insist that their interpretation of theproposals was different from yours Alternatively, they agree with proposedproject plans and then sabotage them more subtly For example, a manager

in a building society agreed to provide an individual to become a trainer for

a new insurance system, then changed that person four times during theproject Each time, the new person had to be trained in the skills needed tobecome a trainer, the training approach and the new insurance system - thishad time and cost implications that affected the whole project You can getsome insight into the likely forms of resistance by conducting a change readi-ness assessment with your users at the start of the project

Before you work out how to deal with resistance to change, you need tounderstand the pattern of ups and downs that characterises behaviour dur-ing the lifecycle of an IS project The change curve in Figure 1.2 shows earlyenthusiasm for change gradually falling off as problems surface, and thenaccumulating strength again as people lift themselves out of the' dip' Thepoint is that, whatever the type of change brought about by your project, youwill have to drive individuals and groups along this curve In planning for

this, the first thing to realise is that:

Trang 21

The quality of the design of the solution may affect the final level of formance but the time taken to get there and the depth of the dip in per-formance in the transition will depend on how well you deal with the peopleissues Let us look at the phases of change in more detail.

Then, as people gain more information about the system, they may feel a loss

of self-esteem because the job is broader than they expected; a loss of ence in their ability to perform against the demands being made They mightexhibit signs of stress, such as working longer hours and being indecisive.Gradually, people confront their difficulties by talking them through with col-leagues or by trial and error; their self-confidence grows

confid-Over time, people become more responsive, decisive and assertive They takeresponsibility for and pride in the exploitation of the benefits that the systemcan bring

1.3 ORGANISATIONAL CULTURE

The impact of the change curve on your project and the tactics you can employ

to drive people along it depend on the culture of the organisation in whichyou are working

There is more discussion about organisational culture in later chapters, buthere we shall use a model of different organisational cultures based on thework of Charles Handy and Roger Harrison, which classifies organisationsaccording to the degree of centralisation and the degree of formality in theway things are done This is shown in Figure 1.3

To help to remember them they are characterised with the names of Greekgods You may be able to identify organisations that operate in these ways.When you run up against them you will find the following suggestions help-ful in dealing with them

Zeus or power

culture

Here, obtaining and demonstrating sponsorship is the key Everyone looks

to those with the power to supply the answers and sanction actions managed businesses often fall into this category But in larger organisationsany department with a charismatic leader can develop a power culture Unlessyou get the explicit backing of the people in power you may find that you

Trang 22

Informal

Autocratic Bureaucratic power culture role culture

Figure 1.3 Organisational cultures (after Handy and Harrison)

get low participation at user workshops and review sessions where you want

a cross-section of users to express their own opinions You also need to beaware that, whatever formal sign-off route you have agreed, no significantproducts will really be approved until the person at the top has said yes.Here the culture is formal and centralised Everyone has a role, a job descrip-tion and a formal relationship with others in related roles Public sector organ-isations and large financial institutions are often bureaucratic role cultures.The watchword here is to play by the rules but also to be aware that there

is probably a parallel informal set of relationships that people use to 'getaround the system' and to 'get things done' Ifyou can identify this and tapinto some key contacts you can often get access to information and opinionsmuch more quickly than by going through the formal channels But remem-ber that when it comes to spending money or other decisions which need to

be defensible later you need to have covered the formal systems as well.Here tasks are devolved to the lowest practical level but there is still a formalframework for reporting and decision making Organisations like this are used

to forming taskforces and problem-solving teams Modern manufacturingcompanies often fall into this category In many ways it is the easiest cul-ture in which to run a project as many of the traditional disciplines of pro-ject management such as planning and control and team responsibility areembodied in a task-based culture The main source of difficulty here isthat user staff may want to get too involved in the running of the project, toquestion all the internal working arrangements of the project and to beengaged throughout the life cycle rather than just providing input or review

at a specific stage

Here the organisation is so informal and decentralised that people often donot like to think of it as an organisation at all In general, professional organ-isations often best fit this category Lawyers may talk of their practice orchambers and designers talk about their studio; people working in a Dionysusculture may say things like - 'we all think of ourselves as more of a familyhere' In a culture such as this, everyone has a distinct voice and all opinions

Trang 23

deserve to be aired This type of organisation can be a very challenging place inwhich to run an IT project The watchwords are to use the formal mechan-isms, such as the baselining of specifications and plans, sparingly But whenyou do, make a big show of it Make it very clear to all concerned why you,

as the project manager, need to go through this process in order to do yourjob properly, and try to win their respect as a fellow professional Also spellout the consequences of going back on a decision once agreed and highlightany forthcoming decision dates well in advance

More recently, Gareth Jones and Rob Goffee have offered an alternative butconnected analysis of organisational culture which, from personal experience

of its use, really lights up the bulbs in people's heads when they considertheir unit's culture They say that the character of an enterprise, a division, adepartment or a project can be described by identifying its

• Sociability, and its

• Solidarity

These terms need some explanation Sociabilityis a measure of friendliness

It is the same in our personal lives and at work It means that people relate

to each other in a friendly, caring way; they 'look out' for each other Projectteams with high sociability play together outside work, invent their own lan-guage and develop their own team characteristics The benefits at work thatcome from high sociability are often those associated with high team spirit,the sharing of information and ideas, and a willingness to work beyond nor-mal limits The kind of atmosphere found in start-up companies is often high

on sociability where high creativity and a commitment to performance areessential to establish and grow the business

Sociability is not a universally' good' dimension: it has a dark side Highsociability can lead to friendship becoming more important than performance.There can be too much tolerance of poor performance or disagreements, withcolleagues being unwilling to criticise or disagree The result is that the bestsolution never gets implemented; life is all about compromise In large organ-isations, high sociability can lead to the establishment of cliques, 'kitchen cabi-nets' and 'in groups' where those 'in' disempower those who are 'out'

Ifwe think of sociability as a heart thing, then solidarityis a head thing It

is very much concerned with the tasks of project management: common goals,common tasks and mutual interests that affect everyone You do not have tolike everyone on your project but you do have to focus to get the job done

In high solidarity organisations, poor performance is not tolerated and poorperformers are shown the door - and no one misses them when they aregone No doubt a project team's customer would rather see this kind of cli-mate than one high in sociability where compromise rather than goal achieve-ment was the norm

But would anyone want to work in solidarity-focused project teams? Toomuch focus on the goals can lead to an unfeeling atmosphere where perform-ance is the only thing that counts and there is little inclination to explore thereasons for poor performance so that they can be addressed

Trang 24

Figure 1.4 Sociability/solidarity matrix

These two dimensions - sociability and solidarity - give us the matrixshown in Figure 1.4 with the four different cultures

Let us look briefly at these four different cultures; remember that each haspositive and negative aspects which are displayed in various ways

In networked cultures:

• People know each other at work and outside work They like each otherand help each other

• There is openness, trust and tolerance

• Poor performance is managed in the ways described in Chapter 19 onperformance management

• Development is encouraged and there is an open approach to developingcareers and moving people around

• People deal well with complexity and uncertainty; they can 'feel' theirway towards a solution

On the other hand, networked cultures can be over-tolerant of poor ance, there can be over-reliance on consensus, and too much focus on pro-cess and discussion rather than on outcomes and results

perform-In mercenary cultures:

• There is strong agreement about targets and goals

• There is a real sense of purpose and drive

• Work is very important and there is great task focus

• Socialising has a purpose: to talk about work

On the other hand, it is a ruthless place to work There is no peace orsympathy and people who do not deliver are a 'waste of space' Managersthink short term about meeting results and there is little inclination to helpanyone else

Trang 25

• People work for themselves and not for the organisation.

• High performance is everything; it is not who you know, it is what youdeliver that counts

• There is a lot of freedom; you do not have endless consultation (highsociability) or constant reminders of corporate goals (high solidarity)

On the other hand, it is not a particularly friendly place to work, a fragmentedculture is the culture of the individual This often makes it a culture found

in legal practices, consultancies, journalism - print, radio and television - andthe academic world

People in communal cultures:

• Have a high level of commitment to each other There is friendship aswell as high energy and focus on the goals

• Are focused on the product or service; there is no need for personalagendas

• Work in teams all the time

• Support the leader

On the other hand, communal cultures absorb all of your time Either youare goal-focused (high solidarity) or you are colleagues-focused (high soci-ability) It is a great place to work ifyou believe in the brand and want tobelong, but not if you want time to think your own thoughts or have a lifeoutside work

Finally, some overall comments about organisational cultures It would

be neat and tidy if an organisation had only one culture and, whilst it istrue that organisations can be characterised by a single culture, for exampleindividualistic (using Handy) or fragmented (using Jones), most organisationscan demonstrate several different cultures within them at the same time Forexample, the human resources department might be networked, the consult-ing division might be fragmented and the sales division might be mercenary.Also, no single culture is good or bad by definition It all depends on what

is right or appropriate for the competitive climate and the work context Forexample, if the IT department has a networked culture and you are leading

an external consulting team there, you will need to accommodate your ture and the way you work to your client's needs

Most information systems are a tool for people to use to support them intheir job - therefore to implement the change successfully you have to ensurethat people are using the system effectively and efficiently Just because the

Trang 26

system is available does not mean that people will use it Therefore, a changeprogramme that combines training, awareness, communication and businessprocess design activities is crucial to the success of an information systemsproject Armed with a knowledge of the business context for the project and

an understanding of the organisational culture you are working within, youcan design and manage a change programme which takes the users with youand ensures that the project as a whole delivers what the business needs.There are four overlapping stages in such a change programme:

• Launching the project

• Winning hearts and minds

• Skilling the end-users

• After go-live

1.5 LAUNCHING THE PROJECT

As soon as the project is launched, find a sponsor from the business who willact as the change manager; they will need to be credible and influential ratherthan senior You need to work in partnership with this sponsor because youneed them to visibly sign up to decisions and take a leading role in bringingabout the change You also need to raise their aspirations so they become aradical champion for the project Manage their expectations of the technicaldifficulties, as well as the people difficulties, in implementing the new sys-tem so they do not become disillusioned when the going gets tough

You will need help from other people as well, so try to identify championsand change agents throughout the organisation and get commitment fortheir involvement from their line managers This group will need trainingand support to develop new skills to carry out change programme tasks Forexample, you might need to train people to become system trainers or runuser acceptance tests Remember, though, that delegation of tasks does notmean abdication of responsibility: you should provide ongoing, active sup-port and monitor people to ensure that their learning is positive and effect-ive For example, you might review a training guide or observe a practicetraining session and then provide constructive feedback You must focus onthe business benefits of the change you are introducing, and as a team sharethe responsibility for achieving them

Having prepared the sponsor and the user side of the project team, youthen need to launch the project to a wider user audience At this early stage

in the system's project lifecyde you probably will not have many facts abouttimescale or functionality, and the temptation is to say nothing in case goingpublic means you will be held to account later In fact the greater danger isthat by saying nothing the grapevine will run riot and the rumours that spreadabout what the system can or cannot do could cause far more damage to yourfuture reputation Typically at this stage what people want to know is: whythe system is being introduced, who is responsible from the business point

Trang 27

of view for making it work, when it will affect them, and some broad-brushpictures about what it could do for the business and how this could be meas-ured Wherever possible you should try to ensure that these messages aredelivered down the management line - starting with your sponsor rather thanfrom the IT department.

Do not be afraid of saying 'I don't know', but be clear about what is known,and give dates that you are prepared to stick to for when you will be able

to give more information A 'countdown to go-live' chart is a good way ofpreparing people for a fairly lengthy build-up before they get their hands onthe system You might want to consider giving the project and the system aname and a visual branding, such as a logo, at this stage This gives peoplesomething more tangible to identify the project by in the months before anynew systems actually hit their desks

Winning people's hearts and minds is the next step in implementing cessful change The key is to involve customer staff in the change With helpand coaching from the project team, users can find facts, analyse data, invest-igate needs, brainstorm solutions, produce reports and prepare training com-munications materials A powerful way to start this process is to involve users

suc-in preparsuc-ing a risk profile for the project Inevitably, the pre-emptive actionsfor many of the risks will fall to the users themselves and immediately theyare engaged in making the project work

Winning hearts and minds also means communicating widely with one who will be affected by the new system First, there needs to be a con-sistent way of describing the need for change This often means finding ways

every-of describing the problems with the present situation - what is pushing ustowards a new system - and the vision, the opportunities offered by the newsystem - what is pulling us towards the new You also need to plan the rightvehicle for the communication For example, use 'hot' vehicles for sensitive

or significant information, and' cold' vehicles for uncontroversial or detailedmessages Typical hot vehicles are face-to-face events like conferences andseminars, presentations, roadshows, team briefings, and regular managementmeetings Cold vehicles are impersonal things like paper or electronic mediasuch as videos, notices, posters, e-mails or the internal mail Most of allremember communication is a two-way process: you need to make time tolisten as well as to inform

There is a useful model to remember when trying to win hearts and minds

It is not quite as simple as ABC, but it is as straightforward as AABBCC!

AA Identify audiences and the actions you want from them Audiencesand

actions.

BB Identify the barriers which audiences might have that may prevent themfrom delivering these actions and tell them about the benefits that willcome from the actions Barriers and benefits.

CC Choose the communication channels to each audience and the controlsand measures that you will use to check that the messages have beenreceived and understood Communications and controls.

Trang 28

1.6 SKILLING THE END-USERS

You need to continue winning hearts and minds right from when you firstlaunch the project through to go-live and beyond, but as the systems getnearer to live use, the emphasis of user activities has to move from givinginformation to building new skills and knowledge; from communication totraining The two sets of activities must be closely linked, and it is often agood idea to use the same team to develop and deliver both

The key to effective system training is to base it around the business tasksthat users will perform, not just around the menus and functions of the sys-tem Make the training examples as realistic as possible, use a copy of thelive data if you can By doing this people see the context in which the sys-tem will be used and you minimise implementation problems later Do not

be constrained by thinking just of conventional classroom training, considerdelivering training in the workplace, possibly using key users - but makesure you select these people carefully and invest enough time in buildingtheir training skills One successful approach is to create a model office inwhich you can run past 'real work' scenarios using the new systems and pro-cedures Well designed, these events can give the two-fold benefits of havingpowerful impact on the people involved (who have now been part of thefuture, for a few hours at least, and can then act as powerful advocates ofthe change with their peers) and also giving valuable feedback on the depend-encies between the various technical parts of the project Finally, make surethat training materials and user guides look professional The quality of theseprinted materials will playa large part in forming users' initial expectations

of the quality of the system itself

1.7 AFTER GO-LIVE

As far as the system is concerned you may think your job is almost over assoon as it goes live, but for the users the job is just beginning For users tomake the most of the potential benefits of the system and for the project toachieve its business objectives, users still need your support after go-live Thejob is much easierifthe training has been designed to produce self-supportinggroups, people who are confident in using the paper-based and on-screendocumentation and know which of their colleagues to turn to for local advice.But in setting up a support system, there are a few broad lessons to bear inmind Make sure that each level of support filters problems and resolves thosethat are their responsibility and does not just pass them on Monitor helpdesk calls and when you find repeated problems produce short, targeted 'bestpractice' user guides to educate users to solve them themselves Make surethat new recruits are properly trained in the current best practices and not justleft to find their own ways of doing things.Ifstaff turnover is high, computer-based training is an effective way of coping with new joiner training

Trang 29

• build the user team

• create a project branding Focus on key influences and early converts

• define a communication plan

• build support mechanisms

• train key users Focus on the best and the worst

• catch problems early

• stop and review, measure success

• encourage 'model' behaviour and build on the best practice

Business benefits delivered Figure 1.5 Four-phase model

Finally, make sure you stop, review the benefits that users are deliveringagainst the original objectives, and acknowledge the contribution that peoplehave made Because large projects never have a clear end-point, it is all tooeasy to forget the need to celebrate successes, to identify what still remains

to be done and to learn the lessons for next time

The four-phase model of managing business change is summarised inFigure 1.5

1.8 WHY PROJECTS FAIL

The whole of this book is to help project managers and to prevent them ing to answer the question: 'Why has your project failed?' In truth, everyoneinvolved knows two things:

hav-• Most projects fail; it is just a question of how much failure can still bedeemed a success

Trang 30

• Everyone knows the golden rules but thinks that, this time, there is asuperordinate reason for breaking the rules and that 'it will be all right

on the night' In other words, a good project manager ought to be able tosort it out; it is what he is paid for, a fter all

Let us begin with a definition of a successful project; it is one that delivers

to the customer everything specified, to the quality agreed, on time and withincost Three pieces of research are now quoted to show how often this isachieved

Perhaps most widely known is a survey by the Standish Groupin the USA.Their example included 8,380 applications Projects were classified as:

pro-The survey report does not pretend to know all of the answers, but it doesoffer a 'success potential' chart with user involvement, top management sup-port and a clear statement of requirements as the three most important fac-tors for success They also say:

smaller time frames, with delivery of software components early and often, willincrease the success rate Shorter time frames result in an iterative process ofdesign, prototype, develop, test, and deploy small elements This process is known

as 'growing' software, as opposed to the old concept of 'developing' software.Growing software engages the user earlier, each component has an owner or set

of owners, and expectations are realistically set In addition, each software ponent has a clear and precise statement and set of objectives Software compon-ents and small projects tend to be less complex Making the projects simpler is aworthwhile endeavour because complexity causes confusion and increased cost.The problem is, we do not learn from our experience or, if we do, we areunable to get our sponsors, clients or users to take notice of it The UK House

com-of Commons Public Accounts Committee sums it up by saying: 'of particularconcern is that problems continue to occur in areas where this Committeehas made recommendations in the past' The Committee, which examined 25public sector projects drew attention to the importance of senior manage-ment's role, noting that the big decisions about IT systems are likely to bebusiness based rather than technical decisions They also emphasised the inter-connectedness of IT systems and wider changes in the environment - veryoften political decisions in the public sector - and the need for good changemanagement

Trang 31

Let us finish then with something about change management and relate it

to the difficulties associated with achieving a successful project

implementa-tion The change curve in Figure 1.2 still holds true, but if we follow Kotter's

eight reasons why change fails, what do we find?

1 There is not enough sense of urgency There are not enough people whowant to make the change In project management terms this means thatthere is no top management driving force behind the need for the newsystem and no sense of urgency - 'the sooner we get this system imple-mented the sooner things will improve.'

2 There are not enough interested parties pushing for the change; it is notimportant enough to a wide cross-section of management and users Howmany projects dealing with customers actually involve customers on thesteering committee? What a powerful force that could be Do the develop-ment of hospital systems involve doctors, nurses, patients, general practi-tioners, administrators, laboratory technicians and members of the hospitaltrust?

3 There is no vision In change management terms, 'vision clarifies the ection in which the organisation needs to move.' In project managementterms it is a combination of the business case and the scope In a study

dir-carried out by Andrew Taylor, poor scope management and poorly defined

objectives were highlighted as common reasons for project failure

4 Under-communication Business change is not achieved in the short termand the same is true of IT systems developments Throughout the develop-ment lifecycle everyone needs to believe that useful change is possible,that the new system will work and will deliver the promised benefits.There are many things that can be done to make communication effectiveand later parts of this book suggest some of these But it is not just theproject team that needs to communicate; user management, sponsors andkey users need to communicate positive messages about the systemschange all the time

S Leaving an elephant in the way Successful systems change involves manypeople Good communication means the people get positive messagesabout the new system and its benefits, but obstacles always appear Theymay be organisational obstacles, or managers' refusing to let their staffparticipate in activities connected with the development process Whateverthey are, they need to be removed else they give the wrong message: one

of 'talking positive and acting negative'

6 There are no short-term wins In other words, the project waits for the bigfinish when all results are delivered at once and users are expected tokeep the faith until the day of deliverance This is what the Standish reportcalled the old concept of developing software Creating short-term winsmeans growing the solution so that a succession of successes demonstratesthe beneficial effect of the systems development project

7 Declaring victory too soon It is easy to believe that development iscomplete when systems testing is going well The IT director of a well

Trang 32

known engineering firm regularly told his fellow directors how goodthe test results were and why they should accept the new system intooperation They told him about all the errors uncovered by their users'departments and enquired when all of the changes they had requestedwould be implemented.

8 Not cementing the changes into everyday life Systems change shouldnever stop The implementation process should be pursued rigorously tomake sure that all parts of the system work and that everyone can usethem This then becomes the new baseline from which the backlog ofchanges can be tackled before development moves on to deal with newrequirements from a changing business environment

So, how can we conclude our review of why systems projects fail? Instead

of talking about failure, let us put the summary in a positive framework.Successful projects have:

• A strong business commitment to making them work They are businessand not technology driven

• A clear, detailed scope and requirements that are agreed and ically supported by everyone concerned

enthusiast-• A clear process for dealing with project changes The project is not stantly following moving goalposts

con-• Requirements that can be delivered through a series of staged productsand deliverables

• Proactive project management good at managing the client and the ject team

pro-1.9 SUMMARY

There is not an all-purpose, simple way to implement and manage change.Key ingredients in a change programme are to plan it properly as a sub-project in its own right, to ensure that communication and training worktogether to reinforce the messages of the change - the benefits of the newsystem Involving the users throughout so that they manage their changerather than become victims of it is essential Some final pieces of advice wouldinclude:

• Treat everyone with equal respect, making an effort to understand theirmotivations, viewpoints and perspectives

• Being right does not count You need to take people with you to get theirbuy-in

• Always maintain your focus on the business benefits of the change

• Take advice from, and use the help of, experts You do not have to do itall yourself!

Trang 33

Environmental stimulus

Decision to introduce new computer- based system

USER

Planning and design given to functional IS group with technical orientation

~ Re_lationshlp difficultie_s~ _ _ ~

IS SPECIALIST

Low level

of communication with IS group Low user

understanding of design processes

IS and user objectives

in conflict

Low IS understanding

of user needs Low user

confidence in

IS group

User group experiences high uncertainty

and loss of control: copes with this by

Passive resistance, low motivation, low morale

Pseudo cooperation Informal systems develop

Individual user experiences high

uncertainty: copes with this by

Physical withdrawal, absenteeism, quitting job Mental

withdrawal from threatening situation

Low IS group confidence

in user

IS group experiences isolation:

copes with this by

Authoritarian approach

Design diverges from user needs Misplaced

confidence in systems

Individual IS specialist experiences isolation:

copes with this by

Loyalty to profession not organisation

Looking for another job

System operates at low efficiency when introduced

Future systems are more difficult to introduce

Figure 1.6 The risk of the traditional approach

Trang 34

1.10 QUESTIONS

1 Figure 1.6 shows how bad an implementation can become Action needs

to be taken to prevent this kind of situation What would you mend should be done?

recom-2 You are the project manager for a new management accounting systemthat will provide monthly profit and loss accounts to a chain of 30 com-puter dealerships, each of which is franchised to its local owner/manager.They have all done their own accounting before What change issues wouldyou expect to encounter? Does the fact that they are PC dealerships makeany difference? Why might they have joined together in the chain?

3 Consider the organisation that employs you or where you study What isits culture? Why does it have that particular culture? What organisationalculture would give you most satisfaction as an employee? Where mightyou find such an employer? Given your preferred organisational culture,what would it mean for you as an employee in terms of your responsib-ilities and obligations?

4 You have to design a 'hearts and minds' programme connected with theimplementation of a new system for the recording and management ofstock in a book-publishing company and for the supply of books to book-sellers What would be the main stages of such a programme?

1.11 CASE STUDY

Introduction

The case study running through this book illustrates how the ideas and principles set out

in the text could be applied in practice to IS projects The case study itself (and the isations referred to within it) are fictional but it does illustrate the issues and problemsthat the authors have encountered or witnessed in many real-life projects

Trang 35

France Vacancescurrently uses two main sales channels:

• Direct selling to customers through mailshots of its brochures and customer slLtpportcentres (70 per cent of sales)

• Sales via high-street travel agents (30 per cent of sales)

However,the company is aware from press coverage and from surveys among itscustomers that there is a growing public demand to be able to book holidays via

net This is particularly true as its customers are precisely the sort of people who

aware' France Vacances does have a website but this is really just its

electronic format and it does not have links to up-to-date availability data or the tacilit:iesfor customers to make secure bookings online

Consequently, France Vacances has decided to implement a new internet-based bOlDkingsystem This will be linked to its existing computerised booking system, which containsdata on the availability of properties, and to its customer database as well as havinglinks over which credit card data can be received In addition, the company wants

enhanced so that it can 'trawl' its databases and send targeted information to customers

on properties that are likely to be of interest to them

France Vacances organisation

The current organisational structure of the company is shown in Figure 1.7

Richard ThorntonFinance Manager andCompany Secretary

Mary Appleby

MarlagE!rS (8)

negotiators (4)

Salessupervisors (4)Telesalesstaff (44)

Accountspayable (3)Accountsreceivable (4)Bankingsection (2)

OrganisatiOn of France Vacances

Trang 36

In essence, the two founders have divided the business between them David Martin(who has a sales background) looks after the sales and operations side, and Jean-PierreMassenet, an accountant, takes care of finance and administration.

The small IT department within the administration function consists of the IT manager,Peter Clay, three analyst; programmers and a computer operator; trainee programmer

The project

Because of the small size of its IT department, and since it lacks skills in the design of commerce applications, France Vacances has decided to entrust the development of itsinternet service to a consultancy company, E-Con This firm has tendered for the followingservices:

e-• Analysis of the requirements

• Production of a detailed requirements specification

• Design, development and implementation of the internet systems, including a new site and secure communications links

web-• Training France Vacances staff in the use of the new systems

• Specification of the interfaces required from France Vacances's existing customerdatabase and booking system (the development of the links at the France Vacances end

to be done by its own IT department)

• Specification of the additional hardware required to support the new system (to beobtained from France Vacances's usual suppliers, the procurement to be managed bythe IT department)

• 'Skills transfer' to France Vacances's IT department, so that ongoing maintenance anddevelopment of the new system can be handled in-house The development of the MISaspects of the new system will be dealt with by France Vacances's IT department.The date now is 1 April and France Vacances wants to have the new system up andrunning for the start of the winter season's bookings at the end of June

Organisational issues

Imagine that you work for E-con and that you are part of the team assigned to the ject for France Vacances Because of your special skills and experience you have to write

pro-a bpro-ackground ppro-aper pro-and brief your project collepro-agues pro-about Frpro-ance Vpro-acpro-ances - the kind

of organisation it is and its organisational culture You also need to give your colleagues

a few tips to help them to fit in with France Vacances

What are some of the things that you would do to uncover the information to give toyour colleagues and what results would you expect to find?

A useful technique to use, to get rough-and-ready but fast information about priorities,

is the critical incident technique A group of people representing the target population isasked about the topic to be investigated or about the way they would respond to specificcircumstances For example, a services company might spend 80 per cent of its trainingbudget on technical training because it believed that it was important to be a technological

Trang 37

leader, and 20 per cent on project management and interpersonal skills If a c

ent survey and analysis showed that fewer than 25 per cent of the ct ov

caused by technical issues and that about 75 per cent were caused by

tomer management, then the training budget should perhaps be 11

In a cultural analysis context you might explore how E-con han success and failure,change and innovation, opportunities and threats So what critical incidents could

to your group of representative France Vacances people? You would need to fin

identifying networked, communal, mercenary or fragmented cultures if you w

the Jones and Coffee model This would mean exploring the extent of solidarity a

ility at France Vacances Let us take as an example how the different cultures

at pay rise time - surely a critical incident if ever there was one Someone recei

big rise What does it mean and how do the different cultures react?

• Networked people either want to be in their network (a good place to be because tare obviously going places) or assume that she has pulled off a confidence trickbeen unfairly rewarded (a negative response)

• Mercenary people might work harder so that they get a similar rise next time, ormight concentrate on defeating the successful person or bringing them down in sway

Try working out for yourself how a fragmented culture (low solidarity and

ability) and a communal culture (high solidarity and sociability) might react

accurate picture Try devising some more critical incidents for success, failure, ch

innovation, opportunities and threats

Trang 38

Business strategy and

information systems

2.1 INTRODUCTION

This chapter is all about context: the business context within which systemsprojects are created; how the strategy of an organisation determines its shapeand how that shape determines the business processes and their systems Thiscontext begins with a 'systems planning activity' that determines which pro-jects are started according to the needs of the enterprise The systems plan-ning function enables business plans to be translated into developed computersystems to meet business goals Typical business goals might be related toprofit, or growth, or market share but could also focus on customer services,safety or staff development Business goals lead to the identification of keyresult areas (KRAs) which specify in turn the need for new systems IS man-agement is therefore concerned with the development of new systems to con-tribute to the achievement of the business's key result areas Figure 2.1 showshow this systems planning process can take place and how it can produce arange of possible systems projects

We now want to look at what happens before the systems planning ity and address some of the issues around an organisation's strategy Withincreasing expectations that computer people - especially analysts and pro-ject managers - will have an understanding of the wider environment withinwhich organisations operate, it seems even more necessary to explore thewider context of how information systems fit into business strategy

activ-2.2 WHAT IS STRATEGY ALL ABOUT?

Firstly then, what is strategy? It is not some twentieth century idea comingout of big business or the business schools - even though big business andthe business schools have taken it to their hearts We come across the con-cept of strategy in the development of military strategies in the time of theancient Greeks over 500 years Be. First of all the word described the role ofthe general of an army - what the general did - then it became a civilianactivity, but still in a national context, where it was concerned with a system

23

Trang 39

Rejected \ ideas

Ideas

Un budgeted projects Unbudgeted projects pending

Dead ducks

Figure 2.1 Planning for projects

Feasibility study

Fully authorised projects

of government, and finally it moved from the military and diplomatic orgovernment worlds into business Secondly, strategy is not an exact science.Indeed, some writers have said that 'there is no single, universally accepteddefinition of strategy' Ifthis is true - and judging by the number of booksand articles about strategy it certainly seems to be true - what can we use-fully say here to give us a foundation for thinking about business strategy?

We can begin with some general definitions of aspects of strategy and tify the components of an effective strategy

iden-James Quinn and also Michael Porter make the following observation aboutstrategy:

Strategy is the pattern or plan that integrates an organisation's major goals, icies and actions into a cohesive whole In other words, it pulls together and givesmeaning to everything an organisation does A well formulated strategy helps toorganise resources into a unique and viable force based on the competences andshortcomings of the organisation, on anticipated changes in the environment andactivities by competitors

pol-In other words, strategy is the result of a careful analysis and it is ful; it is a plan for achieving something The problem with strategy though

purpose-is that it cannot be a plan for everything How could it be possible to knowall of the environmental changes that might take place in the lifetime of thestrategy? How can the strategic planners know what competitors will do?Also, Henry Mintzberg, a leading American thinker and writer about strat-egy, says that strategies can emerge: they are not all formulated by strategic

Trang 40

planners in quiet offices on the top floor but are formed by events that fallinto patterns that are then recognised and developed Consistency of beha-viour then becomes a strategy even though that is not how it started out It

is almost a post-event rationalisation of what looks like intuitive actions This

is why 'strategies' change and why strategic plans and the IS developmentsthat support them get thrown out of the window and why systems projectsare shut down for what seem like arbitrary or irrational reasons 'We're killingthis project, the strategy's changed.'

We might find it difficult to define 'strategy' but we know a good one when

we come across it A good strategy is:

• Clear. The overriding goals for all units of the enterprise are clear enough

to give continuity and cohesion to all of the tactical choices made duringthe lifetime of the strategy Managers can answer the question: 'Does what

I do now move us towards the strategy?', and answer it correctly

• Keeps the initiative.A good strategy preserves freedom of action, supportsempowerment and enhances commitment Itsets the pace and determinesthe course of action Consequently people feel 'in charge' and motivated

to achieve

• Concentrated. A good strategy concentrates resources at the place and thetime where they will generate maximum advantage A good strategydefines what will make the enterprise superior to its opponents and organ-ises the resources to achieve that advantage

• Flexible. This is not about changing the strategy but about being wellbalanced to take advantage of changes that occur Is the opposition kept

on the run by our consistent innovation?

• Well led. Successful strategies require commitment, not just acceptance.Good leadership is needed to turn a strategy into competitive advantage

• Full of surprises.Our strategy is seeking to gain an advantage for us Weare in competition with other organisations, other ideas, other projects

We gain advantage out of proportion to the effort expended by doing theunexpected

Just as we can recognise the criteria for a good strategy, it is possible - ing to Mintzberg - to see strategy as:

accord-• A plan.People talk about having' a strategy' for this sales visit, or for thismeeting or for this game Really it is just a plan or a consciously intendedcourse of action to deal with a situation

• A pattern. This is different from a consciously intended course of action.Strategy as a pattern means that intended or not we consistently behave

in a certain way and that leads us to formalise this pattern of behaviourinto a strategy

• A position.Our strategy describes how we position ourselves in our ket It therefore enables us to exclude areas of possible activity - 'Ourposition is here and we do this kind of thing, so we can't consider doingthat'; 'We intend to be active in the public sector but not in local

Ngày đăng: 10/04/2017, 14:40

TỪ KHÓA LIÊN QUAN

w