Buying Information Systems: Selecting, Implementing and Assessing Off-The-Shelf Systems

Buying Information Systems To my wife Angela, for her patience and support. Buying Information Systems Selecting, I...

Author: David James

6 downloads 339 Views 1MB 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

Buying Information Systems

To my wife Angela, for her patience and support.

Buying Information Systems Selecting, Implementing and Assessing Off-The-Shelf Systems

DAVID JAMES

GOWER

© David James 2004 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 the prior permission of the publisher. Published by Gower Publishing Limited Gower House Croft Road Aldershot Hants GU11 3HR England Gower Publishing Company Suite 420 101 Cherry Street Burlington, VT 05401-4405 USA David James has asserted his right under the Copyright, Designs and Patent Acts 1988 to be identified as the author of this work. British Library Cataloguing in Publication Data James, David Buying information systems: selecting, implementing and assessing off-the-shelf systems 1. Computer systems – Purchasing 2. Computer systems – Evaluation I. Title 004’.0687 ISBN: 0 566 08559 3 Library of Congress Cataloging-in-Publication Data James, David, 1964– Buying information systems: selecting, implementing and assessing off-the-shelf systems /David James. p. cm. ISBN: 0-566-08559-3 1. Information technology. 2. Information storage and retrieval systems -- Purchasing. I. Title T58.5.J355 2004 004--dc22

Typeset by Author and Publisher Services, 11 North End, Calne, Wilts. SN11 9DQ Printed in Great Britain by MPG Books Ltd, Bodmin, Cornwall

2003062639

Contents List of Figures

vii

List of Tables and Checklists

ix

Introduction Case Study: ElectAM

1 8

1

Buying an information system is like buying a desktop publishing package, isn’t it? The range of software products Configuring the software Software procurement Back to our question

9 10 13 14 15

2

Where can I find advice? General procurement guidelines Information system implementation Information system success/failure Evaluating the system A simple process view ElectAM: Part 2 Requirements and scope Vendor selection System implementation Multiple views

17 18 18 19 20 20 20 22 22 23 23

3

Who should be involved? Stakeholders Stakeholder expectations Management of expectations

25 26 29 31

4

How do I manage the purchase? ElectAM: Part 3 Case Study: PowerSound Organising to buy Managing team and contract Summary

35 36 40 47 51 54

5

How do I decide what I need? What are you trying to achieve? The Invitation to Tender

57 58 59

vi

Contents

What not to specify The User Requirements Specification (URS) How do the stakeholders fit into the process? How will you know that you have got what you want?

59 62 66 67

6

Which package/supplier should I choose? ElectAM: Part 4 The traditional approach to vendor selection Problems and considerations A risky business An alternative approach to selecting a vendor

69 69 70 72 73 76

7

How do I manage the implementation? Case Study: CSM What we can learn from this, and other, case studies The management of expectations

81 82 87 91

8

How do I know if the system is successful? What is success? Common measures of success Why established measures don’t work Expectations versus perceptions

95 96 97 100 101

9

Putting it all together Manage the purchase Manage the implementation Celebrate or drown your sorrows

107 109 112 115

Glossary

119

Index

123

List of Figures Figure 1

Worldwide expenditure on information technology

4

Figure 1.1

COTS, configurable and custom software

10

Figure 1.2

Typical equipment configurations

12

Figure 1.3

Typical commercial off-the-shelf software configuration

12

Figure 1.4

Typical configured package software system configuration

13

Figure 2.1

Sources of guidance

17

Figure 2.2

Procurement activities

21

Figure 3.1

Stakeholders

27

Figure 4.1

ElectAM project schedule

35

Figure 4.2

ElectAM organisation

36

Figure 4.3

PowerSound project schedule

42

Figure 4.4

The organisation of PowerSound

43

Figure 4.5

The organisation of people suggested to manage information system procurement

48

Figure 5.1

The procurement process – definition of scope of supply

57

Figure 6.1

The procurement process – vendor selection and negotiation

Figure 6.2

71

Comparison of traditional and alternative vendor selection processes

78

Figure 7.1

The procurement process – system implementation

82

Figure 7.2

Project team interaction with the organisation

86

Figure 8.1

Sources of information on success

96

Figure 8.2

A model for determining information system success

103

Figure 8.3

A view of information system success

104

Figure 9.1

The procurement process

107

Figure 9.2

Making it a success

115

Figure 9.3

A real view of success

116

This page intentionally left blank

List of Tables and Checklists

Table 3.1

Approaches to software project management

32

Table 4.1

User Requirements Specification (URS) contents

38

Table 4.2

System Requirements Specification (SRS) contents

44

Table 5.1

Suggested contents of an invitation to tender

60

Table 5.2

Example contents of process automation system URS

63

Table 5.3

Suggested structure for a URS

64

Table 9.1

Summary of checklists

108

Expectations checklist

34

Purchase checklist

55

Specification checklist

68

Vendor selection checklist

79

Implementation checklist

93

Evaluation checklist

105


Introduction ‘I can only say HELP US, the business is slowly being strangled by this situation.’ This was not the message that the managing director of ElectAM, an electronic assembly manufacturer, expected to be sending to his manufacturing computer system supplier when he first decided to replace ElectAM’s ageing system. Nor had he expected that it would take eight minutes for a user to log on to the new system, or 15 minutes to find an item to select.

CASE STUDY: ELECTAM

Procurement results This company, whose products encompass anything that consists of a populated printed circuit board in a plastic box, such as electronic sounders and TV remote control units, has about 650 employees distributed over four sites at three geographic locations. It also provides research and development services as well as contract manufacturing, using variants of continuous flow production, engineer-to-order and manufacture-to-forecast methods. Each of the company’s major customers require that they conform to the purchaser’s specific practices for production engineering, quotation and contract management, understand their demand and demand horizons, procurement practices, production and quality control, despatch and distribution, invoicing and payment collection, etc. At that time, the company could only see the variety of methods of operation in these areas increasing in the future and were expecting their current annual sales turnover of £25 million to double during the following three years. Since most of their products are the single source of supply of that product for their customer they tend to win 100 per cent of market share with each new product that they produce. Consequently, the majority of their growth was expected to come from new products, from both existing and new customers. At that time they introduced major new products at a rate of about one per month. Within the next three years they expect this rate of new product introduction to have doubled. The company had been using a business computer system that supported 88 sessions; that is, 88 operator terminals connected to the system, across the four sites. Due to the steady expansion of the business there was now a need to support at least 110 sessions. However, the existing business computer system:

2


• Had been customised to the extent that it was no longer supportable. The supplier had updated the base product over the years. However, the installed system had been substantially modified so as to meet the needs of the organisation and to now upgrade the base product would involve considerable effort to reimplement all the bespoke changes; • Was becoming expensive to maintain. This was partly due to the fact that the version of the base product in use was now not routinely supported by the supplier and partly due to the large number of modifications that had been made to the system; • Could not be expanded to accommodate more users due to both hardware and software constraints; • Did not provide some needed applications. The nature of the business processes had changed over the years and important long-term scheduling, fine planning and reporting functions were not available. There was also a need for faster production of schedules (long-term so as to look at the effect of new or potential orders, and short-term so as to react to changes). The existing system could not produce revised schedules in the required time frame; • Was causing a number of independent applications to be developed, by isolated groups or individuals, which were not integrated into the overall system. The lack of functionality in the system was encouraging users to develop their own ad hoc solutions. This was taking up time which should be spent on other activities, did not allow information to be easily passed around the organisation, and resulted in applications that had not been thoroughly tested and were difficult to maintain. So the company decided to replace its business computer systems and therefore set up a project team with representatives from each department, plus a steering committee. Their intent had been to assess ten potential suppliers, further investigate a shortlist of two or three vendors and then place an order within 11 months of their decision to embark on the venture. In practice it took them 23 months to reach the point of placing an order and then their planned five-month implementation period extended the process by a further 12 months. When the system did go live, however, performance was so bad that a more powerful computer had to be hired, eventually being four times more powerful than the one originally specified. Also, some of the functions were still not available and major problems continued to be found with the new release of software that was supplied. At that time the organisation was still trying to implement the requirements as specified and the ‘What if?’ facility, one of the main reasons for selecting this system, still had not been implemented. Some of the problems are summarised within a site report produced by the supplier in which he states: • • • •

RESPONSE TIMES + ISSUES = LOST CONFIDENCE; 5 MINS TO FIND A VENDOR TO SELECT; 15 MINS TO FIND AN ITEM TO SELECT; SIGN-ON TAKES AN UNACCEPTABLE TIME! i.e. 8 MINS.

Introduction

3

Shortly after the system went live, the purchasing organisation’s managing director wrote to the supplier’s MD summarising their current perception of the system and of the supplier. He spoke of: ‘[the] software shipped to us contained catastrophic defects and was not implementable. The current packages, whilst in the main apparently satisfactory, remain disappointing in comparison to the expectations created by your original sales presentations.’ ‘ . . . the system as specified by [the supplier] is incapable of providing the performance we require.’ ‘Throughout the planning and implementation phases there has been a growing sense of unease amongst my project team at the level and, frankly, the competence, of support available and received from [the supplier].’ Later that month the same writer finished a letter to the supplier’s director of product services with a plea for help. The words he used are the opening lines of this book. Three months later the hardware had been upgraded, various ‘fixes’ had been applied to the software, and the company had survived.

We shall return to the case study of ElectAM a number of times within this book to help illustrate various aspects of the information systems procurement process. This first part of the story tells of a small company’s problems that did not even reach the local press. However, sometimes the problems associated with implementing information systems hit the headlines of national newspapers. In 2001, Cambridge University, with the help of KPMG, was said to have wasted £10 million of public money on a bungled attempt to introduce a new computerised accounting system. An official enquiry found that Cambridge lacked a culture of accountability, had no clear management structure and seemed unable to solve its problems. Similarly, in 1996 it was claimed that a group of senior NHS bureaucrats in the Information Management Group had wasted £500 million on virtually worthless computer systems. An example was £106 million spent on the Hospital Information Support Systems initiative that saved only £3 million. Organisations in the private sector seem to fare no better. For example, in 1993 the chief of the London Stock Exchange resigned when the Taurus paperless share trading system was scrapped after spending a reported £75 million and with an estimate that it would take a further three years to complete with additional costs of at least £150 million. The experiences of the London Ambulance Service are left as further reading.1 Looking further afield than the newspaper headlines, surveys by academics provide us with some clue to the scale of the problem associated with the procurement of information systems. Looking only at information technology investment in the UK, a report published in 19962 stated that: ‘80–90 per cent of IT investments do not meet their performance objectives . . . Around 80 per cent of new systems are delivered late and over budget.’

4


More recently, during 2000, a survey3 indicated that more than 90 per cent of respondents reported dissatisfaction with the results of their Enterprise Resource Planning (ERP) computer systems. The authors of the report commented that the worldwide spend on ERP systems is in the region of £6 billion per year and so the mismatch between expectations and reality results in a huge waste of investment. These authors also note that it is rare for software development problems to be publicised, and so details of these losses are hard to find. It is understandable that those who have committed organisations to spend money on computerised systems are going to be less than keen to tell their own management, let alone the world at large, that their investment has not produced the benefits sought. As we shall see in Chapter 8, it is often the case that no attempt is made to evaluate just how well an information system has met its original objectives. This ‘sweep it under the carpet’ approach actually does the business community a disservice by making the problems less visible and preventing us all from learning from the experience of others. By combining these estimates of unsatisfactory information systems with data on worldwide sales4 (Figure 1), the implication is that a significant proportion of the expenditure in information systems throughout the world is not actually resulting in business benefits. The types of information systems referred to above range from ‘world stage’ financial systems to manufacturing systems within small companies. So where are we aiming with the content of this book? Much of the work on which the book is based was carried out in manufacturing organisations that had purchased manufacturing computer systems. However, it is suggested that the lessons learnt from these particular cases provide a framework that can be applied to the procurement of the majority of information systems purchased by organisations.Whether your organisation is concerned with manufacturing, commerce or service provision, or operates on a voluntary or commercial basis, it is likely that you will employ accounting and personnel administration systems. If you deal with many suppliers then supply chain management systems might be required or you may benefit from customer and distributor resource management software. As a manufacturer, publisher or wholesaler it might be that you can serve your

Figure 1

Worldwide expenditure on information technology

Introduction

5

customers better by using a warehouse management system and process, and discrete manufacturers will be replacing manual production methods with automated control systems. In other words, no matter what type of information system or networked computer-based system your organisation needs to purchase, the guidance provided in this book will help you achieve a successful outcome. The one distinguishing feature of the computer systems considered is that they are all based on the application of ‘packaged’ software. In other words, we are excluding situations where an organisation has the need (or should we say courage) to start with a clean sheet of paper and have a software system programmed for its specific requirements. Many of the recommendations might be transferable to such a situation, but our focus is clearly on the application of pre-built, off-the-shelf software that is then configured so as to meet the needs of the particular application. So, by reading the rest of this book, those new to the procurement of information systems can look forward to gaining: • an outline understanding of the processes involved in the procurement of packagebased information systems; • a framework which, when applied, will help to reduce the risk inherent in the information system procurement process; • point-by-point guidance on actions to be taken early in the procurement process to improve the likelihood of a successful outcome. For those who have been ‘bitten’ by attempts to purchase information systems in the past we can offer: • help in learning from past experience of buying information systems; • a source book to help you keep on track with your future information system purchases. We will approach the subject by asking a series of questions related to the procurement of information systems, devoting one chapter to each. We shall be exploring, if not providing complete answers to the following:

Chapter 1: Buying an information system is like buying a desktop publishing package, isn’t it? There is evidence that having experience of purchasing systems rather than just products reduces the risk associated with the process. In this chapter we look at the difference between buying off-the-shelf products and purchasing configurable software systems.

6


Chapter 2: Where can I find advice? By looking at the procurement process, we can identify the management and organisational skills that are needed during an information system (IS) procurement episode. This allows us to point to some of the existing guidance on information technology (IT) procurement and project management that is applicable and useful for IS procurement and which is not the main thrust of this book.

Chapter 3: Who should be involved? In examining this question we provide an introduction to the ‘stakeholders’ of the system and how we can go about establishing the expectations each have of the intended system.We start to look at how those expectations can be managed so that everyone feels they are a winner. This includes gaining approval for the purchase.

Chapter 4: How do I manage the purchase? At this point we make a start on IS procurement by introducing the processes involved in defining requirements and selecting a supplier or suppliers. We place emphasis on the dangers of going into too much detail and of trying to use people on a part-time basis, with case study evidence of what can happen.

Chapter 5: How do I decide what I need? Here we think about why you want to buy an information system in the first place and identify the business requirements. We then describe how to work down to the outline functional requirements. The importance of defining performance requirements for the system is stressed and we consider how the installed system will be tested to ensure that the business and performance requirements have been met.

Chapter 6: Which package/supplier should I choose? There is a fairly standard approach that most people take when they start on the vendor selection process, but it rarely seems to work. We introduce some considerations associated with vendor selection and describe a practical approach to narrowing the field.

Chapter 7: How do I manage the implementation? In this chapter we do not try to provide guidance on basic project management practices, but instead highlight the importance of defining responsibilities for project management activities. We emphasise the importance of communication; with everyone and

Introduction

7

anyone associated with the new information system. We also outline the importance of training, along with a suggestion for a practical approach.

Chapter 8: How do I know if the system is successful? Much has been written on the evaluation of information systems. In this penultimate chapter we provide an outline of the IS evaluation methods available and why they don’t work or are difficult to use. We then go back to the beginning of the process, where the expectations of the stakeholders are established, and describe the management of expectations process as a means of ensuring success. It is my intent to provide practical guidance to those involved in the procurement of information systems, along with tools that can assist with the process. Along the way, therefore, I provide a set of checklists that can be adapted to your own particular needs to help cover all the bases. Having discussed all those bases we take a step back in Chapter 9 and take a wider view of the process, reflecting on what we are striving to achieve. This final chapter also provides an opportunity to re-emphasise the essential aspects of each of the phases of the procurement process. So, no matter what experience you have of purchasing information systems, make yourself comfortable, with your equivalent of a gin and tonic by your side, and learn from other organisations that have already successfully (or otherwise) purchased information systems. Our aim is to avoid the euphoria of the sale/purchase transgressing into the despondency of an over-budget, over-time and underperforming project.

Notes 1 Beynon-Davis, P. (1995) ‘Information Systems “Failure” and Risk Assessment:The Case of the London Ambulance Service Computer Aided Despatch System’, in Proceedings of the 3rd European Conference on Information Systems, Athens/Greece, June. 2 Clegg, C. et al. (1996) ‘The performance of information technology and the role of human and organizational factors’. Available from the Institute of Work Psychology, University of Sheffield, www.shef.ac.uk/~iwp/resprogs/itperf.html, 27 February 1996. 3 Farish, M. (2000) ‘A difficult enterprise’, Engineering, November, pp. 22–23. 4 EITO (2002) ‘European Information Technology Observatory Report 2002’, EITO.


CHAPTER

1 Buying an

information system is like buying a desktop publishing package, isn’t it?

It is always said that if you can’t programme your video recorder then you should get your nine-year-old to do it for you. These days the same can probably be said for formatting a letter to the bank, putting animation into a presentation, or including a photo in an e-mail to your cousin in Australia. Most people who have a desk-based job cannot avoid being in contact with the ubiquitous personal computer (PC) and many of the office-related software packages that have transformed the way that we do business. There is no longer the chore of writing a letter longhand, getting a secretary to type it in draft form, making corrections and then getting it retyped on headed stationery; nowadays we write it on our PCs using a template complete with letterhead, make alterations as we go and get it spell-checked by the word processing software. Then we send it to the laser printer over the network and add our signature with a flourish, after we have coaxed the ink to flow from our fountain pen.Then, when at home and after the children have finished their homework for which they need the PC, we check our e-mail and look up the best holiday deals on airline and travel agents’ web sites. So it is that in our working and home lives we are coming into contact more and more with computers and the software that gives them their usefulness. In both these work and home environments we are also under market pressure. The new features in the latest release of our desktop publishing package will make our publicity material stand out from that of the competition.We could save valuable time on those (infrequent) business journeys by using route-planning software, not to mention using it when planning a holiday. At home, in addition to marketing pressure we get pressure from our children, who in turn get it from their friends. If we had a scanner attached to our home PC then their homework assignments could be made so much more interesting by including photos and diagrams from books and magazines. This increased use of PCs and common software packages gives us a familiarity with both hardware and software technology that is available in the office and home. As a consequence, many people become computer ‘experts’ in the eyes of their friends and

10


peers but, no matter what our level of knowledge, we all form expectations of what we think the technology can do and what it should cost.

The range of software products This experience of computing products, both hardware and software, will surely be of use to those of us who are involved in the procurement of information systems. However, we need to recognise that our experience may only be at one end of a very broad range of computing systems. It is convenient for this discussion to categorise software into three distinct but overlapping groups: Commercial Off-The-Shelf (COTS) software, configurable packaged software and bespoke or custom software. Figure 1.1 illustrates the correspondence of these three classes of software and, following a brief review of each class, we will consider their differences from the point of view of information systems procurement. My comments above, about the experience that most people gain from home and office encounters with personal computers, is really centred on COTS software. The CD-ROM containing the software (and user manuals) takes up only a small fraction of the box in which it is supplied, and that box is shrink-wrapped so that you can’t see inside until you have bought it. Office and home applications (in which I include games) are available at a number of high-street stores or can be mail-ordered from catalogues or over the Internet. COTS software packages include the common ‘office suite’

Figure 1.1

COTS, configurable and custom software

Buying an IS is like buying a DTP package , isn’t it?

11

components such as word processors and spreadsheets but also include software to help with the planning of projects and Computer-Aided Design (CAD) drafting software. A common attribute of these software packages is that they are generally single-user software; that is, they are installed on a single PC and the only interaction between various people is through the sharing of access to files.The database tools that come with some office suites do allow multiple user access to a database resident on a file server computer but, unlike word processor or presentation software, an application needs to be written so as to provide user functionality. Configurable packaged software is rarely found in the home, being aimed at solving business problems in, for example, manufacturing, distribution and service organisations. These software systems often interact with the real world via such devices as badge or barcode readers, analogue to digital converters for reading such quantities as temperatures and weights from instruments, or time clocks. These systems generally allow a number of people to work with them at the same time, often performing different functions at a number of workstations. Examples of configurable packages are Enterprise Resource Planning (ERP) systems, used for the planning and monitoring of manufacturing processes, and process control systems, used to operate equipment for the manufacture of such diverse products as gasoline, paint, pharmaceuticals and soup. I have referred to our third and final classification of software as bespoke or custom software. In essence, this is software that is written specifically for a particular application or organisation. Although various COTS and configurable packages may be incorporated into the design, the supplier designs the application specifically for the client, and a significant amount of the software is programmed for this application.Types of bespoke applications software might include command and control systems such as ambulance dispatch systems or air traffic control systems. The software systems described by Flowers,1 when looking at the problems sometimes encountered with large software systems, fall into the category of bespoke or custom software. The above has concentrated on the software running on a system. It is probably true to say that the hardware used for most systems, no matter to which category they may be assigned, is generally a collection of COTS equipment. Therefore we will find a proliferation of PCs or UNIX workstations, together with ethernet network interface cards, hubs and routers. COTS software is likely to be running on a simple collection of COTS hardware. The suppliers of some configurable systems, however, also provide their own equipment on which some of the packaged software runs. An example of supplier-specific hardware is the Programmable Logic Controller (PLC), used for the control of manufacturing equipment. Although the various modules that make up a PLC are standard, off-the-shelf items and are not customised for each individual user, the different brands are only available from their respective supplier. At the level below the PLC, the input/output modules, where the volume of modules sold is much higher, more standardisation and interoperability exists so that modules from different suppliers can directly compete. Our common business and home experience of computing is the standalone or networked PC running various office software packages. Figure 1.2 shows just such an arrangement next to a hardware system that might be thought of as a typical platform for configurable packaged software, in this case a manufacturing control system using a number of distributed PLC devices.

12


Figure 1.2

Typical equipment configurations

Differences in the complexity of hardware are also reflected in the complexity of the software system that runs on each category of equipment. Figure 1.3 illustrates the software environment for a word processing package, where its sole interface is with the base operating system, providing interaction with the user through the graphical interface and with the file storage system. By contrast, Figure 1.4 provides a simplified version of the software structure found in just one of the programmable logic controllers and one of the operator workstations of the manufacturing system. In addition to the base operating system, which is different in the two pieces of equipment, we now have database software, again different in the two cases, communications software and a suite of software that enables the user to configure the combined package to perform the required task. In the case of the manufacturing system this task is likely to be: • the control of machinery such as tablet making and packaging machines; • the control and monitoring of machinery by the operator through a set of graphical displays; • the collection and reporting of data associated with the manufacturing production process.

Figure 1.3

Typical commercial off-the-shelf software configuration


Figure 1.4

13

Typical configured package software system configuration

Configuring the software This concept of configuring the software package needs a little more explanation. After all, we are all familiar with selecting Tools|Options or Tools|Customize from the menu of our office software package. It is true that some degree of ‘configuration’ is available with COTS software packages. However, this is generally to do with the appearance of the user interface and the provision of quick access to some of the standard features such as formatting buttons or drawing toolbars. There is little, if any, chance to alter the actions the software performs under a given stimulus. The functionality that comes with the package is what you get and what you have to live with. What about spreadsheets? I hear you say, and it is true that you can configure calculations and build up quite complex applications using the features provided. Database packages provide a similar level of configuration, allowing table structures to be defined, along with queries on the stored data within those tables. As we said earlier, however, these packages allow cooperative working only by the sharing of data files or records. Let us now consider a configurable packaged software system. We have already seen that both the hardware and base software structure of configurable systems is likely to be more complex than that of the desktop PC with which we are all familiar, but a configurable system in the sense that we mean here is essentially a toolkit that allows us, or someone on our behalf, to build an application that suits our business processes. This application might be controlling the production line for making chocolate-coated sweets; opening and closing milk valves, weighing quantities of sugar, starting stirrers and controlling the speed of conveyors; providing dynamic colour graphic displays to operations staff and reporting on production totals. Or it might be managing the production of telephone handsets; accepting requirements from the production

14


scheduler; producing parts lists for assembly kits from the bill of materials; tracking work processes, materials used and finished goods; or providing daily, weekly and monthly production figures against target. In other words, having put together the system hardware and installed the base software the system will not do anything except allow you to configure the application. It is only then, after expending considerable amounts of effort, that the system can finally be put to use. That effort is used to define the detailed functionality required, configure the software to provide that functionality, test the system to show that it now does what is required and train those who are to maintain and use the system.

Software procurement I hope that you are starting to understand that the purchase of a configurable packaged software system is outside the experience of most people working in industry or commerce. Large multinational organisations may have a dedicated group of people who spend all their time purchasing such systems for their sites around the world. They are also likely to have purchasing staff with experience of purchasing systems as opposed to materials and services. We cannot, however, expect the majority of small and mediumsized organisations to have this level of experience in-house. Also, we cannot expect purchasing officers who normally deal with the terms and conditions of purchase for materials and facility-related services to be able to immediately adapt to the requirements of buying an information system. They may have experience of purchasing high-value capital equipment, but usually the functionality of that equipment is well defined and demonstrable. When purchasing a configurable system, however, we are accepting a promise from the supplier that the required functionality will be provided at some time in the future, within budget and to schedule. This brings us back to Figure 1.1 (see page 10). The overlapping areas of commercial off-the-shelf software, configurable software and bespoke/custom software are located on y-axes of ‘complexity’ and ‘effort to procure’ and an x-axis of ‘risk’. Our discussion above emphasised the fact that, as we move away from our ‘desktop’ notion of software, so the complexity of the hardware and base software increases. The process of configuring the toolkit of functions to form the required business application also consumes considerable effort. Choosing to have software written specifically for an application simply increases the level of complexity and the amount of effort expended. In the introduction I mentioned the millions of pounds spent in vain on attempts to produce a hospital information support system and a paperless share trading system. Figure 1.1 illustrates that as we move from COTS to configurable to bespoke/custom software, not only does the complexity and cost increase but the risk of not achieving our aims also increases. And, as all managers will tell us, we need to analyse risk and either eliminate it or manage it.


15

Back to our question So how should we answer the question that forms the title of this chapter? I have positioned the focus of this book on configurable packaged software systems that, in terms of complexity, effort and risk, lie somewhere between COTS software of the type that we might use on our desktop PC and bespoke/custom software designed for unique situations. I have also identified that the fixed, ‘take it or leave it’ functionality of PC packages is extended to provide a toolkit that needs to be applied to your particular business requirement.That requirement is likely to impact on a number of people within the organisation, each performing different functions, and the system is almost certainly being bought to perform a major business function. It is also likely that, as an organisation, you have little experience of purchasing a system, that is, a collection of hardware and software modules that are configured to work in an integrated manner. As we saw from the case study at the start of the introduction, information systems such as manufacturing execution systems can be such a fundamental part of a present-day business that if the new system fails to provide the facilities and performance required of it then the organisation can be in serious trouble. So our answer must be that, no, buying an information system is not like buying a desktop publishing package. Consequently, if you make the assumption that it is, then you stand a high chance of failure, or at least of not achieving the benefits sought. There is evidence that asking the company buyer to manage the procurement of an information system or asking the production manager to project-manage the implementation is a cheap but high-risk approach.The lesson we should learn from those who have tried that approach is that we can reduce the risk by employing people with experience of procuring systems of the type we are considering. We shall discuss how best to go about this in later chapters but it is important for small and medium-sized organisations to seek advice from those who have been there before, which is the topic of Chapter 2.

