FiscaloomA useful diagnostic does more than collect pain points. It creates a shared operating model of the current process and enough evidence to decide what should be automated, what should remain human, and what must be resolved before implementation.
Capture the process as it is actually operated
Walk through real examples from trigger to recorded outcome. Compare the written procedure with the workarounds, handoffs, spreadsheets, and informal decisions people use when the standard path fails.
Document inputs, decisions, actions, systems, roles, evidence, and exceptions at the same level of detail. An integration diagram without decision ownership is incomplete; a process map without system actions cannot support delivery planning.
Convert observations into design decisions
For each step, decide whether it is deterministic, judgment-based, informational, or an approval. Then identify which actions are permitted, which require confirmation, and which should stop the workflow.
- Process boundary and exclusions
- Decision and approval inventory
- Exception taxonomy and owners
- System and data dependency map
- Acceptance criteria and test scenarios
- Open risks that must be resolved in the SOW
End with a scope that can be priced and tested
A buildable scope names deliverables, responsibilities, interfaces, assumptions, environments, controls, acceptance criteria, and change procedure. It should be possible for business, technical, and commercial reviewers to understand the same commitment.
Create an evidence pack the delivery team can use
A diagnostic should leave behind more than workshop notes. Assemble representative cases, the current procedure, actual handoffs, system screenshots or interface references, decision rules, exception examples, access constraints, existing reports, and known control evidence. Identify the date, owner, and reliability of each item. Conflicts between documented policy and observed practice should remain visible until an accountable role resolves them.
Use the evidence pack to test the proposed boundary with people who do the work. Walk one standard case and several difficult cases through the future-state design. Mark every point where the team lacks an authoritative input, a permitted system action, a decision owner, or a recovery route. These gaps become named dependencies rather than implied implementation work.
Turn open questions into commercial decisions
Separate questions that can be answered during normal configuration from questions that change price, timing, responsibility, or risk. The latter belong in an assumptions and dependencies register linked to the statement of work. Give each item an owner, due date, validation method, and consequence if the assumption is false.
At the end of the diagnostic, the sponsor should be able to choose among proceeding, narrowing the process, funding additional discovery, or stopping. Present the choice in operating terms: what outcome will be delivered, which scenarios are included, what remains manual, which systems will be touched, how acceptance will be tested, and what the customer must provide.
Further reading
These primary references informed the operating principles in this guide.