Assume it already failed

A better question than “what could go wrong?”, and the sort that follows it — which risks you retire this week, and which you can only watch.

The estimate lesson ended with a range and one named branch: nine weeks if deprovisioning turns out to be quirky across identity providers. That branch was chosen because it was the most likely thing to go wrong, and because a range needs exactly one top end.

Which means you have not actually thought about risk. You produced a single data point for a different purpose and moved on. Doing it properly is one exercise, and it is the last thing between you and committing to this plan in public.

Why “what could go wrong?” is a weak question

It is the obvious thing to ask and it reliably produces a thin, agreeable list. Two reasons, and only one of them is about analysis.

The analytical reason: the question invites you to search the risks you already have names for. You will list the ones you have been quietly worrying about — which are, by definition, the ones already priced into your thinking. The risks that actually sink projects are the ones nobody in the room has a name for yet.

The social reason is bigger and less discussed. By the time you ask, everyone has just agreed to the plan. Raising a serious objection now means being the person who disagrees with a decision the room already made, and it reads as disloyalty or as sour grapes. So people volunteer small, safe risks — the ones that make them look thorough without making them look obstructive — and the large ones stay in people’s heads.

The pre-mortem

Gary Klein’s technique inverts the framing. Assume it is six months from now and the project has failed badly. Not “might fail” — it failed. Now write down why.

This works for a measurable reason. It relies on prospective hindsight — imagining that an event has already occurred — and research by Mitchell, Russo and Pennington in 1989 found that doing so increases people’s ability to correctly identify reasons for an outcome by around 30% (Klein, “Performing a Project Premortem”, HBR 2007). Explaining a fact is a different cognitive task from forecasting a possibility, and people are markedly better at it.

Run alone it is still worth doing; run with two or three colleagues it is worth considerably more, because the risks you cannot name are precisely the ones somebody else can.

What it turns up on SSO

Assume the SSO project failed. It is six months later, the deal did not close, and the team is doing the retrospective. Plausible reasons, of the kind “what could go wrong?” tends not to surface:

Deprovisioning behaved differently across identity providers and each one needed its own handling — the branch you already knew about.
The prospect’s IT admin took three weeks to provision a test tenant, and nothing could be verified until they did.
Sales promised a date in the contract based on the bottom of your range, and nobody told you until it was signed.
The security questionnaire arrived late and asked for SOC 2 evidence about the auth path that nobody had prepared.
The vendor was fine, but wiring their model to your existing user-and-org tables turned out to be the actual work, and nobody had looked at it.

Notice how few of those are engineering problems. That is typical, and it is the main argument for doing this before committing rather than after.

The sort that matters: retire or monitor

A list of failure causes is not yet useful. What makes it useful is sorting every item into one of two piles, and the sort is not by severity.

Retire — you can convert this from unknown to known right now, cheaply, by doing something. The deprovisioning quirks are retirable: two days against one real identity-provider tenant tells you whether it is a footnote or a fortnight.

Monitor — no amount of effort this week resolves it, because it depends on someone else or on something that has not happened yet. The prospect’s admin being slow is not yours to fix.

Where people get burned

The expensive mistake is putting a retirable risk on a monitoring list. It feels like diligence — it is on the register, it has an owner, there is a column for it — and it is actually deferral with paperwork. If two days of work would settle it, the honest move is to spend the two days before you commit to a number that assumes the answer.

What a monitored risk needs to be real

Most risk sections are ignored because they are lists of worries, and a worry is not actionable. A monitored risk needs three things, and if any is missing you have written a feeling down:

An owner — a named person, not a team. “The team will keep an eye on it” means nobody.
A trigger — the observable signal that this is now happening, specific enough that you would notice it. “If the test tenant is not provisioned by the end of week one.”
A response — what you do when it fires. Decided now, while it is cheap and nobody is panicking.

This is also how you narrow the estimate

Recall the cone of uncertainty: the precision you can honestly offer depends on how well-defined the work is. Retiring a risk is definition — it is exactly the act of turning an unknown into a known.

So the pre-mortem is not a separate ceremony bolted on beside the estimate. It is the mechanism that earns you a tighter one. Spend two days on the deprovisioning spike and your four-to-nine becomes something like five-to-seven, honestly, with the reason attached. That is a much better answer to give the VP than a confident number would have been.

Retrieval check

Without scrolling up: what is the test that sorts a risk into “retire” rather than “monitor”, and why is getting that sort wrong expensive rather than merely untidy?

Check your answer

Can you convert it from unknown to known right now, cheaply, by doing something? If yes it is retirable, and putting it on a monitoring list instead is deferral dressed as diligence — you commit to a number that assumes an answer you could have simply gone and found. It is expensive because the cost of learning it later is paid in schedule and credibility, while the cost of learning it now was two days.