Note 1 Flowers, S. (1996) Software Failure: Management Failure. Amazing Stories and Cautionary Tales, Chichester: John Wiley.


CHAPTER

2 Where can I find advice?

Your office ‘expert’ on PC packages, the buyer who deals with your material supplies, the production manager who bought a flow soldering machine; they can all offer advice and are probably quite free with it. However, we have seen that buying an information system based on configurable software is unlikely to have featured in any of their recent experiences. Nevertheless, their advice should not be ignored since, if there was a single right way to go about purchasing such systems then there would be one piece of guidance on the subject and this book would be unnecessary. As with most topics that are of reasonable complexity, it is always wise to seek advice from as many different sources as possible. By building up views of the problem, from a number of alternative directions, we can hope to develop a better, more complete understanding of the problem and be in a better position to deal with the unexpected situations that will inevitably arise. So where can we find a variety of views of the procurement process for information systems? Figure 2.1 shows that available guidance in written form is divided into general guidance on procurement and that associated specifically with information systems. The former is not aimed at the procurement of any particular item, although may be particular to the purchase of services, whereas the latter category includes literature that is written for those interested in a wider view of information systems than the procurement of configurable systems.

Figure 2.1

Sources of guidance

18


General procurement guidelines If we look on the general procurement side in the industrial marketing literature then, as we might expect, we find supplier-focused guidance, mainly associated with the supply of goods or services, but generally ending at the point where an order is placed. Similarly, the purchasing literature looks mainly at the buying of materials and simple services, sometimes venturing into the purchase of capital equipment but usually only going as far as placing an order. Descriptions of building relationships between purchaser and supplier are normally in terms of supply chain management, minimising stock and inspection processes for the purchaser and easing production scheduling for the supplier. Neither set of literature says much about the one-off purchase of an information system where the order is placed on the promise of functionality and performance to be delivered at some time in the future and of a lasting, supportive relationship. The industrial marketing literature does, however, provide a view of the stages through which the purchasing process goes, up to the point of order placement and we shall return to this in a moment. Since the supply of an information system includes both goods (including equipment and software licences) and services of various types, then we can find some guidance in the service quality literature. The purchase of an information system may be made on behalf of an organisation but it is individuals who make the buying decisions, place the order and use the resulting system. From the service quality literature we can obtain a view on the way in which individuals judge the services that they receive, whether it is across a counter in a shop, at a table in a restaurant, in a classroom on a training course, or being questioned on business processes and information flows. That view of service quality can then inform us about ways of evaluating both the service provided by a supplier and the service that we provide to our ‘customers’ in the form of our project team and users of the system. We will study this area in more detail in Chapter 8 when we look at how to assess the success of the information system that we have procured.

Information system implementation Just as the purchasing and marketing literature generally only take us up to the point of an order being placed, so the software system implementation literature takes the order as its starting point and then concentrates on the software development process. Perhaps this is too much of a generalisation, since some guidance is available that does try to straddle the purchase/implementation boundary. A good example is a book by Smith,1 concerning what he refers to as ‘troubled IT projects’. Although the emphasis is on the procurement of bespoke software systems and the book is written from the supplier’s viewpoint, Smith stresses the importance of the proposal from the supplier in setting the foundation for the success or failure of the resulting development. His use of the design and building of the SS Great Eastern steam ship (designed by Isambard Kingdom Brunel and launched in 1858) as a case study of a troubled project is both novel and entertaining. However, his 40 root causes of troubled IT projects arise from experience within a system development environment. Nevertheless, some of these causes,

Where can I find advice?

19

particularly those about the definition of project objectives and the involvement of users, are relevant to our enquiry and we will come back to them later. As well as reporting the results of a survey on how successful, or otherwise, IT development projects had been, the Chaos Report2 from the Standish Group describes a survey of users on their top success criteria. The top three items were to ensure user involvement all the way through the process, to obtain and maintain executive management support, and to produce a clear statement of requirements. These are very similar to the buyer-related ‘root causes’ in Smith’s book. Then, within his ‘ten deadly sins’ associated with computer disaster, Collins3 adds ‘overambition’ and ‘deciding to tailor the software’ to the themes of ‘poor definition’ and ‘lack of user involvement’. Again looking at advice aimed at a wider, more general audience, Peterson and Carco4 provide a sometimes entertaining collection of guidance on a wide range of topics from the dangers of the technophile to negotiating techniques. In spite of the book’s comprehensive scope, however, it fails to talk about the link of an information system purchase to business strategy, and the authors propose a very adversarial approach to the relationship with the supplier. If we remember that our new information system is going to be in use for a number of years, then a good relationship with the supplier is essential to ensure cost-effective and timely support. It is during the implementation phase of the procurement process that the purchaser/supplier relationship is formed and it is always hard to turn a sour relationship into a sweet one.

Information system success/failure A number of authors have examined the available records of the headline-grabbing failures of large information system developments, such as those briefly mentioned in the introduction to this book. Sauer5 defines a failed system as one where development has stopped but the system is not used since it does not serve the interests of its original supporters. Flowers,6 on the other hand, simply looks at those cases where large projects have run excessively late and consumed considerably more money than was in the original budget. In both cases, however, they use information that is already in the public domain to piece together the story behind the disaster and try to suggest the causes that led to the project’s demise. It seems to be an unfortunate fact that the public never hears about the majority of failed, troubled or unsuccessful information systems projects. If an organisation has spent a lot of money on a system that is abandoned, then those responsible for sanctioning the project are not going to be keen to advertise the fact that they got it wrong. Similarly, if a new information system does not produce all the benefits upon which the system was justified, then those who initiated the project are likely to emphasise those benefits that were realised, not those that were not. Therefore those authors who write about information system failure are only able to study projects at the tip of the iceberg; that is, those that cannot escape the glare of the media. Both Sauer and Flowers’ books make interesting reading, but most of the recommendations that they extract from the case studies are little more than common sense. However, what seems obvious with the benefit of hindsight is rarely so at the time action needs to be taken. One interesting suggestion by Flowers is that the reason for

20


some information system failures is that the new system was seen by the organisation as providing a technical fix to what is essentially a management problem. In other words, it can be dangerous and expensive to look for technology to solve problems that really require management action.

Evaluating the system Returning to Figure 2.1, we see that the two remaining areas that offer guidance on the procurement of information systems are those of information systems evaluation and user information satisfaction. Farbey et al.7 provide a good overview of the methods used for information system evaluation but point out that these methods are used mainly to help justify the expenditure prior to proceeding with the purchase. The most popular approach is to attempt to calculate the Return On Investment (ROI) that will be achieved. It seems that straightforward financial methods are readily accepted by senior management within an organisation. However, the literature points out that more subjective approaches, based on such things as the organisational change that a new information system might encourage, are just as important. At the other end of the procurement process we find that users’ degree of satisfaction with the information the system is providing can give a guide as to how successful the system is. However, providing the right information for a user to perform the wrong function may not be of much help. But the implication is that defining – at the start of information system procurement – what users need is likely to improve their satisfaction with the system.

A simple process view Moving away from the generalised guidance we find that by combining models of industrial buying behaviour8 with recommendations from the computer system development literature,9 we can arrive at a simplified view of the activities which make up the information system procurement process. This view is shown in Figure 2.2 where we see that our view of procurement encompasses purchasing activities as well as implementation activities and, in addition, extends to the initial putting to use of the system. The first stage, before we even get into the realms of a purchase, is the ‘recognition of a need’. We return now to our case study of ElectAM, who recognised that their existing manufacturing computer system was holding back their business. They soon moved into the second stage, that of determining the characteristics of the needed item.

ELECTAM: PART 2

The specification To grow the business to match market opportunities the manufacturing computer system needed to provide access for more users. It also needed to support the


21

physical distribution of the organisation and provide tools to more quickly plan day-to-day production scheduling. This overview of the business requirements led ElectAM to the next stage of procurement, and they produced a written specification of their requirements that was used in the vendor selection process, having searched for and found qualified potential suppliers. After evaluating their proposals, they then reached the end of the purchase phase by placing an order. The supplier filled in the detail of the specification by using a prototype method on a system set up in the company’s boardroom. The equipment was ordered at the same time. That equipment was installed and configured and the prototype application was configured on the real system, and tested. In this case, it was at this point that things really started to go wrong; but more of that later. In parallel with the latter stages, users were trained on the new system, completing the supply contract. Then the system was put into use and the procurement of the new manufacturing computer system was complete. Over the years that followed, the computer system evolved as markets changed, when production was moved to cheaper areas of Eastern Europe and as business processes were modified.

The simplified view (shown in Figure 2.2) of the stages through which an organisation passes when procuring an information system is useful since it allows us to ask questions about the main groups of activities and how we might tackle each of these areas. These questions form the basis of the rest of the chapters in this book. But first we can consider

Figure 2.2

Procurement activities

22


each of the main procurement phases of requirements and scope definition, of vendor selection and system implementation in terms of the other available guidance.

Requirements and scope Specification of the needed item is all about defining the requirements and the scope of the project and is a prominent topic in a number of the books mentioned in this chapter. This topic is the main focus of Chapter 5, where we learn some lessons from organisations that have already been through the experience of defining their requirements, with varying degrees of success. Another source, again based on the experience of people active in the IT world, is Guideline 1 (Planning Delivery of the Business Benefits) and Guideline 2 (Identifying the Business Requirements) from the BuyIT10 Best Practice Guidelines. These guides, produced under the auspices of the UK Department of Trade and Industry, are worth reading since they identify many of the key topics that need to be considered. Each guideline summarises the key issues and required actions on a single page and then provides a succinct set of best practice guidance and tips, finishing with a set of early warning signs that the phase of the process is going wrong. The inexperienced purchaser, however, needs to read around each of the topics covered and may not be easily able to identify the early warning signs or know what to do about them.

Vendor selection Referring back to Figure 2.2, ‘search for and qualification of potential suppliers’, ‘acquisition and analysis of proposals’ from those suppliers and ‘evaluation of proposals and selection of supplier’ make up the vendor selection process. ElectAM evaluated 20 potential suppliers, sent their requirements specification to ten of them and ended up with a shortlist of three between whom they could not differentiate. They finally made their decision 23 months after starting the vendor selection process, when they had scheduled for only nine months. Chapter 6 concentrates on these processes and what can be done to manage and contain them so as not to get behind schedule. Most of the available literature associated with vendor selection tackles only one of the aspects of the vendor selection process. For example: • the distinction between the intangible attributes of a supplier, such as competency, and the technical attributes of the product; • the composition and attributes of the group of people who make the buying decision; • the behaviour of that group of people and how they respond to the influences to which they are subjected. One of the few documents that considers the scope of vendor selection, specifically for information systems, is again the BuyIT Guidelines. Guidelines 4 to 6 cover the establishment of the best team for the process, consider your relationship with the


23

supplier, along with how it might need managing, and the supplier selection process itself. Provided the proposed capital expenditure has been approved, the result of the vendor selection process is the placement of an order and the signing of a contract. BuyIT Guideline 7 discusses the writing and negotiating of a contract suited to the purchase of an information system. However, the guide does not talk about the different types of contract, the model forms available or the fact that a supplier may only be able to provide part of the overall system or services. While not attempting to be a primer on purchase contacts and contract negotiation, Chapter 6 provides an introduction to the areas that need to be considered and the further advice that should be sought.

System implementation As a purchaser of an information system, your inclination will be to leave the implementation of the system to the supplier. However, evidence suggests this is a highrisk strategy. ElectAM discovered that the supplier followed a ‘template’ process for implementing the system but did not have the experience or skills to manage the specification, configuration and testing of the system within their operational environment. One mechanical structures manufacturer, on the other hand, identified this lack of capability in their chosen supplier and took on the management responsibility themselves. The activities from ‘detailed specification’ to ‘user training’ in Figure 2.2 cover the implementation phase of information system procurement and in Chapter 7 we look at your involvement in this process. Much has been written on project management in general and on software and information system development in particular. A good example of this is provided by Holmes,11 however, this is generally aimed at the development of bespoke or custom software, an area that we have excluded from our scope. Books such as that by Smith (mentioned earlier) provide guidance, mainly to the supplier, on aspects of the management of the development process, but few consider the subject from the purchaser’s point of view. Some authors, publishing in academic journals, consider certain aspects of the implementation process, particularly with regard to the organisation’s business objectives, but the BuyIT Guidelines once again provide guidance to the purchaser on both the management of simpler projects and the management of complex information system projects.

Multiple views You can never have too much advice when buying an information system; you just have to be discriminating and listen more intently to those that have been there before. Also, every information system purchase is different. Even the same software package on the same hardware platform will be configured differently because the organisation to which it is being applied is different. As a result, the areas associated with the purchase that were particularly important to one person in another company may not be that relevant

24


to you and your organisation. Nevertheless, most guidance will be of some use and, as I said earlier, being able to obtain views of the problem from different directions helps you to see the whole problem and makes you more aware of the areas that need your attention. Much of the published literature on the subject of information system procurement concentrates on the purchase of large, bespoke software systems or the horror stories that hit the headlines. Practical advice for small to medium-sized organisations wishing to purchase a packaged solution is harder to come by. The books and guides referenced here are a good start, and I hope that more will be written as people put their experience into words. So it is always worthwhile doing a quick search on the Internet for any new publications that might be relevant. Also, as I mentioned at the start of this chapter, your colleagues are a potential source of information and there are a number of people within your organisation who should be involved in some aspect of the procurement exercise, which is where we head in the next chapter.

Notes 1 Smith, J. M. (2001) ‘Troubled IT projects, prevention and turnaround’, IEE Professional Applications of Computing Series, no. 3, Stevenage: IEE. 2 Standish Group (1995) ‘The CHAOS Report’, www.standishgroup.com/chaos.html 3 Collins,T. (1997) Crash.Ten Easy Ways to Avoid a Computer Disaster, London: Simon & Schuster. 4 Peterson, B. L. and Carco, D. M. (1998) The Smart Way to Buy Information Technology: How to Maximize Value and Avoid Costly Pitfalls, New York, NY: AMACOM. 5 Sauer, C. (1993) Why Information Systems Fail: A Case Study Approach, Henley-on-Thames: Alfred Waller. 6 Flowers, S. (1996) Software Failure: Management Failure. Amazing Stories and Cautionary Tales, Chichester: John Wiley. 7 Farbey, B., Land, F. and Targett, D. (1999) ‘Evaluating investments in IT: Findings and a framework’, in L. P. Willcocks and S. Lester, editors, Beyond the IT Productivity Paradox, Chichester: John Wiley. 8 Robinson, P. J., Faris, C. W. and Wind, Y. (1967) Industrial Buying and Creative Marketing, Boston, MA: Allyn and Bacon. 9 CCTA (1994) SSADM and Information Systems Procurement, Norwich: HMSO. 10 DTI (1996) BuyIT Best Practice Guidelines, London: IT World Consultants. 11 Holmes, A. (2001) Failsafe IS Project Delivery, Aldershot: Gower.

CHAPTER

3 Who should be involved?

When you go out to buy a CD or a book, who will you involve in the purchase decision? It’s likely that you will involve no one but yourself. But how about when you buy a house? Unless you are a single person you will almost certainly involve your spouse and perhaps other members of your family. Certainly those who are going to live in the new house will feel that they ought to have a say in the matter. Even if you are single you are quite likely to ask the advice of others who have past experience of house purchasing, and take them along to view prospective properties; and your mortgage provider will certainly want to have assurance that their money is being wisely invested. But what about when you buy an information system for use by many people in your organisation? In this chapter we will start to get into the details of the procurement process and begin by considering who should be involved in the purchase and implementation, or rather, how you go about deciding who to include. This chapter is also the first to have a checklist at the end, something that you can take and adapt to your own needs and that provides the prompts you’ll want when this book is back on the shelf. It may sound mercenary but when considering who to involve in the procurement of an information system you need to think of those who can help you achieve your objectives and then to ensure that they have a vested interest in the project proceeding and being successful. Generally these people fall into two categories; those who provide support for the project in terms of budget, expertise, resource and influence within the organisation, and those who will help execute the procurement process itself. We will come back to who these people might be, but you can help make them feel part of the procurement exercise by inviting them to join one of two groups, a steering group and a core team. This approach has been used successfully by a number of organisations and can help ensure that: 1. Those from whom you need continued support are kept informed and given the opportunity to have input into the decision-making process, and; 2. You obtain commitment from those with experience of the various business areas and from those who will later help bring on board the rest of the organisation. If you are to gain the most benefit from the involvement of your information system stakeholders then it is wise to identify who they are right at the beginning of the procurement process and let them and others know that they are included. We will talk about communication in the next chapter and continually return to the subject. However, one of the key decisions to communicate to the organisation is the names of

26


those involved in the steering group and core team. This immediately provides a focal point for comments and ideas from around the organisation, broadcasts the responsibilities of the steering group, motivates the core team members and starts to raise awareness of the project within the organisation. I spoke in Chapter 1 about the complexity of information systems, and the evidence suggests that the process of procuring a system is far from simple. Part of the reason for the complexity of information systems is the interactions between all the parts of the system, and we find some similarity with organisations. Touch one part of a company and the effect is likely to be felt in all other parts. Combine the complexity of a new information system procurement with that of an organisation and we have just multiplied the interactions that can take place many-fold. Consequently, the management of both the purchase (discussed in Chapter 4) and implementation (Chapter 7), and the perceived success of the resulting system (Chapter 8) are tightly linked. The roles of the steering group and the core team are covered in a number of the following chapters and, to some extent, the choice of individuals depends upon those roles. However, we will start by considering the possible range of stakeholders before thinking about how they can best contribute to the procurement process.

Stakeholders I spoke above about those who have some stake in the new information system falling into two categories; those who provide support for the project in terms of budget, expertise, resource and influence within the organisation, and those who will help to execute the procurement process itself. I also suggested that these people should be invited to join one of two groups, the steering group or the core team. However, it may be more practical to have a representative of a stakeholder group directly involved with the project, feeding back project status information to that group and bringing their comments, concerns or even directions to the project.

THE TOP LEVEL STAKEHOLDERS One major stakeholder group is the organisation’s board of directors or their equivalent. It is important that one member of the board is identified as the ‘sponsor’ of the project, is able to devote time directly to the project and act as the link to the board in terms of business strategy input to the project and progress reporting back to the board. The board member who takes on the role of project sponsor depends upon the nature of the information system and on the capabilities, experience and interests of the individuals. For example, even if there is an IT director on the board, it might be more appropriate for the operations or manufacturing director to be the sponsor of a new manufacturing computer system. One organisation which manufactures audio equipment and that was replacing their manufacturing system made the finance director the project sponsor because he had once worked for a computer system supplier company! Needless to say, the finance department was well served by the new system, but manufacturing and

Who should be involved?

27

distribution were not overly pleased with the result. In their case, having the manufacturing director as the system sponsor but with the finance director also part of the steering group may have produced a more satisfactory outcome. The main objective of the system was to improve the flexibility of manufacturing, but the IT resource was controlled by the finance director.

USERS AND MAINTAINERS The board of directors is one of the stakeholder groups represented in Figure 3.1 but perhaps the largest group in that diagram is the users. Whereas the board of directors will have been the instigators of change, either from manual methods to a computerised approach or from an existing information system to a new one, most users will have change thrust upon them. Unfortunately, many people do not like change.There are also others who will have criticised the old system for not providing what they needed to do their job and if those features are not present and easy to use in the new system then they will voice their concerns loudly. Each department in an organisation needs to be considered on its own merits but organisations that have included a representative on the core team from each department affected by the information system have observed the benefits. Indeed, if a department includes more than one operational function, such as materials management and production scheduling, then having more than one representative on the core team may be an advantage. These user representatives can act as an interface to all the members of their respective departments, acting as a conduit for information flow in both directions and adding their own expertise and experience

Figure 3.1

Stakeholders

28


to the procurement process. It has also been found that the core team plays an important role in the purchase phase as well as in the implementation phase, subjects we shall cover in later chapters. Once the system is installed and in use then its continued availability to provide the necessary functions is likely to depend upon the group of people charged with its maintenance. The needs of these maintainers are almost certain to be different to the needs of users, and so these people too become stakeholders of the new information system. Certainly their requirements from the supplier of the system will be different to those of other stakeholder groups; being involved with the system itself rather than how it is put to use. One of the organisations studied discovered that, after their new system had been installed and was being used, the effort required to incorporate software updates from the supplier fully occupied one of the two IT support staff; effort that had not been budgeted and had not been required for their old system.They found that ‘hotfix’ packages came out monthly but over a three-month period an additional 300 fixes needed to be retrieved individually from the supplier’s web site and installed. Although many of the fixes were not relevant to their implementation, the supplier would not provide support unless all fixes were installed. The maintainers of the system will develop an ongoing relationship at least with the hardware and package software suppliers. It is likely, however, that there will also be a systems integrator or consultant company involved in the procurement of the information system. This supplier certainly has a stake in the new system and it is important to consider how best to include their representative in the core team. In Chapter 7 (on the management of the implementation) we will also consider this supplier’s role in the management of the project, looking at the experience and recommendations of a number of organisations.

THE PIVOTAL STAKEHOLDER As in Figure 3.1 the project manager is the person given the responsibility to: • • • • •

steer the organisation and the core team through both the purchase and implementation phases of the project; interface with the supplier (and the supplier’s project manager); deliver a system that meets the stated requirements; establish the support structure for both system and users; and keep everyone happy.

Your project manager also acts as the link between the steering group and the core team, being a member of the former and the leader of the latter. All stakeholder groups are important, but the project manager is pivotal in the whole procurement exercise and should be chosen carefully.The IT manager of one organisation said that a senior person is needed for this important role and that it is ‘not a job for the quiet’. The above is just an outline of some possible stakeholder groups. Each organisation is different and so the particular groups are likely to vary from one information system procurement to the next. Identifying the stakeholder groups and finding the appropriate


29

representatives for the core team need to be tackled right at the start of the procurement. This activity may be easier to perform once you have read about the roles and responsibilities of the steering group and core team in the discussion on the purchase and implementation phases of the project. Part of that process, however, is to think about and to research the stakeholder groups’ expectations of the new information system.

Stakeholder expectations Members of the stakeholder groups provide the resource for both the purchase phase of the project and the implementation phase, providing staff who are going to help make the decisions and those who are actually going to do the work involved in system and vendor selection, configuration and training. The members of these stakeholder groups are also going to be the people who decide how successful the results of the project have been. We will explore this in more depth in Chapter 8 but, for now, establishing the expectations of the various stakeholder groups, and perhaps individuals within groups, will allow you to make a sound start to the system and vendor selection process. If you follow the traditional approach of listing the objectives of the system then, at best, you are likely to concentrate on the requirements of the business and, at worst, concentrate on the available technology. In either case you will miss the requirements of individuals in terms of doing their job, developing their career and getting more enjoyment out of their work.

PERSONAL EXPECTATIONS Let us start by looking at some softer issues before exploring examples of typical expectations among the various stakeholder groups. As with all aspects of organisational behaviour, there are no hard and fast rules when it comes to what individuals will want to get out of the procurement of a new system. For one person, the process of acquiring the system may be important, whereas for another it might be the way that the system is going to be used within the organisation. Another point to consider is that some individuals may not be prepared to talk about their personal objectives and so you may need to read between the lines of conversations. Outside the context of a person’s job, the objectives of an individual probably fall into one of two categories. First, most people are looking for an easy life. In other words, they want to reduce the amount and level of hassle they need to endure, be able to complete their tasks with relative ease and, at the end of the day, feel some sense of achievement. Completing tasks with relative ease often means removing the boring parts of their work so that they can spend most of their time doing things that require a modicum of thought and decision-making, both of which help to lead to a feeling of achievement. Consequently, identifying those tasks that could be automated can make better use of resources from the organisation’s point of view as well as satisfying unspoken expectations of the individual. The second category not related specifically to a job function is personal development. This can take many forms, from acquiring new skills, through taking on more responsibility, to achieving promotion

30


within the organisation. At one level the individual can enjoy a sense of achievement by feeling they have developed and are now a more knowing, experienced person. At another level, people like to be recognised by others as having become an ‘expert’ in a topic or for being formally or informally responsible for part of the organisation’s tasks. The introduction of an information system in place of manual methods or the replacement of an old system may be challenge enough for some people, whereas others relish the thought of learning something new, expanding their scope or taking on new responsibilities. It is nearly always the case that an organisation is its people, and so any opportunity to develop staff should move the organisation in the right direction. Helping individuals to recognise that they are learning, developing and progressing as part of an information system procurement is likely to improve motivation, help ease the introduction of the system and improve the way it is viewed by stakeholders. In addition to the non-task specific objectives of individuals I believe that all levels of management within an organisation have a responsibility to help their staff enjoy their work. Management styles, objectives, responsibilities and organisational behaviour are the subject of many books, and others are more qualified to discuss them. However, the procurement of an information system is often a major event within the life of an organisation and impacts on the working environment of many of its staff. Both the procurement and the use of the system provide opportunities to enhance the working environment of individuals and those responsible for the procurement of an information system should look out for such opportunities. The spares management section leader in an aerospace parts supplier was made part of the core team for the procurement of an ERP system. She was coached in how to delegate work to members of her team so she could devote sufficient time to the project and, as a consequence, had a more enthusiastic team and, following the implementation, found time to look at business improvements, adding scope and enjoyment to her work.

TYPICAL EXPECTATIONS Returning to the stakeholder groups identified in Figure 3.1, we can look at some of the typical expectations of each of those groups. The board of directors or their equivalent within the organisation will cover a range of disciplines and responsibilities and each person may also belong to other stakeholder groups. However, their group expectations are usually centred on the objectives of the business, both in terms of the procurement activity and the ongoing use of the system. They will have approved the capital expenditure and will be looking for payback from the system in terms of the benefits that it should provide. These benefits might result from reduced labour costs, reduced inventory, increased throughput or reduced time to market. Basically, whatever was used to justify the cost of the new system should have been well recorded, along with how those benefits were to be measured. Research has shown that many organisations use Return On Investment (ROI) methods to justify capital expenditure, but then rarely attempt to evaluate how well those benefits have been realised. If our discussion on information system failures in the introduction is anything to go by, then perhaps there is good reason for not following through with any form of evaluation!


31

