The Five Questions I Ask in Week One of Every Large Program

Week one of a large program is mostly meetings about the plan. After 11+ years of leading enterprise and public-sector programs, I can tell you: the plan is rarely what kills them.

Programs die from the things the kickoff deck never mentions — the undecided decision, the sponsor whose picture of success doesn't match the contract, the stakeholder quietly rooting against you. So while everyone else is reviewing the Gantt chart, I'm working through five questions. When I can answer all five, I start trusting the plan. When I can't, I know exactly where the program will hurt later.

1. What decision is nobody making?

Every troubled program I've been asked to rescue had one thing in common — and it wasn't bad estimation. It was a decision everyone was waiting on and nobody owned. Which legacy system is the source of truth during transition. Whether the go-live is big-bang or phased. Which of two executives' conflicting priorities actually wins.

These decisions have a peculiar property: they're invisible on a status report. Every workstream shows green because every workstream has quietly assumed a different answer. The program isn't late yet — it's incoherent, and incoherence converts to lateness on a delay.

In week one, I ask each workstream lead: "What are you assuming that someone else should be deciding?" The answers go on a decision log with a named owner and a date. Half the value of a program leader in the first month is simply forcing decisions to exist as decisions — visible, owned, and dated — rather than as scattered assumptions.

2. What does "done" mean to the person who signs?

Not the requirements document — the human being. Somewhere above your program is a person who will one day declare it a success or a failure, and their picture of success is almost never the same document your contract describes.

The contract says "migrate 20 applications to the new platform." The sponsor's mental picture is "my analysts stop complaining, my board stops asking about the old system, and nothing embarrassing happens in the press." You can hit every contractual milestone and still fail the mental picture — I've watched it happen, and no change-order process can save you from it.

So in week one I sit with the economic buyer and ask versions of the same question until the real answer surfaces: "A year after go-live, what will make you glad you did this?" Then I reconcile that answer with the contract, in writing. Where they diverge, that divergence is the program's most important risk — more important than anything on the technical register.

3. What happens if we do nothing?

Every transformation program has a competitor that never appears in the vendor evaluation: the status quo. If the legacy system can limp along another year, someone in the executive team is quietly doing that math whenever your program hits turbulence.

You need that math done first, and done honestly. What does standing still actually cost — in maintenance spend, in compliance exposure, in the manual workarounds nobody has ever totaled up, in the risk of the ancient system failing on its own schedule? On one public-sector program I supported, the case only became undeniable when the cost of paper-based processes was quantified in oversight gaps — things that could not be seen or acted on because the information lived in filing cabinets. That number carried more weight in the legislature than any feature list.

Know the do-nothing cost cold, because the day your program needs executive air cover — and that day always comes — it's the number that keeps the funding intact.

4. Who loses power when this succeeds?

This is the question people find cynical until they've lived through the alternative. Every meaningful transformation shrinks something: a team whose manual process is being automated, a manager whose headcount justification disappears, a vendor whose contract your platform replaces, a department that used to own the data everyone will now share.

None of these people appear on your risk register, and all of them attend your stakeholder meetings. They rarely oppose the program openly. Instead you get slow-walked data access, endless "clarifying questions," subject-matter experts who are perpetually unavailable, and testing feedback that arrives late and hostile.

The move isn't to outmaneuver them — it's to see them clearly and early. In week one I map who loses what, and those people get my first coffee meetings. Sometimes there's a genuine role for them in the future state, and finding it converts your most dangerous critic into your most credible champion. Sometimes there isn't — and then at least the resistance is a known quantity you can plan around, instead of a mysterious drag on velocity you diagnose in month eight.

5. What's our fallback if go-live fails?

Not a rollback script — a business continuity answer. There's a difference. A rollback script answers "how do we un-deploy the software?" A fallback plan answers "how does the organization keep operating while we recover?" — exactly how failure would be detected, exactly when the go/no-go decision gets made and by whom, and exactly how the business continues serving its customers in the meantime.

I learned this on systems where the stakes made it unavoidable — platforms where downtime didn't mean lost revenue, it meant licenses not issued and care not delivered. The client's real fear was never "will the new system impress us?" It was "what if it doesn't work and we've already turned the old one off?"

Here's the paradox I keep relearning: the most valuable fallback plans are the ones you never use. Writing them — and rehearsing them — is what makes the go-live decision possible at all. Executives don't approve cutovers because they believe nothing will go wrong. They approve them because they know exactly what happens if something does. Confidence isn't the absence of a plan B. Confidence is the plan B.

What these five questions have in common

Notice what's absent: nothing about methodology, tooling, or estimation technique. All five questions are about decisions, people, and trust — the substrate underneath the plan. That's not a coincidence. Modern delivery tooling has made the mechanical parts of program management dramatically easier; AI is accelerating that by the quarter. What no tool has touched is the layer these questions live in.

They also share a property that makes them uncomfortable: each one is cheap to ask in week one and brutally expensive to discover in month six. The undecided decision becomes a stalled workstream. The unreconciled definition of done becomes a sponsor who feels misled. The unexamined status quo becomes a funding fight. The unmapped loser becomes a resistance movement. The unwritten fallback becomes a go-live nobody will approve.

Week one is the cheapest week your program will ever have. Spend it on the questions the kickoff deck doesn't ask.