How to Use AI to Stress-Test a Business Decision

Premortem analysis examines how a proposed decision could fail before the company commits to it. Our new decision pre-mortem skill turns that exercise into a structured memo: plausible failure paths, a provisional verdict, a revised plan, a challenge to that revision and measurable warning signals. The decision owner remains responsible for what happens next.

The skill is part of Rhize Ops in the Rhize Plugins marketplace. It can review a business investment, a project, a team process or a personal decision. Its instructions are general purpose: a company supplies its own goals, constraints, evidence and dates. No Rhize-specific operating model is required.

Why run a pre-mortem before a decision?

A plan can sound reasonable while relying on an untested assumption. A CRM migration assumes staff have time for training. A new service assumes the team can deliver it without disrupting existing work. A marketing campaign assumes somebody can answer the additional enquiries.

Those assumptions often span departments. The person approving software may not own the migration. The person approving a campaign may not see the dispatch calendar. A decision review is useful when it makes those dependencies visible early enough for somebody to act on them.

Gary Klein described the project premortem in Harvard Business Review in 2007. Source: https://hbr.org/2007/09/performing-a-project-premortem

Our skill applies a specific five-stage review to the user's plan. Look for a more precise decision and checks the team can complete before commitment. We have not demonstrated that using this skill improves business outcomes, and it should not be treated as a forecasting model.

Which decisions deserve the effort?

Use the review when a mistake would be expensive to reverse, when several teams depend on the same assumption or when enthusiasm is running ahead of evidence. Examples include changing a core system, hiring for a new service line, committing to a vendor or launching a process that adds recurring work.

A small reversible choice usually needs a short check, not a lengthy memo. The skill is designed to ask for missing details when no concrete plan or failure definition exists. "Should we use AI?" is too broad. "Should we pilot an AI-assisted quoting process with one team before changing our customer-facing workflow?" gives the review something to test.

Define both success and failure. Include the decision owner, start date, capacity constraints and the last point at which the company can change course cheaply. The date a project launches is not always the date a commitment becomes difficult to reverse.

The five stages of the decision pre-mortem skill

1. Autopsy: describe plausible failure paths

The review begins with a clearly labelled hypothetical failure. It traces possible causes back to supplied details or verified evidence. Each material risk gets an identifier so it can be followed through the rest of the memo.

For a system migration, a failure path might connect incomplete data cleanup to a rushed import, unreliable records and staff reverting to the old system. That is a hypothesis to investigate, not a prediction. Missing information belongs in an explicit list of unknowns rather than being filled with convincing guesses.

2. Verdict: separate likelihood from consequence

The skill distinguishes the most likely problem, the most dangerous problem and the biggest hidden assumption. These may overlap, but they are different questions. It does not turn an unsupported ranking into a numerical probability.

Its recommendation is provisional: proceed, proceed with changes, pause to test or decline. A fatal flaw needs a supported constraint that defeats the goal. An unanswered question is an unresolved issue to test, not automatic proof that the plan cannot work. The review also considers the alternative and the cost of delay.

3. Rebuild: change the plan

A useful review proposes changes tied to the identified risks. It explains their cost, tradeoffs and remaining exposure. A smaller pilot, a staged commitment or a dependency test may be more useful than adding another general instruction to "communicate better."

Pre-commitment checks need evidence, a proposed owner, a deadline and a pass condition. They also need a consequence: revise, pause or walk away. The decision owner must agree to those commitments; the assistant cannot assign work merely by writing a name in a table.

4. Adversary: challenge the revised plan

The skill then tests the rebuilt plan against a credible response from a vendor, competitor, stakeholder or substitute. If there is no meaningful opponent, it can examine inertia or conflicting incentives. It should not invent a hostile rival to make the analysis dramatic.

For example, a vendor may have little incentive to provide migration help beyond the signed scope. Staff may prefer the old process because it remains easier during the transition. Those possibilities should change the checks or the plan where warranted, rather than appearing as a detached story at the end.

5. Tripwires: decide what would trigger action

Each retained material risk needs a useful signal, a source for that signal, a check date, an owner and a response. For each metric, decide what the owner will do if it crosses the agreed threshold. A warning that arrives after the irreversible commitment may be too late to help.

If there is no baseline, the skill should specify what to measure and when. It should not treat missing data as zero or invent a threshold because a table needs a number. Some risks cannot be monitored in time; those need an earlier test, bounded exposure or an explicit owner decision to accept the uncertainty.

A hypothetical CRM migration review

Imagine a service company planning to change its CRM before its busiest season. This is an illustrative scenario, not a customer case study. The owner wants cleaner records and a more consistent follow-up process, but the migration plan does not yet establish who will clean the data or test the handoffs.

The first review could identify three unknowns: whether existing records can be mapped correctly, whether staff have training time and whether the new system preserves the current enquiry-to-booking process. None of those questions can be answered from a software feature list alone.

A rebuilt plan could test a representative set of records before a wider import. It could ask the team to walk through an enquiry, a booking change and a follow-up using the proposed process. The company would agree what counts as a passing result and who has authority to pause the migration.

The tripwires would be tied to those checks. Unresolved mapping errors might block the broader import. Missing training capacity might move the rollout date. A failed handoff might require a revised process before the old system is retired. Thresholds would come from the company's requirements and loss tolerance, not from an arbitrary AI-generated percentage.

The potential benefit is a decision with fewer invisible dependencies. Whether the review saves time or prevents a bad rollout would still need to be measured. The company would need to compare the review effort and the resulting project outcomes to know whether it helped.

A reusable brief for your first review

Give the assistant a concrete decision and the evidence available today. A useful starting prompt is: "Run a decision pre-mortem on this plan. Label supplied facts, verified facts, inferences and unknowns. Keep the failure scenario hypothetical. Identify what we should test before committing and what would make us change course."

Then supply the goal, alternatives, proposed timeline, capacity limits, decision owner and relevant evidence. Include money constraints when money matters. Include available hours when time matters. State what has already been committed and what remains reversible. Leave unknowns visible rather than supplying estimates solely to complete the form.

Review the returned memo with the people who understand the work. Check its arithmetic, dates, assumptions and proposed owners. Reject invented probabilities, unsupported baselines and recommendations that silently redefine success. Ask what evidence would support proceeding as well as what would support stopping.

The full skill instructions are public: https://github.com/Rhize-Media/rhize-plugins/blob/main/rhize-ops/skills/decision-premortem/SKILL.md

Turn one uncertain decision into a testable plan

Start with an upcoming commitment your team can still change. The decision pre-mortem skill is available in Rhize Ops through the Rhize Plugins marketplace. Use it to prepare the discussion, then have the owner agree on the checks, dates and actions. The useful result is a plan the team can test and revise before the expensive part begins.