The majority of users of the new information system are unlikely to be interested in the return on investment of the system, unless they are measured in some way on achieving these benefits. Some may not even interact directly with the system but may be recipients of output from the system. Whatever their form of use of the system, their expectations are generally found to fall into two categories, those associated with departmental business objectives such as overhead reduction and productivity, and those related to the functions that they need to perform through or as a result of the system. The widespread nature of user expectations makes it difficult to capture their full extent. However, identifying the departmental level of user expectations, together with a sample of key user expectations, is likely to help with the management of the procurement exercise, a subject I shall discuss shortly. Experience has shown that information systems are rarely installed and left alone. A large amount of effort is expended in keeping the software up-to-date, the data collected by the system needs to be archived to secure media, and the application needs to support changes to business processes. Consequently, a number of people are involved in the maintenance of the system, keeping the hardware and software running and adapting the system to keep pace with the organisation. If the new information system replaces an older one then maintainers of the system will have expectations formed largely from their experience of the old system. Maintainers of the application, however, are perhaps more likely to form their expectations as they become aware of the capability of the new system and how it can be applied to their business processes. You may have been surprised to see the supplier included within the list of potential stakeholders, but suppliers too have a stake in the future of the system. Initially, during the procurement process, they hope to maintain a healthy cash flow and produce a reasonable profit from the hardware, software and services that are being supplied. Once installed and in use, they may also see your system as a good reference site to help them sell systems to other users. As far as your site is concerned they will want to sell you support services and undertake any application enhancements and hardware and packaged software upgrades that you might require. In fact, you might have as many as three or even more suppliers, one or more providing hardware, one providing the packaged software and one providing application engineering services. Consequently you must consider how a supplier’s vested interest in your system can be turned to your advantage during the management of the procurement.

Management of expectations When discussing the management of software projects, Boehm and Ross1 described a number of approaches that are summarised in Table 3.1. They chart the development of project management from the hard scientific approach, through some attempts to soften the methods used to control a project, to their suggestion for an alternative approach. Unfortunately, the scientific method is still the most widely used and any hint of a problem in the project is likely to result in the application of tighter control and attempts at even finer definition of tasks.The method they call ‘Theory W’ is of interest to us when we consider the procurement of an information system. When applying ‘Theory W’, the

32


Table 3.1 Theory X

Theory Y

Theory Z

Theory W

Approaches to software project management This is the scientific management approach in which one organises jobs into well-orchestrated sequences of tasks and in which people are as efficient and predictable as machines. With Theory X the manager is an autocrat. With this approach one attempts to stimulate creativity and personal initiative. The manager is essentially a coach but the method creates difficulties dealing with conflict and coordination within the project. Here one attempts to eliminate conflict by up-front investment in developing shared values and arriving at major decisions by consensus. The manager is a facilitator, and emphasis is placed at the corporate culture level rather than on the inter-company level or individual project level. Software project managers stand more chance of being successful if they make winners of all the other participants in the software process. This includes superiors, subordinates, customers, users and maintainers. Here the manager is a negotiator, a goal-setter, a monitor of progress towards those goals, and an activist in seeking out day-to-day win-lose or lose-lose project conflicts, confronting them, and then changing them into win-win situations.

project manager attempts to identify any situation in which one of the stakeholders is likely to end up in a losing situation and then tries to turn it around so that everyone is a winner, or at least feels that they are a winner. As we shall discover in Chapter 8, a good substitute for success is achieving a situation where all stakeholders feel that their expectations have been met or exceeded; so knowing the expectations of all stakeholder groups becomes crucial. Our discussion on the management of the purchase and the implementation draws heavily on this concept, and capturing these expectations is the first stage in the process. As I have said before, it may be possible to divide the process of procuring an information system into a number of phases to help us understand that process, but there are many dependencies between phases. We find that capturing the expectations of stakeholders not only helps with the management of the processes but is the starting point for our definition of the requirements of the system, a subject that we shall discuss in more detail in Chapter 5. The ‘Theory W’ approach suggests that we need to ensure that everyone’s expectations are met and so we may well need to take some action in order to achieve this. Many expectations will simply be functional requirements of the system and so will require no specific action other than ensuring that the feature is provided. Some functional requirements, and certainly all the non-functional expectations, need to be reviewed and a decision made as to what action needs to be taken and by whom. An expectations checklist (see example below) provides a simple approach to both the capture of the stakeholder group’s expectations and the necessary actions. Clearly, this is a major exercise and a more practical approach is to put these expectations into a database that includes fields for date of capture, date of completion, category of expectation (for example, ROI) and cross-reference to other related expectations. However, the importance of this step cannot be overemphasised.The study of real information system procurements has provided strong evidence that the capture of stakeholder expectations can provide the foundation for:


• • • • •

33

the management of the purchase phase of the project; the specification of the requirements of the system; the selection of the supplier or suppliers; the implementation of the system; and a successful outcome to the project.

Strangely enough, these are the subjects of the following chapters, and so it might be time for another stiff gin and tonic.

Note 1 Boehm, B.W. and Ross, R. (1989) ‘Theory-W software project management: principles and examples’, IEEE Transactions on Software Engineering, 15 (7), pp. 902–16, IEEE.

34

EXPECTATIONS CHECKLIST

Stakeholder Group/Individual

Expectations

Actions needed

By

Board of directors

Return on capital outlay within two years

Identify benefits of new system in financial terms

Project manager

Agree measures with board

Project sponsor

Put measures in place as part of normal operations

Department managers

Identify size of reduction Agree plan and schedule for redeployment of staff

Project manager Project manager/ operations director

Operations director

Reduction in production scheduling staff


List your stakeholders, their expectations and what actions must be taken to meet those expectations. Also record who is responsible for each action. Some example text is included to help you in this process.

CHAPTER

4 How do I manage the purchase?

Recall our case study of the electronic assembly manufacturer ElectAM. I said in the introduction that their intent had been to assess ten potential suppliers, further investigate a shortlist of two or three vendors and then place an order within 11 months of their decision to embark on the venture. As you can see in Figure 4.1, they had

Figure 4.1

ElectAM project schedule

36


intended to select a vendor within nine months and then place an order within another two. As you can see, it actually took them 23 months to place an order, a full year longer than their original intent and six months longer than their original total schedule for the project. Let us look in a little more detail at this phase of their procurement and then compare it with the same processes in another organisation which was buying a similar system. This should lead us to a view on how to manage the purchase phase of an information system procurement, linking the stakeholders that we discussed in Chapter 3 with the procurement project organisation and the management of the team and contract.

ELECTAM: PART 3

Getting to order placement The reasons why ElectAM’s existing business computer system needed replacing were described in the introduction, and so it was that early in 1993 the company decided to replace its system. Having made this decision, the company set up a project team with representatives from each department, plus a steering committee, both shown in Figure 4.2. The original intent of the board of directors was that the project team as a whole should make the vendor selection. In practice, this turned out to be too cumbersome and the steering committee made

Figure 4.2

ElectAM organisation

How do I manage the purchase?

the final selection. That steering committee consisted of the manufacturing director, the company’s cost accountant, the materials manager and the data processing manager. Following a visit to a trade exhibition, the project team started with a list of about 20 suppliers, ten more than planned. As can be seen from the project schedule shown in Figure 4.1, it was not until January 1994 that the Invitation to Tender (ITT) was sent to 10 prospective suppliers, rather than the planned two or three, and this was six months behind schedule. By July 1994 this had been reduced to a shortlist of three, which included the supplier of the original business computer system. The time schedule shown in Figure 4.1 also indicates the main time-ordered phases of procurement that were discussed in Chapter 2, namely: • • • •

identification of requirements; definition of scope of supply; vendor selection and negotiation; and system implementation.

The first three phases are of interest to us here, and so we shall briefly consider ElectAM’s approach to each. In this chapter we are interested in the management approach to the purchase phase, whereas the next two chapters look in more detail at system definition and vendor selection.

Identification of requirements This phase of the procurement process is one of defining the characteristics of the system to arrive at some form of justification, financial or otherwise. The outcome of the stage is to provide corporate approval for the expenditure of resource on the production of a more detailed statement of the requirements. In February 1993, following the selection of ten potential suppliers, the steering committee posted the following statement of aims on the notice board: • • • • • •

improve customer service levels; improve manufacturing service levels; maximise stock utilisation; reduce customer lead times; improve management information; and improve utilisation of resources.

Therefore, in addition to the deficiencies of the existing computer system as described in the introduction, clear business objectives were identified at the start of the project.

37

38


Definition of scope of supply Before asking suppliers to bid for the provision of the system, most organisations feel it is necessary to produce a User Requirements Specification (URS), or equivalent. In this case, an Invitation to Tender (ITT) document was issued by ElectAM’s steering committee to potential suppliers at the end of January 1994. The 43-page document was made up of the sections shown in Table 4.1. In this case, the buyer insisted that the supplier proposal should match the structure of the requirement specification, answering each question in turn. In fact, suppliers who did not respond as requested were not even considered for the shortlist.

Table 4.1

User Requirements Specification (URS) contents

Introduction – Details of how the vendor should respond to each item within the ITT Overview of company’s activities – Description of the product types manufactured and of the manufacturing capability and methods across the three sites Strategic and operational objectives – Seven items requiring IT support covering: The provision of quality and price competitive products Fast response to customer requirements New product development Growth in production capacity and manufacturing facilities Interfaces with customer’s information systems Reduction in information processing times A flexible and continually improving information system supported by a vendor committed to support the company Problems with current system – Divided between hardware and software problems Detailed departmental functionality requirements – A collection of questions and requirements statements for each of the following departments: Sales/Marketing Purchasing Materials control and stores Estimating/Engineering Quality control Finance/Costing Human resource systems System specification – A list of requirements considered necessary for system maintenance Supplier issues – A request for details of the vendor organisation Appendix A – A list of current users of the system with location and some indication of application use Appendix B – A summary of the current and required peripheral devices (screens and printers) Appendix C – Sizes of the data files on the current system


39

Vendor selection and negotiation Usually in parallel with the production of a User Requirements Specification document, the purchasing organisation starts the process of identifying potential suppliers. This stage includes the receipt and analysis of proposals from the selected suppliers, and the contract negotiations leading to the placement of an order. Here, the materials manager set up a spreadsheet that the steering committee then used to perform an analysis of the data from each proposal. This spreadsheet resulted in a ‘degree of fit’ for each of the sets of departmental requirements and was used to reduce the nine proposals (one response was not in the requested format and so was eliminated) to a shortlist of three. This was achieved by the beginning of July 1994. The same approach, when applied to the three contenders, failed to differentiate between the potential vendors. It was not until October 1994 that the final decision was justified on a single sheet of handwritten A4 paper. The company had expected the vendor selection process to take a total of nine months from the decision to proceed with the computer system replacement. The process actually took them 23 months. Their intent had been to evaluate 10 potential suppliers and then issue an ITT to a shortlist of two or three. In the end, they evaluated 20 suppliers, sent an ITT to 10 and ended up with a shortlist of three between whom they could not differentiate. Finally frustration caused them to pull back from the very detailed weighted comparisons and to select on the few most important requirements. The decision was finally based on: •

• •

Ease of migration from the existing system plus ‘future-proofing’; that is, easier upgrades of hardware and software since the new version of software, which was shortly to be released, would run on a wider variety of hardware platforms; An available solution to the ‘What if?’ requirement; that is, the ability to quickly see the effects of potential orders on the production schedule; The view that there would be better support and a good relationship with the supplier.

On the down side, the chosen product would not handle forecasts for families of products and the price was higher than the alternative shortlisted systems. On the subject of price, the official line was that the cost of the system was not one of the key factors used to help select the vendor. However, each member of the steering group had their own shortlist of criteria and, although one had placed cost last on their list, another had price as the second most important item. From the final three vendors, the highest price option was chosen. Part of the extended time that it took ElectAM to reach a decision on a supplier was clearly due to the steering committee’s inability to keep the shortlist down to a manageable length. The other undoubted factor was that all those charged with making a recommendation were also expected to continue to perform their normal duties. In other words, selecting one of the most important tools of the company’s operation was

40


considered to be a part-time activity. It also appears that the steering committee laboured long and hard to evaluate each system against the detailed features of their existing system and the detailed processes used with that system. Packaged software systems tend to embody current best practice, and so looking at how you can reimplement present business processes may not help you to move forward.

CASE STUDY: POWERSOUND

From requirements to order placement This audio equipment manufacturer was surprised at the effort needed to maintain their new ERP system. However, they took a slightly different approach to the vendor selection process. Their existing business computer system had been installed four years earlier. It was described as a ‘very simple system’ and, according to their finance director, ‘There was so much we couldn’t do with the old system, for example support for Kanban.’ At that time the company employed about 600 staff across a number of geographically distributed sites and exported 95 per cent of its products through owned and independent distributors. The existing business computer system supported 40 concurrent users but with the expansion of the company there was now a need to support 160 concurrent users in real time, spread across multiple sites. The system was designed primarily to provide Manufacturing Resource Planning (MRP II) capability, and provide only rudimentary finance and sales administration facilities. For example, it would not print purchase orders or sales invoices. This lack of functionality caused the increased use of non-ERP tools, which resulted in a strong IT capability within the company. Although primarily a manufacturing system, little consideration had been given to the growth rate of the company and the MRP II module was now taking eight hours to run and the general ledger had to be run overnight. PowerSound had implemented enough infrastructure around the existing system for them to be able to work adequately, for example by using SQL and Microsoft Access. However, five or six Year 2000 problems had been identified in the system and there was no support to fix these. It was said that the existing system had been chosen principally on technical grounds with what was described as ‘a significant lack of focus placed on the supplier’s ability to both maintain and support the product’. In fact, following installation, the relationship with the supplier deteriorated rapidly and their key personnel associated with the purchase left. This highlighted the supplier’s lack of ability to provide even basic support, and eventually they were taken over by another supplier. The new supplier would not support the system as implemented and instead offered a high-price upgrade, resulting in PowerSound deciding to run with the existing product unsupported except by in-house personnel. Although this decision was understandable, given the circumstances, it was considered to be unacceptable in the long term to have


the company dependent upon a computer system that could neither be upgraded nor repaired. In addition to the Year 2000 problems (the entire system was built around a two-digit date code), PowerSound wanted to achieve a number of other objectives: 1. Daily rather than weekly planning through the ERP system to the shop floor; that is, all 11 work-sets. They currently had an in-house developed off-line system to achieve this. 2. The existing system did not support sufficient decimal places and many small entries, such as adhesives, had a zero entry. Stock for these items was therefore maintained between maximum and minimum values but could not be included in product costs. 3. They wanted MRP II runs to multiple sites. 4. They needed to buy materials in foreign currency so they wanted to work in the foreign currency and then let the system calculate the amount in pounds sterling. The existing system forced them to work in pounds and then convert. 5. They wanted to use a back-flushing method; that is, book items out of stores as the modules are built. 6. They wanted to use absolute costing (rather than standard costing) since they were sourcing materials from around the world. Standard costing requires lots of corrections. 7. The existing system was made up of various systems bolted together. Integration of these systems was seen by some to be the most important benefit of the new system. 8. To implement Distributor Resource Planning (DRP) so as to make distribution easier and less manpower-intensive. 9. Although the existing system had a crude report writer, PowerSound had bolted on an SQL tool to produce reports in Microsoft Access. The main requirement for some was for flexibility of reporting. According to the finance director, ‘The system was restricting the business. Something had to be done and Y2K formed a backstop date.’ The actual timescale for the procurement of the ERP system (following a year spent on a business process review) is illustrated in Figure 4.3, along with the planned timescale and the phases of the procurement used to describe the process.

Identification of requirements As a result of a year-long business process review, PowerSound identified those areas that could be better handled with new systems. It was noted that the key to this process was the identification of duplicate effort in various departments processing similar data. One of the outputs of the review was the recognition that

41

42


Figure 4.3

PowerSound project schedule

confusion was being caused because different criteria were being applied in reaching results such as sales figures. There were also a ‘multitude of different spreadsheets and databases’ being manually maintained. The finance director recognised, however, that as a result of needing to manually analyse data PowerSound had a good supply of computer-literate staff. As a result of the review, a number of key business requirements were identified, including: 1. The need to place greater emphasis on managing and integrating the supply chain, especially in relation to the company’s distribution operations. 2. The need to improve/optimise existing processes by integrating the mixture of systems that had sprung up around the existing business computer system. 3. The delivery of new processes and additional functionality to the business. 4. A reduction in the amount of paperwork generated and reliance on printed output. 5. A reduction in supply chain lead times and inventories through the use of Distributor Resource Planning (DRP). 6. The facilitation of single-entry/processing of a piece of information. 7. An improvement in customer service levels without increasing inventory levels.


8. An improvement in flexibility and agility throughout PowerSound (that is, product development, manufacturing, supply and management). 9. Increased support for company growth and expansion for at least the next five to ten years.

Definition of scope of supply Having completed the business process review project, a systems requirements document was produced for the new ERP system. This involved a review of all departmental objectives using the knowledge gained from the review process. The project was led by the finance director, who was the sponsor of the project, and by the business systems manager, both of whom had previous experience of procuring a similar system in other organisations. Figure 4.4 shows how PowerSound had evolved due to the strength of character of certain individuals, rather than by design. A point to note here is that the business systems manager was assigned full-time to the project, as was the finance director during the vendor selection phase of the project. In addition to the departmental objectives, which were approved by each departmental manager, the company wanted a new business computer system to: 1. improve the speed, automation and efficiency of the production planning process;

Figure 4.4

The organisation of PowerSound

43

44


2. have a positive impact on the new product development process; 3. enable completion of the Just-In-Time (JIT) supplier development programme; 4. provide powerful management reporting facilities; and 5. eliminate the need to export data from the main system for reporting and analysis purposes. The System Requirements Specification (SRS), the contents list of which is reproduced in Table 4.2, consisted of a detailed description of all the functions that each department in the organisation performed. Where the originators of the SRS had tried to omit detail they had provided little that could help a supplier relate to the business needs of PowerSound. For example, the critical success factors listed in the specification were: • • • • • •

management buy-in and support; empowered project team; focus on processes, not functions; structured and organised approach; high level of project management, communication, user involvement and training; not stopping short.

Table 4.2 System Requirements Specification (SRS) contents Introduction Background Objectives New system requirements Overview Scope Supplier profile System architecture/System management requirements Productivity features Office support functions Integration/Compatibility/Interface ability Production functionality Purchasing functionality Finance functionality Multi-currency requirements Sales and distribution functionality Warehousing functionality Marketing support functionality Quality assurance functionality Good inwards functionality Management information/Reporting requirements Sizing and performance requirements

How do I manage the purchase? Implementation Timescales Critical success factors Measures of Success Production Purchasing Quality assurance New product development Document management Drawing management Sales and distribution Finance Marketing General Future requirements Appendices Appendix A – Reasons for new system Appendix B – BPR highlights Appendix C – Sizing information/data volumes Appendix D – Sample documents Appendix E – Proposed [company] project team members Appendix F – Further contributions

Similarly, the ‘measures of success’ were a list of items, under the headings in Table 4.2, which would either be achieved or not achieved, for example ‘Rough cut capacity planning’, or subjective in their achievement, for example, ‘Improved engineering change process’. We will talk about the selection of the system in the next section and implementation issues in Chapter 7 but one common criticism of the Requirements Specification was that it did not marry up with what the chosen system could actually do. By this it was meant that the new system was designed around a business model which was different to the one that the originators of the specification had described. Consequently, although the requirements could be implemented, there was a better way of achieving the desired result. Many felt that the core team really needed more knowledge of the system so as to produce a better implementation. For example, knowing the system capabilities for Kanban and repetitive manufacturing would have been useful when configuring the manufacturing module. Although the System Requirements Specification concentrated on processes, they were business processes that were specific to the way that the company had previously worked. In spite of the apparent comprehensive nature of the System Requirements Specification document and its focus on the business process review project, some people expressed the opinion that the project had not been well specified. One senior person also felt that the producers of that document did not probe people enough. He thought that they should have questioned users further rather than just written down what was said.

45

46


Vendor selection and negotiation Up until now the process undertaken by PowerSound is not too dissimilar to that used by ElectAM. However, during January and February 1998 the finance director and the business systems manager derived a list of key requirements from the System Requirements Specification, which they then used to carry out a telephone poll of 24 potential suppliers. Their intent had been to arrive at a shortlist of suppliers who would then be visited. They spent up to two hours on the phone with each supplier, completing a supplier profile pro forma for each, which sometimes required more than one call. Due to their existing experience PowerSound had decided to use a particular operating system and was therefore looking for a product that was tightly integrated with that operating system. The ability of the product to run in that operating environment, together with the supplier’s size, support capability and number of installations were all identified as key factors that separated out the strong candidates. In addition, a number of ‘must have’ features were identified as: • • • •

the management of foreign currency; the control of engineering change notes; integral quality management; the ability to handle modern manufacturing techniques such as Kanban, Justin-Time, work-order-less back-flushing, and back-flushing to supplier payment.

PowersSound found that a number of suppliers could meet all the requirements by the use of ‘bolt-on’ third-party products. However, one supplier had all the functionality that was required, and more, without the need to integrate products from third-party suppliers. Although this supplier was the most expensive, PowerSound decided to progress with a more detailed review on the basis that this would be a yardstick to measure other suppliers against, should there be any major problems with the strongest contender. Initially PowerSound thought that this supplier would be too expensive but they had a Value Added Reseller (VAR) network and proposed their VAR for discrete manufacturing for the supply of implementation and training services. These consultants proposed to use an ‘accelerated implementation methodology’ that reduced the amount of implementation effort needed, and therefore the cost. They were also to provide first-line support. The heads of sales and finance, the master production scheduler and the business systems manager all visited the consultant for a full day. They then had a four-day visit from the consultant at which the system was demonstrated to show the core team what could be achieved. They met the VAR account manager, a project manager and a consultant who was being used to help sell the product. The PowerSound group systems manager felt that the supplier was very good at


47

‘selling’ itself and the system, although the finance director commented that ‘[The supplier] was the safe choice.’ A visit was made to an existing installation of the product, a visit that was described as ‘the clincher’. Then, following board sanction, the purchase order was raised in March 1998. However, there were some problems in reaching an agreement on the terms and conditions of the contract (one person said that the finance director was trying to get the price down), which delayed order placement until July 1998. The result was that the allocated consultants at the VAR were no longer available, and so the work was sub-contracted to another company. This also meant that the system had to be implemented at an even more accelerated rate and, due to a lack of available staff, the sales and distribution consultant started two and a half months after the start of the implementation.

Organising to buy This chapter is concerned with the best way to organise a company for the processes of specifying the requirements, of selecting the software package and supplier and finally of carrying out the implementation. The details of these processes will be covered in future chapters but our two case studies of the early stages of information system procurement can help point us in the right direction. For both companies, the systems that they were buying were at the heart of their business. They had both reached a level of manufacturing complexity where they could not operate without the facilities provided by such a system and in fact ElectAM almost went out of business due to lack of performance of the new system.Yet ElectAM assigned key members of the core team on a part-time basis. Research carried out in other organisations also suggests that keeping the purchasing stage of the procurement as compact as possible can help keep the momentum high and contribute to a successful project. So follow the example of PowerSound and dedicate key members of the core team to the project on a full-time basis. This will mean relieving them of their other duties, but that in itself can help expand the experience of other members of staff and improve motivation. It also sends a signal that the project is important to the organisation. During the description of the purchasing phases of these two companies’ ERP system procurement I used terms such as sponsor, steering group and core team. We will now spend a little time expanding on these individuals and groups and on the responsibilities of each. Figure 4.5 illustrates the relationships between these groups and shows how each is linked to the other.

THE SPONSOR Information systems relate to large capital expenditure, tying up resources for an extended period and impacting on the operations of most, if not all, of the organisation. The purchase of a manufacturing system, personnel administration system or management information system is therefore likely to be a major event in the life of a company and, as a consequence, have a high visibility at board level. This is as it should

48


Figure 4.5

The organisation of people suggested to manage information system procurement

be and it should also be the case that one member of the board takes on the role of sponsor. The best person to choose as sponsor is probably the board member that has the most to gain (or lose if things go wrong) from the introduction of a new system. The sponsor is the most senior supporter of the project, both keeping the board informed about the decisions and progress of the project and lobbying the board for resources and commitment across the organisation. Just as the project should be very visible to the board, so the sponsor should be visible to the rest of the organisation, again emphasising the importance of the project. The role taken by the sponsor within the steering group depends upon the individual members, although my preference is for the sponsor to chair steering group meetings since this is likely to increase their ownership of the project.

THE STEERING GROUP Whatever the role taken by the sponsor, it is important that the steering group is given legitimacy by being formally announced by the board. It is also important that all meetings, no matter how informal, have their decisions and actions recorded. Inevitably things will get missed and memories will fail, so it is very useful to have the outcome of group discussions recorded in meeting minutes. One organisational purchase of an ERP system that was studied set up both a steering group and a core team. However, the steering group appeared to give little importance to its role, and few meetings were held. As a consequence the core team went off at a tangent and started trying to re-engineer the business, wasting several months at the start of the project.There may well be a need to change the business processes at the time of introducing a new information system, and we shall return to this idea later. However, the steering group is there to do just that; steer the core team in terms of the primary objectives of the business and the agreed strategy, keeping them on the rails towards their destination. You will notice from Figure 4.5 that the appointed project manager for the procurement is a member of the steering group and forms the link to the core team, just


49

as the sponsor is the link to the board of directors. Otherwise, the members of the steering group are chosen on the basis that the group needs to ensure that the business objectives are achieved and that support is provided from the rest of the organisation as required and agreed. It is therefore likely that major function heads will be part of the steering group, the only caveat being that the group needs to have a wide enough coverage to support the project but be small enough to be effective.

THE CORE TEAM Now we come to the people who actually do the work! We will find in the following chapters that there is considerable work involved in specifying the requirements, making recommendations on the package and vendor, and then in implementing the system. It is the members of the core team who undertake this work. It is common sense, given the importance of most information system purchases, and there is strong evidence to support the view that there is a need to appoint people to the core team on a full-time basis.This usually presents organisations with a dilemma, since those needed to perform this important task are also the key people involved in running the business. There is probably never a good time to move people from their operational roles and the fact that a new system can be justified probably means that the business is under stress due to the inadequacies of the existing system. Nevertheless, the situation can be turned to your advantage. Here is an opportunity to publicly reward key individuals by showing that their worth is recognised and at the same time not only motivate core team members by giving them a new challenge but develop the next level of staff who take over the core team’s previous roles. The latter can be achieved in a number of ways, including a onefor-one temporary replacement or distribution of responsibilities across a number of people. The method used depends upon the individual circumstances but with careful planning, the benefits can be realised.The need to free these people for the project is one reason why the steering group should include representation from each of the main functional areas of the organisation, in other words, from the main stakeholder groups below the board of directors. I said earlier that the core team has two main functions during the purchase phase of the procurement; define the requirements of the new system, and make recommendations on software package and vendor selection. Those organisations which used only a small core team, from their IT or business systems group, failed to get sufficient support from the operational areas of the company and this resulted in systems that only met part of the overall requirements. Employing people from the main functional areas results in three main benefits: 1. The functional managers have demonstrated support for the project and are keen to get a good return on their investment. 2. Those with day-to-day knowledge of the operations are involved during the whole procurement process. 3. Those working in the functional areas are more likely to accept the new system knowing that one of their colleagues has been involved in making it do what they need.

50


We will discuss how the core team should be managed in the next section and what they actually need to do in the following chapters. However, you can list the main players in the first part of the purchase checklist, stating why that individual was chosen.

