The Programme That Was Green for Four Months

The situation

About 2 and a half years into my time at Wema, I was asked to take over a customer-onboarding programme from a colleague who had moved to another part of the bank. The programme was meant to digitise account opening across the whole branch network, which is a genuinely large undertaking touching technology, compliance and the daily reality of every branch.

On paper, it was green. It had been reporting green for 4 months. Within my first week it was obvious to me that it was not green at all.

There were about 5 workstreams: the customer-facing app, the back-end integration with the core banking system, identity verification through a third-party supplier, the compliance and know-your-customer rules, and the branch operations and training. And here was the quiet disaster: each workstream lead was reporting their own status honestly, and each of them, individually, was roughly right. Nobody was lying. The problem was that nobody was looking at the joins between them.

The identity supplier’s API was not going to be ready until 6 weeks after the app team needed it. The compliance team had not signed off the new process, because nobody had formally asked them to. And branch training was scheduled for a go-live date that had quietly become impossible. Every one of those was a crack between two workstreams, and the status reports looked at workstreams, not cracks.

What I did

The first thing I did was resist the temptation to fix anything, which is harder than it sounds when things are visibly on fire. I spent my first 10 days doing three things instead. I met every workstream lead one to one and asked the same three questions: what are you worried about, what are you waiting on from someone else, and what would you do if you were me. I read every steering committee paper from the very start of the programme, because the history of decisions is where the bodies are buried. And I built a single dependency map, on one page, showing every handoff between workstreams and whether it was on track.

That map was the turning point of the whole thing. Once it was all on one page, it was obvious to anyone who looked at it that the programme was at least 2 months behind the reported date, and that the reason was not any one team failing. It was the complete absence of anyone managing the connections between them.

The uncomfortable part

Then I did the part that is never comfortable. I went to the programme sponsor, one of the executive directors, privately, before the next steering committee, and I told her the programme was red, not green, and that the go-live date was not achievable. She had been telling the board it was green, so this was not welcome news.

But I did not just bring her the problem. I brought a re-baselined plan with 2 clear options. Option 1 was a phased launch: put the app live in 10 pilot branches on the original date, with a manual identity check as a temporary fallback for the late supplier, then roll out fully once the supplier was ready. Option 2 was to hold everything for 9 weeks and launch once, cleanly. I laid out the cost, the risk and the benefit of each, and I recommended Option 1, because it started delivering value immediately and started teaching us what customers actually did, while we waited for the supplier to catch up.

Because I had given her the bad news privately, before the committee, and because I had given her a solution rather than just a problem, she was able to take ownership of it rather than being ambushed in front of the board. She backed Option 1 at the steering committee.

Putting in the structure that was missing

Then I put in the thing that had been absent the whole time. A weekly dependency review, just 30 minutes, with every workstream lead in the room, looking only at the handoffs between them. A single integrated plan owned by me, rather than 5 separate plans that never referenced each other. A RAID log that was actually reviewed rather than merely updated. And a change to the reporting so that status was based on evidence of progress, not on each lead’s private judgement of how they felt it was going.

Outcome

The pilot went live on the original date in the 10 branches. Full rollout followed about 8 weeks later, which was a month earlier than the realistic date I had forecast when I took over, because the pilot flushed out the problems early where they were cheap to fix.

But the thing I was proudest of came 6 months later, when the same workstream leads were running the dependency review themselves while I was away. The structure outlasted my involvement in it, which is the real test of whether you built something or just carried it.

If I am honest about what I would do differently, I would have gone to the sponsor even sooner. I took 10 days to be completely sure of my facts, and I think 5 would have been enough. In a programme that is slipping, every week of false comfort costs you something you cannot get back.

The lesson

Status reports look at workstreams. Programmes fail in the handoffs between them. Put the whole thing on one page and the problem becomes undeniable.