Discovery before design.

Start with the decision discovery must support.

A broad instruction to “understand the business” produces broad notes and weak conclusions. Define the decision leaders expect to make when discovery closes. Examples include whether to redesign collections, centralize an administrative process, introduce an AI-assisted workflow, establish a shared service or change the operating model.

The decision scope should state the outcome, the part of the business in scope, the time horizon, the known constraints and the evidence required to proceed. It should also list what is explicitly outside scope. Without this boundary, every issue becomes relevant and the team cannot distinguish root cause from background noise.

Build an evidence map before scheduling interviews.

Interviews are important, but memory and opinion cannot be the only sources. For each business question, identify the evidence that could confirm or challenge what people say.

• Policies, SOPs, role descriptions and approval authorities
• Volumes, cycle times, aging, errors, rework and exception records
• Customer complaints, lost sales, service requests and satisfaction signals
• System reports, spreadsheets, queues, emails and locally maintained trackers
• Training material, quality findings, audit issues and risk events
• Supplier commitments, handoff records and commercial terms

Record the source owner, period covered, definition, limitations and reliability of each item. A number without a stable definition is not yet a baseline.

Hear the whole operating system, not only the hierarchy.

Senior leaders understand intent and strategic pressure. Front-line teams understand friction and variation. Customers experience the result. Enabling functions understand constraints. Suppliers see dependencies the organization may have normalized.

Use a common interview spine so themes can be compared, while leaving enough room to follow unexpected evidence. Ask for recent examples. “Show me the last time this happened” usually produces more useful information than “How does the process work?”

Observe work where it actually happens.

A process map built only in a meeting room usually reflects the official sequence. Observation reveals the operational sequence: waiting, searching, double entry, manual checking, escalation, workarounds and informal decisions.

Follow representative cases from beginning to end. Include normal work, difficult cases, high-value cases and failures. Capture who acts, what information is used, which system is touched, where a decision is made, what can go wrong and how the exception returns to the flow.

Establish a baseline that can survive scrutiny.

A transformation cannot demonstrate value if the starting point is reconstructed after implementation. Agree the baseline during discovery and document its limitations.

Not every metric needs to improve. Select a small set connected to the business outcome, alongside guardrail measures that prevent improvement in one area from creating harm elsewhere.

Separate quick wins from structural redesign.

Discovery will surface simple corrections and deeper design issues. Mixing them creates two problems: small improvements become trapped inside a large program, while structural weaknesses are disguised as an action list.

Classify findings by root cause, business consequence, urgency, control risk, dependency, value potential and implementation effort. A quick win should be safe, reversible and consistent with the likely target state. If it creates a new workaround or locks in a weak design, it is not a quick win.

Prioritization should show why an opportunity matters and what evidence supports it. It should not be a voting exercise based on enthusiasm.

Close discovery with outputs people can use.

A good discovery report is not a transcript of activity. It is a decision pack. It should make the current state understandable, show how conclusions were reached and define what the next phase must resolve.

Review findings with the people who contributed before finalizing them. This is not about giving every stakeholder a veto. It is about correcting factual errors, identifying missing dependencies and ensuring the design phase starts from a shared understanding of the operating reality.