Nearly a decade ago, I was in Tauranga for a conference event. As part of the event, visits to local businesses were available, and one of these was Port of Tauranga, NZ’s largest port. There we were told that Tauranga could land a container and rail it to Central Auckland faster than Ports of Auckland could process it through their container terminal.
That same year, I was running a business that had many transport companies for customers, including the largest in NZ. In the course of that business, we often heard concerns about the (in)efficiency of POAL. Remember this is all nearly ten years ago.
Fast forward to June 2022 and Port of Tauranga is still the largest and claims to be the most efficient in the country. What’s Ports of Auckland’s most recent claim to fame? Burning at least $65m (of presumably ratepayers’ money) in a failed automation project.
Making tech projects successful is a topic that I have researched in depth and can get pretty passionate about, so please excuse me if I get a little ranty on this one.
There has already been much commentary from national media outlets, technology interest groups and other commentators. Most of the commentary is explanatory and suggesting lessons need to be learned.
Lessons to be learned?
Are there really any new lessons here? This kind of stuff has been encountered over and over and over again. Some of the stories about these kinds of debacles are so old that the journos who wrote them have retired.
There are plenty of competent people who don’t need to learn these lessons, but all too often they are not invited to get involved or they are not listened to when these projects start up. I sit on a board of governance for a massive project that is quietly delivering to a strategy that was first conceived over twenty years ago.
There have been no less than two previous failures to realise this strategy, and yet the current team is making it look easy and we receive reports of successful milestones achieved month after month. This is by no means unusual, but we don’t hear about so much it when it goes well.
So, it is not - despite what some people would have us believe - that technology projects inevitably go awry. It comes down to a simple, easily understood and completely fixable problem: Don’t let people do things when they don’t know what they’re doing.
I don’t have any more knowledge than any other ratepayer, so I decided to find out what I could about the POAL debacle. It took me just 10 minutes of Google search to turn up what I think the root of the problem is.
The 2021 Ports of Auckland Statement of Corporate Intent is, like all such corporate documents, beautifully presented with lots of nice graphics, pictures of smiling wharfies, senior executives, and attractive images of the Auckland harbour with ships on it.
On page 5 we find that a principal objective of the business is to “Deliver automation”. There’s the problem (with the automation project anyway), right there in two words.
Silly me, I along with all my erstwhile transport company customers always thought that the principal objective of a container port would be to efficiently process containers.
Automation is not an objective
How on earth could anyone know when “automation” has been “delivered”?
I cannot believe that any executive worth their salt or indeed any professional director could accept that “Deliver automation” is a meaningful objective in itself.
Perhaps further in, on Page 8 “Key performance targets” … under the “Deliver automation” objective the key performance measure is “Successfully implement automation by June 2022”. Sigh.
So, zero out of 10 then, unless “Deliver automation” is actually short for “Deliver automation programme manager from the pain of having to implement this project”. Never mind that “implement automation” isn’t any more meaningful than “deliver automation”. We should give them some credit for making the deadline, I guess.
Even the most competent project team will flounder unless they have a crystal-clear view of what they are aiming to achieve. Without that, any project will become over-complicated and bogged down in technical details. In the worst cases, these projects become a kind of death march to the point where everyone involved is relieved when the powers that be decide to put them out of their misery.
I blame the scapegoats
In these circumstances, it is customary to find scapegoats that are in some way not involved in the current business. A popular choice is the technology vendor, after all they are the ones that sold us this pile of junk, right? Except that it isn’t usually that simple. Granted, technology vendors are sometimes due a share of the blame, but they are often subject to unfair criticism, which they prefer not to challenge.
Vendors work extremely hard in very competitive circumstances to win these deals; they must be able to demonstrate high levels of competence and the last thing they want is any sense of failure to taint the next deal. Nor are they likely to win future business by dissing a customer, however much that might be deserved. All of this makes vendors a convenient scapegoat option because they probably won’t punch back.
By all accounts, the vendor in the POAL case has an excellent track record of automating ports around the world, including Rotterdam which I suspect is slightly larger and more complex than Auckland.
Another hardy annual scapegoat is the “previous administration”. I’m fairly certain that the hapless Tony Gibson will handily absorb the blame for this one, as he has for charges under the health and safety act. If that doesn’t do the trick, Rodney Hide is probably fair game thus, leaving the hands of the current executive and board with sparkly-clean plausible deniability.
It doesn’t have to be this way
Of course, there is somewhere a project plan more detailed than the few words in the statement of intent, but I think the lack of clarity at the strategic level, combined with an apparent inability to get any questions about the project answered is at the root of this particular bonfire of cash.
To paraphrase Ernest Rutherford:
If a scientist can’t explain to their cleaner what they’re doing, then they don’t know what they’re doing.
So it is with strategic clarity. Complex is easy; simple, elegant strategy requires time and thought. If you can’t be bothered to figure out and articulate what it is you are trying to do with your digital project, then don’t expect any vendor or consulting team to be able to work it out for you.
Strategic intent is a very important concept that deserves a level of intellectual rigour, not just a nice glossy presentation.
I’m very thankful that our clients - who are generally significantly smaller and have far fewer resources than any major corporation - tend to be much better at this stuff. It’s not that the challenges are any greater, but the level of true accountability is.
We genuinely love working with these businesses!
Ray Delany is Founder of CIO Studio and loves working with organisations to drive business success with digital and technology – including automation that actually works! Drop Ray or the team a line to have a chat.
Get industry updates, tech news, and CIO Studio blogs free to your inbox!
