You have to wonder how on earth big IT programmes such as the NHS National IT project recently in the news get into such serious trouble so often. The NHS debacle makes eye-watering reading: more than £2 billion of your money and mine has been spent, and apparently nothing of much value has been achieved. Given that those involved were probably capable and sensible, a lot of people find this unfathomable.
Big is Bad
Looking at this from inside the IT industry, it becomes a bit more fathomable. It turns out that the problem is, purely and simply, one of size. Of course, big isn’t necessarily bad in other industries, but very big software development projects are very often failures. What makes them fail is their size. But why?
Software development is a peculiar discipline. There are a several things about it which are just downright odd (and which defy common sense). For example, what do you think of these statements:
1. The more software developers you put on a large project, the longer it will take you to deliver a useable product.
2. It is impossible to know before you start a large software project what you’ll ultimately deliver to your users.
3. The worst software projects of all never finish.
4. The best software projects of all never finish.
When you start saying things like this to the average project manager who works outside the software industry, they look at you rather oddly. If you believe stuff like this, then a software project cannot be managed in any kind of conventional way, can it?
No, absolutely, it cannot. If you don’t know what you’re aiming for, it’s very hard to assemble a big team and manage it effectively. If the aimpoint is regularly changing, a big team will have to spend increasing amounts of time agreeing amongst themselves what it is, each day – and even after spending that time they may maintain different views. In short, a project management nightmare. You can start to see how the NHS IT system gradually fell off the rails.
Lets discuss the four statements above a little bit more:
Statement (1) above is stated as a general rule, which is a bit unfair – of course there are some circumstances where it isn’t true. But there are a surprisingly large number of circumstances where it is true, and software developers need to be continually mindful of whether they are on the right side or the wrong side of it.
Statement (2) is the clincher. Software is not something you specify at the start, then develop, then test at the end. Why? Because doing it that way you miss the trick – software can be adapted and re-crafted, in ways you hadn’t even considered when you started, but which offer themselves to you once you’re underway. So when you develop software you need to have an eye for these opportunities. Sticking to what it was you thought you were building to start with guarantees you’ll miss these opportunities, and for a lot of software, missing them is a mission critical failure.
Statement (3), as long as you don’t start quibbling about exactly what I mean by “never”, is unarguably true. The NHS system is an example – enough said.
Statement (4) is, I assure you, very true. The best pieces of software (of course, Truckcom is one of them – you knew I’d say that…) never stop developing. That’s the aim – to never stop. And that’s a good link to the next bit.
And yes, small really is beautiful
So you need a commercial framework which will keep things going indefinitely. At Truckcom, our commercial approach has been very carefully designed to match up with this model. It isn’t so hard to do for a small team, once everyone’s expectations are matched up – and as long as you make sure you’re managing it as an ongoing process, not as a start it – do it – and then stop it exercise (i.e. a project).
And when you start to consider the other rules above, they fall down one by one. A small team works quicker than a large one, mostly because it’s so much easier to keep just a few people on the same page, and up to date with the latest objectives – so you’ve won against rule (1).
With rule (2), though, the trick is not to conquer it but to accept it. With a small, close knit team, you can move the goalposts regularly and it just works. In fact it becomes the big win for small teams – the brilliant flexibility they can bring to the rewarding process of developing stuff quickly that works well.
Rule (3) doesn’t apply – and rule (4) is a given – if things are going well, why would you want to stop? After all, it takes quite a long time for the kind of evolutionary approach that develops the best software to deliver it’s very best results.
So yes, small really is beautiful.