The dreaded feature creep

Even in the best managed projects, feature creep is difficult to avoid. Here are my tips for how to reduce the risk.

Apologies for another quantum mechanics in-joke. But this explains a lot.

Right, I’ve been told off for starting too many blog entries with “I’m afraid this is going to be another moan”, so this time I’m going to try to be a bit more positive. My last post had a go a web designers often over-charge for websites, and people who actually pay them that much. This contained an observation that this can apply to IT procurement more widely, with an example of the notorious contracts for £3,500 per computer in some government departments. Having thought about this, it was a harsh generalisation.

Where government IT projects overrun costs, it’s rarely because a company charged a fortune upfront. It’s usually because the initial costs are cheap but the contractor charges extra for things like including additional features, or installing new hardware. In some cases this gets out of control, like ridiculous call-out fees for something as simple as changing a mouse, and that is a key driver to the argument that IT companies rip off Whitehall. But the IT companies do have a good counter-argument. They often say that if government departments ask them to do a simple task, and then keep changing their mind in mid-project, it really does cost that much to keep making all the changes. I have come across both scenarios in my time.

But if we forget these two extremes and assume both client and contractor are genuinely motivated to work together and keep costs down, the fact remains that controlling costs is an absolute bugger. It is very difficult to get every detail of a working IT system right when the system currently only exists in paper plans. The mistake that must be avoided at all costs is “feature creep”, where more and more changes are requested to software in development, until costs rocket, the original design is no longer fit for purpose, and if you’re the NHS – well, we know what happened there. But there’s nothing new about feature creep, so why is does this mistake keep being made?

I’m a software tester and not a project manager, so I won’t claim I have the magic answer for how to run a project cheaply. But based on how I’ve seen projects go from my tester point of view, here’s my tips for how I think feature creep can be avoided:

• Don’t embark on a “big bang” project unless you have to. Hugely ambitious and revolutionary IT projects might make the project manager look bold and decisive, but this is how the most embarrassing and expensive failures begin. If you can, deliver a large project in manageable stages. That way, you can observe how taking to the new system works in practice and adjust your plans accordingly. It also reduces the worst-case scenario from a whole project getting binned to losing only a single stage.
• Get the software testers involved as soon as possible. All right, I’m a software tester so I’m bound to say this, but it’s good practice. There’s plenty of good reasons unrelated to feature creep, but one added advantage is that it’s the job of software testers to look for flaws from day one. A tester saying “Have you thought about this problem?” or “Wouldn’t it be better if we did that?” at design stage could save an expensive mid-project feature change later.
• Get the users involved as soon as possible. This isn’t always practical if your intended userbase is the general public, but if it’s for your own workforce you should listen to what they think. Some systems, I swear, are designed, programmed and tested without consulting anyone who’s actually going to use it. Testers and programmers can sometimes make an educated guess on how a system might be used, but they won’t know the subtle intricacies of how things work in practice on the shop floor. And again, if a prospective user spots a flaw in the business process at design stage, you’ll be grateful.
• Remember there’s always the next release. Once the programming starts, it is inevitable that you’ll discover something isn’t designed as well as it could be, or a feature wasn’t included that should have been. That’s not the end of the world, but it will be if you commit a complicated patch every time this happens. Ask yourself if this change can wait until the next release when it can be planned and delivered properly.
• Include people in project management who understand both the business and the software. I keep saying this, but feature creep is one of the strongest reasons why. It’s a lot easier to weigh up the pros and cons of a last-minute feature if you can weigh up the business benefits against the technical issues yourself – leaving the technical arguments to another department or the contractors is not reliable. Understanding both the business and technical aspects also makes it easier to find a practical solution when all other options are being dismissed as technically impossible or expensive.
• Avoid a departmental free-for-all. Assume every department in your company considers themselves the most important one. If Finance request feature A because Anti-Fraud requested feature B, leading the procurement requesting feature C and so on, you are in trouble. Someone has to make a decision on which features are feasible and which ones aren’t, which features can’t wait and which features can.

However, none of these techniques are foolproof. IT projects are unpredictable, and unless you are very lucky, management reaction to unexpected problems is equally unpredictable. It is very rare that I have been involved in a project where everything went to plan. Which brings me on to my final and most important tip:

• Allow time in your project for the unexpected. Delays and overspends sometimes can’t be avoided. Sometimes a serious bug can only be fixed by a completely new feature. If a decent system gets delivered in the end, the project should not be considered a failure just because it was late. But if will be if you’ve tied your hands to a deadline, by perhaps advertising a launch date for an exciting new product you can’t deliver, or promising a Cabinet Minster your high-profile project will definitely definitely definitely be ready to go on a certain date. All too often, the solution found is to shorten or cut the testing phase – after all, it looks like it’s working, doesn’t it?  – and it’s the users who discover the real price for ticking the “on time” box.

Unfortunately, the standard reaction I’ve seen to botched feature creep-ridden projects isn’t to learn any of these lessons – it’s to blame the contractors. And that usually means making the same mistakes all over again with new contractors. This is why it’s dangerous to dwell too much on “rip-off” IT projects as if it’s always someone else’s fault. Regardless of who’s in the right and who’s in the wrong, the fact remains that clients and contractors have to work together. It is only with a true spirit of trust and mutual understanding that problems such as feature creep can finally be put to bed.