SUPER-USERS ElectAM, PowerSound and an organisation that I shall introduce later all had the equivalent of a steering group and core team, even if some were not particularly effective. However, only one company used the concept of ‘super-users’. As you approach the point where the new system needs to be put into use, so you will be planning the training and subsequent support of the users. This is a time-consuming exercise and can be costly if the supplier’s training courses are used for everyone. The supplier’s courses should be good at describing how to use the basic facilities of the new system, but you will want to train your staff in how to use it to perform their particular functions. This is where super-users come in. Your core team members are going to be very busy during the implementation phase of the project and their availability for giving training courses will be limited. The organisation that did appoint super-users identified people in each functional area who were sent on the supplier’s course and then given up to half of each day to prepare and then give courses to their colleagues. The training material was relevant to their business since it included screens from their configured system and all the presentation files were made available online for future reference. These super-users were then also available to provide first-line support to the users in their departments. During the whole process the super-users had the support of the core team and the user training and support operation proved effective, cost-efficient and an excellent change management tool.

THE PROJECT MANAGER Although I mentioned the project manager as being the link between the steering group and the core team, we have not yet said much about his or her responsibilities. The experience of organisations that have relied on the supplier to manage the project have generally been disappointing. This has either been due to the lack of project management experience of the supplier or to the fact that they have tried to manage internal activities on a part-time basis, or perhaps both. The approach to managing an information systems project depends upon the nature of the contract and on the experience of both parties, and we shall discuss these points in the next section. However, your project manager is probably the most important person in the whole procurement exercise. He or she needs to be appointed to the position on a full-time basis, have a good outline knowledge of the operations of the organisation, have a strong but accommodating personality and preferably have experience of procuring information systems. Recalling our discussion of ‘Theory W’ in the last chapter (see pp. 31–32), your project manager needs to make everyone feel that they are a winner if you want your new system to be viewed a success. If you don’t have a person with these qualities in-house then you are strongly advised to hire such a person, either on a permanent or contract basis.


51

Managing team and contract Let us briefly turn our attention to the contract, since this can be fundamental to the way in which an information system project is managed. As with most of our discussions there are no hard and fast rules about the type of contract best suited to the purchase of an information system. For the procurement of an ERP system you may only want to purchase training from the supplier, along with some consultancy to help your own staff configure the system to your requirements, paying the supplier for the hours that they work. Alternatively, for a manufacturing automation system you may want the supplier to convert your requirements document into a detailed functional specification and then for the supplier to configure and test the system before installation, all for a fixed price agreed at the time of order. There are advantages and disadvantages to the ‘time and materials’ (T&M) type contract as well as to the fixed-price contract. The information systems that are our concern are all complex in terms of the functionality that they provide and the degree of configuration required to adapt that functionality to individual requirements. It is therefore very difficult to write down a complete and unambiguous specification of what the system is expected to do, and equally difficult for a supplier to estimate the cost of configuring it.

COMPARING CONTRACT TYPES Unlike the purchase of materials or equipment such as a photocopier, at the time you place your order you only have it on trust that the system can be made to meet your business objectives. And that trust, in turn, is not only based on how well you have enunciated your requirements and how well the supplier has understood them, but also on the capability of the system and on your ability to instigate change within your organisation. There is the risk with a time- and materials-based contract that you will need to purchase more time from the supplier than had been budgeted.Training courses can be quantified but consultancy to help you implement the system is open-ended. Although suppliers will provide an estimate ‘based on their experience of your type of organisation’ they will not want you to believe that you will require more effort from them than from their competitors. However, with less pressure on meeting a fixed budget it is likely that your relationship with the supplier will withstand the pressures of the project. After all, your new system will require support into the future and you might be dependent on the supplier to provide it. There have been many examples of a purchasing organisation saying ‘if they say they can do it for that price then they are taking the risk’ when referring to a fixed-price bid from a supplier. Unfortunately, experience shows this not to be the case. Looking at it from the supplier’s point of view, they are in a competitive situation and so will want to limit the scope of what they are offering so as to keep the price down. The corollary to this is that they will then charge for anything that they can show was not explicitly defined in your requirements specification. As I said earlier, it is difficult to write a comprehensive specification and your interpretation of a business requirement will often be quite different to that of the supplier. Even though you will have chosen a supplier

52


with experience of your type of business, you will both have your own ‘language’ and different meanings attached to the same words. Logically, an open and honest relationship between the purchaser and supplier, where both parties have the common aim of improving the supplier’s business for the lowest investment would seem the obvious starting point. This is difficult to establish within a commercial and competitive setting, however. A supplier might see the advantages of working in this way with their client if, by so doing, substantial further business would accrue, as might be the case if the purchaser had many sites or many group companies. The small to medium-sized organisation that is only going to buy one system becomes, at best, a source of support services and a reference site to help sell systems to other purchasers.This view may sound very cynical but we need to remember that the behaviour of each individual will depend upon how they, and the supplier organisation as a whole, are measured. A salesperson has a sales target to achieve, a consultant has a level of utilisation (paid hours), a project manager a target gross margin for the project, and a company has sales and profit against forecasts. I am not suggesting that you should look for a hidden message in everything a potential supplier says, but it is worthwhile trying to put yourself in their shoes and understand their motivations. Certainly they will be doing the same with respect to you.

CHOOSING A CONTRACT TYPE So where do we stand with regard to the type of contract most suited to the purchase of an information system? First, use someone in the core team, preferably the project manager, who has past experience of contracts for this type of system. Then, having looked at the potential suppliers, decide whether you or the supplier is to manage the project. If you choose the latter then make it clear to the supplier that is what you expect, insist on meeting the project manager who will run your project, and talk to other organisations that have bought similar systems or services from the supplier. Then consider the risks associated with the different types of contract. Of course, the time and materials and fixed-price contracts are not the only options.You can combine the two by using a T&M contract for the production of a detailed specification, at which point the supplier is in a good position to provide a fixed-price quotation for the project implementation. Budgetary estimates at various points in the process provide a check against your expectations for the whole project. You would be advised to include a contingency of between 10 and 15 per cent in your budget to cope with the inevitable extras, depending on how well you have been able to specify your requirements. A contingency fund can also provide another variation on contract type. Following estimates or a fixed price from the supplier you could declare your total budget, including contingency, and offer to split any money remaining at the end of the project between the supplier and yourself. The problem with this type of ‘risk and reward’ contract is that it becomes more complex to define and administer, and so should not be considered unless you have considerable contract experience. A number of model forms of contract are available from professional institutions such as the Institution of Electrical Engineers (IEE).1 The model forms provide a template that you can apply to your own needs and include all the basic general terms and conditions of


53

contract that need to be part of any contract into which you enter.You can also use the second part of the purchase checklist (see p. 55) to record your risk assessment for each type of contract you might consider.

OTHER PURCHASE MANAGEMENT CONSIDERATIONS Our discussion so far on the management of the purchase phase of an information system has a significant overlap with the following chapters on specifying requirements, selecting a supplier and managing the implementation. The suggested organisation depicted in Figure 4.5 has been shown to work reasonably well through both the purchase and the implementation phases, and the choice of contract type is intimately linked to the supplier selection process. The case studies of information system purchases described earlier in this chapter also suggest other points that apply to the purchasing phase but need to be continued through to the end of the project: 1. Whether you are managing the entire project yourself or just mustering your resources, keep it simple. PC-based software packages for planning and monitoring projects can take over your life. Your aim should be to spend the minimum time in front of your PC screen and the maximum time supporting the people doing the work. 2. In both purchase examples, circumstances prevented the expected consultants being available for the project implementation. Suppliers will try to avoid being tied down too much in terms of the use of their resources, but it is worthwhile trying to get some demonstrable commitment from your supplier concerning the individuals who will be used for your project. 3. As we shall see later, selecting a configurable software package is not an easy task. The process will be easier to accomplish, however, if you plan some basic training for members of the core team on the system before you place an order. This will allow you to have a better appreciation of the capability of the system and how it can be used to solve your business problems. 4. Right from the start, define the responsibilities of members of the steering group and the core team, not just in terms of their areas of involvement but by defining the project deliverables expected from each person. 5. We will discuss communication in Chapter 5 but the core team is fundamental to the success of your project and they must have a common understanding of policy, strategy, requirements and expectations. Regular core team meetings help to achieve this and it is suggested that they should be held weekly. Towards the end of the project the frequency will increase to daily. 6. All sorts of things start going wrong if the purchase phase takes a protracted length of time, as we saw in our two case studies. Therefore try to keep the purchase phase compact to keep the momentum going both within your own organisation and within the contending suppliers. 7. One organisation in the case studies spent time specifying the particular software operating system and database management system they wanted and were looking for cutting-edge technology for fear of buying an out-of-date system. Beware the

54


technophile. We shall return to this topic in Chapter 5 but experience shows us that concentrating on the functionality, performance and support needed to meet your business objectives is more likely to result in a successful system. 8. During the purchase phase of the project and then through the implementation it will be necessary to monitor the progress being made by your own staff and by the supplier. Whether the project is being managed by you or by the supplier, you should get into the habit of monitoring progress against project deliverables and not on the time spent on each activity.

Summary The experiences of medium-sized organisations that have procured information systems have suggested an optimum organisational framework consisting of a steering group and a core team, with the project manager linking the two and the sponsor linking up to the board of directors. Both organisations described used a time and materials type of contract but whereas one decided to manage the whole project themselves, the other chose to rely on the management skills of the supplier. The type of contract and the approach to managing the project result from the iterative process that is the purchase phase of such a project. It has been stated more than once already, and will probably be stated again before the end of this book, but a strong recommendation is that if you have not bought an information system before then hire someone who has. You can use the final section of the purchase checklist to check off the main activities associated with the purchase phase of your information system procurement. The complexity of the information system itself and of the organisation in which it is going to be applied, together with the wide-ranging impact that most systems have on an organisation, means that sharing goals and expectations is imperative. Communication therefore becomes a critical part of any information system project and an activity that should be started early. As one information system project manager said, ‘Talk to anyone and everyone about everything.’

Note 1 MF/1 (Revision 4) Model Form of General Conditions of Contract, ISBN 0 85296 759 4, 2000 edition. Information can be found at www.iee.org/Publish/Books/Model/index.cfm


PURCHASE CHECKLIST Organisation

Who

Stakeholder group

Why

Sponsor Project manager Steering group Core team Contract Type

Risk summary

T&M FP T&M/fixed-price Risk and reward Other Simple purchase phase plan produced? Core team meetings scheduled? Business/technology focus? Steering group/core team responsibilities defined? Supplier staff commitment received? Core team overview training arranged?

55


CHAPTER

5 How do I decide what I need?

Your board of directors has agreed that a new information system is required and they have approved the outline budget both in terms of capital outlay and the use of internal resources to complete the task. The board has announced the project, the sponsor has been chosen and he or she has told the whole organisation about the members of the steering group and their responsibilities, including the project manager. You have identified the members of the core team and again their names have been announced along with their responsibilities. So now you have an approved budget and resource to start the definition stage of the project. This stage (definition of scope of supply) is shown in Figure 5.1 within the overall generic procurement process for a configurable information system. However, producing an information system specification is a daunting prospect even for those who have produced one before. It is, after all, the foundation upon which the rest of your IS procurement is based and a lot of effort (and man-hours) will be expended on it, effort that can just as easily lead you into trouble as give you the result that you want. To move forward with some degree of confidence we need to take a step back and consider what you are trying to achieve and how the stakeholders that we discussed in Chapter 3 fit into the process. We will then look at the specification documents themselves, in terms of the areas to avoid as well as the things to include.

Figure 5.1

The procurement process – definition of scope of supply

58


What are you trying to achieve? You may recall in Chapter 4 that ElectAM had a sheet with six aims pinned to their noticeboard and a section within their Invitation to Tender entitled ‘Strategic and Operational Objectives’. For some reason, there was only a partial overlap between the two lists. However, they were on the right track. You are planning to purchase a new information system to improve the operation of your business and so the system must satisfy some business needs. If the supplier is not aware of these needs then they are less likely to provide a system that will help satisfy them, and will not expect the success of the system to be measured against them. Writing down the business objectives that are relevant to the new information system is not an easy task, but it is one that can be accomplished by the steering group and the board of directors. Certainly the latter should approve them even if they are not active in their production. It is a good idea, before trying to define your business objectives, to write down an outline description of your organisation and the business processes on which the new system will impinge. On the one hand this description can be included in the requirements document to set the scene for potential suppliers, and on the other it is a vehicle to help you focus on the objectives that are most important to your operation. The outline description of your organisation does not need to go into fine detail (that will come later), but should allow the reader to obtain a good grasp of the nature of your business and the way it is conducted. For example, if you have a distributor network and you want the system to help you manage it then you should provide an overview of it here. A number of techniques are available to help a group arrive at a refined set of business objectives; techniques from brainstorming, through process mapping to grouping Post It® notes on a board. If you are unfamiliar with such techniques then almost any management book will provide a guide. The important thing is to involve members of each area of the organisation that will be affected by the system. If you have chosen your steering group well, then these people will already have been identified. Both the outline description of your organisation and your business objectives are likely to be derived in several iterations, as a suggested objective makes you realise that a portion of the description is incomplete or as one of the reviewers notices a process that has been omitted. Providing business objectives that are meaningful in respect of a new information system is not easy. ‘To improve/optimise existing processes’ as one purchaser wrote in his requirements specification, is unlikely to tell prospective suppliers very much about their business or the direction in which they wish to move. However, writing the following should solicit a response from the potential supplier: Volume growth will be accomplished by capacity growth. This will come initially from more effective utilisation of existing resources but will also require some increase in factory space and in supporting services. Three broad growth options exist; extend existing factories, commission a fourth site, or acquire an existing company. A new IT system must be able to be extended to accommodate all of these possibilities.

How do I decide what I need?

59

Members of the steering group are likely to be far enough removed from the details of the business processes associated with the system to be able to avoid going into too much detail in this part of the requirements specification. They, or the board, should also be in a position to frame strategic and operational objectives in business rather than process terms.

The Invitation to Tender The requirements that you need to convey to the supplier really fall into two categories, those associated with the purchasing process and those that apply to the operation of the system itself. Often these two sets of requirements are combined in the same document but they have different aims and are probably produced by different people. Also, the purchase phase instructions have a relatively short lifetime, whereas the system requirements may evolve during the course of the system implementation, particularly if your business is in a regulated industry such as pharmaceutical manufacture.You might also find that you can reference a number of existing internal or external documents and an Invitation to Tender (ITT) document can list those as well as your system requirements document. The ITT document is the place to define: • • • • • •

the scope of supply from the supplier; the responsibilities of the supplier; contract terms and conditions; payment schedule; the time schedule for the purchase and the project; and request for supplier details.

Table 5.1 provides a suggested outline for an Invitation to Tender document. However, the table’s main purpose is to get you to think about the process of procurement from beginning to end. One of the main activities of any form of management is to identify areas of risk, assess the impact of those risks and identify means to mitigate them. As we have seen, procuring a new information system is a high-risk venture and so by concentrating on the process you can look for potential risk areas and decide how you can manage them.

What not to specify When it comes to the operational requirements of the system it is worth spending a few moments thinking about what should not be written in your specification. The examination of a number of requirements specifications has highlighted two tendencies of their authors. One tendency is to describe the functionality of the existing system or of a ‘design’ of a system that they think they want, and the second is to expend a lot of effort describing the technology that they expect to be used within the system.

60


Table 5.1

Suggested contents of an Invitation to Tender

Section Introduction Purpose Scope Reference documents Terms and abbreviations Definition of terms

Description

A brief outline of what you want to purchase and why An overview of the scope of supply you are seeking from a vendor Other documents that form part of the requirements to the vendor Any terms used within this document that may not have a generally understood meaning Acronyms abound in most organisations, so define them here

Definition of abbreviations Responsibilities Vendor’s responsibilities A qualification and expansion of the scope of supply but including activities and the provision of progress reports and attendance at progress meetings Client’s responsibilities The things you will do such as make qualified people available to answer questions during both the purchase and implementation phase Conflicts and errors You will be supplying this document, a User Requirements Specification (URS) and perhaps some other documents.You may also reference some national or international standards and there will be a commercial contract. There is a high chance that some of the information provided will conflict with other information and so it is wise to establish the precedence of documents Vendor proposal Here you state your expectations as far as the proposal from the vendor is requirements concerned. Suppliers will want to keep their selling costs to a minimum and so might try to produce a proposal from standard templates and sales brochures, leaving you to interpret them for your organisation. Insisting on a response to each clause within your requirements document will help ensure that the potential supplier has considered each requirement and make it easier for you to assess their offer. Other items include how you want the price broken down, details of warranties, delivery, installation and system support Project management In Chapter 8 we discuss the approaches to managing the implementation of the system. Whatever approach you choose, you need to describe the project management responsibilities you expect from the supplier Contract The nature of the contract you wish to use, including any reference to proposed model forms of contract. Also details of the way in which you expect to pay for the system in terms of stage payments linked to deliverables, retention of money for a period after installation or interest in any finance options Schedule Proposal Details of your schedule for receiving and evaluating proposals, including visits to the supplier and to existing installations Project Your current expectations of the major milestones from order placement to the system going live Supplier details A request for details of the supplier’s business and installed base

Describing the features you want in terms of the way that they are provided by your existing system is problematic. First, you are unlikely to find anything that satisfies your requirements and second, even if you could find such a system, you would not be moving your business forward. Both problems have the same cause. You might overcome capacity, performance or support problems but it is likely that the business models upon


61

which your old system was based have been superseded. Manufacturing computer systems encompass current thinking on work-flow and lean manufacturing, automation systems support international standards for intelligent instrument interfaces and batch manufacturing models, laboratory information systems adhere to US and European regulations for the control of electronic records. Consequently, if you simply describe your existing system then you make it difficult to take advantage of current best practice as embodied in available commercial products. This also has a serious implication in your quest for a new information system.There is evidence to suggest that trying to force a modern system to fit your present business process will reduce the chance of a successful outcome. Since our thinking on how businesses operate has moved on and software packages have been developed to apply this more recent thinking, then you should take the opportunity to examine the way you do things and adapt them to fit the new system rather than the other way around. Some organisations have chosen to perform a complete business re-engineering exercise prior to selecting a new system. However, the example set by PowerSound is probably a good approach.They performed a review of their business process, in order to understand their current deficiencies, before writing their ERP system requirements document.They were then able to use the modern facilities provided by their chosen system and change their processes accordingly. A similar problem is encountered by suppliers when a purchaser produces a specification that is expressed in terms of a system design. With this approach, once again you are unlikely to find a system that matches your requirements. You have to recognise that suppliers of the type of system you are seeking are generally in a better position than you to design how it works. Unless you really need the expense and risk associated with a bespoke or custom software solution, you are advised to concentrate on your business and operational requirements and let the supplier demonstrate to you how their system will satisfy those requirements. The second tendency of specification writers, focusing on technology, leads to similar problems. ElectAM actually asked (in the covering letter that went out with their ITT) the prospective supplier to state the computer operating system and the relational database management system that were used by their ERP system. In the days before Ethernet was widely accepted in an industrial environment and many communications protocols were proprietary, at least in part, specifications would call for token-passing based communication, immediately making many otherwise acceptable systems noncompliant. You may have good reason for requiring a particular operating or database system to be supplied; if, for example, you use it elsewhere and want common support capability. However, there are usually many technological solutions to a requirement for operational functionality, and it is better not to exclude these options from the start. So forget RAM, processor speed and communication bandwidth and concentrate on business and operational requirements.

62


The User Requirements Specification (URS) We have described the Invitation to Tender (ITT) document as that which defines your requirements for the purchasing process. Now we move on to specifying the business and operational requirements in a User Requirements Specification (URS). I mentioned in Chapter 2 that some advice was available within the BuyIT Best Practice Guidelines1: Guideline 1 (Planning Delivery of the Business Benefits) and Guideline 2 (Identifying the Business Requirements). These guides provide an outline of the process that helps you to define your business objectives, capture your business requirements and then convert them to functional requirements. Other guidance is available for particular types of application. For example, the Good Automated Manufacturing Practice (GAMP2) guide, produced by a pharmaceutical industry body, is widely referenced and followed by purchasers and suppliers. Although the GAMP guide is concerned with the whole automation system development process, it contains guidance on the content of a URS document and Table 5.2 shows an example contents list from a URS that is based on the GAMP guide. Taking existing guidance and examples of requirements specifications from a number of application areas, it is possible to arrive at the main topics that should be covered in a URS. One point to remember is that within this document we need to describe what is required of the system rather than how the system should perform its functions. When considering the content of a URS you should: • • • • •

•

•

•

Provide an overview of the organisation and of its business processes. This can be the description used previously to help formulate the business objectives. Then state your strategic and operational objectives so that the supplier can understand the direction in which you are heading. Give an overview of the main functions required and the interfaces needed to the system. If you are replacing an existing system then it is helpful to describe the problems currently being experienced with that system. Describe each of your business processes as they are currently performed. These are probably best described department by department but care should be taken not to state the existing means of performing these functions as mandatory requirements of the new system. Each potential supplier needs to explain how each of those processes would be handled with their system or replaced with an alternative approach. Information systems of all types collect and generate large quantities of data. Consequently you should either specify your data security and integrity requirements or ask what facilities are available with the proposed system. Describe the interfaces required to the system. These might simply be PC-based workstations and printers but might also include time clocks, badge readers and other systems. We saw in the introduction that although ElectAM had specified details of file sizes and number of users to be supported, response times to user queries were unacceptable. It is therefore important to specify not only your capacity requirements but also your system performance expectations.

How do I decide what I need? Table 5.2 1.

2.

3.

•

•

•

•

63

Example contents of process automation system URS

Introduction 1.1 Purpose 1.2 Scope 1.3 Reference documents Overview 2.1 Background 2.2 Key objectives and benefits 2.3 Main functions and interfaces 2.3.1 System functions 2.3.2 System interfaces 2.4 Applicable regulations Operational requirements 3.1 Process operation 3.1.1 Overview 3.1.2 Recipe procedures 3.1.3 Equipment trains 3.1.4 Materials 3.2 Unit control 3.2.1 General unit control 3.2.2 Units and connections 3.2.3 Equipment modules 3.2.4 Phases 3.3 Basic controls 3.3.1 Conventions 3.3.2 Parameter defaults 3.3.3 Control modules and indicators 3.3.4 Interlocks

3.4

Data management 3.4.1 Data recording 3.4.2 Capacity 3.4.3 Data archive 3.4.4 Data security and integrity 3.4.5 Reports 3.5 Interfaces 3.5.1 I/O interface 3.5.2 Operator interface 3.5.3 Security access 3.5.4 Displays 3.5.5 Alarm management 3.5.6 System interfaces 3.6 Environment 3.6.1 Layout 3.6.2 Physical conditions 4. Constraints 4.1 Timescales and milestones 4.2 Regulatory requirements 4.3 Compatibility 4.4 Availability 4.5 Procedural constraints 4.6 Development and maintenance 4.7 Standards 5. Life-cycle 5.1 Development 5.2 Testing 5.3 Delivery 5.4 Support 6. Glossary Document amendment history

Your new system will exist in some physical environment and so it is important to provide details of the locations of equipment and the conditions associated with those locations. You are likely to want to impose a number of constraints on the supplier or on the system.These might include the compatibility of hardware and software with existing equipment, the minimum availability of service provided by the system, or standards to which the installation needs to comply. By the time you come to write the URS you will have decided how you want to manage the implementation of the new system. You should therefore describe your expectations in terms of the life cycle of the system development, covering configuration, testing, delivery and support. Finally, you will want to formally accept the system from the supplier, an act that will probably release a payment of money. It is relatively easy to check off a list of equipment and installed software packages and even the provision of user forms,

64


displays and reports. However, you started with a number of business objectives and, although some may be subjective in nature, you need to specify how you are planning to measure the success of the installation against those objectives. A suggested URS contents for an information system, covering the topics listed above, is provided in Table 5.3. As with all aspects of our discussion on information system procurement, this table is provided as a starting point from which you can develop the URS structure that best satisfies your needs.The specification phase checklist is a simple means of ensuring that all parts of the ITT and URS are allocated to particular individuals, for checking and approving as well as writing.

Table 5.3

Suggested structure for a URS

Approvals

Nothing aids commitment more than a signature. The URS should be approved by the sponsor on behalf of the board of directors and perhaps also by the managing director, depending upon the impact that the system will have on the operations of the organisation

Document amendment history

All documents issued internally or externally should be given a document reference number, a revision number and the date on which they were issued. The URS is likely to suffer a number of revisions, both before it is issued to suppliers and between being issued for bid purposes and issued to the successful vendor as part of the contract

List of contents

Just to make life easier for the reader

Introduction Purpose Scope

The purpose of this document rather than of the required system The scope of this document rather than of the required system

Overview of organisation and business processes

An outline description of the organisation and how it conducts its business. This section sets the scene for the rest of the document, and helps the reader to understand the organisational context for the system requirements

Strategic and operational objectives

A description of the high-level business objectives. Within the context of the organisation as described above, this section describes why a new system is required and what it needs to achieve

Main functions and interfaces

Having set the organisational context and the direction in which the organisation wishes to travel, we provide here an outline of the required system functions and interfaces to help the reader obtain a view of the scope of the system before getting into the detail

Problems with existing system

Users of the system will expect the limitations of any old system to be removed when a new system is installed. It is therefore useful to capture the problems that have, in part, resulted in the need for a new system


65

Operational requirements

A description of the business processes as currently performed, trying to concentrate on what the processes are intended to achieve rather than on how they are achieved. It is probably best to describe these requirements on a department by department basis

Capacity and performance

Describe in this section the physical capacity and performance requirements of the system. This includes such items as the number of concurrent users, the data storage capacity (in terms of the time and data records rather than trying to estimate the size of the storage media required) and response times to operator actions and other interfaces

Data security and integrity

Include here any requirements for transaction integrity, data backup, archive and retrieval and data security in terms of duplicate databases or secure storage devices

Interfaces

In addition to PC workstations and printers, you may require the system to interface to a number of other devices such as weighscales or barcode readers. List all such interfaces here, stating whether or not the devices are to be supplied as part of the new system, are already on site or whether specific models are required. If the specific devices are not to be proposed by the vendor then provide as much information as possible about the physical and software interfaces and the way in which the interfaces are to be used

Environment Layout

Physical conditions

Constraints Compatibility

Availability

Procedural constraints

The new system equipment is likely to be distributed around your site, and the networking may be part of the scope of supply. Even if that is not the case, equipment may need to be delivered to and installed at a number of different sites. A diagram showing cable run distances and/or a table listing equipment requirements at each location should be provided here It may be that all equipment is to be located in a normal office environment, but some equipment may be located in a warehouse, for example. Define the temperature and humidity ranges and hazardous area classification plus any other environmental parameters in this section

You may wish to use some existing equipment as part of your new system, access data that has been collected by your old system, or use an existing tool to view or analyse data. Any requirements for compatibility with other systems should be described here Your new information system is likely to be a key part of your operations and your business could be severely affected if facilities are unavailable for periods of time. Describe what is acceptable in terms of unavailability rather than trying to state how the required level of availability should be provided Moving from one system to another or from a manual set of procedures to computer-based processes can be traumatic for an organisation. Describe here any procedural constraints that might apply to the implementation process

