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
What your scope already answers
- Scope and exclusions: 3 topics across 1 modules.
- Workshop series: 1 end-to-end streams — Plan-to-Deliver (Project).
- Assumed already in place: General Ledger — depended on, not included.
First draft
3/8 sections the scope could speak to
Generated from your scope. It is not a finished document and it does not pretend to be — where a section needs something only you have, it says so rather than inventing a plausible sentence, because plausible sentences are the ones that get left in.
Workshop plan
Objectives and the decisions to be made
5 artefacts have to be produced across the releases, 1 of which are decisions that constrain everything after them. 1 interfaces need specifying on both sides.
End to end, the work sits on 1 value stream: Plan-to-Deliver (Project).
Series structure, following the streams
The dependency order gives 2 releases: 1. Project Planning; 2. Project Costing. Items within a release have no unmet prerequisite inside the scope and can start together.
Attendees and decision authority per session
To write. The scope cannot supply this one.
Pre-reads, current-state pack and scenarios
To write. The scope cannot supply this one.
Facilitation approach and plain-language rules
To write. The scope cannot supply this one.
Outputs, acceptance and the decision log
To write. The scope cannot supply this one.
Sequence and cross-stream dependencies
1 data flow straddles the scope boundary — one side is changing and the other is not. Capitalised project costs (Asset Management ← Project Costing, monthly; without it: capital work in progress never becomes an asset.).
Logistics, and what happens to the parking lot
To write. The scope cannot supply this one.
Still needed
- Attendees with decision authority — 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.
- The decision each session has to produce — Named in advance. Sessions without one fill their time with current-state narration.
- Pre-reads and current-state pack — Circulated ahead, not read in the room. Including the process as it runs today, with its workarounds named.
- Worked scenarios and real data — The organisation's own transactions, including the awkward ones. Abstractions get agreed quickly and mean different things to different people.
As markdown, to lift into a document
# Workshop plan ## Objectives and the decisions to be made 5 artefacts have to be produced across the releases, 1 of which are decisions that constrain everything after them. 1 interfaces need specifying on both sides. End to end, the work sits on 1 value stream: Plan-to-Deliver (Project). ## Series structure, following the streams The dependency order gives 2 releases: 1. Project Planning; 2. Project Costing. Items within a release have no unmet prerequisite inside the scope and can start together. ## Attendees and decision authority per session > To write. The scope cannot supply this one. ## Pre-reads, current-state pack and scenarios > To write. The scope cannot supply this one. ## Facilitation approach and plain-language rules > To write. The scope cannot supply this one. ## Outputs, acceptance and the decision log > To write. The scope cannot supply this one. ## Sequence and cross-stream dependencies 1 data flow straddles the scope boundary — one side is changing and the other is not. Capitalised project costs (Asset Management ← Project Costing, monthly; without it: capital work in progress never becomes an asset.). ## Logistics, and what happens to the parking lot > To write. The scope cannot supply this one. ## Still needed - **Attendees with decision authority** — 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. - **The decision each session has to produce** — Named in advance. Sessions without one fill their time with current-state narration. - **Pre-reads and current-state pack** — Circulated ahead, not read in the room. Including the process as it runs today, with its workarounds named. - **Worked scenarios and real data** — The organisation's own transactions, including the awkward ones. Abstractions get agreed quickly and mean different things to different people. _First draft from a scope. 3 of 8 sections had something the scope could say; the rest need a person, and so does everything under Still needed._
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