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 artifact.

The colorful 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 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 through practice , such as 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 that it 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 help.

• Start small . Deliverables may be 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 design and in the invitation process. Investigate expectations to possibly address the deeper needs of the organization. The whys behind a request for a deliverable are usually worth investigating.

• Explicitly state that EventStorming is a draft model , not the final artifact. Show pictures of what the workshop artifact may look like. If a polished artifact is necessary, it can be produced, provided key people have time dedicated to it.

• Don't be caged by the EventStorming format: just because EventStorming is a draft, lo-fi model doesn't mean your overall workshop design can't include different formats and models. Your goal is not to run an EventStorming, but to solve a problem. EventStorming is a tool in the process.

• Double-check the expectations before kicking off the workshop with an Expectations Map . It's probably already too late to add an extra (especially if you negotiated the price), but till better than after the workshop.

• 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 insights from a modeling session to build a running prototype can be a very effective strategy. The intermediate artifact becomes necessary when you have to put an artificial pause between the workshop and the first implementation round.