AI delivery in most UK organisations is still run the way traditional IT projects have always been run: a defined scope, a go-live date, a project team that disbands once the thing ships. A growing number of delivery leads argue that’s exactly the wrong model for AI, which behaves less like a finished product and more like something that needs ongoing tending long after launch day. We put some of the more common questions on this topic to a delivery lead at a UK financial services firm who asked to speak candidly, without attribution, about what’s changed in how her team runs AI work over the past two years.
Why doesn’t the traditional project model work for AI?
A: Because a traditional project has an end date, and AI genuinely doesn’t. You launch a piece of software and, barring bugs, it behaves the same way on day 500 as it did on day one. An AI model doesn’t. The data it sees drifts. User behaviour around it changes. Regulatory expectations shift. If you run AI like a project and disband the team at go-live, you’ve built something nobody is watching, and that’s when things quietly go wrong, usually months later, which makes the original cause much harder to trace back.
What does the product model actually change day to day?
A: Ownership, mostly. A product has a named owner for its entire life, not just its build phase. That person is accountable for whether it’s still delivering value six months in, whether it needs retraining, and whether it should be retired. We also budget differently. A project gets a budget line that ends. A product gets an ongoing one, because monitoring, retraining and governance don’t stop just because the initial build is finished. It sounds obvious written down, but it was a genuine shift in how our finance team thought about approving AI work.
Does that make AI more expensive to run?
A: It makes the true cost visible, which isn’t the same thing. Most of the AI projects that quietly failed in this industry over the last few years weren’t underfunded at the build stage. They were unfunded at the operate stage, because nobody budgeted for it, because it was scoped as a project rather than a product. The cost was always there. It just showed up as an unpleasant surprise instead of a planned line item.
How do you decide which use cases are worth this ongoing investment?
A: We score them on value and effort before we build anything, and we’re honest that most ideas don’t clear the bar. It’s tempting to say yes to every interesting AI idea a business team brings you, but a product mindset forces the question: is this worth owning indefinitely, not just building once? That filter alone kills off a lot of proposals that would have made a nice demo and a forgotten production headache.
See also: How Technology Drives Business Innovation
Is there a practical structure other organisations could copy?
A: We didn’t build ours entirely from scratch. Several UK consultancies have written publicly about structuring AI delivery this way. Transparity’s description of how its AI Factory model separates strategy, foundations, delivery and ongoing operation maps quite closely onto how we ended up running things internally, particularly the idea that operating and optimising a use case is a distinct, funded stage rather than an afterthought tacked onto the end of a delivery sprint. We didn’t adopt it wholesale, but it was a useful reference point when we were redesigning our own approach.
What would you tell a team just starting this shift?
A: Get comfortable saying no to more ideas than you say yes to, and get comfortable telling finance that the bill doesn’t end at go-live. Both conversations are uncomfortable the first few times. They get much easier once you’ve got one or two use cases running well enough that people can see what ‘well-run AI’ actually looks like, rather than just hearing you argue for it in the abstract. And keep the scorecard simple. Ours is basically value against effort, reviewed quarterly. It’s not sophisticated, but it’s a lot better than the alternative, which was no scorecard at all.
