Did you read what the National Audit Office said about the notorious NHS IT project recently? In case you missed it, here are some of the highlights.
"the core aim that every patient should have an electronic care record.will not now be achieved."
"the NHS is now getting far fewer systems than planned despite the Department paying contractors almost the same amount of money."
"in acute trusts, the systems are mainly providing administrative benefits, rather than the expected clinical ones."
"the £2.7 billion spent so far.does not represent value for money."
What's your response to this? Exasperation that another government IT project has failed? Relief that you aren't responsible for this project? A slight chill of recognition at the problems they've described?
Probably a bit of all three. But let's look for a positive. Can we learn anything from what's gone wrong?
The conventional response to project failure is to do more of the same. More steering committees, more strictly defined roles and responsibilities, more detailed schedules. But take a step back. If the same things keep going wrong, perhaps it isn't the way we're applying the technique that's at fault. Shouldn't we take a critical look at the technique itself?
That was why I found this article by Peter Henderson so interesting - here's what he said.
IT projects - like other types of project - traditionally fall into two distinct phases. First, comes the specification. Once everybody's happy with it, it's signed off. Then you move on to phase two, and implement the specification.
But in fact it never works out like that. Once you start the implementation, requirements change. New requirements are added and existing requirements are revised. This is what Henderson calls "project drift". You may not be familiar with the term, but I'm sure you're familiar with the effect.
And project drift causes most of the problems: budget over-run, missed deadlines, broken promises about the benefits, functionality that doesn't fit the real need.
The obvious response is to see project drift as the culprit, and try to eliminate it. But Henderson says that's the wrong approach - because project drift is unavoidable.
During any project, both customer and supplier learn. The customer learns about the real potential of the system, and the supplier learns how the customer really works. As both learn, they change the requirements - they would be stupid not to. So any large project always turns out to be different from its original specification.
If we ignore project drift - because we think it's a symptom of failure - we actually create problems for ourselves. Spending more time and money on the specification, and then refusing to diverge from it, won't help. Instead, we should plan our project EXPECTING project drift to happen.
Here are the three key things you can do.
First, your project management and execution must look constantly for drift. You should expose it and resolve it as early as you can. Sometimes that means changing the requirement, but sometimes it means deciding against a potential improvement. Either way, the earlier you resolve drift, the easier it is to deal with.
Second, design your project to be "loose-coupled", or modular. If a system is loose-coupled, that means you can make changes within one component of the system without having to make changes in another. Then you don't have to rewrite the whole system every time you make a small change in one part of it.
Third, don't try and implement everything at once. Test prototypes in limited areas so that you can learn before you implement. And then implement modules separately if you can, so that users are familiar with the system as later stages are introduced.
So that's this month's message. If you're involved in a large and complex project, don't expect to be able to define what you want right at the start. Your project requirements will drift - there's nothing you can do to prevent it.
Instead, plan your project to take account of drift:
- expose drift as soon as possible
- design your system to be "loose-coupled"
- run prototypes and implement in stages
If you're about to embark on a major project, give me a call on 01244 314567 or email me at Stephen.errey@lucidea.co.uk . I'll be happy to explain more about how this approach to project management will benefit you.
<< Back