66


Development and maintenance

Standards

Life cycle

Configuration

Testing Delivery Support

As a minimum, you will need to maintain the new system, mainly in terms of software updates and data archiving. Request details of how those processes will be provided and what support contracts are available.You are also likely to have requirements for the future expansion of the system, both in terms of additional functionality and additional users or data storage capacity. If significant future growth is anticipated then it might be worthwhile describing this in its own section of the URS List the company, national and international standards to which the installation must conform. State whether they are mandatory or desirable This section of the URS looks forward from the point of order placement to the processes involved in implementing, putting to use and supporting the new information system Define whether configuration of the system is to be performed by your own staff with support from the supplier or as part of the fixed-price contract. If the latter, include what level of support you will be providing and your expectations in terms of functional and design specifications Describe what you expect of the supplier in terms of system functional testing Describe the supplier’s responsibilities for delivery and installation of equipment and software Either define what level of support you require from the supplier or request information on available support contracts

Measures of success

Part of your contract with the supplier will be acceptance of the system, probably linked to the payment of money. These acceptance criteria will depend upon the scope of the work undertaken by the supplier but, whatever the scope, you need to make clear what measures will be used to determine acceptance. As a minimum you should include a review of the organisational and departmental objectives set out at the start of the URS

Glossary

All organisations use their own language and so it is important to make clear what you mean by the terms you use

How do the stakeholders fit into the process? In Chapter 3 we defined your stakeholders as all those people who have some interest in the information system that you are about to procure. It was also suggested that these stakeholders could be categorised into groups, and that their interest could be due to their use of the system or of some output from the system, or they had an operational, financial or business interest in the new system being viewed as a success. The boardlevel sponsor heads the steering group and links the project into the board of directors, with the steering group containing senior representatives of stakeholder groups and the core team containing operational-level representatives.


67

As we shall discuss in more detail in Chapter 8, the perceived success of the system depends upon the views of the stakeholders in these various groups, and so their involvement in the development of the requirements specification is crucial. This is where the steering group and the core team first have an impact on your procurement process by helping to capture stakeholder expectations within the URS. The URS sections on the overview of organisation and business processes, on the strategic and operational objectives and on the main functions and interfaces are primarily the domain of the steering group, whereas other sections have major input from the core team. If you recall, the core team is made up of representatives from each of the operational units that use or interface with the system. Armed with the strategic and operational objectives, these core team members can supplement their own experience with that of their colleagues and thus draft their parts of the URS. The resulting URS document is ‘owned’ by the steering group, with support by the core team for their respective sections. In summary, the URS should express the expectations of all stakeholder groups so that the supplier is clear about how the success of the system is to be assessed.

How will you know that you have got what you want? Your URS has captured the expectations of the various stakeholders in your new information system and at the end of the day the system will be judged against those expectations.We shall return to this topic in Chapter 8 but it is important to think about this when producing the URS. As someone who gets involved with the marketing of complex information systems (as well as their implementation) I am often accused of writing ‘fluffy’ prose. Certainly it would be difficult to test any system against those ‘fluffy’ marketing words, and so the style used within your URS is important. My general guidance is to separate the background explanations and scene-setting words from the specific requirements, limiting each clause, where possible, to a single requirement. For regulated industries such as pharmaceutical manufacture, where each requirement needs to be traced through functional and detailed specifications to tested items, it helps if each requirement is given a unique reference. In industries where the traceability of requirements is not mandatory it still helps if individual requirements can be easily identified, so that a simple checklist can be used to establish that every requirement has been tested. In some ways the URS is a bit of a compromise since it is used for two purposes, first as a document against which prospective suppliers can bid and second as a document on which detailed specifications and configurations will be based and the system tested. In some industries, particularly when using a fixed-price contract, the supplier is expected to produce a more detailed functional specification for approval by the purchaser, against which the system will be tested and accepted. The rationale behind this approach is that the URS deals with overall business and operational requirements whereas the functional specification details the specific functions to be provided. The role of the URS in the activity of soliciting bids and selecting a vendor is the subject of the next chapter.

68


SPECIFICATION CHECKLIST Invitation to Tender Section Introduction Terms and abbreviations Responsibilities Contract Schedule Supplier details User Requirements Specification Section Introduction Overview of organisation and business processes Strategic and operational objectives Main functions and interfaces Problems with existing system Capacity and performance Data security and integrity Interfaces Environment Constraints Life cycle Measures of success Glossary

Author

Checked by

Approved by

Author

Checked by

Approved by

Notes 1 DTI (1996) BuyIT Best Practice Guidelines, London: IT World Consultants. 2 ISPE (2002) Good Automated Manufacturing Practice, Version 4, Tampa, FL: ISPE.

CHAPTER

6 Which

package/supplier should I choose?

ELECTAM: PART 4

Vendor selection If you cast your mind back to the project schedule shown in Chapter 4 for ElectAM, you will see that there is significant scope for extending both your timescale and your budget. ElectAM had intended starting with a long list of ten potential suppliers, collecting sales material from these suppliers and then analysing that material so that they could issue their Invitation to Tender (ITT) document to the shortlisted two or three vendors. While these potential vendors were putting together their response to the ITT, ElectAM’s steering committee would visit the suppliers to see demonstrations of their software and to further discuss the organisation’s requirements. Then, using a spreadsheet with weighted scores against each of the features and capabilities listed as requirements in their ITT, they expected to select a supplier. This whole process was due to take a total of nine months and involve the steering committee on a part-time basis, since each member still had his or her normal responsibilities to fulfil. It is perhaps a sign of the times that within both the high street and the organisational purchasing arena we are presented with more and more choice. ElectAM certainly found that to be the case when looking for a replacement manufacturing computer system and, as a result, started their search with a longlist of 20 suppliers; so their initial task of filtering out the weaker candidates was twice the exercise that had been planned. However, they also found that the task was more difficult than they had expected, either due to the basic capabilities of the systems on offer or to the quality of the marketing material provided by the suppliers. Consequently, an expectation of reducing ten potential suppliers to two or three to whom the ITT would be sent became the reality of reducing 20 suppliers down to a shortlist of ten. It was to these ten suppliers that the ITT was sent and from whom a response was received. Clearly it was not a practical proposition to visit all ten suppliers, particularly as the selection process was being performed on a part-time basis. The steering committee therefore

70


completed the weighted scoring for each of the ten systems and suppliers and used that to further reduce the candidates to three. These three potential suppliers were visited and gave demonstrations of their products. Offers of visits to sites where the software was already in use were turned down by ElectAM on the basis that such installations would have been chosen to present a good impression and so might not be typical. As indicated in Chapter 4, the use of the weighted scoresheet was not sufficient to discriminate between the three candidate suppliers and so a simple list of primary business requirements, handwritten on a single sheet of paper, was used to make the final decision. The whole process had taken 14 months longer than originally planned and had consumed many more hours of effort from members of the steering committee than they could afford to spend, while still trying to hold down their normal jobs. As it happened, their choice of system and supplier led them to the point where ElectAM almost went out of business. The reasons for this cannot all be laid at the door of the vendor selection process but with hindsight we can see that some of the decisions made during vendor selection contributed to later implementation problems.

The traditional approach to vendor selection The ElectAM case study includes the main activities that are illustrated in Figure 6.1 for this phase in the generalised procurement process.We need to consider the identification of potential suppliers, the acquisition of proposals from a subset of those suppliers, and the analysis and evaluation of those proposals, resulting in the placement of an order. In previous chapters I have mentioned the BuyIT Best Practice Guidelines,1 and Guideline 6, ‘Selecting the Supplier’, is relevant to our discussion here. This guideline tends to focus on transaction processing-type information systems and so is more difficult to use for such systems as Laboratory Information Management Systems (LIMS) or factory automation systems.The BuyIT Guidelines also adopt what might be called a ‘traditional’ approach to vendor selection, which is similar to that used by ElectAM. On the subject of other available guidance, Smith2 provides useful insight into the supplier’s perspective of producing a response to a requirements specification, while Peterson and Carco3 describe ploys used by suppliers for winning business. However, here we should be more interested in finding a supplier with whom we can work and develop a mutually rewarding relationship than in treating the supplier as the enemy. Returning to the traditional approach to vendor selection, this typically involves the following steps: •

Form a selection team with enough experience to understand the business and operational requirements of the organisation and enough authority to ensure that their recommendations are accepted. In terms of the procurement organisation described in Chapter 4, this would be most, if not all, members of the core team.

Which package/supplier should I choose?

Figure 6.1

•

•

•

•

•

•

•

71

The procurement process – vendor selection and negotiation

Define the process steps that are appropriate to the type of information system that you are buying and to your organisation. Most of the following points fall within the process steps of the traditional approach. Trawl the Internet, trade journals and published directories for potential suppliers. You may have the opportunity to visit a trade show or be able to ask associates from other, similar companies via trade or professional bodies. With the information available from web sites and advertisements, generate a long-list of potential suppliers, having first defined any criteria that might include or exclude a supplier on or from the list. Define the information required from each supplier on the long-list, such as trading statements, reference installations, implementation capability and product features. Request this information from each of the suppliers on the long-list. Define the criteria to be used to reduce the long-list to a shortlist of two or three suppliers and apply those criteria to the long-list of suppliers. You will almost certainly want the supplier to have recent experience of your type of business but, depending upon your preferred approach to implementation, you may also want them to have experienced project management and configuration resource. Issue the ITT and the URS to the selected shortlisted suppliers, including instructions on how they should respond. For example, comparisons between proposals will be easier if the supplier’s standard literature is supplemented by a response to each section of your URS. Decide upon the criteria that your selection team will use to evaluate both the written proposal to your ITT and the visit that your team will make to each supplier. Some of these criteria will be subjective but can be rated on a three- or five-point scale. Arrange visits to the offices of the shortlisted suppliers to see demonstrations of their proposed software and to meet with those likely to be involved with your project if they were to be successful. Ensure that the software will be demonstrated on the same hardware that would be supplied to you and that the functions that are most

72

• • • •


important to you are included. Also take along a set of questions that are specific to your organisation and your business problems. Arrange to visit a current user of the hardware and software platform who operates in a similar industry or has similar requirements. Evaluate the proposals from the shortlisted suppliers and the result of your visits using the criteria defined above. If a strong candidate does not emerge from the evaluation then try eliminating one vendor at a time to arrive at a preferred supplier. Meet with the selected supplier to tie down the scope of supply and other contract details such as payment schedules and performance guarantees.

The above may appear to be a protracted process. However, some guidance, such as that from the BuyIT Guidelines, includes another level, introducing a ‘shorter’ list to which to send the URS and obtaining a technical response before selecting two or three potential suppliers to receive the ITT.

Problems and considerations It should be clear by now that selecting a vendor for the supply of an information system is not a trivial matter, but the traditional approach outlined above may present some particular problems for small to medium-sized organisations. For example: •

•

•

•

There is a significant amount of work involved in evaluating a proposal from a supplier. Experience gained from others who have been through the exercise has already suggested that the selection team should be assigned to the task on a full-time basis. Even so, every additional proposal examined adds significantly to the elapsed time and the total effort expended. We concluded in Chapter 4 that the whole purchasing phase of the procurement should be kept as compact as possible to maintain the momentum of the project. Try to avoid the mistake made by ElectAM and keep both the long and shortlists to a manageable size. An idea of what it is likely to cost is not produced until near the end unless a ‘typical’ configuration is specified to each supplier on the long-list, against which they should provide a budgetary price. A ‘typical’ configuration should only include an outline of the main facilities that will be required, and not full extracts from your URS. However, if this approach is adopted then you must remember that a supplier will not want even an outline price to be viewed as expensive. If you are a small to medium-sized organisation then there is unlikely to be much experience within your organisation of the negotiation of contracts for high-value, one-off systems that include a combination of equipment, software packages and services. If you are unfamiliar with payment schedules and performance guarantees then hire someone who is, even if only for the duration of the procurement. As ElectAM found, it is easier to differentiate suppliers on the features of their products than on intangibles such as the level of future support they are likely to


•

73

provide. Also, more mature products tend to have very similar features and so a lot of effort rating all the features and attributes can leave you without a decision. Supplier responses are likely to put a great deal of emphasis on the technology they offer to help solve your problems, so when trying to evaluate offerings from different suppliers it is easy to concentrate on product features and put too little emphasis on how the business benefits will be achieved.

The above listing of some of the problems associated with the traditional approach to vendor selection highlighted some particular considerations. It is worth listing these considerations in a little more detail since they come up time and time again within the information systems literature: •

•

•

•

•

Price should never be the most important criterion in your selection process. As with most things, you tend to get what you pay for and whereas one hardware and operating system platform may be cheaper than another, it probably comes at the expense of performance and/or reliability. Within the area of service provision the effect can be even more marked. It is often observed that a good engineer can be an order of magnitude more efficient than an average engineer. Within the marketing hype and the sheer quantity of information with which you will be bombarded it is easy to forget that you will stand a much better chance of implementing a successful project if the supplier’s staff have experience of your industry. Most suppliers will have implemented systems in a range of industries and so will have staff with varying degrees of experience. After establishing that they have knowledge of your type of business, try to obtain a commitment from the supplier that the staff used for your project will have relevant experience. If the members of your selection team do not have experience of purchasing an information system then bring into the organisation one or more people who do have that experience, particularly in the area of contract negotiation. Of course, suppliers will provide reference sites where they hope the user will give a good account of the supplier and the system. However, if they cannot provide at least one reference site where the software being offered to you is being used in an industry that is directly relevant to your business then be very cautious, to the extent of eliminating them from your list. It is very easy to get over-involved in the technology that is being offered, therefore include some technology sceptics on your selection team. Our learning from many case studies is that an overemphasis on technology at the expense of business requirements can seriously damage the health of your project.

A risky business Clearly the vendor selection process is both time- and effort-consuming, yet is vital to the success of your project. As with most business processes it is therefore necessary to strike the right balance between cost and risk. That is, the costs associated not only with

74


the time spent by your team on the selection process but also the effect on your business of delaying the introduction of enhanced business processes, and the risk of buying a system that does not meet your business needs. A large organisation that purchases many systems for use around its operating units can develop a long-term relationship with one or more suppliers and so can circumnavigate the vendor selection process, significantly reducing its purchasing costs. Such a strategy is, however, not available to the average small or medium-sized business that will perhaps only buy a new information system once in five years. Consequently we must look for ways in which the effort expended on vendor selection can be minimised while the risk is still contained to acceptable levels. Evidence suggests that there are no risk-free ways of procuring information systems and so it is imperative that you identify the risks, assess their impact on your business and then define a strategy to either mitigate or manage each risk. The risks associated with the procurement of an information system vary from one organisation to another and from one application to another. At the generic level, however, typical risks include: •

•

•

•

Failure to fully satisfy your business needs. One organisation decided that one of the primary requirements of their new system was to provide a ‘what if’ facility so that they could look ahead at production capability under different conditions such as taking a new, urgent order and inserting it into the schedule. Six months after the new system went live this facility was still not available since the third-party software did not work with the new release of the base software package they had installed. Ensuring that the selected supplier uses staff with recent experience of your type of business and that they are made aware of your business requirements can help mitigate against this type of risk. Not providing the performance required to carry out day-to-day operations. I have already described how the new ERP system installed by ElectAM initially caused them to wait up to 15 minutes for a response to an operator request. This is just one example of where we expect modern technology and an experienced supplier to provide adequate system performance levels without us needing to explicitly request them. Clearly specifying your system performance expectations in your URS and getting potential suppliers to explain how they intend to deliver the required performance levels will help mitigate against this risk. Overrunning both the time schedule and the budget. Usually an extension in time results in a commensurate increase in cost. This is due both to the extra time that people need to spend on the project and the delay in providing business improvements. Managing and mitigating risks associated with time and cost generally result from actions taken with regard to other areas of risk. For example, if system and operational performance expectations are clearly defined and tests are performed early in the system development then overruns due to rectifying performance problems can be avoided. Failure to integrate the new information system with existing or proposed systems and equipment. Very few information systems operate in isolation, needing to collect data from equipment such as time clocks or analysers, receive instructions from business systems such as production schedules and pass data to other systems such as a warehouse stock control system or a spreadsheet on the finance director’s PC. Again


•

•

•

75

it is a question of including your requirements in the URS and asking prospective suppliers to describe how they will institute these interfaces. Getting carried away with the technology of the solution at the expense of the business objectives. Many people find new technology interesting and absorbing and suppliers play on that fact by promoting the technology of their systems. From a functionality point of view most comparable systems offer very similar facilities and so suppliers, looking to differentiate themselves from their competition, market their use of the latest and greatest technology. Sometimes business benefits can result from the use of one technology rather than another. For example, an information system that provides ODBC access to its database is likely to provide more flexible interface options than one using a proprietary interface. Similarly, a system that allows a choice of commercial off-the-shelf database management packages to be used might mean that a package already in use elsewhere in the organisation could be used. This risk needs to be managed by ensuring that the selection team is not dominated by those with a technology bent and by insisting on demonstrations of the precise technology to be delivered, together with visits to reference sites using that technology. If there appears to be a real benefit to using a new product, for example, then build safeguards into the contract such that the supplier takes responsibility for the delivery and performance of the technology early enough for any problems to be rectified or a backup option pursued. The high cost of ongoing maintenance and the lack of future support. You may recall that PowerSound discovered, too late, that maintaining the software release level of their new ERP system was a full-time activity for one member of IT support staff. This may not have altered their decision to select that supplier but it did affect the payback period of the investment. Similarly, if the supplier sub-contracts the configuration of your system to a third party then you suddenly have to deal with two companies for support, one for the base software and another for the application. Mitigating against such risks involves requesting within your ITT details of the support conditions, costs and how the proposed support is to be delivered. Poor user acceptance of the new system and of the required change to business processes. Since we are considering the vendor selection process, we have been concentrating on areas of risk that can be managed during that process. We need to remember, however, that risks exist within our own organisations and acceptance of the new system by the various stakeholders is just one of them. The system can be installed on time and within budget and provide the required functionality, but if users are unhappy with it or the implementation process then the whole exercise could be viewed as a disaster. I talked in Chapter 3 about stakeholders and we looked at a procurement organisation involving a steering group and a core team that was partly aimed at involving all stakeholder groups in the purchasing and implementation processes. These topics will also be discussed in the next two chapters, but you must remember that areas of risk can be internal to your organisation as well as external.

The first part of the vendor selection checklist at the end of this chapter allows you to record the fact that a risk assessment has been performed, and by whom.

76


An alternative approach to selecting a vendor The problems associated with the traditional vendor selection process, the considerations and risks evident with this process and experiences of those who have been through the process before us can all combine to suggest a more pragmatic and effective approach.You need to bear in mind, however, that there is no generalised ‘right’ way of tackling the process of vendor selection. My aim in this book is to provide alternative views of the problem so that you can make a more informed judgement of what is best for your particular situation. An alternative approach to the vendor selection process consists of the following steps: 1.

2.

3.

4.

5.

6.

7.

Identify who will be responsible for each of the steps listed below. I talked earlier of forming a steering group and a core team. The first step in the suggested approach is to assign responsibilities to members of these two groups. Generate a list of potential suppliers. As for the traditional approach, there is the need to start with a list of suppliers that might be able to provide the range of products and services that you will need. Trawl the Internet, trade journals and published directories for potential suppliers and use whatever information is available to form your long-list. Try to keep this to no more than ten potential suppliers. Using your ITT and URS documents, generate a short-form version that lists your major requirements, both of the supplier as an organisation and of the capability of the product or products. Organise this short-form specification so that responses can be written in beside each requirement. This short-form requirements specification should be approved by the same people who approved the ITT and URS. Use one or two members of your core team to perform telephone interviews with each of the potential suppliers. Expect to take about one hour on each interview, perhaps spread over two or three calls and perhaps speaking to different people in the supplier organisation. During the interview, work through each of the items on your short-form requirements specification and write in the responses given. Once you have been through the list it is worthwhile reading back your notes to check that your interpretation of the response is correct. Define the criteria to be used to review each of the responses from the telephone interviews. It is important to be consistent and to be able to justify your decisions and having a set of written criteria helps in both cases. This set of criteria should be reviewed by the members of the core team. From your analysis of the interview responses select the most likely supplier. That is, the one that has experience in your industry, appears to be able to provide the features you need, can provide the implementation and support services required and is a stable and successful organisation. This is an activity for the core team but the decision needs to be ratified by the steering group. Issue the ITT and the URS to the selected supplier. Don’t tell this supplier that they are the only candidate currently being considered.


77

8. Decide upon the criteria that your selection team will use to evaluate both the written proposal to your ITT and the visit that your team will make to the supplier. This will be an expanded form of the selection criteria used for evaluating the interview responses and again should be generated by the core team as a whole. 9. Arrange a visit to the offices of the supplier for in-depth demonstrations of the system and hear how they intend to meet your requirements. Again, arrange to meet with those likely to be involved with your project if the supplier were to be successful, and ensure that the software will be demonstrated on the same hardware that would be supplied to you. Also check that the functions that are most important to you are included, and go along armed with a set of questions specific to your organisation and your business problems. 10. Again as for the traditional approach, arrange to visit a current user of the hardware and software platform who operates in a similar industry or has similar requirements. 11. Evaluate the proposal from the supplier and the result of your visit using the criteria defined above. If there is a ‘show-stopper’ with this supplier then this is the time to go to the next most likely supplier from your evaluated interviews and repeat the above few steps. 12. The final step is to meet again with the selected supplier to tie down the scope of supply and other contract details such as payment schedules and performance guarantees. The main advantage that this process has over the traditional approach is that it puts most of your effort into reviewing the most likely candidate. If you need to look in more detail at a second or third candidate then you have not expended any more effort than you would have otherwise done, although the time elapsed might be a little longer. You will notice that there has been no mention of price in the above discussion. In a competitive marketplace it is likely that there will be little difference between suppliers, and it is more important to get what you need than to save a few pounds.To some extent this lack of emphasis on price requires a leap of faith on your part and if you include people from purchasing in your core team then you might come up against stiff opposition. The point to remember is that, even though suppliers like to market their wares as commodity items and therefore of low risk, you are purchasing a complex combination of hardware, software and services and your system, in spite of its COTS origins, will be unique. The main aims of this alternative approach to the vendor selection process are to maintain control over that process, minimise the effort expended on the process and maintain the overall momentum of the new information system project while containing the risk inherent in the selection of a system and supplier. The extent to which this approach can help achieve these aims is illustrated in Figure 6.2 where a comparison is made between the traditional and suggested alternative vendor selection processes. In addition to the reduced number of steps, the alternative approach includes repetition only at the long-list telephone interview step, which is significantly less demanding than the repeated full proposal evaluations that are part of the traditional approach. At the same time, a full evaluation of the selected supplier’s proposal still takes place,

78


Figure 6.2

Comparison of traditional and alternative vendor selection processes

minimising both effort and risk. Both the responsibilities for the steps in the vendor selection process and the results of each step can be recorded in the vendor selection checklist.

Notes 1 DTI (1996) BuyIT Best Practice Guidelines, London: IT World Consultants. 2 Smith, J. M. (2001) Troubled IT Projects, Prevention and Turnaround, IEE Professional Applications of Computing Series; no. 3, Stevenage: IEE. 3 Peterson, B. L. and Carco, D. M. (1998) The Smart Way to Buy Information Technology: How to Maximize Value and Avoid Costly Pitfalls, New York, NY: AMACOM.


VENDOR SELECTION CHECKLIST Risk assessment Reference

By whom

Produced Reviewed Approved Responsibilities Step Establish long-list Generate short-form requirements Telephone interviews Criteria for review of interview responses Selection of most likely supplier Issue Invitation to Tender Criteria for evaluation of proposal Proposal evaluation Contract negotiation Vendor selection process steps Step Establish long-list Generate short-form requirements Telephone interviews Criteria for review of interview responses Selection of most likely supplier Issue Invitation to Tender Criteria for evaluation of proposal Visit supplier for demonstrations Reference site visit Proposal evaluation Contract negotiation

Who

Result/Reference

79


CHAPTER

7 How do I manage

the implementation?

It is often thought that implementation of a computer-based system is all about project management and keeping tight control over the tasks being performed. It certainly seems to be the case that when things start going wrong then attempts are made to tighten the control over those performing the work, applying more and more ‘hard-hat’ management to the problem. It rarely seems to work. The building of software-based systems is often compared with the building of a bridge. It is said that when constructing a bridge from point A to point B then the positions of both A and B are known. However, when constructing software to take you from point A to point B then no one can agree on the location of A and you know that B will move before you get there. This analogy is applied to the development of software systems whereas we are concerned with the configuration of packaged software, so the developers of that software will have sorted out their A and their B. However, we’ve seen that a configurable package is really just a tool-set that we need to apply to our own problem and which will involve a number of people and many hours of work to realise our stakeholders’ expectations. In other words, the end point is still difficult to tie down. Consequently I will not refer in this chapter to any books on project management, which tend to be more related to the ‘hard-hat’ approach, but refer only to the findings from real-life case studies. Chapter 4 looked at the management of the purchasing phase of an information system procurement, taking an organisational approach that has proved to be of use to those who have already been through the process. That organisation included a steering group, with the project sponsor forming the link to the board of directors, and a core team, where the project manager made the link back to the steering group. Both assemblies of people have been prominent in subsequent sections on producing a User Requirements Specification and using that, along with the Invitation to Tender, to help select a system and a supplier. The culmination of our work so far is the signing of a contract with the selected supplier, or of a range of contracts if hardware, packaged software and implementation services are to be purchased from different suppliers. Much of the available literature on information systems either treats the order as its goal or as its starting point. Consequently we are striving to view the procurement process as a whole and to set within the purchase phase a firm foundation for the implementation. Our aim all along has been to prevent the euphoria of the purchase from becoming the despondency of an over-time, over-budget and underperforming project. So, the order has been placed and members of the steering group and the core team can justifiably celebrate. The supplier will be celebrating too, but for all members of the project the hard work is just about to start. Here we shall consider the implementation

82


Figure 7.1

The procurement process – system implementation

phase of your information system procurement, as illustrated in Figure 7.1. However, before we delve into the implementation process it is instructive to look at the experience of CSM who, after a protracted and at times acrimonious purchase phase, embarked upon the implementation of their chosen system.

CASE STUDY: CSM

An ERP system implementation Until now my case studies have tended to highlight the difficulties that organisations have experienced on their quest for business improvements using information systems. CSM, however, achieved a successful implementation of a new ERP system only two months behind their planned time schedule of 12 months. To help put this implementation into context, it should be said that the system was implemented by an organisation that manufactures complex mechanical structures from a mixture of familiar, exotic and composite materials. These complex structures are assembled from bought-in components and the specialist components manufactured on site, and so the business combines conventional fabrication and detailed manufacturing facilities with precision measurement, material treatment and testing facilities. The manufacturing process is characterised in terms of there being only a few complex products (measured in tens), all of which are very different. The manufacturing process also needs to cope with many changes. In fact one person commented that the company does not like to make two products the same, a very different situation to the mass production of the other case studies. It is also a larger organisation than the others, requiring a manufacturing computer system made up of a large database

