Reports of a blowout in the Auckland Council information technology budget are as dismal as they are unsurprising. Nigel McNie, a software developer who has been building complex, bespoke IT systems for many years, offers some free advice.

Eyes have been rolling up and down New Zealand at news of a Super City IT cost blowout, and the tediously predictable way in which it happened.

With $1.2 billion spent and counting, this is shaping up, notwithstanding council efforts to play it down, as one of the biggest overruns ever for a country all too familiar with them.

Public IT projects are a notoriously problematic. Here’s some advice for anyone planning one.

1. Half of IT projects costing more than $15m massively blow their budgets

“Massively” for software projects means an average 66% blow out. These project also overrun their time by 33% and deliver 17% less benefit than they were predicted to. Ouch. (Source: McKinsey-Oxford, 2012.)

2. 17% of IT projects go so badly that they threaten the very existence of the company

The same study provides us with this quite incredible statistic.

Such overruns match or surpass those experienced by black swans among complex construction projects such as tunnels and bridges. One large retailer started a $1.4 billion effort to modernise its IT systems, but the project was eventually abandoned. As the company fell behind its competitors, it initiated another project  —  a new system for supply-chain management  —  to the tune of $600 million. When that effort failed, too, the retailer had to file for bankruptcy.

The Auckland Council has spent $1.24 billion on IT since 2010. The IRD transformation project has over $1 billion allocated to it. Just fixing Novopay has cost around $50 million. INCIS (the Integrated National Crime Information System)  was budgeted at around $85 million. Do you sense a pattern here?

3. There is no such thing as an off-the-shelf solution for your problem

The Standard’s article on the Auckland Council IT blowout says that the former head of information services “threw out the existing software used for property, consents and LIM’s (Pathway), in favour of heavily customising the expensive off the shelf SAP package”.

Read that again. The strategy was to start with something off-the-shelf, and then … heavily customise it.

For those unfamiliar with software development, this is like trying to build a five-storey house by starting with a one-storey house, and then attempting to build upward. At some point, you realise that you need to go back and change the foundations to get results, but by then you’re three storeys up. It will either cost you big time, or you’ll have to start again, or you’ll have to live with it.

4. With your complexity, you need to employ, or contract for the long term, the people who will build the systems

The art of building a great IT system is to truly understand the problem you are solving. This is easiest if your IT team is either in house, or you have a long, good relationship with them.

The crux of it is this: At some point, somebody has to take the problem and explain it to the computer. You will never get this right the first time. Your best chance for success is to have the team close enough to the problem, and able to move fast enough, that they can clarify the explanation given to the computer before you run out of money.

This feedback loop works best when you have a team that understands both software development and your requirements. Think of the institutional knowledge that a public department has. How can it be easier for an outside IT team to understand the nuance, the rules, the laws, the exceptions, the changing environment within your organisation, when the project is so large?

5. The way to spend more than $10m on an IT project …

… is to first spend $100K, and if it’s working, slowly spend more.

Code is great. Creating and deleting it is easy. Creating the right code is hard, but creating code that tests out approaches quickly is very cheap. Open Source software can give you huge assistance to get started, and New Zealand now has a significant pool of IT talent that knows how to build projects of this size.

Consider how startups turn into successful businesses. They spend a small amount (by necessity), and if it works, they get to spend more, until they succeed. Xero is an IT project that would cost more than $10 million if built from the ground up, but they didn’t do it all at once. They started with a small slice of the problem, and proved it would work as a business first.

6. Enterprise providers will screw you over and leave you with the bag …

… even you don’t know the full extent of your requirements right now. A huge project to work out what they might be, right now, so that we can spend years building systems to match it, is a comically bad idea.

Software and hardware are not like skyscrapers. You can’t design one up front, build it, and have it sit there for 80 years. Your requirements will change. New governments pass laws. Hardware becomes obsolete every three years. Security is a huge problem requiring ongoing investment to fix. What’s more, if you design up front, you make it so much harder to adapt to an improved understanding of the situation as you build.

You must embrace uncertainty. The requirements will not be fully understood up front, but if you keep your projects small and fast, there is room to adjust them on the fly. The software development community even has entire models of work built around this concept (for example: agile). You would do well to use them.

7. Open source is not a panacea

It’s incredibly helpful, but you must be careful how you do it.

If your project gets too large, you get stuck with many of the same problems that a “customised off-the-shelf” closed-source solution has. In particular, your foundations will move, and you need to accommodate this.

If you’re not prepared to keep the WordPress you built on fully patched, if you don’t appreciate that sometimes an open source project will make backward-incompatible changes, or if you simply make too many changes yourself, you are nearly as doomed as if you used closed source. At least your failure will be cheaper.

Keeping your project small really helps. The software development industry uses open source software all the time at small scale, with great success. Don’t make the mistake of thinking you can build larger projects on its back.

8. A path forward: develop your own in-house IT expertise

You have so much complexity and nuance inside your operation. Your IT projects will last far longer than the first hardware you buy. They will even outlast you.

Build a team inside your organisation that understands IT, that can begin to understand your organisation. Let them build small projects. You can bring contractors in to provide extra speed or expertise, but their projects must also be small.

IT is critical. You won’t function without it. You’re IT-driven whether you like it or not. Own it.