Why IT projects in government are more likely to fail

Putting IT and government in the same sentence may elicit cynical smiles. There’s a general belief that these projects are always too late and way too expensive. Tax money is wasted, and it’s all a disgrace. Let’s step aside from the question as to whether IT projects in government are actually worse than in commercial organizations. Our own evidence (taken directly from the SIG software analysis database, the largest such database in the world) shows that, in reality, government IT projects are on par with those in business. But apart from the question as to whether governmental projects actually fail more often than not (which again, they don’t), could it be true that IT and government isn’t a lucky combination? It’s a platitude, and you know what they say about platitudes: there’s always some truth in it. What could be the cause?

Of course, there is no end to people who claim to have the answer. It’s always important to consider the background of the person stating the claim. If somebody is pushing the use of certain (new) technology to prevent IT disasters, more often than not, that same person is selling this technology. New technology isn’t the silver bullet; it’s more complicated than that.

Here’s what I think:

• The distance between business and IT is fundamentally bigger. In most organizations, business can be very close to the development team. It’s certainly true that sometimes they’re not, but in government, they are fundamentally split apart. In government, parliament takes decisions, which are then passed on to agencies to implement. Developers are at least one (un-bridgeable, if that’s a word) step further away.
• Governmental systems tend to be complex, simply because they have to deal with many exceptions. Governmental systems cannot focus on just one target group, like commercial businesses can (and actually should to be successful); that would be unacceptable. These systems are typically responsible for a very vital process, which all people in an entire country, for instance, depend on.
• In most countries, political changes are frequent, thus implying different choices, often with big consequences for IT. These decisions are probably taken with the best intentions, but without considering IT consequences.

These are fundamental things that cannot easily be changed. The distance between political decision making and the actual building of software cannot realistically be made smaller. It’s simply the result of the way society is organized. We need to accept that.

Making systems less complex is easier said than done. Drastic simplification sounds nice in a PowerPoint, until you realize that there’s this exception and that special case, that this family all of a sudden doesn’t receive their money anymore, and that company goes out of business. Where focus is a good thing for businesses, government should not focus: they should serve all. Society is complex, and governmental software reflects that. That’s something we need to accept.

What would help, is for decisions to be evaluated for feasibility. The Dutch Eerste Kamer, for instance, has the obligation to safeguard whether a new law is realistically feasible. More IT knowledge and understanding of the consequences of a seemingly legitimate request would help. However, given that most decisions are compromises and the result of long complex negotiations, it’s unrealistic to expect that after days of heavy discussion, a decision would be taken differently because somebody says that this would be hard to implement in some IT system. We need to improve here, but accept that this is how democracy works.

So, in short, it’s important that all parties (1) realize that these fundamental differences exist and won’t go away, and (2) keep a very close eye on everything that’s being built^*, and correct any deviations as early as possible.

*For those paying attention, this is the part where I’m selling software assurance. Just saying. But honestly, I really believe it’s the only viable way forward.