RISK MANAGEMENT

~

MO.

Risk management in information svsterns

Risk ~ ~ ~ = -

J

development -

1 Requirement not clear

a case studv

Sponsorluser workshops

J Information systems projects have a reputation for overrunning both time and budget. Whilst the ap lication of standard engineering project management teckques will do much to correct ,this trend, there is one sigdicant factor which ddferentiates IS projects from their engineering counterparts: unceaainty.

~

2

by D. Beare

Customer commitment Sponsorluser workshops

nformation systems (IS) requirements are often difficult to define and are inextricably I tied up with people and organisations. Add

to this the continually changing nature of the technology and you have a cocktail of risks. This article focuses on risk management as one tool which can make the difference between success and failure, and examines its application to a risky project developed for the operating companies of a large multinational organisation.

Background The engineering work management system

(EWMS) is a system aimed at improving the ability of operating companies (OpCos) to manage expenditure across multiple engineer- ing projects. The system requires up to 300 users to be connected to a central database without any loss ofperformance. In addition it has to be integrated with the engineers’ other desktop PC tools and be easy to use. Previous attempts to build such syscems had had mixed success because technology was not available which could deliver the system to the desks of such a large number of individuals.

Initial risks The first step in the project was to agree the

scope and write a specification of the required

ENGINEERING MANAGEMENT JOURNAL

3 No idea of technical solution

system. This was done in 1990 in two workshops with representatives from the participating companies and the project team. At this stage the consideration of technical risk took second place to the recognition that the scope must be clear. This highlights the first risk in any project: knowing what is required. OpCo representatives were actively involved in detailed discussions. Thus another risk, customer commitment, was effectively managed right from the start of the project by involvement at appropriate stages. The situation at the end of the initiation stage is summarised in Table 1. Had we done nothing further it is probable that the project would have failed. The remainder of the article describes the effect of embracing risk management as a contiguous concept.

Subsequent risks At the end of 1990 it was decided to inspect

the project specification. This took two weeks Table 1 Initiation stage

Not addressed

APRIL 1995 63

RISK MANAGEMENT

Table 2 End tender evaluation - No

1 .o 1 . 1 2.0

- -

2. I

- 3.1

- 3.2

3.3 -

- 3.4

- 4.0

- 5.0

- 6.0

-

~

Risk Descriplion

Requirement not clear

Specification confusing Customer Commitment

Differing OpCo work practices

NO idea of technical solution

New technology workable?

System performance adequate?

~

OpCo network Infrastructure

Poor implementation

General uncertainty

Contractor management weakness

Smnsorluser workshoos

Redrat? specification Sponsorluser workshops Arrange for customer involvement at all stages Communicate well to keep sponsors informed Develop a programme of marketing and expectation management Strong SlPM and OpCo line project management Ensure use of group project management guide as basis for work practices Focus on work practices in specification Ensure meeting to agree final specification

Utilise market expertise during tendering to find solution Cost plus contract to apportion risk with software house Eliminate anempt at predicting technid solution in specification. Focus on describing user needs in some detail in speckation Strengthen SlPM involvement Add full-time developer to project team

Arrange for tenderen to build simple prototypes prior to contract award

Introduce prototype phase into project and development contract Build cancellation clause into contmct ifprototypes fail to satis@ Shell

Warn OpCos of the infrastructure requirements early Become activelv involved in imolemeniation Dlannino

Early warning of effort required Strong SlPM and OpCo line project management SlPM actively involved in implementation planning

Increase budget contingency Phase Droiect to monitor nsks

Appoint resident software engineer to work in contractor's office

and used the Fagan inspection technique to review the document. This thorough exposure forced a reassessment of the whole project and the conscious decision to recognise and manage the risks. This resulted in decisions being taken in the following areas:

The overall cost estimate was doubled. Contingency allowances were included to allow for the uncertainty. Contract strategy: to take account of apportionment of technical risk, and to make as much use as possible of market expertise during evaluation phase. Project phasing (to allow monitoring of risks). Project management structure (additional people, expertise, and correct level of management involvement). Customer involvement to retain commit- ment. Communications and PR to deal with implementation issues and retain customer commitment.

At the end of the inspection the biggest risk was that we did not know if the requirement could

be technically satisfied. We immediately set about devising a contract strategy which would find the answer. First, we decided to cut all but the bare minimum of technical detail from the specification. We focused on describing what we did know: what we wanted the system to do. The tenderers would be given our requirement and asked to provide the solution as part of their bid. This meant that we were utilising industry expertise during the tender stage by getting as many experts working on the solution as possible. This provided us with a number of solutions from which we chose the best.

