Domain Discovery Facilitation: Make Scale Explicit
If you facilitate or attend domain discovery workshops, one of the most effective and simplest ways to uncover insights is to make the scale or size of something explicit. The scale of something influences the importance and how we treat it.
Making scale explicit can lead to all kinds of insights, like where the biggest opportunities to improve a product can be found. For example, are we talking about a manual process performed by one employee or one thousand employees?
“How often does this happen?”, “How many people perform this role?”, and “How long does it take?” are the types of questions that make implicit assumptions about scale explicit.
Sometimes, these questions highlight that the scale isn’t understood “We don’t actually know how many customers abandon their cart! Maybe we shouldn’t start the new project just yet...”
If you facilitate a lot of workshops with companies in various industries, these types of questions can help you to make discoveries even when you know little about the industry.
How Many People Assume This Role?
A common scenario when mapping out operational business processes is to uncover manual processes that involve spreadsheets, printing out paper, or hacking tools like email inboxes to function as job queues.
When using Process Modelling Event Storming, the notation accentuates human steps in a process (green information followed by yellow actor performing blue action) and draws us in to explore automation possibilities.
Before deciding this is the biggest problem, and then spending hours designing an automated solution, accentuating the scale with a few very trivial questions can help understand the cost/benefits, and avoid being drawn in at the expense of more valuable opportunities
To understand the cost-saving opportunity, a good question to ask is “How many people perform this role?” Automation can also reduce lead times and improve outcomes, so it’s also useful to ask “How will a shorter lead time improve customer/business outcomes ?”.
How Many Different Roles Can the Same Person Play?
When mapping out processes and identifying roles, it’s easy to make the assumption that each role represents a different person. But it’s very common for the same person to play multiple roles within a domain.
Making this explicit can uncover opportunities like when skilled employees get bogged down in low-skill tasks and responsibilities. This wastes their valuable time and frustrates them.
By identifying the multiple different roles a single person can play, we can uncover which of those roles they provide the most value in, and explore possibilities to avoid their time and expertise being put to sub-optimal use in other roles.
During a workshop in the real estate industry, making explicit the fact that the same person could play the role of buyer, seller, and landlord, all at the same time, had a big impact on the direction of the session.
How Often Does this Happen?
During one workshop, I asked a developer “How often does this go wrong?”. He said it very rarely happens and is not something to worry about.
Immediately after, however, one of the customer support people replied “I’ve had to deal with two drivers this morning who have that problem, it’s a common issue.”
As this anecdote shows, asking questions about scale can reveal misconceptions and disagreement, and help a group move towards a shared understanding of the realities. This is why collaborative workshops involving a diverse mix of attendees increase the chances of discoveries and amplify the impact.
When analyzing processes, people are often drawn to what appears to be the bottleneck; “This step of the process can take up to 2 weeks, we really have to fix this.”. But without understanding how often the worst-case scenario of 2 weeks happens, we can’t be sure it is an opportunity worth focusing on.
What’s the Frequency of Each Scenario?
When a journey or process can branch off into one of the multiple possible flows, a question you can ask here is “Which scenario is the most common?” or “What’s the percentage breakdown for these scenarios [in terms of how frequently they occur]?”.
Sometimes you might want to focus on the most common case. If one case is responsible for 90% of occurrences then any optimizations could have a positive impact on 90% of cases. Alternatively, you may want to explore the least common: “Why are customers rarely choosing this approach?”, “What could we do to increase take-up of this approach?”.
I was facilitating a workshop for a financial services company which focused on transferring resources between providers. There was an industry expert consultant in the workshop. He didn’t see the point of the workshop and was being mildly disruptive, implying there was no need for this workshop because “we already have diagrams of this.”.
We identified there were three triggers that could kick off a workflow. I, with no domain knowledge, asked him to give us a breakdown of the three scenarios. He fumbled around for a few minutes before defensively conceding he didn’t know the answer.
It wasn’t a trick question, I would have asked it regardless of who was in the workshop. The point is, a simple question that any facilitator could ask can even highlight gaps in domain experts’ knowledge… and help them to see value in collaborative workshops if they are sceptical.
How Many at a Given Point in Time?
Mapping out processes, journeys, and workflows has a blind spot which clarifying questions can help to address. When we map a process, we often model from the perspective of a single user, and this means we can easily miss the complexity of multiple users who are all active in the domain at a point in time.
We can ask questions like “How many orders are placed per minute at peak time?”, “What’s the minimum and maximum number of orders a restaurant may be processing at a given point in time, and what’s different in each of these scenarios (e.g. delivery time doubles, kitchen staff make more errors)?”.
How Can the Duration Vary?
“How much time is there between these 2 steps in the process?”, and “How does the time vary?”. Questions like this make implicit timescales explicit.
With a technique like Event Storming, you can ask this question about any two random events on the Event Storm if you’re not sure where to focus and want to probe for discoveries.
After making a timeframe explicit, you can follow up with questions to understand what causes the timeframe to vary and the breakdown of durations, and of course the business impact of slower times.
How Has and Will the Scale Change Over Time?
A good facilitation technique in general is to explore how the system has evolved into the current state and how it is likely to evolve in the future. For example, an existing process may have been designed for a scale of one thousand customers and now the business has fifty thousand customers.
Some questions you can ask are: “What are the factors that contributed to the system being designed in this way?”, “Why was this approach chosen over other approaches?”, “What was the scale when this process was designed, and how is it different now?”.
As the scale increases, inefficiencies become more costly. So it can be helpful to understand if the current system design is intentional or is based on constraints and economics that no longer hold at the current scale.
In a recent workshop, someone suggested that a series of checks after an application could all be done before an application to speed up time and reduce effort. Previously, that wasn’t possible for technical reasons, but those constraints no longer existed so the design could be improved.
Looking forward is equally important, anticipating how the scale will change in future.
What if this Number was Higher/Lower?
Another simple trick to add to your toolbox is to look for numbers and challenge them. “Why is the sign up fee £200? Why not £150 or £100? What would happen if we removed it?”.
These types of questions can help to make explicit the randomness of certain decisions. Sometimes you get an answer that indicates a high level of randomness “The requirements weren’t clear so the developer picked a number that seemed sensible.” or “We were a startup with no data, so we picked that number but now we do have data and maybe we could review it.”
Other times there is a bit more scientific or data-driven reasoning. The number makes sense, but there is still value in everybody else understanding the rationale.
Make Scale Explicit in Your Next Workshop
If you’re new to facilitating workshops and would like to get better at helping groups make valuable discoveries about their domain, I encourage you to start making the scale explicit in your future workshops.
The questions are very simple, and if you’re using techniques like Event Storming, you can look at almost any event and think of a scale-related question to start probing for opportunities and increase the engagement of attendees.
Asking these types of questions will also help you to think of other types of questions that lead to domain discoveries.
Let me know how it goes if you try it out, and leave a comment if you have any favourite facilitator questions you’d like to share.
