Chapter 15: Implementing Systems ‑ Driving Home Benefits

Chapter Objectives

In this chapter we shall:

  • Emphasise the need to drive home benefits through project management (not just "get something in on time and on budget").
  • Set out a risk/reward approach to implementing systems which should help you to minimise the risks and maximise the rewards of your implementations.
  • Encourage you to review your IT projects post implementation to improve the effectiveness of future projects and indeed the implementation you are reviewing.

Project managing implementation projects

In the chapter 14 we set out some worrying statistics on IT project failure in order to convince you to use a proper process for selecting systems.  Choosing an appropriate system minimises many project risks and helps you to plan the implementation sensibly, but it does not guarantee IT project success.  Indeed, completing the systems selection is not even the beginning of the end, it is merely the end of the beginning of the project.  The implementation stage of the project requires solid project management to minimise risks and maximise rewards.  In our experience, the technical risks of the project are often given disproportionate attention, at the expense of longer term risks of failing to drive home the very benefits that initiated the project in the first place.  “We got the thing in on time and on budget” is an achievement in itself, but it is a bit of a “so what?” achievement if benefits don’t flow from the project.

The diagram below shows an IT project risk/reward model.  The earlier phases of your systems project, discussed above, should have identified the benefits (rewards) sought and several of the areas of risk.

15.1 Project Risk Reward Model

By directing systems projects towards their potential rewards and minimising the risks along the way, you can vastly increase the likelihood of project success.  A risk/reward management approach to project management requires clear thinking and the ability to make decisions (sometimes tough ones).  It is a rigorous approach to achieving the objectives and rewards that led to you initiating the systems project in the first place.  This approach is entirely in line with structured methodologies for project management, such as PRINCE 2.  We would advocate the use of structured methodologies only in large project environments (most voluntary sector IT projects are not large).  In our experience, structured methodologies are sometimes used as an alternative to structured thinking; in such circumstances the methodology which aims to help the project to succeed can become the “trees that prevent you from seeing the wood” in driving home the benefits.  Nevertheless, structured methodologies are very useful when large projects involving many people need to be controlled in a standardised way.  In all cases, we promote the use of clear and analytical thinking to minimise risks and maximise rewards.

Learning the lessons

George Santayana once said "...progress, far from consisting in change, depends on retentiveness….Those who cannot remember the past are condemned to repeat it" (Santayana, 1905).    Although Santayana was not referring to post implementation reviews of IT projects, his words seem pertinent in that context.

Sadly, few IT projects are evaluated post project.  Exhausted, demoralised, slightly embarrassed and late starting the next project, there often just isn't time.  This is a pity.  Evaluation is a valuable way of learning from our successes and our mistakes in order to allow continuous improvement. A post project review can also produce substantial benefits to the project itself:

  • Assessment of whether objectives have been met and rewards gained - also a means of deciding what additional activities, if any, are required to meet those objectives and gain those rewards.
  • Appraising user satisfaction (or lack thereof) - often some early feed back from users can identify issues which can relatively easily improve the users longer term perception of the success of the project and of their satisfaction.
  • Identifying learning points for future projects - given the consistently high failure rates of IT projects, it seems a shame that organisations are not learning from their past mistakes.  We suggest that solid risk/reward assessment post project would go some way to improving the track record for IT projects.

For larger projects, the post project review is a small project in itself, but for smaller projects a brief assessment addressing the above points would achieve many of the benefits sought from evaluation.

Risk/reward activity from choosing through to post implementation review

Table 15.1 below shows a sensible pattern of risk/reward activity divided between the phases of an IT systems project.  It is not exhaustive, but should illustrate many of the principles involved and provide checklists for you at each stage of your selection and implementation work. 

Table 15.1 IT Project Risk / Reward Management
Areas of risk and reward Planning
(choosing process from business case through to selection)
Implementation
(driving home benefits)
Evaluation
(learning and continuous improvement)
Objectives, rewards and user satisfaction define objectives
estimate rewards
set objectives and rewards as goals
manage user expectations
seek early wins to prove user benefits and start virtuous spiral
have the objectives been met?
have the rewards been gained?
have unintended rewards been found?
are the users satisfied?
Product risks general knowledge of IT product market place
compare IT product risks between potential solutions
plan management of foreseen product risks
revise project plans to manage down emerging product risks
does the product perform?
can it be enhanced or modified?
Supplier services risks general knowledge of IT supplier market place
compare supplier risks between potential solutions
plan management of foreseen supplier risks
revise project plans to manage emerging supplier risks
did the supplier perform during implementation?
what have we learned for our ongoing relationship with the supplier?
In-house resources risks part of risk assessment for feasibility
risks clarify as scope of project and in-house resource requirements clarify
required resources include IT infrastructure, technical skills (often IT, financial and operational), experience of implementing systems
trade-off between other calls on in-house resources and this systems project
ensure that you have planned, budgeted for and scheduled sufficient training and skills transfer
are our resources appropriate for projects like this?
what else have we learned for future projects?
Project organisation risks defined roles, responsibilities and reporting lines
defined project milestones
project control
project monitoring and evaluation
did we manage the project well
what have we learnt to help us manage projects better in future?

Summary

  • Ensure that you manage your IT projects to drive home the benefits you sought in the first place.
  • Concentrate on minimising risks and maximising rewards from your implementation.
  • Make the time to evaluate your IT projects, for the sake of those projects themselves and your future IT projects.
svg.lf_footer_svg{ height: 30px; width: 30px; }