How do I manage the implementation?

server and two client terminal servers, supporting approximately 700 PCs, 100 clocks for time recording and 100 printers. At the time of going live, the ERP system was thought to be the largest installation of that particular software package in Europe. During the system and vendor selection process CSM was not impressed with the project management experience of any of the suppliers. Consequently they decided to manage the project themselves, employing consultants from a company independent of the software supplier to provide them with technical training and guidance. Prior to the vendor selection, a steering group had been established and the IT manager was appointed to be the project manager for the new system. To progress the implementation a core team was set up consisting of a representative from each functional area together with the systems manager and led by the IT manager. All members were to concentrate full-time on the implementation project. The role of the core team was to learn the details of the new system, to implement the areas that were their speciality and to train the super-users. At this stage the steering group monitored progress, but was criticised for not providing enough feedback and often leaving the project manager to make decisions on his own without him knowing if they are right for the business. Although the project management approach was described as being fairly ad hoc, taking place through interactions between core team members on a daily basis, there was a general project plan and a more detailed ‘go-live’ plan. During the design phase, a period of about seven months, two consultants were on site for two days each week. One consultant was a financial specialist and the other a manufacturing specialist and, as indicated above, both were employed from a consultancy separate from the ERP system supplier. The implementation phase of the process involved the following steps, some of which were executed in parallel: • • • • •

core team training; training of the super-users; development of training material; prototyping and testing of each part of the system; and loading real data and taking the system live.

The 20-strong core team spent six weeks on a cut-down version of the supplier’s standard training course, given by the consultants. This was in practice a series of slide presentations and described by one member of the core team as a ‘slow and painful death’. Another person said that it gave an awareness of the system but described the presentation of the course as ‘rubbish’. There was then a need for additional days spent training on other modules. Consolidation training followed this by attempting to use the system and by asking questions of the consultants as needed. During the implementation period 15 super-users were identified. These were based in each of the operational areas and were charged with helping to prepare

83

84


training material and with delivering the training to people in their own areas. Like the core team, the super-users worked full-time on the ERP system for the period of time required for this activity, a total of about six months. They spent the first month documenting the project, the next two months producing training material, and then three months delivering the training. Six training rooms were in use full time for this three-month period. During the preparation period the super-users would spend half of each day being trained by the core team and the other half preparing training material. Every transaction was documented with screenshots using a slide presentation package and these remained available on the system as a form of online help. At least one area of the organisation that was on the receiving end of the super-user-delivered training thought that it was very good, with plenty of hands-on experience. The core team and the super-users gained most of their experience with the system via hands-on trial and error, requesting help from the consultants as required. One criticism voiced was that real data was not actually available until the system went live. The core team, during their hands-on training and familiarisation, undertook testing of the system. Each of the processes handled by the new system was signed off, with a feedback form recording any problems that needed to be resolved. During the implementation of the system most areas had daily meetings on problems and opportunities so that people were involved on a continual basis. There was a general acceptance that they would need to adapt to the way the system worked, not the other way around. Finally, tasks were tested by end line managers with documents being produced detailing the tests. Eight months after the installation of the servers they were still putting ‘fixes’ in place; not all users had been trained properly; they had not done a full data load; and none of the clocks were installed. However, a month later they did a dummy go-live during which they identified some weak areas which were then put right. Two months after that they decided that the system was ready for the product support areas of the organisation, so those groups went live first. Also at that time they did another simulated go-live for the manufacturing area, but this time with real users. The site finally went live 12 months after the equipment installation, over a bank holiday weekend, although the project manager said that they were still struggling to use the system for the next month. As much of the training had been about changes in the business processes as about how to use the new system, the changes introduced, it was said, were aimed at solving root problems in the processes rather than in the system. For example, they had a constant problem with shortages. The old ERP system would load a job, saying that all materials were in stores, but the people on the shop floor would then discover that the material in stores was not of the right type. The old system allowed them to cope with this via manual replacement but this meant that the Bill of Materials (BOM) for each product was never correct. The new system would not allow manual modification of the Bill of Materials and so introduced the necessary level of discipline into the production process. The


85

system was also described as being incredibly flexible and the implementation team could now see its full capability. Initially they had seen things as potential ‘show-stoppers’ but later could see that a small change elsewhere would solve the problem. The IT manager thought that at the start of the procurement process they had a tendency to look at the details of how things were done at that time. He commented that ‘failure occurs when trying to achieve a very detailed specification; success when trying to achieve overall business targets’. He also said that the User Functional Requirements document (their equivalent to a URS) had concentrated too much on the detail, and described it as ‘not adding value’. The people at CSM now have information when they want it, rather than the week-old data provided by their old system. However, not all expectations had been met. For example, one of the original requirements was for a work-flow facility, that is, a mechanism such as using e-mail to tell an individual that everything was ready for the next task to be started. However, that was not part of the base system and so was not available. They had also hoped to move to a paperless operation, but one month after going live with the new system they were producing more printed matter than ever before. Looking back at the implementation process, the organisation was aware of specific mistakes that they had made such as: • • •

Data clean-up was not done sufficiently before going live, causing a lot of glitches during the first days of running the new system. Not enough people were put in to support the core team (that is, not enough super-users). This put heavy pressure on core team members. There were time pressures on people during the training period prior to going live. This meant that people did not have the experience that they needed at the go-live date.

The project manager also looked back, but this time at the way that the project team interacted with the business. His view of how a project needs to interact with the business is illustrated in the timeline shown in Figure 7.2. In other words, the project needs to present something to the business, get feedback, go away and work on that feedback, present the results to the business, get feedback, and so on. In his view it is just as dangerous to involve the business all of the time as it is to not involve it at all. Overall, the members of the project team thought that they had learnt the following lessons from the implementation exercise: 1. 2. 3.

Concentrate on what you do; that is, on the business objectives, not on the system. Clarify the project objectives right from the start and make sure that everyone is aware of them. The implementation team is crucial. Select people who can work together and are ‘forward looking’ users.

86


Figure 7.2

Project team interaction with the organisation

4. It is important to clarify all responsibilities. 5. The role of the steering group needs to be established, and someone needs to manage the tensions between the project and the steering group. 6. It is good to do the training yourself rather than leave it to the supplier/consultant.This way you get what you need rather than what someone else thinks you need. 7. It is important to have documented acceptance criteria for each part of the application implementation. 8. Communications should be ‘with anyone and everyone’. An example of this was the ‘awareness boards’ that were positioned in the entrance to every building. 9. Tackle the implementation in bite-sized chunks. 10. Make sure that the project is managed. They tried using a relatively junior person to manage the project, but that did not work. A senior person with a strong personality is needed. 11. It is important to document the plans. This needs a narrative for each activity and you must measure the activities by their outcome. Also, milestones need to be set. 12. Supplier partners and consultants do not bring project management. The IT manager’s experience was that project management is weak in these companies. He believed that you need to define what you want from them and then try to ensure continuity of personnel. They were lucky in that they had continuity all the way through and a good relationship. 13. Keep the contractual relationship with the supplier separate from the technical relationship. The former can be with the salesperson or project manager and the latter with the consultants. 14. The project needs to be flexible and to bend with the business needs.Therefore control, in the form of project management, by the supplier is not viable. 15. It would have helped to have established a higher level of business involvement alongside the project, for example by using more forums.


87

16. Avoid detail. Get the supplier to produce product specifications. Most big systems can do the basics, but something will always be missed. The project manager said that you need to make a leap of faith. However, you always need to keep the overall objectives in mind.

What we can learn from this, and other, case studies Within the above case study we have a list, in no particular order, of what the core team at CSM learnt from their ERP implementation process. Let us now look at this and other cases and describe some of the more generic aspects that can be learnt about the configurable information system implementation process.

BUSINESS NEEDS In the section in Chapter 5 on specifying your requirements for an information system I emphasised the need to define the main requirements of your business and how you expect a new system to help meet those needs. Basically, if you cannot specify how a new information system will help meet the needs of your business then you are probably better off keeping your existing system. When we moved on to the system and vendor selection process, we again found evidence from our case studies to suggest that we would be better served if the selection process concentrated on how the system/supplier could help meet our business objectives. Getting bogged down in how our existing business processes could be implemented in a new system would only serve to perpetuate our out-of-date practices and prevent us from finding a system that would move us forward in the use of industry best practice. We now find that this theme has followed us through into the system implementation phase of our procurement. It may be difficult in the heat of the project to pull back from the detail and think about your overall business objectives. However, to frequently remind everyone in the core team about the overall aims and objectives of the project in terms of business strategy and goals will help them to make informed decisions about the design of their part of the application. Also, if you are using consultants to help train staff and guide them during the implementation, then their thoughts on implementation issues need to be kept in line with your business objectives. After all, they should be experts in the system capabilities and options, and should have an understanding of your type of industry, but they will need to be educated in your specific business needs.

BUSINESS PROCESSES Current thinking in terms of the way that organisations should operate, whether in the realm of manufacturing, service provision or banking, is likely to be some way removed from the way that you now operate. Similarly, the way you operate now is probably very different to the way your organisation was run a decade ago. It is also the case that suppliers of packaged software systems need to provide support for the latest business

88


process designs so that they can compete in the marketplace. As you move from your old system to a current package so you have the opportunity to overhaul your business processes and implement what is now thought to be best practice. In some areas such as plant and process automation, international and industry standards are now available for such areas as interfaces to intelligent field instruments (such as temperature and pressure transmitters), for data access and for the modelling of batch production processes. Modern configurable packaged software systems and their associated hardware now provide support for these standards, unlocking potential for ease of maintenance and improved asset management. Throughout the computing world the human–machine interface has undergone significant improvement over recent years, resulting in configuration tools and operational facilities that are much easier to use. As a result of all this work being done by suppliers of packaged systems, you have the opportunity to change the way that you do things to reap the benefit of new methodologies. In fact, it could be positively dangerous to try to implement existing business processes on a system that is not really designed to operate in that way. As CSM found, making small changes to one part of the configured system allowed a business requirement to be satisfied, even though the former way of coping with the requirement was not directly available. I’ve never been an advocate of trying to completely reengineer a business in one go, since you stand more chance of successfully implementing incremental change in an organisation. We all know how difficult it is to introduce change, but evidence from case studies suggests that a new information system can be used as a catalyst for change in certain areas of the business.

MANAGEMENT OF THE PROJECT I talked earlier of the inappropriateness of ‘hard-hat’ project management to the type of project that is our concern in this book. Consequently I prefer to talk about the management of the project rather than project management, and would advocate the use of a spreadsheet package for the production of simple Gantt charts rather than the use of one of the planning software packages. Of the three case studies that have been described up to now, one company thought that the implementation project was being managed by the supplier and the other two chose to manage the projects themselves. In that one case, however, the supplier appeared to believe that they were simply managing the training courses and then supply consultancy effort to assist with the implementation. The purchasing organisation’s mistake was not to have a clear definition of responsibilities for the management of the project in its entirety. It is very easy, during the vendor selection process, to get carried away with the technology and its application to your business processes and to pay too little attention to how the implementation is to be managed. However, just as risk assessment is part of the purchasing phase of the procurement, so risk management in terms of resource availability, business continuity and the introduction of change also needs to be considered. The management of stakeholder expectations is a subject that we will discuss shortly, but we can summarise the findings from our case studies with regard to managing the project as follows:


•

•

•

89

Ensure that the responsibilities for the management of the implementation are defined during the contract negotiation. If your chosen supplier does not have people with proven experience of managing this type of project and you do not have such people either, then employ someone to take on the job. We decided earlier that buying an information system was unlikely to have been an activity undertaken by anyone in your purchasing department and so specialist experience and knowledge might need to be hired. The same is true for the implementation phase. Managing the implementation of an information system is not like managing the installation of a piece of equipment with well-defined functionality and of limited impact within the organisation. Keep your project planning, monitoring and reporting simple. A project plan showing the feasibility of the project within a defined timeframe and against which progress can be monitored is an essential tool in a project manager’s armoury. However, people tend to get carried away with the wizardry of PC-based planning packages and before long you find that they have taken over your life. The activities associated with information system implementation are messy. They are difficult to define, overlap with one another and involve iterative elements rather than being serial or having easily defined dependencies. Consequently, trying to define the process in fine detail is only going to take up your time and add little value. Trying to keep such a plan upto-date often becomes a full-time job and doesn’t help with your management task. A simple Gantt chart showing the major activities and milestones and a table of resources required against time, produced using a spreadsheet package, provides a simple tool for monitoring progress and producing reports for the steering group. It is also another PC software package that you do not need to learn. Monitor the deliverables of each activity, not someone’s view of the percentage that a task is complete. One of the problems with using a planning package is its emphasis on manhours required and expended. It becomes very easy to spend all your time looking at the use of resources rather than at the output of the activities on your plan. Consequently, try to ensure that the person performing the task has the correct understanding of the required deliverable and what is meant by the deliverable being complete. The person producing a data entry form might think that making the new form available on the system is enough. Your view, however, might be that a procedure describing how to use the form should have been built into the online help, and the form and procedure tested by an end user.

COMMERCIAL MANAGEMENT Chapter 4 looked at some of the contract types that could be used for the purchase of an information system and by the time that you reach the implementation phase of the procurement you have, by definition, entered into a contract with one or more suppliers. I talked primarily of time and materials based contracts, fixed price contracts or some combination of the two as being the most usual for small to medium-sized organisations to use for this type of purchase. Whether or not the implementation is being managed by you or by the vendor, however, the commercial aspects of the contract need to be managed from your side. Whenever the supplier feels that a payment is due then an

90


invoice will arrive on your desk. You need to be in a position to know if that invoice is justified or not and, unlike buying a piece of equipment, it may not be obvious that the conditions that apply to the payment have been met. For example, if you have negotiated stage payments then the deliverables or milestones related to the invoice must have been completed. With the supply of complex functionality there might still be some outstanding problems and so the risk associated with those problems needs to be assessed. Just to complicate matters further, some of the functionality may not have been supplied because your team has not been able to provide the information needed for the supplier to complete the work. However, the supplier will want to maintain their cash flow and want payment for the work that has been completed. Also in Chapter 4, I suggested including a contingency in your budget since it is common with all types of information systems for variations in the scope of supply to occur during the implementation period. These variations could be additional equipment, additional or changed functionality, or extensions to the timescale due to lack of information or scheduling conflicts with other business activities. A change in contract value will affect all payments, even stage payments that have already passed, requiring future sums to be adjusted. Most changes also incur a time extension that might be important if you have included penalty clauses for late delivery in your contract. People in your purchasing department will have some knowledge of contract law but are unlikely to have experience of forms of contract used for information system purchase or of the considerations necessary to determine if a payment is justified. If your project manager does not have experience of contracts of this type and you have not hired someone with that experience then at least make use of the knowledge of people in your purchasing department.

TRAINING Again in Chapter 4 we identified from our case studies that the process of evaluating system capability is a difficult one. Those who have been through the process found that they were not really aware of what could be done with the system until they came to try doing it. To help gain a better understanding of the capability of a packaged software system I suggested, first, to limit the effort required by concentrating on the most likely candidate and, second, to give the selection team some basic training in the system. Now that the selection decision has been made you must apply the chosen system to your business. You also need to adjust your business processes to fit the methods supported by your new system rather than try to bend the system to fit your existing way of working. In order to achieve this your core team needs to be trained on the system capabilities and on how to apply it to your situation. Most people find that it is not until they try to explain something to another person that they realise the gaps in their own understanding of the topic. The members of your core team are the people who need to have sufficient understanding of the capabilities of the new system to be able to apply it. It therefore makes sense for these core team members to train others in the use of the new information system while they are looking at how the system should be applied. Following CSM’s lead, the core team should


91

receive the standard course modules that are appropriate to their part in the project and then provide training to the super-users on the relevant functional business processes. The core team then converts the generalised content of the standard courses into the specific needs of your organisation and trains those who are to be responsible for training the rest of the organisation. The same principle is applied to the super-users in that by preparing training material for their department or function they reinforce their own understanding of the new system. As CSM found, training is a significant activity in terms of the amount of effort required for preparation and to train system users. The result of the supplier training the core team, the core team training super-users and super-users training the rest of the users is that each functional area then has two people experienced in the use of the new system who can provide first-line support to all staff.

COMMUNICATION There is a great deal of evidence to suggest that many of the problems encountered during the implementation phase of an information system are due to lack of communication in some form. I suggested earlier that management of the project should be kept simple, but management of a team of people is far from simple. This might at first sound like a contradiction and therefore needs a little explanation. ‘Hard-hat’ project management is all about scheduling activities; managing an information system project is all about communication. In the next section I will talk about one very important aspect of that communication process but, in general, you must try to ensure that everyone involved in the project has the same understanding of the requirements, the approach to realising those requirements and the deliverables expected from them. People also like to feel that they are being kept informed about the business in general, other areas of the project that they do not see on a day-to-day basis, and on the effect of their input to the project in particular. Even telling them that there is nothing to report on a particular topic avoids making them feel they are being left out. Management of the project therefore involves the use of simple planning and monitoring tools but also an awful lot of talking to people. Other techniques can also be used to add legitimacy to the spoken word. For example, CSM put up awareness boards in the entrance of each building, specifically for information associated with the project. These boards were updated weekly with lists of tasks completed, targets for the coming weeks and an overview of the whole project status. The occasional cartoon from an artistic member of the team also helped to lighten a serious and important subject.

The management of expectations Research1 has suggested that the chance of achieving a successful implementation of a complex system, such as those we are considering here, is enhanced if the expectations of all the stakeholders are positively managed. I first introduced the concept of managing stakeholder expectations in Chapter 3 when considering who should be involved in the procurement exercise. The topic became a little more concrete in Chapter 5 when the

92


capture of stakeholder expectations was included in our discussion of the User Requirements Specification. Now we come to the part where we try to ensure that all stakeholder expectations are met. You will have internal stakeholders from the board of directors, through users in sales, design, production and distribution, on to those charged with keeping the system up and running. Your supplier is one external stakeholder, and you might have others such as an environmental health department or the Inland Revenue. From a business process point of view you will have captured the expectations of your internal stakeholders but there are other expectations that you need to consider.The expectations that will not have been captured in your URS will be those associated with people’s personal agendas. For example, there might be a production scheduler who sees the new system as providing a route for a career move or a shift supervisor looking to demonstrate his or her capability for promotion to production planner. Communication with anyone and everyone is the best tool you can use to identify undocumented expectations, identify how recorded expectations might be changing and get feedback on perceptions of how well expectations are being met. It is likely that individuals’ expectations will change with time and almost certain that some people’s expectations will be unrealistic. By constantly reviewing the expectations of your stakeholders you can define the actions needed to help meet them and to help realign their thoughts towards what can be achieved.You can also ensure that your stakeholders are made aware that their expectations have been realised by publicising or demonstrating the fact. Collecting feedback from stakeholders on how well their expectations have been met also allows you to form an impression of how successful the system is judged as being; this is the topic of the next chapter. I said that the management of a project was far from simple! However, the implementation checklist opposite provides a set of headings that cover the main topics we have been discussing and provides you with a form that can be adapted to your own needs.

Note 1 James, D. E. (2001) Buying Complex Systems: Purchase Process Influences on Implementation Success, PhD thesis, Brighton, UK: University of Brighton.


93

IMPLEMENTATION CHECKLIST Management responsibilities Write down the overall responsibilities for management of the implementation. Ensure that this view is consistent with the contract and that the supplier has the same view.

Business needs Summarise your top-level business needs from your URS.

Business process changes List the business processes that require changing to align with the new information system.

Training List the members of the core team and the super-users who are responsible for planning, preparing and delivering the user training in each functional area. Area Core team member Super-user

Communication List all methods to be used for communicating details of the implementation to stakeholders, other than by one-to-one discussion, along with the frequency of update of information.

Expectations actions Keep a running list of actions needed to manage stakeholder expectations. Date Stakeholder Action required Action taken

Date cleared


CHAPTER

8 How do I know if the system is successful?

For many people, getting through the process of purchasing and implementing an information system is success enough, particularly if the journey has been traumatic. We know, however, that the odds are against any particular expenditure on IT being successful. In the introduction I used a graph based on published data suggesting that the results of a large proportion of the expenditure on IT resulted in an unsatisfactory outcome. In that case, the term ‘unsatisfactory’ was used to indicate that the IT investment did not meet its performance objectives. But what is meant by performance objectives? As well as an understanding of the term ‘success’ as a conceptual issue, there is also the need to provide some form of measure so that a view can be taken of the success of a particular system installation. This may be in some absolute form, so we can say that this system is considered to be successful within the organisation, or in some comparative form whereby we can say that one system is viewed as being more successful than another. It is often assumed, however, that the success of a system can be determined by testing that system against a complete, unambiguous and definitive specification of requirements. There are two problems with this assumption. First, as we saw in Chapter 5, it is very difficult to produce such a specification and, second, the justification for capital expenditure on the system will almost certainly have been based on business objectives related to cost savings or productivity improvements. These business-related quantities are difficult to measure since all other dependent variables cannot be held constant and some objectives are qualitative in nature. Up to now I have used the word ‘success’ when talking about the outcome of an information system procurement, without worrying about what we actually mean by the term. We have examined the stages of a procurement and looked at methods and approaches that others have used to help achieve their objectives. In this penultimate chapter, before we take a step back and look at the whole process, we will examine various views of ‘success’. As a result, we will be able to derive an approach that not only defines what we mean by the term but that also allows us to obtain a view on how successful the implementation of our information system has been.

96


What is success? The answer that you get to this question is likely to depend upon whom you ask and when you ask them. For example, the view of a user of a new system is unlikely to be the same as that of your finance director or of your project manager. ElectAM’s implementation of their new manufacturing computer system was considered to be a disaster from the managing director’s point of view. The materials manager, however, who had been the organisation’s project manager and had the scars to prove it, expressed the view that ‘the system was becoming successful’. This is not a view that he would have expressed at the time they went live with the new system. This indicates not only that different people will have different views on how successful a new information system is, but also that the views of individuals may well change with time. To help us arrive at a practical definition of what we mean by the success of an information system implementation, we can look at what others have written on the subject. Figure 8.1 illustrates general areas of literature that try to provide some view of at least one aspect of the success of a system. Although there is some overlap, the available literature falls into the categories of information system evaluation, information system failure, user information satisfaction and stakeholder analysis. I will discuss each of these areas below to see what we can learn from them. Also included in Figure 8.1 is literature on customer satisfaction and service quality. Neither of these topics is specifically aimed at information systems, but they provide us with reinforcement of ideas that emerge in other areas as well as a clue as to how we might go about obtaining a qualitative view of the success of our new information system.

Figure 8.1

Sources of information on success

How do I know if the system is successful?

97

Common measures of success During this discussion of the common methods used to determine whether or not a new information system implementation has been successful, I do not want to give the impression that any of these techniques are common practice. It seems that in most organisations no attempt is made to determine the extent to which a new system has achieved its objectives. Surprising though it may seem, this is consistent with the view that most implementations of information systems result in an unsatisfactory outcome. If I was responsible for the procurement of an information system and it was clear that the project or its results had not gone to plan then I would see little to be gained from advertising the fact. And perhaps an organisation for which such a purchase is a one-off event would find little benefit in spending even more time analysing what went wrong. Additional effort might be better spent making the system more serviceable. So why ponder the meaning of success? Well, as I’m sure you realise by now, all aspects of an information system procurement interact with one another and help us view the problems from different angles. By gaining a better understanding of how the resulting system will be judged we can take steps during the purchasing and implementation phases to help move towards our goal of a successful procurement.

INFORMATION SYSTEM EVALUATION There is a growing literature on the subject of information systems evaluation and this provides us with a view of what organisations consider to be indicators of success. From this literature we can extract information on what organisations do in the way of system evaluation, as well as how they do it. We can also look at the comments that researchers have made concerning the evaluation process. Generally the information system evaluation process is considered to occur at three distinct times during the lifetime of a project: 1. 2. 3.

Prior justification – generally in the form of a feasibility study to obtain approval for the capital expenditure; Evaluation during implementation – usually performed on an informal basis, often when the schedule or budget are seen to be at risk; Post-implementation – rarely carried out, due to not being seen as productive, and the risk that the evaluation might not show a cost-effective result.

So, information system evaluation is more often than not performed only for initial project justification when a Return on Investment (ROI) approach is usually taken. This will generally involve financial justification using Net Present Value (NPV) or Internal Rate of Return (IRR) type calculations, cash flow analysis and perhaps cost-benefit analysis. Some of these benefits are likely to be of a qualitative nature and so are difficult to include within an accountancy-based approach. A number of alternative approaches to information system evaluation have been proposed, but there is little evidence that these have been applied in practice. One such approach is user evaluation, where users are presented with questions about the tasks

98


they perform. They are asked to rate the system for each task against a set of characteristics such as accessibility, accuracy and presentation.1 One alternative approach that has been used is to determine the utilisation of a system.The basis for this method is that the more a system is used, the more the system meets its objectives. There are a number of problems associated with these methods for information system evaluation, and I shall return to these problems later in this chapter. However, the mere introduction of a new information system is likely to introduce change into the organisation, so evaluations made after the system has been put to use will be difficult to compare with pre-purchase evaluation. Also, a strong case has been made for moving away from a positivist, scientific approach to information system evaluation to a more interpretative perspective, where the social and cultural influences of information systems are also considered.2 The opinion expressed is that business reasons for undertaking evaluation have been obscured by a focus on the development of rational methods and tools for carrying out evaluation. Therefore it seems that, if carried out at all, IS evaluation is most likely to be done to justify expenditure and how the organisation has changed as a result of the implementation. Consequently, project evaluation would seem to be an unlikely candidate for the direct determination of the perceived success of a system. However, the approach does inform us about the quantitative and qualitative characteristics of an IS investment that may help guide our approach.

INFORMATION SYSTEM FAILURE Relatively small sections of the existing literature examine some widely documented and publicised information system development projects that have been less than successful. Cases studied3 include the attempt by the London Ambulance Service to introduce an automatic despatch system, and the failed Taurus share trading system sponsored by the London Stock Exchange. The critical failure factors derived from these studies provide little guidance on how to measure success except for the level of user consultation and the adequacy of user training. A list of critical success factors, items likely to enhance successful outcome, would seem to offer more chance of guidance towards the concept of success for system implementation. However, the emphasis within this area of literature is generally on the failure of information systems. This is probably because processes show up much more clearly where there are problems and failures than if there is a smooth, successful outcome. Some researchers have proposed a view of information systems failure based on the expectations of the various stakeholders associated with the system, which leads to the view that information system failure is the ‘inability of an information system to meet a specific stakeholder group’s expectations’.4 This view is one that I shall expand upon later, using research from other areas. Although there have been some objections to the expectations failure view, this concept appears to offer us the most insight in terms of a view of information system failure. A range of stakeholder expectations would be expected to include both formal (legitimised by being recorded in a document) and informal (unrecorded views of individuals or groups) system requirements. These could be used to paint a picture of


99

what functions and performance were required of the system, as well as the personal, organisational and business benefits sought.

