Skip the navigation
Opinion

Early lessons from Novopay

Institute of IT Professionals' CEO asks what can be learned from the saga as the IRD embarks on a billion-dollar IT transformation project

By Paul Matthews
February 12, 2013 03:24 PM ET

IDG News Service - Several inquiries into Novopay, of varying independence, are already underway. However there are already lessons we can learn from the debacle, especially in the context of the proposed $1.5 billion IRD IT spend up.

It's important that we resist the urge to rush to judgment on the Novopay situation; it's likely many more details are yet to emerge before the picture is completely clear. While the documents released recently by the government certainly paint a fairly damning picture, that's only half the story.

However even at this early stage, some things are clear. For starters, it's fair to say that the project launch has been an abject failure, certainly in the eyes of the users. Even if the system is fully salvaged and regardless of where blame eventually sits, the fact is that Novopay will be used as a case study in future IT courses for many years to come.

And secondly, there are some lessons we can learn for future projects such as the upcoming major IRD revamp, that perhaps could even help avoid some seriously massive problems in that and other large-scale taxpayer-funded projects.

Lesson 1: Does the tender process lead to bad results?

Someone asked me the other day whether it was clear yet at what point the project first came unstuck. In our view, it was probably before it even started; likely before the tender had even been won, when various companies were jostling over the project.

Why? We're talking about a complicated project. Not only are there more than 100,000 people relying on the system, there is also massive complexity in how these teachers and support staff work, with many schools doing things in different ways.

There are part-time teachers working across multiple schools, big variations in pay and contract rates and much more. You could say "yes, but it's just a payroll system..." but it really ain't that easy in this case.

So what do you do if you're tendering on a hugely complex project like this one? Well, you basically have two options.

You either spend a considerable sum - probably in the hundreds of thousands of dollars or more -- working through the requirements in absolute detail and properly speccing the whole project out, all the while knowing that there's still a very high chance you'll lose the tender and thus have to write off that initial investment.

And, of course, you have to build the ever-growing cost of this work on unsuccessful tenders into the price of successful ones.

Or option 2, you basically "wing it". You still spend a bunch of time, but you only end up with a rough idea of how complex you think the project will be, cost that out, build some fat in for complexity you missed, put in a bid and cross your fingers.

I'm not saying this is what Talent2 did in this case at all, but it is clear the complexity was completely under-rated, and one does wonder if the incumbent lost the contract because they knew full well the complexity involved. Perhaps they based their quote on that knowledge - and were undercut in the process. But I digress.

While a simplification, those are the two options in front of most companies bidding for complex projects in government, and neither lead to a good result. From that perspective, it's excellent that minister Steven Joyce has announced there'll be a review into how future projects are tendered.

But what are the implications for the upcoming IRD system? For one, we have to accept the fact that the larger and more complex a project is, the greater the chance it'll fail and if it does, the bigger mess it will make.

So when we're talking about billion dollar projects, the chance of failure is huge and the cost fallout could be felt for many years to come.

The logical answer is simply to chop it up into a series of far smaller projects or components, focusing on how each component interrelates.

While this approach might take a little more work up front, the risks are far lower than what appears to be the current "big bang" thinking of just farming the whole project out to some offshore company and hoping for the best.

Under the component approach, if some projects fail the fallout is contained and an appropriate plan B can be put in place. To put it another way, if one company is handling the lot, you can't just kick them to the curb and get someone else to do it without massive cost. With smaller projects you can.

But more to the point, this approach doesn't exclude capable and incredibly competent local providers from what will likely be the largest government ICT spend-up in a while.

Rather than sending it offshore, the government could back New Zealanders and use it to truly transform our industry and position it to take on the world, in a way that dramatically reduces risk. But will it?

Lesson 2: Launching to 100 percent capacity on day one

Here we go again. IT and project people should have already understood why a full scale launch on day one was a bad idea. Yet by all accounts, that's exactly what happened with Novopay.

Rather than a staged release and picking, say, 100 schools for the first run, then ironing out the teething issues in a manageable way before taking on more, someone just flicked the switch and hoped for the best.

And predictably, boom! Some relatively minor teething issues occurred but because they were at maximum capacity on day one, guess what happened?

The issues were at a scale they couldn't manage and their support service was totally overwhelmed, mainly initially over missing payslips of all things. Manual processing was required, which takes time and causes audit issues. They really never caught up from there.

So what we're really interested in is why and when that decision was made to push go on 100 percent capacity on day one -- because that was just 'asking for it'. Was it made as a result of political pressure to go live at all costs? Was it pressure from the incumbent? Or was it simply made out of incompetence from those who should have known better?

There was originally intended to be a staged release, or at least a pilot programme, of just the South Island. It was scrapped, presumably because the decision-makers had such complete faith in the system they decided that it wasn't needed.

Conclusion

So there certainly are going to be many lessons learned from Novopay and those two are barely scratching the surface.

However neither is new, and one does have to wonder why they have cropped up once more. Will we just continue to make the same mistakes into the future?

Let's hope that if our government does throw a billion dollars into revamping our tax system, Kiwi companies get a chance to do it right rather than being cut out of the project altogether.

Matthews is chief executive of the Institute of IT Professionals

Originally published on computerworld.co.nz. Click here to read the original story.
Reprinted with permission from IDG.net. Story copyright 2014 International Data Group. All rights reserved.
Our Commenting Policies
Blog Spotlight
Sharky

This pilot fish is a contractor at a military base, working on some very cool fire-control systems for tanks. But when he spots something obviously wrong during a live-fire test, he can't get the firing-range commander's attention.

Sharky
Sharky