Prepare a shared view of the work
At Venus Fashion, I mapped a fragmented web development process across functional teams and led a two-day workshop to redesign how the work moved. We examined the current state, developed a future state together, and followed implementation with feedback. The preparation gave the discussion something concrete to work from.
For your own workshop, choose a process with a clear beginning and end. Interview the people who send, receive, and approve the work. Ask each person to walk through a recent example, including what happened when information was incomplete.
Decide what the workshop must settle
Write the required decisions before you write the agenda. A focused workshop might need to settle:
- What makes a request ready for the receiving team.
- Who accepts responsibility at each handoff.
- Which conditions allow work to proceed and which require a decision.
- How exceptions are raised and resolved.
- What evidence will show whether the revised process is helping.
Use these decisions to select participants. Include the people with knowledge of the work and the authority to make or approve the relevant changes. If an essential decision cannot be made in the room, identify its owner and approval route beforehand.
Illustrative example: a request that keeps returning
Illustrative example: A request moves from an account team to a delivery team, then returns because the delivery team cannot confirm what was promised. The account team believes its notes are sufficient. The delivery team needs a specific acceptance condition.
Ask both teams to examine the same sample request. Have the sender identify what it considers complete, then have the receiver explain what it needs to begin. Record the difference in terms of missing information, responsibility, and the next decision.
The workshop can then agree a readiness rule and a clear route for exceptions. A broad request to communicate better would leave those operating details unresolved.
Give the sessions different jobs
Use the first session to establish a shared understanding of the current process and its consequential gaps. Walk one representative item through the map. Make waiting, rework, and informal approvals visible. Keep a separate list of questions that need evidence.
Use the next session to make the design decisions. Work through the same item using the proposed process, then introduce an exception. Ask the participants to explain:
- What information moves with the work.
- Who knows that the handoff is ready.
- Who can accept it or send it back.
- Where an unresolved issue goes next.
Adjust the design when the explanation breaks down. The goal is an agreement the participants can apply consistently.
Leave with an operating agreement
Before closing, capture the decisions in a compact set of working materials:
- A process map with the agreed steps, owners, and handoffs.
- A readiness checklist for the most important transition between teams.
- An exception route that identifies who decides when normal conditions are not met.
- An implementation list with named owners for changes to tools, guidance, and team communication.
- A review appointment with the people who will assess the first use of the process.
Read back the decisions. Give participants a final opportunity to identify an obligation they cannot fulfill or a dependency that remains unresolved.
Review the first use
Begin with an agreed scope and examine what happens when people use the process. Ask where work still waited, which instructions needed explanation, and whether the receiving team got what it needed. Compare the experience with the original problem the workshop was intended to address.
Update the operating agreement when the team makes a deliberate change. Keep the reason visible. A workshop produces value through the decisions people carry into daily work and the discipline they use to improve those decisions afterward.