USER INFORMATION SATISFACTION It has been suggested that User Information Satisfaction (UIS) is the most widely used single measure of information system success. This may be due to the availability of a simple questionnaire5 that is completed by users who rate each of a number of factors from, say, 1 to 5. Under the headings Quality of Product, Staff and Services, Training, Involvement and Understanding, the factors include such items as ‘accuracy of information produced by the system’, ‘time required for the development of the system’ and ‘feeling of involvement with the system’. Variations have been proposed on the User Information Satisfaction theme, but it seems to provide a reasonable surrogate measure of the success of a system implementation. However, it is perhaps better suited to the evaluation of the system’s effectiveness at meeting users’ needs both initially and as they change with time.

STAKEHOLDER ANALYSIS The concept of stakeholders was introduced in Chapter 3 where we identified stakeholder groups such as the board of directors, the project manager, users of the system, maintainers of the system and suppliers. One group of researchers define stakeholders as ‘… a group of people sharing a pool of values that define what the desirable features of an IS are and how they should be obtained’.6 When looking at solving problems in organisations, authors often use the term ‘stakeholder analysis’ simply to mean the process of identifying all those who have some interest in the problem or its solution, and then considering their view of the problem. In this way there is more chance of understanding the impact that potential solutions will have on each of the individuals or groups that might be affected. Also in Chapter 3, I introduced you to ‘Theory-W’7 (see Table 3.1 on p. 32). The proponents of this approach describe the process as: 1. 2. 3. 4. 5.

Identify the key people and understand how they want to win. Establish reasonable and realistic expectations by those key people. Match people’s tasks to their win conditions. Prepare a supportive environment. Derive strategic project guidelines from Theory-W win-win steps.

Stakeholder analysis, whether applied to problem solving or software project management, is a specific application of the concept of identifying expectations (or helping to formulate them) and then taking action to ensure that the perceptions match those expectations. This is based on the assumption that if an individual’s expectations are met, then an outcome is viewed as being successful. It also highlights the fact that both expectations and perceptions are individualistic. In other words, two people can have different views of the same outcome according to their individual expectations and

100


their individual interpretation of the outcome. From our point of view we would therefore need to consider the importance of the expectation to each individual, along with that individual’s perception of the outcome.

Why established measures don’t work The techniques and methods described above are all sound and all have value in our quest to determine the degree of success achieved with the implementation of a new information system. However, the evidence suggests that each one on its own does not provide a good perspective on the resulting system, and most are difficult to use for the purpose in mind. For example, the costs and benefits for the Return on Investment approach, which are necessary to measure in advance of calculating a Net Present Value, are difficult to quantify. Whereas this approach is used most frequently for project feasibility and approval it would appear that its main attraction is that the senior management of an organisation find it difficult to accept qualitative justifications. Shirani et al. wrote that: Although it may be more desirable to measure system success in terms of monetary costs and benefits, such measures are often not possible due to the difficulty of quantifying intangible system impacts. Improved organisational effectiveness, general job satisfaction, and better decision quality are some examples of possible system outcomes which elude proper quantification.8 The ROI approach only provides a partial view of how successful a system implementation has been, and it also neglects the aims and perspectives of internal and external stakeholders. The user evaluation approach of establishing a set of characteristic factors would lead us to try to establish an absolute scale of success. It would also appear that the factors could be different from one system to the next, making comparison impossible. It has been suggested9 that information system evaluation in general is ill-defined: ‘However, despite the existence of an extensive literature, the IS community appears to be no nearer a solution to the problems of IS/IT evaluation’. The idea of using system utilisation as a surrogate for success is also problematic since a system might be used infrequently to perform very important functions or there may be no option other than to use the system every day. For system utilisation to be of any value then use of the system would need to be voluntary. From our point of view, the assessments utilised in the User Information Satisfaction approach are only made for one of the stakeholder groups in which we have an interest. Although the users are a very important group, we also need to consider the other stakeholders and, in particular, the business objectives of the organisation. On the other hand, the concept of comparing perceptions with expectations runs throughout the published literature and is also to be found in the areas of determining customer satisfaction and service quality.


101

Expectations versus perceptions We might expect that, if the implementation of an information system were successful, then all stakeholders (or at least the majority of stakeholders) would have some level of satisfaction (as opposed to dissatisfaction) with the system at some point in time. Those stakeholders might be financial management, day-to-day users of the system, maintainers of the system, suppliers or customers of the organisation using the system, implementers of the system, or senior management of the organisation. If stakeholder satisfaction were to be a suitable surrogate measure of implementation success then the literature concerned with consumer satisfaction might help with our understanding of the concept of success.

CUSTOMER SATISFACTION AND SERVICE QUALITY The process that a consumer goes through has been described10 as: • • • • • •

forms pre-consumption expectancies; observes product (attribute) performance; compares performance with expectations; forms a perception of the gap between the actual performance and the expectation; combines these perceptions with expectation levels; forms satisfaction judgements.

Just as a measurement method has been developed and validated in the area of customer satisfaction, so we find a similar method concerned with service quality. These methods are generally applied to such services as those provided by a hairdresser, in a restaurant, or those provided by a doctor or an architect. Our information system, however, is usually a mixture of equipment and services where the services cover the provision of sales information, systems specification and design, implementation, installation and maintenance. The primary authors11 in the field of service quality have identified three main characteristics of services, namely: 1. 2. 3.

Intangibility – performances rather than objects; Heterogeneity – performance varies from producer to producer; Inseparability – production and consumption occur at the same time.

They also found three underlying themes: 1. 2. 3.

Service quality is more difficult for the consumer to evaluate than goods quality. Service quality perceptions result from a comparison of consumer expectations with actual service performance. Quality evaluations also involve evaluation of the process of service delivery.

All these characteristics and themes, together with their resulting ‘gap’ model of service quality, in which the various gaps between expectations and perceptions combine to

102


provide an overall view of service quality, would seem to be relevant to our information system procurement.

APPLICABILITY TO INFORMATION SYSTEMS PROCUREMENT Customer satisfaction/dissatisfaction literature says that the higher the expectations in relation to actual performance, the lower the satisfaction. In the service ‘gaps’ model, the consumer’s perceptions of overall service quality result from a comparison between expectations and perceptions of the different components of service.With perceptions of service held fixed, the higher the expectations, the lower the perceived quality. It therefore seems that the concept of comparing perceptions with prior expectations offers a number of advantages, such as: 1.

2.

3.

4.

Identifying the expectations of a wide range of individuals who each represent a different role or view within the organisation sets a baseline of success within that organisation and for that system. The installation as perceived by each individual is then compared against their own set of expectations. Thus the importance of one person’s expectations compared to those of another does not become an issue. Each system implementation studied can be compared with all others since the view of ‘success’ for each is individually based.This has the effect of normalising the data across cases, easing any cross-case analysis process. The individual stakeholder proposes the factors used to assess the degree of success of the system. There is thus no difficulty with interpretation of the factors between individuals and the data should therefore be reliable.

THE SUCCESS OF AN INFORMATION SYSTEM IMPLEMENTATION The above leads us to the model for determining the success of a complex system implementation shown in Figure 8.2.Within this model, E and P are the expectation and corresponding perception respectively of stakeholder 1, and P-E is the resultant satisfaction gap. Combining these satisfaction gaps for similar expectations across all stakeholders provides a range of satisfactions for each expectation and therefore an overall view of system satisfaction. It is suggested that first, corporate goals, such as increasing productivity, help form individuals’ expectations; for example, the production manager expecting to increase throughput in the area affected by the system. Therefore expectations from all stakeholder groups should cover all expectations of the system. Second, the level of satisfaction with the information system provides us with a view on the perceived success of the system. And finally, the scope of the information system includes your requirements specification. The system may meet all of the implied expectations within that specification, but anything wrongly specified or omitted will result in an unsatisfactory outcome. I use the term ‘perceived success’ since any person’s view may contain subjective elements and may depend upon the viewpoint of the individuals. In


Figure 8.2

103

A model for determining information system success

other words, someone simply entering data into a system is likely to have a completely different view of the system to that of the financial controller who is trying to balance the books. This perceptions versus expectations (P-E) approach to assessing the success of an information system implementation allows us to take specific views of a number of individuals and combine them to build up an overall view. To do this, it is necessary to obtain views from the range of stakeholders who are associated with a particular system, an activity described in Chapter 3, the results of which were used to help formulate a User Requirements Specification in Chapter 5. Even after the event, each stakeholder can identify the expectations they had prior to the implementation of the system. Their perceptions of the implementation against each of those expectations can then be obtained using a simple word model to obtain data that can be transformed onto a simple –5 to +5 scale. In this way, a composite view of the perceived success of a complex system implementation can be obtained. The result is a range of satisfaction levels for each of the grouped and reduced expectations, where each range is expressed with respect to the organisation’s expectation norm for that system; that is, a pictorial view of success as illustrated in Figure 8.3. The evaluation checklist at the end of this chapter indicates how a simple tool can be used to collect and analyse data to arrive at a view on the success of your new information system. The expectations collected on the checklist at the end of Chapter 3 are transferred to the evaluation checklist and each person is asked to provide their view on how well each of their expectations have been realised. These will be subjective, but that is the nature of such an evaluation. Grouping the expectations into common themes and deriving a range of values for how well the expectations in the group have been met allows a pictorial view to be formed, as in Figure 8.3. Therefore, with a little analysis of

104


Figure 8.3

A view of information system success

the data collected you can provide evidence of the successful outcome of your information system procurement. It is, of course, no coincidence that this approach to determining the perceived success of an information system procurement aligns with the guidance provided in the earlier parts of this book. This method of assessing satisfaction with a system has been applied within a number of case studies as a tool to help identify the links between actions and decisions, particularly those made during the purchase phase, and the perceived success of the resulting system. The approach then feeds back into all phases of the information system procurement to help steer the management of the whole process. In fact, deciding how to determine the success of the procurement of an information system allows us to develop a whole management approach to purchasing and implementing configurable systems. My intent was that the preceding chapters should allow this management approach to emerge, and in the next and final chapter we will take an holistic view of the whole process.

EVALUATION CHECKLIST From the Expectations checklist at the end of Chapter 3, transfer your list of stakeholders and their expectations to this checklist and record the stakeholder’s perceptions. Then group the expectations and rate them by analysing the perceptions. Some example text is included to help you in this process. Stakeholder Group/Individual Board of directors Operations director

Perceptions

Perception low rating 2 –1

Perception high rating 4 2


Expectation group Return on Investment Production schedule

Expectations Return on capital outlay within two years Reduction in number of production scheduling staff

105

106


Notes 1 Goodhue, D. L. (1995) ‘Understanding user evaluations of information systems’, Management Science, 14(12), pp. 1827–44. 2 Hirschheim, R. and Smithson, S. (1999) ‘Evaluation of information systems: a critical assessment’, in L. P. Willcocks and S. Lester, editors, Beyond the IT Productivity Paradox, Chichester: John Wiley. 3 Flowers, S. (1996) Software Failure: Management Failure. Amazing Stories and Cautionary Tales, Chichester: John Wiley. 4 Lyytinen, K. and Hirschheim, R. (1987) ‘Information systems failure: a survey and classification of the empirical literature’, Oxford Surveys in Information Technology, 4, p. 263. 5 Ives, B., Olson, M. H. and Baroudi, J. J. (1983) ‘The measurement of user information satisfaction’, Communications of the ACM, 26(10). 6 Lyytinen, K. and Hirschheim, R. (1987) ‘Information systems failure: a survey and classification of the empirical literature’, Oxford Surveys in Information Technology, 4, pp. 257–309, p. 261. 7 Boehm, B. W. and Ross, R. (1989) ‘Theory-W software project management: principles and examples’, IEEE Transactions on Software Engineering, 15(7), pp. 902–16. 8 Shirani, A., Aiken, M. and Reithel, B. (1994) ‘A model of user information satisfaction’, Data Base, 25(4), pp. 17–23, p. 18. 9 Ballantine, J. A., Galliers, R. D. and Stray, S. J. (1996) ‘Information system/technology evaluation practices: evidence from UK organisations’, Journal of Information Technology, 11(2), pp. 129–41, p. 130. 10 Oliver, R. L. (1993) ‘Cognitive, affective, and attribute bases of the satisfaction response’, Journal of Consumer Research, 20(3), p. 418. 11 Parasuraman, A., Zeithaml, V. A. and Berry, L. L. (1985) ‘A conceptual model of service quality and its implications for future research’, Journal of Marketing, 49(Fall), pp. 41–50.

CHAPTER

9 Putting it all together

You are about to embark upon one of the most difficult corporate tasks. Don’t let anyone tell you that it is easy and, whatever you do, don’t believe anyone who says they can guarantee you success. What you can do, however, is go into the task with your eyes open, with the knowledge of others behind you, with a view on how you plan to tackle each phase of the project, and with a sense of excitement at the prospect of a new experience. If you have butterflies in your stomach at the thought of embarking on your information system procurement journey then at least you now know more about the problem. During the course of this book we have covered each of the phases of an information system procurement illustrated in Figure 9.1 and in this final chapter I want you to consider the process as a whole. It is easy to get bogged down in the details of the processes and the technology that you are attempting to apply, which makes it even more important to stand back and take a wider view. This gives you the opportunity to keep in mind the overall strategy of your procurement, focusing on the principles that you are applying to solve your business problems. In this way, by keeping those fundamental principles at the forefront of your mind, you can make decisions and provide guidance from a position of strength that can be justified to all levels of the organisation.

Figure 9.1

The procurement process

108


Table 9.1

Summary of checklists

Checklist

Chapter Description

Expectations

3

A tool to help record the expectations of your stakeholders, it lists stakeholder groups and individual expectations together with the actions needed to help manage those expectations and states by whom the action should be completed

Purchase

4

A form to help record some of the fundamentals of your purchasing phase: includes the members of your purchasing team, including your sponsor, project manager, steering group and core team members, and a list of the risks against each of the contract types as they apply to your purchase. Finally, lists some actions that need to be completed

Specification

5

A tool to help you generate your specification documents. Lists responsibilities for the production, checking and approval of each section of the Invitation to Tender and of the User Requirements Specification

Vendor selection

6

A tool to help manage the vendor selection process. Lists responsibilities for risk assessment and each step of the vendor selection process, as well as the results, or reference to the results, of each of those steps

Implementation

7

This form helps you record information associated with the implementation process that is not recorded by the supplier. Includes a description of management responsibility, a summary of your business needs, those responsible for preparing and delivering training, a list of methods to be used to communicate with the organisation about the project and, finally, the running progress on the actions needed to help meet stakeholder expectations

Evaluation

8

A tool to help you evaluate how well you’ve done. Shows feedback from all stakeholders on how well their expectations have been met, followed by a quantified summary that can be used to provide a graphical view of the system’s success

During the course of this book I have used a small number of case studies of organisations that have purchased information systems to illustrate potential problems and, if not their solutions, then at least possible approaches that you could take. However, as I said in the introduction, no one person or one book can provide you with answers to all the questions that you will encounter. I therefore recommend that you continue to read and listen to any advice that you can find, from both inside and outside your organisation. Also scattered throughout this book you will have encountered a number of checklists. The complete set is summarised in Table 9.1, but each checklist is designed as a tool to help you tackle a particular part of the information system procurement process. My aim for including them was to illustrate the process, which may be complex, but it is possible to use a set of simple tools to help ensure that the right information is collected at the right time and decisions are taken at points when they can have the most effect.You can adapt the checklists in various ways. For example, capturing stakeholders’ expectations, along with the actions needed to help manage them, the person responsible, when the actions were completed and the stakeholders’ view of the result (a combination of the expectations and evaluations checklists) might be easier to manage

Putting it all together

109

in the form of a database. However, let us now take a step back and look at an overview of the process split into the two major phases, purchase and implementation.

Manage the purchase Members of your organisation have identified a need to install a new information system or, as in the case studies, decided that an existing system needs replacing. An old system may not now be maintainable or able to be expanded to meet the size or functional needs of the business. Also, as we found in some of those case studies, modern versions of systems often embody current thinking and provide support for new approaches to business processes. Consequently a new system may enable your organisation to use what is currently thought to be best practice. Whatever the reason for deciding to purchase a new information system, you or some of your colleagues will have put forward a business case for the expenditure and upheaval that such a venture will entail. This justification will be in terms of supporting the approved business strategy, cost saving, increased throughput or a combination of such considerations. Whatever the reasons used to justify the start of this major venture, keep that information to hand since it will form the foundation of your search for a system and a supplier.

IDENTIFY THE STAKEHOLDERS As we have seen throughout the previous chapters, the range of people who have some stake in the system play a vital role in the organisation for both the purchase and the implementation, as well as for establishing the system requirements. Those who have approved the expenditure, probably the board of directors, clearly have a stake in the system, as will those whose job it is to maintain the new system, keeping it suitable for use. In previous chapters I referred to the users of the system as one of the stakeholder groups. It is likely, however, that there will be users in each of a number of functional areas of the organisation, each of which might be seeking different benefits from the new system. Consequently all those who have some interaction with the system, including those supplying input data for the system or using the output from the system, should be listed (the left-hand column in the expectations checklist). Don’t forget the supplier or suppliers in your list of potential stakeholders. Within each supplier you will generally find two types of individual, each with their own expectations of what they can gain from the sale. On the one hand, there are those individuals concerned with the sale itself and on the other, those involved in the implementation. The salespeople are generally measured on the level of business that they can attract and so they are interested in a quick sale for as high a value as possible and also in the potential for further business.This may be in the form of support services for this system, future systems for your organisation or sales to other, similar organisations where you can be used as a reference site. The implementers are measured in a different way, perhaps depending upon the nature of the contract used, so they will be interested in maintaining or improving the profit margin on the project and will want to ensure that any increase in scope or time results in a corresponding increase in

110


contract value. As individuals, they will also want to add the experience gained on your project to their curriculum vitaes. When you get to the stage of capturing stakeholder expectations, then these aims of the supplier should not be ignored.

ESTABLISH THE ORGANISATION A substantial amount of work is required during the purchasing phase and then even more during the implementation phase. Those involved in the purchasing phase will almost certainly also be part of the implementation phase, supplemented by others. So now is the time to establish the people to be used during both phases, along with the responsibilities of those people. I made a big point of this exercise not being a part-time activity, and so now is also the time to get commitment from line managers for the scheduled release of people who will be part of the purchasing and implementation teams. Identifying the type of people required from within the organisation and the ‘owners’ of candidates is relatively easy since they should all have appeared in your list of stakeholders. If a function manager wants to reap the rewards offered by the new system then he or she must be encouraged to contribute to the common goal, provide a full-time resource and be part of the purchase and implementation planning process. Nominate a project sponsor from the board of directors, someone who will take ultimate responsibility for the project. Also identify the steering group, the project manager and the core team and get the sponsor to announce these people formally to the rest of the organisation.The purchase checklist (p. 55, Chapter 4) helps you to ensure that all positions have been filled. At this time it is also worthwhile getting the function managers to identify the super-users who will be involved in training staff during the implementation process. The steering group provides strategic direction to the project and the core team does most of the work, under the guidance of the project manager. You now have visibility of the project within your organisation. The board has approved it and everyone knows the members of the steering group and the core team. But don’t forget to make the business objects for buying a new information system visible to the core team members. This will help them in their first task; capturing requirements.

CAPTURE THE REQUIREMENTS You have the business requirements for the new information system from your project justification and you now have the resource to help collect the more detailed requirements for each area of the organisation that has some interest in the system. So you can now complete the User Requirements Specification section of the specification phase checklist (p. 68, Chapter 5), stating who is responsible for the production, checking and approval of each section of the document. Those responsible for collecting the requirements will, of course, be members of the core team, each concentrating on their own area of expertise. It is very easy at this stage for people to fall into the trap of simply describing how activities are performed now, either using the existing system or by manual methods. As I stated earlier, this can defeat the object of the exercise and make the task of selecting a vendor more difficult than it already is. It is therefore very


111

important to coach members of the core team in how to record the ‘what’ rather than the ‘how’. In other words, they must describe the function that needs to be performed in terms of its objectives and constraints, describing also the reasons why the function needs to be performed. It is often useful to consider the inputs to the function, both material and information, and the desired outputs from the function as a way of portraying the requirements to potential vendors. Again I must emphasise the importance of all parties reaching a common understanding of the business and functional requirements. The URS is the primary means of recording information to help form that common understanding. In fact, those generating the document usually find that they learn a lot about their business and the way that it operates as they go through this exercise. In addition to reaching a common understanding of the functional requirements of the new information system, you also want the vendor to have a clear understanding of your requirements in terms of the deliverables, schedule and contract terms and conditions. This is the purpose of the Invitation to Tender document, and again the specification phase checklist provides help with identifying who is responsible for completing each section. The ITT and the URS make up the formal definition of what you want from the supplier. They describe the scope of supply and the functions and performance that the system must provide. However, as we have seen in previous chapters, you can move stakeholders’ view of the success of your new information system by trying to ensure that their expectations have been met or exceeded. Therefore, in addition to the information that is passed to potential vendors, you need to capture the stakeholder expectations that go beyond the functional and business requirements. The expectations checklist (p. 34, Chapter 3) helps you to do this by recording against each individual stakeholder or stakeholder group their expectations plus the actions needed to manage those expectations.

GET HELP WITH THE CONTRACT Before you start on your search for a vendor you should have a clear idea of the type of contract you wish to place. You may have a functional specification that is unlikely to change and a lack of internal resource such that you need a supplier who can manage the whole process, providing a fixed price for a defined scope of supply. However, you may decide that you need to keep control over the management of the project and choose to purchase the equipment and packaged software along with training and consultative effort from a vendor. If you find it difficult to make this decision, then hire someone with experience of purchasing contracts for information systems and use the available model forms of contract as a starting point.

CHOOSE THE SUPPLIER Organisations have found vendor selection to be a very protracted and time-consuming process. It is certainly a process where one can easily get swamped by the mass of information provided by potential suppliers. My suggestion is that you start by

112


identifying the risks associated with the vendor selection process, the implementation process and the resulting system.You can define who is responsible for listing these risks and defining any mitigating strategy for each in the first part of the vendor selection checklist (p. 79, Chapter 6). Within that checklist you can also define who is responsible for each step in the vendor selection process. To keep the selection of a vendor to manageable proportions, generate a short-form of your requirements document and use that to perform telephone interviews with each of your potential suppliers. Assess the results of those interviews against an agreed set of criteria and then send your ITT and URS to the most likely supplier. Then put all your effort into evaluating that supplier. If there is no obvious front-runner or you can’t quite bring yourself to pursue only one potential supplier then issue the ITT and URS to two vendors but only put your effort into evaluating one. If you cannot differentiate between them, it probably doesn’t matter which one you choose. However, if you come up against some show-stopper with the first supplier to be evaluated then at least you have a second supplier to move on to without further delay. The results of each step in the process can be recorded in the last section of the vendor selection checklist.

Manage the implementation You have now selected a supplier or suppliers and placed an order. It may be tempting to relax, on the assumption that others will now take up the running. This is not the case and, although thanks to the team are in order for helping to reach this point, now is when the real work starts.

DEFINE RESPONSIBILITIES It is usual for there to be some form of project kick-off meeting with the supplier in order to confirm everyone’s understanding of the scope of supply. Prior to this meeting it is worthwhile writing down the management responsibilities as you see them in the first part of the implementation checklist (p. 93, Chapter 7). You can then discuss this view with the steering group and the core team before talking it over with the supplier as part of the kick-off meeting, to ensure that everyone has the same understanding.

KEEP IT SIMPLE If used inappropriately, project management software packages can seriously damage your (mental) health. If you have given responsibility for the management of the project to your supplier you will still need to plan and schedule the use of your own people. Whether or not you have delegated responsibility for managing the project, try to keep your planning simple. Remember that a plan is essential to show that what you want to do is feasible, at least in theory, but as soon as a plan is produced it is out of date. Events around a project change on a daily basis, a key member of the team is off sick, equipment arrives minus the cables, and so on, and so you need to be flexible and use your simple plan to define the overall time-related strategy. The plan also allows you to monitor


113

progress against your generalised requirements. Some activities will be behind schedule but others may be ahead, and so you can obtain an overview of where you are. There are two important principles: don’t try to micro-manage the project, and do take action if the overview indicates that something is going wrong. My experience is that far too many project managers repeatedly update detailed plans but fail to take the necessary actions, and so simply monitor slippage.

PLAN YOUR TRAINING Where an area needs special attention it can help to break it down and produce a simple but specific plan for that topic. Training is one such area.You have identified your superusers and obtained a commitment of their time during the training process, so it is wise to plan a detailed schedule for the preparation of training material and the delivery of the training. Remember that you are likely to need meeting rooms and equipment to help with the training and making the training material available to all staff, as one organisation did, can provide a more useful resource than the supplier’s manuals. As a starting point, use the training section of the implementation checklist to record who is to be responsible for each area of training.

TALK TO PEOPLE You have now reached a major milestone. You have selected a system and vendor and placed one or more contracts. So tell the rest of the organisation about it; what system and vendor has been selected and what will now be the schedule of events.You may recall that one organisation used noticeboards in the entrance to each building to help keep staff informed about the progress of the project. If you publish a regular newsletter then put an article in that, or, better still, if you have an intranet site then you can build a whole section about your business objectives, the steering group and core team members, the chosen system and your schedule. If you do use an intranet then try to update it frequently and let people know that there is new information available. You could always encourage members of the core team to write small articles about their experiences on the project to make the whole exercise more personal. There are many communication pathways within your project team and your organisation, and you will reap the greatest reward by making them all work for you. I saw one organisation take what were essentially their core team members and put them all together in a few offices in the attic. The result was that they got in each other’s way and totally lost contact with people in the departments to which they belonged. Another organisation left the core team members at their own desks and held regular and frequent meetings to cover progress and particular topics about the implementation of their system. In this way the people felt like a team and yet maintained daily contact with people in their own departments, and the inevitable informal conversations helped spread the word about progress and plans for the new system. In fact, when it comes to team meetings, they are often more useful in the form of short, apparently informal gatherings that discuss a single topic and reach a conclusion, rather than formal

114


meetings with everyone sitting in their favourite chairs with the best view out of the window. Whatever methods you use, it is worthwhile spending a little time thinking about the people you want to keep informed and what you need to inform them about. The board of directors will get updates both formally and informally via the sponsor, and the steering group will get relatively formal updates from the project manager. You can arrange for the core team to meet together and with the supplier as suits your situation but you need to think about the rest of the organisation. Having core team members working among the rest of the staff will help, but the function heads will want to feel that they are being kept informed. Remember that human nature is such that people would prefer to know that there is nothing new to tell them, rather than not hear anything at all. Use the communications section of the implementation checklist to note the methods you plan to use to communicate details of the project throughout your organisation. Keeping people informed of project events takes effort and is easy to put off until tomorrow. Don’t. Do it today and every day, and continue to seek feedback on your stakeholders’ expectations.

KEEP AN EYE ON THE CONTRACT You should be building a stimulating and informative environment, and your team should be enjoying the challenge. However, you must not forget that you have a contract, both an unwritten contract with the rest of your organisation to deliver a tool to meet their business needs, and a written contract with your supplier. This latter contract will contain details of deliverables and associated stage payments, and might also include your responsibilities to provide information at particular times. It is easy to say that any contractual matters will be raised when they occur, but it often seems to be the case that things remain unsaid until the issue becomes serious in terms of schedule, cost or both. Therefore regular reviews of the contract requirements with your supplier provide an opportunity to discuss impending deliveries of equipment or data and ensure that everyone is prepared for the event.

