The Biggest Mistakes Program Managers Make (and Why Payment Projects Fail)

Projects do not usually fail at the end. They fail early, quietly, in a way that only becomes visible at a milestone that slips or a launch that goes wrong. Having run the programmes that launched four regulated markets in one year, and having written the post-mortem of a transformation that cost several million dollars, I have a short list of the mistakes that were present every time something went badly. None of them is exotic. All of them are avoidable in week one.

1. Noting dependencies instead of owning them

The most common mistake and the most expensive. The plan says "depends on settlement account being open", and the dependency is written down, colour-coded and reported. Nobody on the programme owns the date the account opens, so nobody is calling the bank weekly, and the programme discovers a six-week delay when the milestone arrives.

The fix: every cross-project dependency has an owner inside the programme whose job is to chase it, and a date that is reviewed weekly. If the owner is "the bank", the dependency is not owned.

2. Gates without criteria

A milestone called "regulatory approval" with a date and no criteria will be reported as green until the day it is red. A gate with criteria ("conditions letter received; each condition mapped to a requirement with an owner; compliance sign-off recorded") can be evidenced or not, week by week.

Every programme I have seen slip silently had milestones that were dates rather than gates.

3. Running the steering committee on status

The steering committee exists to make decisions the workstreams cannot make alone. When the agenda starts with status, the decisions get ten minutes at the end and are deferred to the next meeting. Two fortnights later the programme has lost a month waiting for a decision that needed twenty minutes.

Agenda order: decisions needed, risks that have moved, then status. Send the status in writing beforehand.

4. Confusing the plan with the outcome

A programme can close every project on plan and fail. The market launched, but the merchant cohort was not ready, so volume did not arrive. The system migrated, but reconciliation was not re-tested, so the first month's settlement was wrong. The plan measured delivery; the outcome needed operation.

The fix is a benefits review that outlives the projects, with the outcome measured after go-live by someone who is still accountable.

5. Absorbing scope change without re-planning

In regulated programmes scope changes arrive from outside: a regulator adds a condition, a partner changes an integration, a scheme moves a mandate. The mistake is to absorb the change into the existing plan without re-sequencing, because re-planning feels like admitting slippage. The result is a plan everyone knows is fiction, and the honest date arrives as a surprise to the sponsor.

Change control is not bureaucracy. It is the mechanism that keeps the plan true.

6. Treating operations readiness as a final task

Operations readiness (runbooks, training, exception handling, support scripts) is scheduled as the last milestone before launch, and it is the first thing cut when engineering runs late. Then the launch happens with a product operations has not seen, and the first two weeks are a live rehearsal with real merchants.

Operations readiness should start when the product is half built, with operations in the sprint reviews, and it should be a gate criterion, not a task.

7. Under-communicating slippage

Programme managers delay telling the sponsor about a slip because they hope to recover it. Sometimes they do. When they do not, the sponsor learns late, with no options left, and trust is spent. The rule that works: report a risk to the date as soon as it is more likely than not, with the options for recovering it. Early bad news with options is programme management; late bad news without options is a resignation letter.

8. Building artefacts for the committee instead of for the teams

RAID logs updated the night before the steering committee. Status reports that are longer each fortnight. Dependency maps nobody but the programme manager has opened. When the artefacts serve reporting rather than delivery, the programme is being narrated, not managed. The six patterns of PMO failure all start here.

9. Letting the vendor own the plan

Transformation programmes with a systems integrator or a platform vendor often let the vendor's plan become the programme plan. The vendor's plan is optimised for the vendor's milestones and payments. The programme's own dependencies (data migration, operational change, regulatory notifications) sit outside it and are discovered late. The multi-million-dollar post-mortem linked above has this mistake at its centre.

10. Mistaking certification for judgment

A certified programme manager knows the vocabulary. Judgment is knowing which dependency is about to break, which gate criterion is being asserted rather than evidenced, and which sponsor needs the bad news today. The vocabulary is necessary and insufficient. Hire and promote on the record of outcomes delivered across teams.

Why payment projects specifically fail

Three reasons are particular to payments and worth naming on their own.

Money state is not on the plan. The project delivers the feature and nobody planned the reconciliation change, so the first settlement cycle after go-live produces breaks that take weeks to clear.

The partner's timeline is treated as controllable. Banks, schemes and regulators do not move at project speed. Plans that assume they will are wrong from the day they are written.

Compliance is a reviewer, not a participant. When compliance sees the design at the end, it either blocks the launch or signs off under pressure. When compliance is in the design from the start, the controls are built in and the sign-off is a formality.

FAQ

What is the most common mistake program managers make? Recording dependencies instead of owning them. A dependency with no owner inside the programme is discovered as a delay at the milestone rather than managed as a risk weeks earlier.

Why do projects fail? Most often because of decisions and dependencies handled badly early on: milestones without criteria, steering committees that never reach the decisions, scope changes absorbed without re-planning, operations readiness cut late, and bad news delivered too late to act on.

Why do payment and fintech projects fail? In addition to the general causes: reconciliation and settlement changes left off the plan, partner and regulator timelines treated as controllable, and compliance brought in as a final reviewer rather than a participant in design.

How do you prevent a project from failing? Own every dependency, write evidence-based gate criteria, run governance on decisions rather than status, control scope changes formally, start operations readiness early, and report risks to the date as soon as they are more likely than not.

What separates a good program manager from an average one? Judgment about which dependency is about to break and the willingness to deliver bad news early with options. Certifications supply the vocabulary; the record of outcomes across teams supplies the evidence.