In this chapter we shall:
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.
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.
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:
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.
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.
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? |