MANAGE STAKEHOLDER EXPECTATIONS Much of our discussion has been about the nuts and bolts of the information system procurement process. However, my intent throughout has been to help you reduce the risks associated with information system procurement and thus increase your chance of a successful outcome. Managing the project and the commercial aspects of the procurement in a simple but organised manner is going to help and, from the experience of the case studies, it is clear that establishing and maintaining communications with anyone and everyone will move you in the right direction. You also need to remember, however, that it is easy to get buried in the detail of the technology and the way things work, when what should be uppermost in your mind at all times is the business objectives that started off the need for a new system. Not only is it worth summarising those business requirements in the business needs section of the implementation checklist, it is also worthwhile listing the processes within your organisation that could


115

be changed for the better due to the use of the system. These changes can be collected, as you learn more about the system that you have bought, in the business process changes section of the implementation checklist. We started the process by gathering expectations, not only of the business as a whole, but of all those who were identified as stakeholders. The expectations checklist (p. 34) provides a location for the individual and stakeholder group expectations, along with actions that need to be taken to manage those expectations. Our view of what makes a system successful suggested that it was strongly linked to the difference between people’s perception of the final system and their prior expectations. Consequently the key that unlocks the potential of all the other activities of your procurement exercise is the management of stakeholder expectations. The expectations actions section of the implementation checklist (p. 93) allows you to monitor the actions taken and when they were carried out so that you can ensure that none have been missed. The management of expectations is a little different to other aspects of management. Sometimes you only need to make people aware that what they wanted has been provided and sometimes you will need to help them modify their expectations so that they are realistic and can be delivered. However, at other times you will need to take specific action to ensure that the expectation is met. The management of expectations may be the key to a successful outcome, but the desired results are unlikely to materialise without paying attention to all the aspects that we have discussed and, in particular, those illustrated in Figure 9.2.

Celebrate or drown your sorrows Lets hope the outcome is cause for celebration and that, after the system has gone live, you can look back and say that you have enjoyed the experience and also helped all those involved in the procurement to have enjoyed it too. You should also all have a sense of

Figure 9.2

Making it a success

116


achievement. As I said in Chapter 8, however, not many information system procurements are viewed as sufficiently successful for the organisation to want to spend time and effort on evaluating their results. To my mind, this is a lost opportunity, both to the individuals involved and to the wider business community.You have already done the hard work, which included collecting a view of all the expectations held by the various stakeholders. It will now take little additional effort to solicit views on how well those expectations have been met. It has been found that the views expressed can vary with time and so I would suggest that about one to two months after first putting the system to use is a good time to have a quiet chat with all your stakeholders. By this time, most teething problems will have been ironed out and yet people’s expectations should still be relatively fresh in their minds. You can use the evaluation checklist (p. 105) to record these perceptions and then, with a little analysis of the results, you can gauge your success by completing the second part of the checklist. To encourage you in this task you can see a real view of the success of an information systems project in Figure 9.3. Following the identification of their major expectations of the system, the stakeholders in this organisation were asked to rate how well those expectations had been achieved on a ‘Much better, Better, Same as,Worse, Much worse’ scale. However, most classes of expectation have more than one data point representing

Figure 9.3

A real view of success


117

perceived success.These could originate from more than one stakeholder and so they are combined to show an overall rating. The accumulated views on each expectation were assessed to produce a rating on a scale of –5 to +5, with the result being shown as the shaded bars in Figure 9.3. The absolute value of the rating is subjective and not statistically relevant. The objective, however, is to provide an indication of the strength of feeling within the organisation with regard to each expectation. It was not possible to collect enough data on those items marked with an asterisk (*) since it was probably too early after implementation for judgements to have been formed. You can see, however, that the system presented in Figure 9.3 did not live up to the expectations that had developed before and during the purchase and during the implementation. The method may not be scientifically rigorous but it is said that a picture paints a thousand words and a diagram such as this is easy for everyone to interpret. If you can’t really tell from the bars whether you were successful or not, overall, then you have probably not done too badly. However, any significantly negative bars provide you with an opportunity to see, even at this late stage, if anything can be done to improve the service provided by the system. It may only need a small change in working practice to fix the perception of a problem. So communicate! It often seems to be the case that we dash off and try to solve our view of a problem without spending time truly understanding the real problem. Spending a little time upfront can help direct our effort where it can have the most effect. Similarly, spending a little time analysing the results of your information system procurement can magnify the learning that you can gain from the experience. And if we fail to learn from our actions then we will make the same mistakes in future. There is also an opportunity to help others to learn from your experience. A short article in your company newsletter or, better still, a professional society publication means that a wide audience can gain from your experience. And finally … The power of expectation management should not be underestimated. During a radio broadcast, a doctor1 commented that a patient’s expectations before major surgery could affect their recovery. Those patients that were given information about their operation developed more realistic expectations. As a result, their recovery was much better than that of those patients who were not informed. What are your expectations?

Note 1 Morris, M. (1996) ‘Interview with Dr M. Morris on the subject of childbirth’, BBC Southern Counties Radio, 09:15, 7 July 1996.


Glossary The meanings of the acronyms and terms listed below generally conform to the accepted definitions. However, the meanings given here represent the way in which the term has been intended within this book, which may be an abbreviation of the true meaning or a concept rather than a definite entity. Analogue to digital converter

Bandwidth

BOM CAD

CD-ROM Core team

COTS Database

DRP ERP Ethernet

An electronic circuit that converts a voltage level or a current measurement into a bit pattern that represents the value of the voltage or current. Used to convert the measurement of a physical quantity such as temperature or pressure to a form that can be manipulated by a digital computer. Generally used to represent the capacity of a communications medium to transfer information. A high bandwidth communications link is capable of transferring more data than a low bandwidth link. Bill Of Materials. Computer-Aided Design. Often used to describe an engineering drawing software package. Compact Disk – Read-Only Memory. The group of people in your organisation who are responsible for the specification, implementation and testing of your new information system. Commercial Off-The-Shelf. A structured set of information usually in the form of tables containing a number of records (rows), each of which consists of the same set of fields (columns). Distributor Resource Planning. Enterprise Resource Planning. The most widely used computer communications system for moving data within an office environment. A variety of cable types are available, along with a variety of equipment such as hubs and file servers. A number of network software applications use Ethernet facilities to supervise the moving of data.

120


File server Gantt chart

Hard-hat project management

Hub

Implementation phase

Internet

IRR

IS

IT

ITT

JIT

Kanban

LIMS

A networked computer whose hard-disk drive is used as a shared store for data files. A pictorial representation of a schedule or plan with horizontal bars, one for each activity, spanning the planned time for the activity. The type of project management usually associated with the construction industry, consisting of many relatively simple but welldefined tasks that need to be scheduled, managed and monitored. An electronic device that allows a number of physical communication links (such as cables) from computing devices to be joined together to form a network so that any device can send data to any other device. The part of your information system project that converts your requirements into a usable application. This includes the installation of equipment and software and the configuration of that software to perform the required functions. The global collection of computers and communications links that hosts the World Wide Web and supports communications protocols such as HyperText Transfer Protocol (HTTP) and File Transfer Protocol (FTP). Internal Rate of Return. The equivalent interest rate that a series of capital investments would achieve. Information system. An assembly or integration of technology to achieve a range of functionality. Information technology. The individual technologies associated with computing and data communications. Invitation to Tender. A document that invites a vendor to submit a proposal for the supply of goods and services. Just In Time. Generally applied to the manufacturing process where the inputs to each part of the process arrive just before they are required, with a consequential reduction in work-in-progress. A production methodology that pulls materials, components and sub-assemblies through the production process according to the demand for the item. Laboratory Information Management System.

Glossary Microsoft Access MRP

MRP II

NPV

ODBC

PLC

Procurement Purchase phase RAM

ROI

Router

SQL

Steering group

Super-user

121

A relational database software package produced by the Microsoft Corporation. Materials Resource Planning. The production of a schedule of the material requirements for a manufacturing process. Manufacturing Resource Planning. The production of a schedule of all resources requirements, including labour, for a manufacturing process. Net Present Value. The equivalent sum of money that would need to be invested at a defined rate in order to achieve the same return as a capital expenditure. Open Database Connectivity. An industry standard data exchange protocol developed by the Microsoft Corporation. Programmable Logic Controller. A computing device, usually without a hard disk, that reads equipment status from a manufacturing process, executes sequential logic operations, and then sets the state of plant equipment such as motors and valves. The entire project from recognising the need to putting the system into use. That part of the procurement from specifying your requirements to placing an order. Random Access Memory. The working memory of a computer into which program code is loaded when it is required to execute. Return On Investment. Generally used to mean the monetary return obtained by investing cash in capital equipment and labour. A form of network hub that can be programmed to forward data packets according to predefined rules. Structured Query Language. An industry standard syntax for performing operations on the data within a relational database. The group of people in your organisation who are given the responsibility to oversee and ‘steer’ the procurement of your information system. The people in your organisation who are given the responsibility to develop and deliver training to the users of your information system and to provide first-line support.

122


T&M

UNIX

URS

VAR

Workstation

Y2K

Time and Materials. Applied to a type of contract in which the supplier is reimbursed for the time that he or she expends, plus any expenses incurred. A computer operating system that allows multiple programs (tasks) to be run at the same time and multiple operators to use the computer at the same time. User Requirements Specification. A document, usually produced by a purchaser, that defines the high-level operational and performance requirements of a purchased item, in this case an information system. Value Added Reseller. A term often used by suppliers of software packages. Companies other than the producer of the software sell the package to end-users but add value to the sale by supplying services such as those required to configure the software to the particular needs of the purchaser. A company with VAR status will generally have received training from the software package producer and be promoted by that organisation’s marketing machine. A computer that is used by an operator to gain access to the functionality provided by an information system. Year 2000. Generally used within the context of computer system upgrades that were required before the start of the year 2000, to enable the correct use of dates within the system software.

Index absolute costing 41 acceptance criteria, documented

86

back-flushing 41, 46 Ballantine, J.A. 106n Baroudi, J.J. 106n Benyon-Davis, P. 7n Berry, L.L. 106n bespoke/custom software 10, 11, 14 Bill of Materials (BOM) 84, 119 board of directors business objectives 30, 58, 59 expenditure approved by 30, 109 project sponsor as link to 26–7, 48, 54, 66, 81, 110, 114 Boehm, B.W. 31, 106n BOM see Bill of Materials (BOM) Brunel, I.K. 18 business objectives, identification of 37, 58–9, 85, 87, 110–11, 114 business processes 87–8, 109, 114–5 BuyIT Best Practice Guidelines (DTI) 22–3, 62, 70, 72 Cambridge University 3 Carco, D.M. 19, 70 cash flow analysis 97 CCTA 24n Clegg, C. 7n Collins, T. 19 Commercial Off-the-Shelf (COTS) software 10–11, 14 communication, importance of 91, 113–14 complex products 82 Computer-Aided Design (CAD) 11, 119 computerised accounting systems 3

configurable packaged software 10, 11, 13–15 consultants 46–7, 83, 84, 86, 87, 88 consumer satisfaction see customer satisfaction and service quality contingency funds 52, 90 contracts, management of 22–3, 51–3 choosing a contract type 52–3 commercial aspects 89–90, 114 comparing contract types 51–2 expertise required for 72, 73, 90, 111 core team definition of 119 full-time or part-time? 47, 49, 83 identity of members of 25–6, 27–8, 30, 50, 66, 67, 70, 75, 77, 83, 110 interaction with business 85, 113, 114 project manager as link between steering group and 28, 48–9, 54, 81, 114 role of 28, 49, 52, 53, 67, 76, 81, 83, 84, 87, 90–91, 110–11, 112, 114 support for 85 cost-benefit analysis 97 cost of system 39, 46, 72, 73, 77 COTS software see Commercial Off-theShelf (COTS) software CSM, ERP system implementation by 82–7 custom software see bespoke/custom software customer satisfaction and service quality 101–2 data clean-up 85 data security and integrity

62

124


deliverables, monitoring of 53, 54, 89, 90, 114 Department of Trade and Industry (DTI) BuyIT Best Practice Guidelines 22–3, 62, 70, 72 Distributor Resource Planning (DRP) 41, 42 DRP see Distributor Resource Planning (DRP) DTI see Department of Trade and Industry EITO see European Information Technology Observatory (EITO) ElectAM case study definition of scope of supply 37, 38, 58, 61, 62 identification of requirements 20–21, 37, 58 procurement results 1–3 system implementation 23, 37 vendor selection process 22, 35–7, 39–40, 69–70 Enterprise Resource Planning (ERP) systems 4, 11, 30, 40, 41, 43, 47, 48, 51, 61, 74 implementation case study 82–7 ERP systems see Enterprise Resource Planning (ERP) systems Ethernet 61, 119 European Information Technology Observatory (EITO) 7n evaluation of information systems see information system evaluation existing system, specification in terms of functionality 59–61 expectations, stakeholders’ 29–33 information systems failure based on 98–9 management of 31–3, 66–7, 91–2, 99–100, 109–10, 111, 114–15, 117 personal 29–30, 92 typical 30–31

versus perceptions, as measure of implementation success 101–4, 115–17 factory automation systems 70 failed systems see information system failure Farbey, B. 20 Faris, C.W. 24n Farish, M. 7n feasibility studies 97 feedback forms 84 fixed-price contracts 51, 52, 67, 89 Flowers, S. 11, 19, 106n functional specifications 67 future-proofing 39 Galliers, R.D. 106n Gantt charts 88, 89, 119 Good Automated Manufacturing Practice (GAMP) 62 Goodhue, D.L. 106n hard-hat project management 81, 88, 120 Hirschheim, R. 106n Holmes, A. 23 Hospital Information Support Systems 3 identification of requirements 22, 58–9, 87, 95, 110–11, 114 ElectAM’s apprach to 20–21, 37, 58 PowerSound’s approach to 41–3 IEE see Institution of Electrical Engineers (IEE) implementation see system implementation individual objectives 29–30 industrial marketing literature 18 information systems evaluation 20, 30, 97–8, 100 information system failure 19–20, 98–9 information system implementation see system implementation

Index

Information Technology investments, performance of 3–4 Institution of Electrical Engineers (IEE) 52 Interfaces 62, 74–5, 83 Internal Rate of Return (IRR) 97, 120 Internet 10, 24, 71, 76, 120 intranet 113 Invitation to Tender (ITT) 71, 72, 81, 112 definition of 120 ElectAM’s 37, 38, 39, 58, 69 suggested content of 59–61, 75, 76, 111 ITT see Invitation to Tender Ives, B. 106n Just-In-Time (JIT) Kanban

44, 46, 120

40, 45, 46, 120

Laboratory Information Management Systems (LIMS) 70 Lester, S. 24n, 106n LIMS see Laboratory Information Management Systems (LIMS) London Ambulance Service 3, 98 Lyytinen, K. 106n maintenance costs 2, 75 people involved in 28, 31, 109 Manufacturing Resource Planning (MRP II) 40, 41, 120 materials shortages 84 meetings 48, 53, 84, 113–14 Microsoft Access 40, 41, 120 monitoring progress 54, 89, 112–13 Morris, M. 117n MRP II see Manufacturing Resource Planning (MRP II) multiple-user access 11 Net Present Value (NPV) 97, 100, 120 New Product Development 44

125

newsletters 113 NHS Information Management Group 3 notice boards 86, 113 ODBC see Open Dadbase Connectivity (ODBC) Oliver, R.L. 106n Olson, M.H. 106n Open Database Connectivity (ODBC) 75, 120 operator terminals 1 organising to buy 47–50, 110 core team 49–50, 110 project manager 50, 110 project sponsor 47–8, 110 steering group 48–9, 110 super-users 50, 110 Parasuraman, A. 106n payment schedules 72, 77, 89–90, 114 penalty clauses 90 perceptions versus expectations approach 101–4, 115–17 performance guarantees 72, 77 personal expectations 29–30, 92 Peterson, B.L. 19, 70 pharmaceutical industry 59, 62, 67 plant and process automation, standards for 88 PowerSound case study definition of scope of supply 43–5, 61 identification of requirements 41–3 limitations of existing system 40–41 vendor selection process 46–7 price of system 39, 46, 72, 73, 77 process control systems 11 procurement guidelines, general 18 procurement process definition of 121 people involved in 25–34 see also stakeholders phases of 20–21, 37

126


see also identification of requirements; scope of supply, definition of; system implementation; vendor selection product specifications 87 Programmable Logic Controllers (PLC) 11–12, 121 project manager identity of 48, 83, 86, 110 role of 28, 48, 50, 52, 54, 81, 83, 110, 114 project monitoring 54, 89, 112–13 project objectives, definition of 19 see also business objectives project planning 89, 112 project reporting 89 project sponsor identity of 26–7, 43, 47–8, 110 role of 48, 54, 66, 81, 114 published directories 71, 76 purchase decision, people involved in 25–34 see also stakeholders purchasing literature 18 reference sites, visits to 47, 70, 75, 77 regulated industries 59, 67 requirements, identification of see identification of requirements Return on Investment (ROI) 20, 30, 32, 97, 100, 121 risk and reward contracts 52 risk assessment 75, 88 risk management 88 Robinson, P.J. 24n Ross, R. 106n satisfaction gap 102 Sauer, C. 19 scope of supply, definition of 22 ElectAM’s approach to 37, 38, 58, 61, 62 PowerSound’s approach to 43–5, 61 producing a specification 57–68

based on business objectives 58–9, 110 Invitation to Tender (ITT) 59–61, 75, 76, 111 User Requirements Specification (URS) 62–7, 74, 75, 76, 92, 103, 110–11 service quality 18, 101–2 Shirani, A. 100 shortages, material 84 single-user software 11 Smith, J.M. 18, 23, 70 Smithson, S. 106n software procurement 14 people involved in 25–34 see also stakeholders software products, range of 10–12 sponsor see project sponsor spreadsheets 11, 13, 39, 42, 69–70, 74, 88, 89 SQL see Structured Query Language (SQL) SRS see System Requirements Specification (SRS) stakeholder analysis 99–100 stakeholders expectations of 29–33 information systems failure based on 98–9 management of 31–3, 66–7, 91–2, 99–100, 109–10, 111, 114–15, 117 personal 29–30, 92 typical 30–31 versus perceptions, as measure of implementation success 101–4, 115–17 identity of 26–9, 99, 101, 109 project manager 28 top level 26–7, 109 users and maintainers 27–8, 109 standard costing 41 standards, international and industry 88 Standish Group

Index

Chaos Report 19 steering group 2 definition of 121 identity of members of 25–6, 27, 37, 49, 66, 75, 110 project manager as link between core team and 28, 48–9, 54, 81, 114 project sponsor as link between board of directors and 26–7, 48, 54, 66, 81, 110, 114 role of 36–7, 48, 53, 58–9, 67, 69–70, 76, 81, 86, 112 Stray, S.J. 106n Structured Query Language (SQL) 40, 41, 121 success 95–106 common measures of 97–100 inadequacy of 100 information system evaluation 97–8, 100 information system failure 98–9 stakeholder analysis 99–100 User Information Satisfaction (UIS) 99, 100 definition of 96 expectations versus perceptions approach to assessing 101–4 applicability to information systems procurement 102 customer satisfaction and service quality 101–2 success of an information system implementation 102–4, 115–17 user criteria for 19, 98 super-users 50, 83–4, 85, 91, 110, 113 definition of 121 supplier expectations of 109–10 relationship with 19, 22, 39, 40, 52, 70, 74, 86 role in procurement process 28, 31 role in project management 28 role in system implementation 23, 83, 86, 87, 88, 89, 109–10, 112, 114

127

selection of see vendor selection supplier-specific hardware 11 system design, specification in terms of 59, 61 system implementation 81–94, 112–15 business objectives and 85, 87, 95, 114 business processes and 87–8 commercial management of 89–90, 114 communication 91, 113–14 CSM’s approach to 82–7 lessons learned 85–7 mistakes made 85 steps involved 83 defining responsibilities 112 definition of 120 ElectAM’s approach to 23, 37 literature on 18–19, 23 managing stakeholder expectations 91–2, 99–100, 109–10, 111, 114–15, 117 project management 81, 88–9, 112–13 success of see success training 90–91, 113 system performance expectations 62, 74 System Requirements Specification (SRS) 44–5, 46, 61 T & M contracts see time and materials (T & M) contracts Taurus share trading system 3, 98 technology, overemphasis on 59, 61, 73, 75, 88 telephone interviews 46, 76, 77, 112 ‘Theory W’ approach 31–2, 50, 99 time and materials (T & M) contracts 51, 52, 54, 89, 121 time schedule, overrunning 22, 35–6, 37, 39–40, 69–70, 74, 81, 82, 85, 90 token-passing based communication 61 trade journals 71, 76 trade shows 37, 71

128


training 50, 51, 53, 83–4, 86, 88, 90–91, 98, 110 plans 113 ‘troubled IT projects’ 18 URS see User Requirements Specification (URS) user evaluation 98 User Information Satisfaction (UIS) 99, 100 User Requirements Specification (URS) 71, 72, 81, 112 CSM’s 85 definition of 121 ElectAM’s 38, 62 suggested content of 62–7, 74, 75, 76, 92, 103, 110–11 users expectations of 31 involvement of 19, 27–8, 50, 109 satisfaction with system 20, 75, 98, 100 super-users 50, 83–4, 85, 91, 110, 113, 121 utilisation of a system 98, 100

Value Added Reseller (VAR) 46, 47, 121 VAR see Value Added Reseller (VAR) vendor selection 22–3, 69–79 alternative approach to 76–8, 111–12 ElectAM’s approach to 22, 35–7, 39–40, 69–70 PowerSound’s approach to 46–7 problems and considerations associated with 72–3 risks associated with 73–5, 112 traditional approach to 70–72 ‘what if?’ requirement 39, 74 Willcocks, L.P. 24n, 106n Wind,Y. 24n word processing 11, 12 work-flow facility 85 Year 2000 problems Zeithaml, V.A.

106n

40–41, 122


If you have found this book useful you may be interested in other titles from Gower Corporate Fraud 3ed Michael J. Comer 0 566 07810 4

Investigating Corporate Fraud Michael J. Comer 0 566 08531 3

Statistical Sampling and Risk Analysis in Auditing Peter Jones 0 566 08080 X

Managing Communications in a Crisis Peter Ruff and Khalid Aziz 0 566 08294 2

How to Keep Operating in a Crisis: Managing a Business in a Major Catastrophe James Callan 0 566 08523 2

Fire Precautions: A Guide for Management Colin S. Todd 0 566 08182 2

Security Manual 7ed John Wilson and David Brooksbank 0 566 08174 1

GOWER

The Relationship Manager Tony Davis and Richard Pharro 0 566 08463 5

Strategic Supply Chain Alignment: Best Practice in Supply Chain Management edited by John Gattorna 0 566 07825 2

Gower Handbook of Purchasing Management 3ed edited by Marc Day 0 566 08404 X

Gower Handbook of Supply Chain Management 5ed edited by John Gattorna 0 566 08511 9

The Gower Handbook of Management 4ed edited by Dennis Lock 0 566 07938 0

Supply Chain Cybermastery: Building High Performance Supply Chains of the Future Andrew J. Berger and John L. Gattorna 0 566 08413 9

Purchasing Scams and How to Avoid Them Trevor Kitching 0 566 08281 0

Design for Six Sigma: Launching New Products and Services Without Failure Geoff Tennant 0 566 08434 1

GOWER

Practical International Data Management: A Guide to Working with Global Names and Addresses Graham Rhind 0 566 08405 8

Gower Handbook of Customer Service Peter Murley 0 566 07688 8

Handbook of Customer Satisfaction and Loyalty Measurement 2ed Nigel Hill and Jim Alexander 0 566 08194 6

Customer Loyalty Programmes and Clubs 2ed Stephan A. Butscher 0 566 08451 1

Measuring Customer Service Effectiveness Sarah Cook 0 566 08538 0

Dealing with Customer Complaints Tom Williams 0 566 07697 7

Using Smart Cards to Gain Market Share Aneace Haddad 0 566 08315 9

For further information on these and all our titles visit our website - www.gowerpub.com All online orders receive a discount

GOWER

Join our email newsletter Gower is widely recognized as one of the world's leading publishers on management and business practice. Its programmes range from 1000-page handbooks through practical manuals to popular paperbacks. These cover all the main functions of management: human resource development, sales and marketing, project management, finance, etc. Gower also produces training videos and activities manuals on a wide range of management skills. As our list is constantly developing you may find it difficult to keep abreast of new titles. With this in mind we offer a free email news service, approximately once every two months, which provides a brief overview of the most recent titles and links into our catalogue, should you wish to read more or see sample pages. To sign up to this service, send your request via email to [email protected]. Please put your email address in the body of the email as confirmation of your agreement to receive information in this way.

GOWER

Buying Information Systems: Selecting, Implementing and Assessing Off-The-Shelf Systems

Integrated Library Systems: Planning, Selecting, and Implementing

Economics and Information Systems, Volume 1 (Handbooks in Information Systems) (Handbooks in Information Systems) (Handbooks in Information Systems)

Information Processing and Living Systems

Information Systems Reengineering and Integration

Information systems and data compression

Information Processing and Security Systems

Information Processing and Biological Systems

Uncertainty and Intelligent Information Systems

Business rules and information systems

Implementing electronic document and record management systems

Collaborative Geographic Information Systems

Neural Information Processing Systems

Auditing Information Systems

Geographic Information Systems Demystified

Effective Healthcare Information Systems

Modern Information Systems

Visual Information Systems

Transactional Information Systems

Auditing Information Systems

Enterprise Information Systems VI

Mobile Information Systems

Management Information Systems

Information Systems Evolution

Auditing Information Systems

Contemporary Information Systems

Interactive Collaborative Information Systems

Encyclopedia of information systems,

Encyclopedia of information systems,

Auditing Information Systems

Designing Management Information Systems

Buying Information Systems: Selecting, Implementing and Assessing Off-The-Shelf Systems

Integrated Library Systems: Planning, Selecting, and Implementing

Economics and Information Systems, Volume 1 (Handbooks in Information Systems) (Handbooks in Information Systems) (Handbooks in Information Systems)

Information Processing and Living Systems

Information Systems Reengineering and Integration

Information systems and data compression

Information Processing and Security Systems

Information Processing and Biological Systems

Uncertainty and Intelligent Information Systems

Business rules and information systems

Implementing electronic document and record management systems

Collaborative Geographic Information Systems

Neural Information Processing Systems

Auditing Information Systems

Geographic Information Systems Demystified

Effective Healthcare Information Systems

Modern Information Systems

Visual Information Systems

Transactional Information Systems

Auditing Information Systems

Enterprise Information Systems VI

Mobile Information Systems

Management Information Systems

Information Systems Evolution

Auditing Information Systems

Contemporary Information Systems

Interactive Collaborative Information Systems

Encyclopedia of information systems,

Encyclopedia of information systems,

Auditing Information Systems

Designing Management Information Systems

Recommend Documents