Running Effective Discovery Workshops

Discovery Workshops Should Reduce Uncertainty, Not Simply Fill Templates

Discovery is where an enterprise implementation begins to understand how the business actually operates. The signed scope describes the commitment, but it rarely explains every operational exception, control, dependency, data requirement or decision the solution must support.

A weak workshop becomes a long conversation followed by incomplete notes. A strong workshop has a defined objective, the right participants, a business-process agenda and outputs that can be validated and traced into requirements and design.

Chapters 8–11 established mobilization, governance and delivery control. Part IV now moves deeper into the business itself. All examples in this chapter are fictional and illustrate delivery practice rather than a specific customer.

12.1 Start with the Workshop Outcome

Define what must be understood or decided before deciding who should attend. “Understand procurement” is too broad; “understand the purchase-to-pay flow, variations, controls, system touchpoints and unresolved requirements” gives the session a usable purpose.

Expected outputs can include process facts, pain points, rules, exceptions, controls, data needs, integration dependencies, reports, security concerns, requirements, decisions, assumptions, open questions and actions. The facilitator should know which of these are expected before the meeting begins.

12.2 Design a Discovery Journey, Not Isolated Meetings

Organize discovery as a connected sequence of sessions. Start with enterprise context, then move through end-to-end business processes and cross-cutting areas such as data, integration, reporting and security.

Maintain traceability across sessions. A finance requirement may depend on an external application discussed in an integration workshop, while a warehouse exception may change the order-to-cash design. Discovery should create one connected body of evidence rather than separate meeting notes.

12.3 Invite People Who Can Explain, Decide and Validate

Balance process owners, subject-matter experts, operational users and specialists. Senior leaders provide policy and direction; operational users reveal real exceptions; architects and control specialists expose cross-functional implications.

Not everyone needs to attend every session. Identify required participants, decision-makers, contributors and optional specialists. If the process owner cannot attend, treat the workshop as information gathering unless governance has delegated validation authority.

12.4 Prepare the Workshop Before Entering the Room

Review the SOW, process maps, policies, reports, sample forms, interface lists, data templates, audit observations and existing pain points. These materials improve the questions but should not be assumed to represent current reality.

Send a concise pre-read that states purpose, scope, preparation expected, agenda and intended outputs. For important sessions, a short preparation conversation with the process owner can reveal sensitive disagreements or known variations before the larger group meets.

12.5 Build the Agenda Around the Business Flow

Follow the process rather than the application menu. Begin with context and boundaries, walk the process from trigger to completion, then explore rules, approvals, exceptions, data, integration, reporting, decisions and open items.

Use a parking lot for topics that require a different audience or deeper investigation. Every parked item needs an owner and next action; parking is a control mechanism, not a way to lose difficult questions.

12.6 Use a Structured Question Framework

Use WHY, WHAT, WHO, WHEN, WHERE and HOW to understand the process. Then deliberately ask about EXCEPTIONS, CONTROLS, EVIDENCE and VOLUME.

Instead of asking only “what are your requirements?”, ask what triggers the work, who owns it, what rule governs it, what happens when the normal path fails and what evidence proves completion. These questions reveal needs that a happy-path demonstration can miss.

12.7 Understand the Process Before Designing the Solution

A user may ask for a custom screen, a new field or an AI approval. First determine the business problem. A spreadsheet used to track urgent supplier orders may indicate missing visibility rather than a need to rebuild the spreadsheet inside the new platform.

Keep early discovery solution-neutral where practical. Understand the need, outcome and constraint first. Product capability, fit-gap and design choices come later.

12.8 Capture Process and Requirements with Traceability

Capture trigger, inputs, activities, actors, approvals, rules, systems, data, handoffs, exceptions, outputs and completion evidence. Convert conversations into clear, testable requirements with unique identifiers and business ownership.

Separate requirements from pain points, ideas and proposed solutions. A statement such as “approval is slow, so we need a mobile AI app” contains a pain point, a possible cause, a business requirement and two solution ideas. Recording them separately prevents accidental commitments.

12.9 Use Decision, Assumption and Open-Question Logs

A decision is an agreed direction. An assumption is temporarily treated as true until validated. An open question requires an answer. These categories should never be mixed.

Give assumptions validation owners and give open questions due dates. Otherwise an untested assumption can be repeated often enough that the team begins treating it as an approved decision.

12.10 Validate and Convert Outputs into Delivery Inputs

Consolidate process notes, requirements, decisions, assumptions and open actions soon after the workshop. Give stakeholders a practical validation mechanism rather than distributing a transcript and calling it approval.

Discovery outputs should feed AS-IS and TO-BE design, fit-gap, architecture, backlog, data, integration, reporting, security, testing, training, risks and change control. Traceability allows the team to answer later: why are we building and testing this?

From the Delivery Floor

A fictional enterprise began procurement discovery by asking users to walk through their existing screens. Three hours later the team had captured more than seventy supposed requirements, many of which were field names or old-system behaviors.

During review, basic questions remained unanswered: who owned supplier creation, what approval thresholds applied, how emergency purchases worked and what happened when receiving quantities differed from the purchase order.

The team reset the approach and followed the process from trigger to outcome. The number of recorded requirements fell, but their quality improved. One requested customization disappeared completely when the underlying need was shown to be standard workflow visibility.

Discovery had prevented unnecessary build effort before development began.

12.11 The Delivery Leader's View

Measure discovery by uncertainty removed, decisions made, assumptions exposed and requirements clarified—not by the number of meetings completed.

If process owners are unavailable, decisions remain open or business units cannot agree how work is performed, those are implementation risks. Bring them into governance and the delivery-control cycle rather than hiding them in workshop notes.