Article chapter 08 of 08
Review the map before you approve the scope
Before the scope gets approved, take one ordinary request and one relevant exception through the proposed future flow. Use the real roles, states, evidence and system boundaries. If the team has to make up an answer during the review, record it as an open decision instead of smoothing over it.
The review should confirm that:
- every starting event has a named way in
- every active state has an owner or a visible queue
- each decision says what information and authority it needs
- handoffs say what gets passed over and how the receiver knows it arrived
- waiting work stays visible
- corrections keep enough history to explain the current result
- duplicate and retry behaviour is defined for events that matter
- an integration rejection has an operating path
- excluded cases have an interim owner
- acceptance checks can be run without someone presenting and explaining them
Compare the capability list with what you found in the current state. Take out features that are only there because the old interface had them. Add a capability only when the team can name the work it supports or the risk it controls.
Then hand the proposed scope to someone who wasn't in the main workshops, and ask them to trace who acts next when information is missing, an approval changes or an external transfer fails. Their questions often turn up assumptions the regular participants have stopped noticing.
So before replacing the software, I'd map the work it supports, starting from that one finished request and following the handoffs, workarounds and corrections it actually went through. The scope should come from that map, with the old feature list kept as a reference rather than the starting point. I'd approve the scope once the main path hangs together, the important exceptions have owners and the unresolved decisions are clear enough to manage. After that, keep the working map open during design and testing, and for each significant change, note which state, handoff or rule it affected and why it changed.