A while back I was asked to sit in on a steering committee for a programme that had stalled. The committee was frustrated, the vendor was getting a hard time, and one integration had turned out much harder than planned. By the time I joined, the group had settled on what was wrong: the programme needed more technical expertise.
Earlier in my career I would have nodded along and probably offered to help find it. Instead, I asked something that felt almost too simple. Who owns the outcome here? Not the plan or the platform, but the things the business was meant to get out of all this money being spent.
Nobody answered straight away, and the pause was uncomfortable.
I've sat through enough of those pauses now to know what they usually mean. The technology probably does have problems, but that isn't what's holding things up. Everyone at the table owns a piece of the programme. IT has the system, the business has its processes, the project manager has the plan, the vendor has whatever is in the contract. All of them can be doing a decent job and the business still ends up no better off, because delivering the result itself isn't high on anyone's list.
Here's roughly how it goes. The programme reaches go-live, the vendor rolls off, the project team is thanked and disbanded, and IT moves the new system into support. Everyone has done what they signed up for.
The part that was never documented is who now makes sure the business actually changes the ways of working with the new system. Nobody picks that up, because it was never in anyone's job description.
So, the system runs, the old habits carry on beside it, and when someone finally asks why the numbers haven't moved or the promises haven't been kept, IT and the business each look across the table at the other.
What I've learnt from the technology leader's perspective is to look for the owner before I look at the technology. Someone in the business, close to the customer and process change or the number it is meant to move, must own the outcome by name.
That isn't me saying IT should step back. IT still carries the platform and the job of making the change possible. But adoption belongs to the business, and you can't hand it to IT by writing a longer requirements document.
The programmes I've watched land did a few things early:
💡 Agreed what should look different for customers, staff or the numbers before anyone started talking about platforms
💡 Put one person's name against the outcome, not a committee's
💡 Give that person the authority and the time to make the hard calls when things get difficult
💡 Kept an eye on adoption and real value, not just milestones and budget
None of this is me having a go at IT. The best technology teams I've worked with want someone on the business side who'll own the result with them. They know better than anyone that a well-built system people quietly work around isn't what they turned up to build.
What usually gets a stuck programme moving again is the question: who owns this? That's a leadership conversation more than a technical one, and it needs someone prepared to hold on to that ownership when things get uncomfortable.
So, here's my question for you this week. If you're in one of those meetings and the answer on the table is more help, resources or money, have you asked who is accountable for the outcome? If nobody can tell you quickly, you've probably found your real problem.
#NexusConnectNZ #TechnologyLeadership #DigitalTransformation