However, the selection of a contractor uncovered further risks, namely that the technology was new and untried. It was not clear whether the proposed solution would be able to meet our strict performance criteria, or whether the new software being used would fulfil its promise. We were also unsure of whether the OpCos would have the necessary networks and expertise in place to implement such a system. Additionally, our evaluation of the contractor had detected weaknesses in his project management capability. The way in which the system would demand change in work practices highlighted a major risk in implementing the organisational aspects of the system. This needed the active involvement of company senior management. The risk situation at the end of the evaluation is summarised in Table 2 .

Notice that the original risks have been refined into a larger number of more specific issues and that new risks have been added. This is a key point in risk management: it is essentidl to keep updating the risk analysislresponse all the time. Specific measures can only relate to the knowledge of the risk at that time. As knowledge changes so does the perception of risk. The only time in the EWMS project that we did not identify risk we were nearly caught out. Our exposure to integration risks was not recognised, so problems at the end of construction caught us by surprise and caused embarassing delays. It would have been better to have recognised system integration as a risky process and built in contingency for unexpected problems. In this way, at least, the surprise element would have been reduced and our customers' expectations would have been managed accordingly.

Managing the risks Of course, recognising the risks is not

enough on its own. The key is that decisions be

64 ENGINEERING MANAGEMENT JOURNAL APRIL 1995

RISK MANAGEMENT

I a3 a4 a1 a2 a3 a4 01

i PROTOTYPE

I I

confirm

Central Onicel OpCo reviews

Brunei)

JNIWHANDOVER I

4F IMPLEMENTATION

made on how to manage them. This requires a willingness to change the project plan as the project progresses and the risks unfold. It helps if contingency has been allowed for this. For instance, our review of the prototype told us the specific areas where our performance criteria were at risk. We considered this to be so important that we inserted a new phase (Detailed Design, see Fig. 1) so that we could be satisfied with the solution prior to construction starting. Even at the end of this new phase we were uncertain of the likelihood of success so we amended the construction plan so that the critical modules were built and tested first; in this way we would limit investment prior to assuring ourselves that we would have a workable system.

The project plan was largely structured around the need to manage risk. Fig. 1 shows how we divided up the project into manageable phases with a review at the end of each one. Every review had the aim of confirming that certain of the risks had been reduced to acceptable proportions. The last action at each review was to reassess risk and make appropriate adjustments to the plan.

Risks have to be faced as soon as they become apparent and action must be taken to manage them. It is even necessary to be prepared to recommend abandonment of the project if the risks cannot be eliminated. We were prepared to do this twice during the EWMS development: first, at the end of the prototype phase (this was built into the contract, a good incentive for the contractor to perform!); and, secondly, at the end of the design phase if the solutions did not seem to resolve our outstanding performance risks. I t is only by this sort of realism that risks will be tackled early enough, costs limited, and ultimate success assured.

Finally, we are not finished with risk yet even though EWMS is built and has been installed successfully in four major companies. The biggest risk always has been recognised as the organisational implementation. This requires business process changes in engineering departments, in itself an activity with some considerable uncertainty. In order to manage this from Central Office our response has been to warn OpCos early of the organisational prerequisites for EWMS, and to organise pre- implementation visits to all OpCos to identify required action. We have also built up a co- ordinated plan for the implementation and have ensured that lessons learnt in one OpCo are disseminated to the others. This has done much to reduce uncertainty, but we will continue to review and take action to manage risks as the implementation progresses. The focus now, however, is increasingly on getting the customers to recognise and take action for themselves.

h s k management is the key to effective IS project management and the effort put into it can never be relaxed: Not even when the onus for action changes to the customers! Every project has its risks, however large or small. The job of the project management is to assess them and do something about it!

Acknowledgments The author would like to thank the following

for their contributions to this article: A. H. van der Krogt, Shell Internationale Petroleum Maatschappij B. V. and D. Hendry, Diagonal Manpower Services. 0 IEE: 1995 David Beare may be contacted at Ruychrocklaan 60A, 2597 EP Den Hag, Netherlands, Tel: +31 70 3247568, E-mail: dbeare@inter.NL.net, H e is an IEE Member.

Fig. 1 Final project plan

ENGINEERING MANAGEMENT JOURNAL APRIL 1995 65