Workshop plan
AlphaHow design actually gets decided in a room: which workshops, who has authority in each, and what leaves with a decision attached.
What it is for
To stop workshops producing notes instead of decisions. A workshop with no decision to make is a briefing, and should be an email.
- Audience
- Workstream leads, facilitators, business participants.
- The decision it supports
- What the process will be, settled by people who can settle it.
Inputs — 5 blocking
Blocking means the document cannot be honestly drafted without it. The rest can be left open and marked as such.
Workshop series by value stream
From /scope
The end-to-end streams in scope, broken into sessions that follow the flow rather than the org chart — because the hand-offs between teams are where the design problems are.
Delivery
Attendees with decision authority
Only you have it
Per session, who can settle the question in the room. A representative who must check with someone else is a delay, not a decision-maker.
Business owners · Empower People
The decision each session has to produce
Only you have it
Named in advance. Sessions without one fill their time with current-state narration.
Facilitator · Actions and Decisions
Pre-reads and current-state pack
Only you have it
Circulated ahead, not read in the room. Including the process as it runs today, with its workarounds named.
Analysts
Worked scenarios and real data
Only you have it
The organisation's own transactions, including the awkward ones. Abstractions get agreed quickly and mean different things to different people.
Analysts · Ditch the Dirty Talk
Draft around these if needed
Standard process demonstration
Only you have it
What the product does out of the box for this process, shown before the room designs something else.
Solution architect · Development Standards
Decision log and parking lot
In the library
Captured in the room with owner and date, including what the decision assumed. Minutes written afterwards lose the rationale.
Facilitator · Actions and Decisions
Output artefact per session
From /scope
What the session produces and who accepts it, so the workshop has a deliverable rather than a follow-up.
Analysts
Cross-stream dependency map
From /scope
Which sessions produce decisions other sessions need, so the sequence is right and nothing is designed twice.
Delivery
Bring a scope
Several of these inputs can be answered from a scope — the processes in play, the artefacts they demand, the interfaces that straddle the boundary, and the order the work falls into. Pick the areas you intend to change and come back.
Scope it first →Outline
- 01Objectives and the decisions to be made
- 02Series structure, following the streams
- 03Attendees and decision authority per session
- 04Pre-reads, current-state pack and scenarios
- 05Facilitation approach and plain-language rules
- 06Outputs, acceptance and the decision log
- 07Sequence and cross-stream dependencies
- 08Logistics, and what happens to the parking lot
What separates a useful one from a compliant one
- —Every session has a named decision and someone present who can make it.
- —Scenarios use the organisation's own data, including the exceptions.
- —Decisions are captured in the room, with the assumption behind them.
- —Rapid agreement on anything abstract is treated as a warning, not a win.
- —The parking lot has an owner, not just entries.
The rest of the set