03 · Programme Rescue

Rescuing a Transformation in Flight

Rescue of a failing programme to redesign the Finance and Actuarial operating model.

The programme was already £2 million into a 24-month transformation

The objective was important. A recently acquired London Market insurer was taking more than six weeks to complete its financial month-end close. The process relied on extensive manual intervention and repeated corrections to the same data.

Finance and Actuarial were spending much of their time preparing the data rather than analysing it.

The business needed a fundamentally better operating model.

The programme wasn't delivering it.

I was given a simple brief by the COO and CFO:

Stop

My first decision was to pause the programme for 30 days.

That might sound counterintuitive when a programme is already behind and has spent £2 million. But continuing would simply have committed more money to a programme that wasn't under control.

I needed to understand what we actually had.

The business case was strong. The scope was deliverable. The expectations were achievable.

The problem was how we were trying to deliver them.

Requirements were continually changing. The SME had significant influence over the programme and could introduce new requirements with little challenge. The steering committee continued to accommodate those changes.

The programme was becoming a money pit of change.

The delivery date and cost were becoming secondary to satisfying the latest requirement.

Reset

I used the 30-day pause to speak to stakeholders, review the programme and establish what could realistically be delivered.

The answer wasn't to reduce the ambition. It was to sequence it properly.

The scope needed to be phased rather than delivered in parallel. The operating-model changes needed to be adopted alongside the technology. And the stakeholders needed to agree what the programme was actually committed to delivering.

I restated the objectives in business terms, reset the programme structure and milestones and introduced stronger control around requirements.

I also introduced a dedicated data-quality workstream and restructured testing so that development and testing worked much more closely together.

A PMO specialist strengthened communication across the programme and with the Board, while also providing tighter control of budget and spend.

Make the work visible

One of the simplest changes made the biggest difference.

I brought the teams together into one location.

Different functions. Different vendors. One room.

We turned it into a war room.

The walls became giant whiteboards. The project plan and deliverables were visible to everyone. We created a physical Kanban board.

The programme was no longer something that existed in separate workstreams and stakeholder meetings.

Everyone could see what needed to happen, what was happening and where we were stuck.

We introduced morning working-party stand-ups and afternoon stakeholder sessions.

The purpose wasn't more governance.

It was visibility, accountability and speed of decision-making.

Make the difficult decisions

A programme rescue ultimately comes down to decisions.

Two were particularly difficult.

A General Ledger component had already been selected. I concluded that it would not meet the business requirements.

I changed it.

A “big data” technology had also been selected for the core solution. It had been designed for organisations considerably larger than ours and, in my view, was inappropriate for the business.

I rolled it back.

Both decisions went against the wishes of senior leadership.

I knew that challenging them would put a target on my back.

But a programme manager cannot simply implement decisions they believe will fail.

One vendor project manager privately believed that the technology use case was unsound. But the instruction had been to implement it, so that was what they would attempt to do.

Change the business, not just the technology

The transformation was fundamentally about the Finance and Actuarial operating model.

The business had three different Finance operating models that needed to become one.

Too much time was being spent preparing and correcting data before the Finance and Actuarial teams could analyse the business.

The new model reversed that.

Data would be corrected closer to source, rather than repeatedly repaired downstream.

Manual adjustments were automated where possible.

Data-quality feedback loops were introduced.

Governance and audit trails were strengthened.

The result was a much more transparent process.

Data scientists and model validators could do the jobs they had been employed to do rather than spending their time cutting and pasting data into spreadsheets.

The actuarial process became less of a black box.

Business stakeholders could see how the numbers were derived and understand the relationship between the data and the resulting business position.

Rebuild confidence

The team itself wasn't the problem.

They were frustrated because there had been no credible plan, no locked scope and little certainty about what would actually be delivered.

They wanted order.

The vendor teams had different commercial incentives, and the business didn't always appreciate the cost of missed dependencies. If a business deliverable was a week late, the vendor resources could remain engaged for another week — and the programme cost increased accordingly.

The existing leadership team didn't need replacing.

They needed direction and certainty.

My bigger challenge was rebuilding credibility with the steering committee.

That was difficult because the committee had also contributed to the problem by allowing requirements to remain fluid and by giving the SME significant influence over acceptance.

At one point I had to tell the Board that the system they believed was the system of record wasn't actually the true system of record.

We needed to change the environment to make it so.

These weren't comfortable conversations.

But the programme couldn't be rescued by telling people what they wanted to hear.

The point where it became real

For most of the programme, it was difficult to say with confidence that we had turned the corner.

There were too many unresolved dependencies and too much ambiguity around accountability.

Four weeks before go-live, we completed a clean parallel run of the new solution.

For the first time, we had evidence rather than optimism.

That was the point I knew we had a credible path to delivery.

The outcome

The programme delivered.

The Finance and Actuarial operating-model transformations were completed.

The financial month-end close was reduced by 28 days.

The repeated reworking of data to establish the month-end position was eliminated and data quality improved dramatically.

Costs reduced.

The new model also provided a level of business analysis that surpassed many larger organisations.

The finer level of data enabled detailed “what if” analysis of reserving and pricing that had not previously been possible.

The first live month-end close demonstrated the value of the transformation.

The business could see its position more quickly, with better data, greater transparency and far less manual intervention.

The programme had stopped being a technology project and had become what it was always intended to be:

The lesson

When a programme is failing, the instinct is often to change the programme manager, add more people or increase the reporting.

Sometimes that works.

Often it doesn't.

And the money already spent is gone.

The question is what you do next.

You can keep tweaking the existing programme and hope it eventually becomes something that works.

Or you can stop.

Learn from what has happened.

Salvage what you can.

Reset the foundations.

And build a deliverable solution.

Sometimes the most cost-efficient way forward is to stop, learn, and then start again.