Two-week iterations don't describe a core banking conversion, and they barely describe a regulatory remediation program. Yet walk into many bank PMOs and the tooling assumes exactly that shape, because many of the tools that won the last decade of the project management market were built for software teams. Bank transformation programs aren't sprints, and the tools that govern them shouldn't pretend they are.

PMI's research points the same way. Its 2024 Pulse of the Profession found that use of hybrid approaches, which blend predictive and agile practices, rose from about 20% in 2020 to 31% in 2023, and that teams perform about equally well with predictive, hybrid, and agile methods. The method matters less than the fit, and for bank transformation the fit is governance.

A Mismatch in Four Parts

Agile tooling assumes small units of work, frequent delivery, and a team that owns its own backlog. Bank transformation programs tend to have none of those properties, and the gap shows up in four places.

1. Approvals: A core conversion has formal decision points with named approvers, documented criteria, and consequences for proceeding without them, and most boards don't model approval as a first-class concept.

2. External Dependencies: Regulatory timetables, vendor release schedules, and other institutions in a payments migration aren't backlog items, and the team can't reprioritize them.

3. Portfolio View: The audience is a steering committee that needs to see twenty programs at a level of abstraction a board view wasn't designed to produce.

4. Audit: Someone will ask, possibly years later, who approved what and on what basis, and a board shows current state rather than the history of how it got there.

The Workaround Everyone Builds

The mismatch doesn't stop the work, it produces a familiar and expensive workaround.

The program runs in the tool. Then, before each steering committee, somebody rebuilds the real status in a deck, with a spreadsheet that reconciles what the tool says against what program leads actually report, plus a RAG assessment that lives in neither.

That leaves two versions of the truth, and the one presented to decision-makers is often the more accurate of the two, which says something uncomfortable about the system of record.

The cost isn't only preparation time. The steering committee ends up deciding from a monthly snapshot, so decisions that could be made in week two get made in week five, and on multi-year programs that delay compounds. McKinsey and the University of Oxford, studying more than 5,400 IT projects, found that large IT projects ran about 45% over budget and 7% over time on average while delivering 56% less value than predicted, and that each additional year of schedule increased cost overruns by about 15%.

Governance Built for Programs

What a bank PMO needs isn't a better board, it's portfolio governance where gates, approvals, dependencies, and roll-up are native concepts rather than things configured around.

That means gate models with criteria and named approvers, and approvals captured as records with field history, so the audit answer is a query rather than an archaeology exercise. It means dependencies that can sit outside the team, and portfolio roll-up at the abstraction the steering committee actually uses, available on any day rather than the week before the meeting.

None of that is exotic. It's the standard shape of program governance, and it simply isn't what agile tooling was designed to express.

Why It Belongs Beside the Bank's Own Data

Transformation programs touch customers, products, channels, and commercial agreements, and for banks and insurers running Financial Services Cloud, most of that already lives in Salesforce. Cloud Coach puts program governance in that same org, so gates, approvals, and portfolio roll-up sit beside the business context they affect, with no integration to maintain and no second security model to assess. Approvals carry Salesforce field history, and steering committee views read live program records rather than a rebuilt deck.

For a sector where every new system means an assessment, an approval, and an ongoing control obligation, that matters more than it does elsewhere. It's also why being live in days, rather than after a six-month enterprise PPM implementation, is meaningful here. One Cloud Coach customer reports redeploying about 3,400 hours a year to client value, and in a bank PMO, the monthly rebuild of status the system should already know is often where that kind of time is hiding.

How We See It

Bank transformation programs aren't sprints. They have gates, approvers, external dependencies, and an audit trail that has to hold up for years. Choose tools that reflect that, and stop paying a monthly tax to translate between the tool and the truth.

Frequently Asked Questions Related to Fintech

• Is agile project management software a good fit for bank transformation programs?

Agile tools work well for software teams, but bank transformation programs usually need formal gates, named approvers, external dependencies, portfolio roll-up, and a durable audit trail, which most board-based tools don't model natively. Many banks use agile methods inside workstreams while governing the overall program with stage gates.

• What should a bank PMO look for in portfolio management software?

Gate models with criteria and named approvers, approvals recorded with history for audit, support for external dependencies, and live portfolio roll-up for steering committees, ideally on the platform that already holds customer and product data.

• Can program governance run in Financial Services Cloud?

Yes. A Salesforce-native PSA can run gates, approvals, and portfolio reporting in the same org as Financial Services Cloud, under the same security and permissions model the institution has already assessed.

Sources Cited

Project Management Institute, "Pulse of the Profession 2024: The Future of Project Work." https://www.pmi.org/learning/thought-leadership/pulse/future-of-project-work

Michael Bloch, Sven Blumberg, and Jurgen Laartz, "Delivering Large-Scale IT Projects on Time, on Budget, and on Value," McKinsey & Company (research with the BT Centre for Major Programme Management, University of Oxford). https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value