Lessons From The NBN Rollout For Major IT Projects

Whatever final form it takes, the National Broadband Network (NBN) is a massive exercise in project management and technology deployment. What lessons can IT pros draw from the experience so far when managing their own deployments?

Cabling picture from Shutterstock

One standard attack point for NBN opponents is to argue that the project is hopelessly behind schedule. Based on its own published plans, it is in fact three months behind its original projections. Leaving the politics of the NBN aside, there are many IT pros who would be more than happy with a delay of only three months on a project stretching over more than a decade. Many rollouts of complex enterprise software run much later than that.

During his exit press conference last week, outgoing NBN Co CEO Mike Quigley shared some thoughts on the progress of the NBN which also service as useful lessons for others.

During that talk, he singled out the IT systems being built to manage the project as a “major asset”, a useful reminder that the NBN requires more than just digging in pits, even if that generates the majority of the headlines. We’ve collected the highlights here.

Lesson 1: Accept that deviations will happen

Any large project requires a detailed plan — the overview corporate plan for the NBN runs to 100 pages on its own — but that doesn’t mean that every last detail will be accurate at the start. “It’s not uncommon that in something of this complexity there are going to be start-up learnings,” Quigley said. “People do need to get up the learning curve. If you’re tackling something big and complicated, you don’t always get it right when you’re tendering for such things.”

The key lesson? Ensure everyone involved in the project understands that the entire document is not set in absolute concrete. The more you can specify, the less room for arguments later, but absolute inflexibility won’t help.

Lesson 2: Ensure everyone knows changes alter costs

One common anti-NBN argument is to point to the changes from the original December 2010 budget and the revised plans that were delivered following negotiations with Telstra. “It is true that some of the costs increased from our original December 2010 corporate plans, but that’s because our shareholder asked us to do different things,” Quigley noted. Changes included adding in Optus’ cable network and taking on responsibility for greenfield sites.

Quigley draws a useful analogy: if you asked a house builder to add two bedrooms to your plans, you wouldn’t expect the costs and delivery times to be identical. The switch may well make sense and offer greater long-term benefits; criticising it for not being the original house would be pointless.

Lesson 3: Embrace scrutiny

The NBN is scrutinised to a much greater degree than most enterprise projects, something Quigley happily embraced. “I think it’s good that a government business enterprise such as ourselves is subject to ongoing detailed scrutiny. We are after all spending taxpayers money and we have to be held to account.”

While few IT projects will be ogled at that level (and with a chorus of various media interests commenting on every move), projects that don’t need to justify their choices can often fall behind without anyone even being aware. Don’t view questions about your delivery schedule as an attack; let them serve as a chance to check how well you’re performing.

Lesson 4: Don’t let minor details distract from agreed goals

With that said, the big picture remains important. Obsessing over minor details is pointless if the broad project remains on track.

In the world of the NBN, this comes in the form of claims that the project suffers from “cost blowouts”. Quigley emphatically rejected this idea when a journalist raised it as part of a different question. “The reality there haven’t been any cost blowouts. If you look at the number we’re reporting now compared to our August 2012 plans that there is no substantial differences. I think it’s frankly quite remarkable.”

The lesson? Don’t let unjustified assumptions about your project become accepted as established fact. If you are in fact delivering what was promised and agreed in writing, make sure everyone knows it.