Test the assumption that could change the plan

Imagine a team preparing to automate an approval workflow. There are forms to redesign, services to connect, permissions to establish, and a queue of requests to process. The work looks concrete enough to estimate.

Underneath it sits an untested assumption: the approval rules are consistent enough to encode.

If that assumption is wrong, the proposed system may automate only the easy cases while leaving the costly judgment work untouched. A polished prototype could demonstrate the interface without revealing this problem. A detailed architecture could explain how the wrong idea will be built.

The useful first investigation examines the approval rules themselves.

Find the decision underneath the question

“We need to understand the workflow” is a reasonable intention, but it has no natural stopping point. A team can spend weeks collecting information without becoming more able to choose its next step.

Make the decision explicit: should we invest in automating the common approval path, and which part could be delivered responsibly first?

Now list what must be true for that investment to make sense. The relevant data must exist. The rules must be explainable. Exceptions must be detectable before they cause harm. Someone must own disputed decisions. The people doing the work must be able to use the result.

This is not an invitation to catalogue every possible uncertainty. Start with assumptions that could invalidate the approach, substantially change its cost, or expose people to consequences the team cannot responsibly manage.

Consequence matters as much as doubt

A highly uncertain detail may be inexpensive to change later. A seemingly probable assumption may be disastrous if wrong. Investigate with both dimensions in mind.

Choosing the wording of an optional label can usually wait until there is a usable flow to examine. Discovering whether an automated decision requires an explanation that the proposed design cannot produce should happen much earlier.

Ask what would happen if the assumption failed after implementation. Would the team revise a small component, rebuild the approach, interrupt a critical service, or have to repair decisions already applied to people? The answer helps determine how much evidence the next investment deserves.

Avoid converting this judgment into a decorative scoring exercise. The point is to choose an investigation and explain why it comes first.

Use a probe suited to the uncertainty

Different questions need different evidence. A conversation can reveal how someone understands an exception. Inspecting actual records can show how often a field is absent in the available data. A code inspection can uncover behavior the written documentation omits. A prototype can expose whether people understand the proposed interaction.

None of these substitutes automatically for the others.

For the approval example, the team might walk through a small, deliberately varied set of previous decisions with the people responsible for them. Include ordinary approvals, rejected requests, disputed cases, and unusual inputs. Ask which information changed each decision and where judgment entered.

The purpose is to test whether the proposed rule model survives meaningful variation. Selecting only neat examples would make the exercise reassuring and largely useless.

Define an answer before collecting more material

Write down what finding would support the next slice and what finding would force a change. Perhaps a bounded class of requests has explicit rules and a reliable route for exceptions. That could support a narrow pilot. Perhaps decisions depend on undocumented negotiation. That could redirect the work toward making judgment visible before attempting automation.

Also identify what the investigation cannot establish. Reviewing a handful of cases may expose a missing rule without establishing how frequently it occurs. A prototype session may identify a confusing control without predicting adoption across an organization.

Keep the limit beside the finding. Evidence becomes easier to misuse when its context disappears.

End the investigation with a decision, its supporting evidence, and the remaining uncertainty. If the next responsible action is another investigation, explain which new question makes it necessary and bound that work too.

Before the next implementation commitment, ask the crew to finish this sentence: “We would change the plan if we discovered…” If nobody can answer, the uncertainty may be hidden rather than resolved. That sentence is often a better starting point than another page of requirements.