Insights / Program Recovery
PROGRAM RECOVERY
September 22, 2026
A bank transformation program can have a detailed plan, an established steering committee, and a large team, yet still move steadily away from its intended outcome. People remain busy. Reports keep arriving. Yet each discussion seems to produce another explanation for why the work is taking longer.
That is program drift. The distance grows between what leadership believes is happening and what the program is actually delivering. In a large bank change program, that gap often crosses business, operations, risk, and technology. Each function may be working toward its own commitments without a shared understanding of what the bank needs to achieve as a whole.
Over the course of my career, I have been brought into troubled programs after substantial time and money had already been committed. One of the first things I try to establish is how close the people responsible for the program are to the work itself. Can they show what has been delivered? Do they understand what is preventing the next step? Can the people doing the work raise a problem and get a decision while it still matters?
Those questions often tell me more about the prospects for recovery than the latest completion date.
A large change program needs every affected function invested in its success from the beginning. Business leaders need to define the intended result. Operations needs to help shape how the work will be performed. Risk needs to bring effective challenge and help establish appropriate controls. Technology needs to understand and enable the changes. Each group must understand how its decisions affect the others.
When that shared commitment is missing, the first significant problem can turn into finger pointing. Business says the solution does not meet its needs. Operations says the process cannot be run. Risk identifies concerns that were never resolved. Technology says it delivered what was requested. The bank still has an unresolved problem, even if each group can explain why it met its own commitments.
A good program leader brings these perspectives together to develop a workable solution. That requires agreeing the outcome, examining tradeoffs openly, and assigning specific responsibilities across functional boundaries. Shared commitment must include clear individual accountability and respect for risk's independent challenge.
Bridging these groups is a central part of our work at AntePartners. We help them understand one another's constraints, resolve disagreements, and stay engaged through implementation so they can tackle problems together.
A program's original business case needs to be revisited throughout delivery. When an initiative stretches over several years, the opportunity it was intended to capture may diminish. Business needs can shift, costs can rise, and benefits that once justified the investment may be smaller or arrive too late. Leadership needs to ask whether the expected value still justifies the remaining work, cost, and time, and what should change if it does not.
That assessment needs the same cross-functional participation as delivery. Business, operations, risk, and technology should be able to explain the value the bank expects to receive, how it will be demonstrated, and why their contribution matters. The value statement must be clear enough to guide decisions and meaningful enough to sustain each group's commitment.
The benefit does not have to be identical for every function. One area may take on additional work to support an important outcome for the bank. But it needs to understand and support that purpose. When a function sees only the burden and no compelling value, the program risks losing an invested partner whose contribution it will eventually need.
Each expected benefit needs a named owner accountable for assessing whether it is being realized. Agree how the benefit will be measured, the starting position and target where applicable, and when it will be reviewed. The owner should bring evidence to the cross-functional team at those review points so the groups can assess progress and decide whether action is needed. Revisit the assumptions when scope, cost, timing, or business conditions change materially. Value realization deserves the same accountability as delivery.
At AntePartners, we bring those perspectives into the recovery discussion alongside the delivery plan. We help leadership reassess the intended benefits, examine evidence of value delivered, and agree changes to scope or sequence when the original assumptions no longer hold. For regulatory work, that assessment must also account for the bank's obligations and the risks the remediation must address.
Leaders need to understand how the proposed change will work across the bank. Can business explain how it meets the intended need? Can operations walk through the process, including exceptions? Can risk assess the controls and the evidence of their effectiveness? Can technology demonstrate that the supporting systems perform as required?
In my conversation with Tom Castriota on The Hire Ground Podcast, I gave one example of that distance from delivery: an executive responsible for applications who could not demonstrate them because he did not have a login. The same concern applies when a leader cannot explain a process, an unresolved business decision, or how a control will operate. I expect leaders to understand their responsibilities well enough to recognize a gap and make an informed decision.
In a troubled program, information can pass through several layers before it reaches the person who can act. Each handoff creates an opportunity for delay, lost detail, or a softened explanation. By the time leadership hears that a proposed process cannot handle an important exception, several functions may already have spent another week working against an assumption that no longer holds.
Recovery starts by shortening that distance. Bring the people producing the work into focused discussions with the people who depend on it and the leaders who can resolve the obstacles. Ask to see the output. Establish what has been tested, what remains incomplete, and what the next team can actually use.
Getting the right people into a room only helps if they will tell you what is wrong.
One exercise I discussed in the interview involved a rolling computer table I had bought for my home office. It arrived with a manufacturing defect: one of the holes for a caster was on the wrong side of the base. The table could not be assembled correctly as supplied.
I brought it into the office and asked groups that deliberately mixed colleagues from business, operations, risk, and technology to assemble it. I made clear that they could come to me if they encountered a problem. Most groups returned with a photograph that concealed the defective leg and said the task was complete. One colleague raised the issue despite pressure from others in his group to work around it.
The exercise exposed a problem that an open-door invitation had not solved. People were still more comfortable presenting completion than acknowledging an obstacle. I had expected the changes we were making to produce more openness. Seeing how the groups responded showed me how much work remained.
A program with many connected activities cannot operate that way. An unresolved issue in one area can become rework, delay, or operational risk elsewhere. Leaders need to make early escalation a normal part of delivery and respond in a way that encourages the next person to speak up.
That means listening before assigning blame, establishing the impact, identifying who can resolve the issue, and following through. It also means distinguishing an honestly raised problem from a repeated failure to meet an agreed responsibility. Accountability and openness need to work together.
Anyone close to the work may identify a weakness that others have missed. Their observation deserves to be heard and acted on.
I have written previously about measurable tasks and direct ownership. The practical test is whether the plan allows us to establish, at short intervals, that the program has moved closer to its intended outcome.
A task such as “complete the operating model” leaves too much open to interpretation. What will be different when it is complete? Who will use it? Which decisions, procedures, systems, and controls must be in place before it can operate?
Consider, for illustration, a bank changing a credit approval process. A near-term deliverable might be a walkthrough of a defined set of lending scenarios: business confirms that the proposed decisions meet the intended need, operations exercises the procedures and exception handling, risk assesses the controls, and technology demonstrates the supporting workflow. Gaps are documented, assigned, and resolved before the next stage.
Each function produces measurable work, and the groups jointly establish whether those pieces support a workable process. As the process becomes operational, they also need to assess whether it delivers the intended value, such as shorter approval times, less rework, or more effective controls. The measures should reflect the benefits agreed for that particular program.
For each deliverable, establish:
In recovery work, I look for demonstrable progress each week. Some outcomes take longer to complete, but the work should still be broken down far enough to expose progress and obstacles along the way. A weekly checkpoint is useful only if it reveals something substantive. Some benefits take longer to emerge. Keep delivery evidence visible at the weekly checkpoints, and have each benefit owner assess realized value at the agreed review points. A completed deliverable and a realized benefit should be reported distinctly.
Those increments also need to fit together. A collection of completed tasks does not establish that a bank can operate the new process from beginning to end. Test the connections, the exception paths, and the readiness of the people who will run it.
A team can identify an obstacle promptly and still lose time waiting for someone to decide what to do about it.
A recovery plan needs explicit decision rights. The team should know which decisions it can make, which require the sponsor, and which need specialist review. When an issue is escalated, the discussion should include the impact, the available options, the recommended action, and when a decision is needed to protect delivery.
If a new process leaves exception ownership unresolved, for example, referring it from one function to another will not move the program forward. The relevant leaders need to agree who will act, how the decision affects customers and staff, what controls are needed, and whether systems or procedures must change. The program leader brings those decisions together and follows them through to implementation.
Board and executive reporting remains necessary. It should draw on current delivery evidence and explain the decisions that matter. The working team also needs a faster route for decisions that cannot wait for the next formal meeting.
Moving dates without changing how the program operates can carry the same problems into a new plan. The assessment needs to distinguish useful work worth preserving from work that needs to change, and identify why delivery has become unreliable.
The cause may be an unclear outcome, conflicting priorities, a missing skill, an unresolved dependency, or a vendor commitment. A leader may lack the authority to make the decisions assigned to them. Adding people before understanding those conditions can create more coordination work while leaving the original obstacle in place.
At AntePartners, we typically deploy three seasoned professionals who have held senior operating roles and take an active part in delivery. We use no junior consulting delivery resources. That is our staffing model; the bank's own delivery expertise, at every level, remains essential to the recovery.
A small senior team can reduce handoffs and management overhead. Its value comes from diagnosing the problem, doing the work, and helping the bank make and implement sound decisions. Team size must reflect the expertise and scope required.
A successful recovery leaves the bank able to operate the change: business outcomes are understood, procedures and controls work in practice, supporting technology is usable, and people know their responsibilities. The bank also needs the relationships, documented decisions, and capability to sustain delivery after the recovery team leaves.
Where the program addresses a regulatory finding, those same disciplines need to support comprehensive remediation. The work must address the underlying concern across the affected activities, put the changes into operation, and produce evidence of effectiveness. I examine that specific challenge in our article on recovering stalled bank regulatory remediation programs.
Intervene when progress becomes difficult to demonstrate, obstacles persist because decisions are delayed, or the expected value no longer justifies the current course. Waiting for a major milestone to fail consumes time the bank could have used to correct the underlying problem.
A sponsor can begin by asking the functional leaders together: what can the bank now do that it could not do last week, what is preventing the next result, and what decision do you need from me? Connect those answers to the value the bank expects to receive, and follow the discussion through to action. Over several delivery cycles, leadership should see whether delivery is improving, the investment remains worthwhile, and the functions needed to complete the change remain committed.
If your program is missing milestones or struggling to demonstrate value, an initial conversation can help establish whether a focused recovery assessment would be useful. We can discuss the intended business outcome, the decisions blocking progress, and the commitment needed across business, operations, risk, and technology.
