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?

Are web designers the new car mechanics?

Websites are easier to make than most people think. Bear this in mind when a website designer wants a hefty payment.

A joke, obviously. But does this sales pitch work in IT?

Advance warning: this post is another moan. Up to now, I’ve had two pet hates: people who sign up to wildly optimistic cheap/convenient IT projects that turn out to be unreliable and expensive; and at the other end, people who block trivially easy IT projects because of silly overblown cost estimates. I’d forgotten the third type. But we’ll get on to that later.

This story begins with my website – you know, the one in my shameless plug masquerading as a piece on Search Engine Optimisation. Well, my web traffic is still quite abysmal, in spite of pushing up the Google rankings. But from the few people who’ve looked at the site, I’m quite likely to set up a website for an arts organisation, which I’m happy to do as a freebie; and if all goes well I may get some paid work off the back of that. And in this scenario, the obvious question is: how much should I ask to be paid?

The thing is, there’s nothing special about my web design knowledge. What I created for myself was technically very basic (I was using a free web template and Kompozer if anyone's wondering). I’d rate my skills above those of a 13-year-old who has discovered FrontPage – I do at least understand the importance of Cascading Style Sheets, W3C compliance and not doing fancy animated backgrounds – but ask me to produce a site that handles user-uploaded content, streaming video or credit card payments and I wouldn’t have a clue. And yet paltry offerings to the interweb like mine seem to be regarded as the height of technical genius.

How to spot a black swan

New research suggests one in six IT projects run three times over budget. Keeping expectations realistic might avoid this.

"Well, maybe it collided with a tin of paint"
(Photo: Jon Smith photography, Flickr)

A study that came out last week was about IT projects breaking their budgets (see this and this). According to the research, in a sample of 1,471 large-scale IT projects, they ran on average 27% over budget, but the headline-grabber was then observation that one in six projects go three times over budget. The researchers have named these projects “black swans”, and blames managers for failing to account for low-probability high-cost risks in big IT projects. To the more cynical IT professionals, this is nothing unexpected. It’s not hard for a software tester to witness at least one project like this – failing that, you don’t have to look far for the latest story about the notorious NHS IT system.

What was interesting, however, was the reference to the Black Swan theory. This phrase was originally coined by Lebanese-American essayist Nassim Nicholas Taleb. There’s a whole book about this, but the basic idea was that there was a time when it was believed all swans were white. No-one had ever seen a swan in any other colour, so no-one gave serious thought to this possibility. Then Dutch explorer William de Vlamingh went to Australia and discovered that some swans are black, fundamentally changing how people saw swans. And in hindsight, it was nonsensical to assume swans could never be that colour just because you hadn’t seen one before. Taleb used this analogy for all sorts of events: he suggested, amongst other things, the attack on the World Trade Center and the Credit Crunch could be considered “black swan events” – both unexpected at the time, both easy to rationalise now.