Deliverable Obsession

In-person workshops, particularly the Big Picture format, have stringent participation requirements. So many stakeholders, expected to be available on the same day, can raise more than a few eyebrows. Room and logistical requirements can increase the event budget, especially if you're working in a remote or distributed organization.

When organising high-stakes workshops, the pressure to justify the organisational effort can turn into an explicit requests for deliverables to be used as a measurable outcome.

While budget concerns are absolutely relevant, some sponsors' obsession with deliverables can highlight misconceptions about the nature of the workshop (which is fine if they've never joined one) and deeper flaws in their understanding of software development.

The main outcome of a discovery workshop is collective learning , the result of the many conversations needed to solve the massive-scale orange puzzle, but which cannot be effectively captured in a single artefact.

The colourful sequence of sticky notes on the paper roll can be a fantastic anchor for remembering important conversations in the days immediately following the workshop, but it won't be a good medium for those who didn't actively join the workshop.

Sometimes exposing the contradictions of the current state is enough to trigger a specific response. But this is something that we can't promise.

Overall, focusing on the deliverable will make you lose sight of the real workshop goal.

• If the goal was learning , then reinforcing with practice , like building a prototype, can be the fastest way to consolidate the findings.

• If the goal was to solve a critical issue , then documenting the problem is slowing down the resolution path.

• If the goal was to build a case for someone else to decide , then you probably had the wrong people in the workshop.

The obsession with deliverables signals that something is off, and probably cannot be completely solved before the workshop.

The obsession with deliverables can be a revealing symptom of a deeper misunderstanding, and sometimes you won't have many cards to play before the workshop.

While there is no perfect solution to this problem, here are a few ideas that may eventually help.

• Start small . Deliverables are requested by sponsors who don't understand yet, but that should provide approval. You may eventually flip the discussion, running smaller workshops that don't require approval but that build trust and awareness.

• Clarify expectations for the workshop in advance by actively engaging in the invitation process. Investigate unreasonable expectations to possibly address the deeper need.

• Explicitly state that EventStorming is a draft model not the final artefact. If some polished artefact is necessary, it can be produced, given that key people have time dedicated to that.

• Double-check the expectations before kicking-off the workshop with an Expectations Map

• If a specific deliverable, like a [ Context Map ], is part of the expectations, have a task team ready to work on it on the days immediately following the workshop.

• With Software Design Format the best deliverable is running code. Leveraging the insights from a modelling session into a running prototype can be a very effective strategy.