Now apply it: run the pre-mortem on SSO

Hands on

Fail the project on purpose, then act on it

Done when: You have a sorted risk list, one risk actually being retired this week with a defined spike, and every monitored risk carrying an owner, a trigger and a response.

Set the scene properly before you write anything: it is six months from now, the SSO project failed, the deal did not close. Do not hedge this into “it went badly” — the premise only works if the failure is total.
Give yourself ten minutes and write every reason you can. Aim for quantity over quality; the useful ones tend to arrive after the obvious ones are out of the way. Include non-engineering causes — contracts, people, timing.
Sort each into retire or monitor using the one test: could you convert it to a known this week?
Pick the single most valuable retirable risk and design the spike: what you would do, how long you would give it, and — the part people skip — what result would change your plan. A spike with no decision attached is just reading.
For each monitored risk, write the owner, the trigger and the response. Delete any that you cannot give all three to; it was a worry, and leaving it in is what teaches people not to read this section.
Bring the sorted list and your spike into the chat. I’ll push on the sort in particular — the most common mistake is filing something as “monitor” because retiring it would be inconvenient this week.

What this does not cover

You now have a plan, a range, and an honest account of what could break it. But look again at that list of failure causes: at least one of them is not yours to prevent, because the work it describes belongs to another team. A risk you cannot retire and cannot schedule is a different kind of problem, and it is the one most likely to decide your date. That is where this goes next.

Assume it already failed

A better question than “what could go wrong?”, and the sort that follows it — which risks you retire this week, and which you can only watch.

Why “what could go wrong?” is a weak question

It is the obvious thing to ask and it reliably produces a thin, agreeable list. Two reasons, and only one of them is about analysis.

The pre-mortem

Gary Klein’s technique inverts the framing. Assume it is six months from now and the project has failed badly. Not “might fail” — it failed. Now write down why.

Run alone it is still worth doing; run with two or three colleagues it is worth considerably more, because the risks you cannot name are precisely the ones somebody else can.

What it turns up on SSO

Assume the SSO project failed. It is six months later, the deal did not close, and the team is doing the retrospective. Plausible reasons, of the kind “what could go wrong?” tends not to surface:

Deprovisioning behaved differently across identity providers and each one needed its own handling — the branch you already knew about.
The prospect’s IT admin took three weeks to provision a test tenant, and nothing could be verified until they did.
Sales promised a date in the contract based on the bottom of your range, and nobody told you until it was signed.
The security questionnaire arrived late and asked for SOC 2 evidence about the auth path that nobody had prepared.
The vendor was fine, but wiring their model to your existing user-and-org tables turned out to be the actual work, and nobody had looked at it.

Notice how few of those are engineering problems. That is typical, and it is the main argument for doing this before committing rather than after.

The sort that matters: retire or monitor

A list of failure causes is not yet useful. What makes it useful is sorting every item into one of two piles, and the sort is not by severity.

Monitor — no amount of effort this week resolves it, because it depends on someone else or on something that has not happened yet. The prospect’s admin being slow is not yours to fix.

Where people get burned

What a monitored risk needs to be real

Most risk sections are ignored because they are lists of worries, and a worry is not actionable. A monitored risk needs three things, and if any is missing you have written a feeling down:

An owner — a named person, not a team. “The team will keep an eye on it” means nobody.
A trigger — the observable signal that this is now happening, specific enough that you would notice it. “If the test tenant is not provisioned by the end of week one.”
A response — what you do when it fires. Decided now, while it is cheap and nobody is panicking.

This is also how you narrow the estimate

Retrieval check

Without scrolling up: what is the test that sorts a risk into “retire” rather than “monitor”, and why is getting that sort wrong expensive rather than merely untidy?

Check your answer

Now apply it: run the pre-mortem on SSO

Hands on

Fail the project on purpose, then act on it

Done when: You have a sorted risk list, one risk actually being retired this week with a defined spike, and every monitored risk carrying an owner, a trigger and a response.

Set the scene properly before you write anything: it is six months from now, the SSO project failed, the deal did not close. Do not hedge this into “it went badly” — the premise only works if the failure is total.
Give yourself ten minutes and write every reason you can. Aim for quantity over quality; the useful ones tend to arrive after the obvious ones are out of the way. Include non-engineering causes — contracts, people, timing.
Sort each into retire or monitor using the one test: could you convert it to a known this week?
Pick the single most valuable retirable risk and design the spike: what you would do, how long you would give it, and — the part people skip — what result would change your plan. A spike with no decision attached is just reading.
For each monitored risk, write the owner, the trigger and the response. Delete any that you cannot give all three to; it was a worry, and leaving it in is what teaches people not to read this section.
Bring the sorted list and your spike into the chat. I’ll push on the sort in particular — the most common mistake is filing something as “monitor” because retiring it would be inconvenient this week.