Insights
Good Delivery Is Never One-Size-Fits-All
What separates a good implementation from a great one? Katey Cooper, Chief Delivery Officer, shares why the answer lies in experience, judgement and adaptability.
What separates a good implementation from a great one? Katey Cooper, Chief Delivery Officer at LendingMetrics, shares what experience has taught her about successful delivery, and why judgement and adaptability can matter just as much as the plan itself.
Over the years, I've seen one misconception come up time and again: that successful technology implementations come from following a standard process. I don't believe that's true. The most successful implementations I've led weren't the ones that followed the original plan most closely; they were the ones where the delivery approach evolved as the customer's priorities became clearer. That's where long-term value is created.
Methodology matters. Every delivery team should have one. But I don't believe methodology is what separates good implementations from great ones. Experience and judgement do. Methodology gives delivery teams consistency. Experience gives them the confidence to know when consistency needs to give way to what's right for the customer.
When LendingMetrics delivered humm Canada's implementation in under four months, it's easy to focus on the timescale. For me, it demonstrated something far more important. What made that project successful wasn't simply the pace of delivery; it was our willingness to adapt around the customer's circumstances. As the project progressed , we kept decision-makers engaged, focused on removing the biggest delivery risks first and maintained regular communication so issues were resolved before they became blockers. The pace was a consequence of those decisions, not the objective itself.
The project reinforced an important lesson for me: successful delivery isn't about following a process perfectly. It's about knowing which elements need consistency and which need to adapt to achieve the right customer outcome.
That's something I've seen repeatedly. No two lenders work in exactly the same way. They have different governance, different decision-making structures, and different commercial pressures. Trying to force every implementation through the same process rarely produces the best outcome.
Good Delivery Is About Judgement
One of the biggest mistakes a technology partner can make is believing the project plan is the project.
Project plans provide structure. They establish governance, responsibilities, and momentum. But they should never remove the need for judgement.
One thing experience has taught me is that customers judge a project by how well we understand what they need and whether we deliver against their expectations. A good project plan gives us the structure, but it's the experience, judgement and collaboration across the team that brings it to life. That's something that continues to shape how we approach implementations today.
I've learned that experienced delivery teams know when to challenge assumptions, when to change priorities and when to have difficult conversations before small issues become expensive ones. Sometimes that means reordering activities. Sometimes it means involving different stakeholders earlier. Sometimes it means slowing one part of a project down so the overall programme can move faster.
That's exactly what happened during our work with humm.
Faced with organisational change and ambitious delivery timescales, they needed a partner that could:
-
Work to ambitious timescales
-
Maintain implementation quality
-
Give them confidence throughout delivery
Rather than rigidly following the original project plan, we adapted the delivery approach to reflect the reality of the customer's situation. We prioritised the work that reduced risk earliest, maintained regular communication with decision-makers and adjusted the programme as requirements evolved, without compromising governance or quality.
That's where experience makes the difference. Methodology provides the framework, but judgement determines how and when to apply it.
Building Beyond Go-Live
One lesson I've become more convinced of over the years is that implementations shouldn't be designed purely for go-live.
I've seen organisations reach the end of a project only to discover six months later that they're launching a new product, responding to regulation, or changing lending strategy. If every implementation decision has been made around today's requirements, tomorrow's changes become far harder than they need to be.
That's why I believe one of the most important responsibilities of a delivery team is thinking beyond the project itself. Decisions made during implementation affect how easily customers can change policies, test new strategies, and respond to future demands once the project team has stepped away.
For me, the best implementations aren't remembered because they were delivered quickly or because every milestone was met exactly as planned. They're remembered because they leave the customer in a stronger position than when the project began.
That's the difference between delivering software and delivering lasting value.
For me, the real measure of successful delivery isn't whether every milestone was completed exactly as planned. It's whether customers are in a stronger position six months after go-live than they were on day one. If we've given them the confidence, flexibility and foundations to keep evolving, then we've delivered far more than a successful implementation—we've delivered lasting value.
