Big IT Projects fail all the time
How to Run an IT Project
A practical look at why IT projects go wrong and what you can to do avoid it
You know something is a thing when it has a “List of …” page on Wikipedia.
So, of course, there is a list of failed and over-budget custom software projects. Ah! The Big IT Project. You can already smell the money; purchase orders being raised, PowerPoints being produced, gantt charts everywhere, outsourcing companies straightening their collective ties and preparing their packs and claims.
Here’s what happens: an executive spots a fiddly problem in the organisation and brings it up in a meeting (there is probably catering at this meeting). Another C-titled person says she has a similar problem. Then some wag decides they need to run a transformation programme to fix it. So they add a big box onto a PowerPoint or a line on a tracker called “Big IT Project” and dump all those annoying problems into there. “We need a name for this project,” someone pipes up. This is the conversation they enjoy the most, and probably the pinnacle of engagement. “Barracuda?” someone suggests.
“Cherrystone?”
“Topaz?” Everyone is having so much fun. Isn’t this project going well?
On a high, the CFO signs off a budget and hands things over to a Programme Manager to deliver. They’ve done the hard bit now, right? With a name this good, Project Echelon will basically deliver itself. IBM put together a great pack and SAP have a new product coming out in the next year to eighteen months that can basically do it all, so how hard can it be?
I build technology products. Although increasingly these days I sit in meetings and ask other people to build technology products. I’ve worked on some that have gone very well, and I’ve worked on (and contributed to) some that have gone very badly. I’ve even been involved (obliquely) with one of the ones on the famed Wikipedia list. #lifegoals, I guess?
I’d like to say that I’ve solved the problem of IT projects and that the ones I run go well, so here are four tips you can follow to make yours all go well too (number three will shock you). However, life is rarely that straightforward. If there were easy things to do to make multi-million dollar projects run smoothly, they wouldn’t keep failing.
So what’s the difference between projects that go well and projects that fail, and where do we go from here? Perhaps we can try to say something more nuanced.
Sometimes, when I’m browsing the internet, I see websites that look like they were once beautiful but have gradually fallen into disarray through tweaks and changes. Often these sites belong to big companies that have plenty of money. Maybe the logo is stretched out of proportion, the icons are inconsistent, or half of the site is inexplicably in Times New Roman.
I have a theory about these, because I’ve seen them happen. The project had one person who cared deeply and considered all these small details. Made sure the graphics were loaded in correctly. Read the manual to check how to set the background to transparent. Spotted that issue with the site not working on Android and filed a bug. This person cared about the product. And then… they got a new job.
The website became like Britain after the Romans went— all the great edificies left to wrack and ruin with the new site managers like the Anglo Saxons; not sure what the deal is with all these aqueducts. Or how to add a new bath in. I came, I saw, I bodged it.
Caring. I wonder if caring is the most overlooked requirement in web development. Caring enough to pay attention to small detail. Let’s break down a bit more what we mean by caring:
- To know that there should be a design philosophy behind the website. Or that the website is running slowly, or that it should be easier to use than it is.
- To bother to come up with a design philosophy, or find someone who can come up with one, or fix the issue that is causing it to run slowly.
- To remember the details and implement or check them in future.
If people don’t care about the project, they’re just delivering. They may care deeply about their profession and reputation, but ultimately, they’re at the mercy of a requirements list. And, I can say with complete confidence, there is no requirements list that contains everything you need to think of when making a large project. It’s just not possible to write down every decision ahead of time. The decisions are too numerous, too small, too interconnected. Too changeable in the face of cold hard reality. Ultimately, the final product becomes the list of requirements.
If you browse that list of failed IT projects (which is barely the top of the polar bear’s head on the tip of the iceberg), you’ll notice how often you see the word “outsourced”. The company with the problem has found a big IT conglomerate and said, “Look, if I give you a wheelbarrow full of cash, can you make this problem go away for me?”. Who doesn’t want a wheelbarrow full of cash?
The issue is not with outsourcing per se, but with what has been outsourced. You can outsource the work, but it’s extremely difficult to outsource the caring. And if you do successfully outsource the caring, when all those developers and consultants have gone away you’re left, once again, like those Anglo Saxons, finding out that ducting all this aqua is a real pain in the gluttonous maximus.
From a high level, the projects I’ve worked on that have gone well look identical to those that have gone badly. Sometimes the same people are on them. Often the budget and governance structure is the same. Even the reporting packs look identical, with the same patterns of red, greens and ambers and pretty little images showing heat maps of risks and issues.
The difference is in how much effort the team are putting in to catch and fix all the millions of tiny decisions that aren’t on any charts or requirements documents. And this difference is invisible. After all, if it weren’t, everyone would know some projects weren’t going well, and would step in and do something about them, rather than just heaping the budget onto the massive money pyre of failed delivery.
And here’s what happens: Project Echelon keeps cropping up in executive level meetings. It’s delayed again. The first version hasn’t gone down very well, for a series of slightly nebulous reasons that are too complicated to express through PowerPoint. Some unforeseen issues have arisen and it’s going to cost, oh I don’t know, another £12m now. No one mentions sunk cost fallacies. The execs eat their sandwiches and tiny fruit skewers sadly. Echelon lumbers on for a bit until someone cancels it and adds it to that Wikipedia list. Or perhaps it crawls over the finish line, with enough of it complete that success can plausibly be claimed.
“I’m pleased to announce Project Echelon is complete,” internal communications write at the bottom of an all staff mail, just tucked under the bit about the annual cake sale.
The execs breathe a sigh of relief. Maybe their bonuses will be safe after all.
A few months later a new CTO is appointed. “I’ve reviewed our estate and we have some significant tech debt,” he says, “we need to run an IT refresh project.”
“Is that like the IT transformation programme we ran last year?” Someone asks suspiciously.
“No,” the CTO says, somehow managing to keep a straight face, “it’s completely different.”
If all this talk of keeping people engaged isn’t enough, when you tilt too far the other way you have problems too. Very engaged employees that care too much treat projects like religious crusades. It’s the plot of a very unexciting action movie. Because they believe it’s for the greater good, the end starts to justify the means: arguing in meetings, delaying projects, generally causing issues.
So here are the conclusions I’ve reached: it’s easy to hire skills. It’s difficult to hire people who care. And when we look to hire people or companies for projects, we judge them by their skills not by the amount they care. But IT projects don’t go wrong because of not enough skill. Look at the organizations who have had failed IT projects: the Swedish Police, the US Air Force, the UK Border Agency. They aren’t short of developers. These projects didn’t fail because the developers asked how to code a database on Stack Overflow and didn’t get a good enough answer. They went wrong because of not enough care.
The bigger the project, the more decisions and the more you need people at the right level who care just the right amount. People who care enough to spot problems and work them through, but not so much that they cause problems for other areas.
Agile says that developers and customers should work together in small groups and iterate frequently. Amazon added the two pizza rule to keep teams small. Squads, scrums, guilds, gangs, coteries, whatever the latest new term is. All of these ideas are trying to do the same thing: keep the group small and focused so that the people there can care about what they’re doing.
Back to Project Echelon. What went wrong? Well, it started with the idea that all the annoying, fiddly problems could be bundled up and a barrel of money could be chucked at them. It may have looked neat on an org chart, and been a load off everyone’s mind, but those fiddly problems were still there, just buried. They were tricked by the hopeful siren call of a magic bullet.
Nuance, caring, attention. These are ideas that don’t scale very well. It’s difficult to care about a project that’s so big you can’t see the totality of it and your impact is small. When the project is so big that it’ll “fix everything”, chances are it’ll fix nothing.
If there’s a team that works together well, and cares at the right level, then they have a fighting chance of solving one or two of those problems. Even if they don’t have the skills right now, that’s okay — you can use money to buy skills. You can’t use money to buy care.
But the idea of chucking everything into a bucket and hoping that it’ll magically get sorted? Or that you can pay someone else to care about the problems that even you don’t care enough to look at? Well, you better make sure you have a good project name, because it’s soon going to be appearing on the bottom of a Wikipedia list.
