No Pains No Gains?

Should we start by capturing pains first in a process workshop? Or are we just inflicting more pain on ourselves?

Recently, a lot of discussions with our partners has been around the order in which they should conduct workshops for improvement projects. They have described how they often started with a ‘Pains’ session with subject matter experts followed by a series of process workshops.

In fact in every instance, our partners expressed their own pain and frustration in completing this exercise. Time wasted discussing a pain that later turned out to be low priority or the really big problems they had to deal with that didn’t come out until later workshops. Of course by this stage they’d already spent a lot of time and effort exploring solutions that were no longer relevant.

Inevitably we wondered why they did it this way but the answer was predictable

 “we’ve always done it this way even though we always tell our clients that’s the worst thing they can say!”

It’s not however,  just “pains” workshops where this happens, we often see it with requirements gathering workshops. A team gathers around a flipchart and lists all the requirements / pains / risks etc that they believe are the most important. Yet when we dig into these they are either not as important as they first appeared, or those that didn’t seem important at first turn out to be the highest priority. This seems to be a common issue experienced in process workshops.  

Why does this happen?

Asking people what pains they experience, or what they require from a new system, are not easy questions to answer. On the face of it they appear straight forward. What do I not like about the current process? Sure I can answer that, but how I express it, how I perceive it, when it last happened to me and how I experience it are likely to be quite different to the next person.

It means that how I answer that question on any given day could result in a completely different answer. Combine this with a group of different people and you also have to contend with how loud someone talks, their individual personalities and the level of engagement in this particular session.

The psychologist Daniel Kahneman in his book ‘Thinking, Fast and Slow’  describes ‘substitution’ a behaviour common in humans when faced with difficult to answer and ambiguous questions. The brain is inherently lazy and always finds the easiest way to answer a particular question. When asked about the pains you feel in a particular process you’re unlikely to think really deeply about this and will simply substitute an answer that you can easily remember – therefore the last thing that happened to you rather than the most painful thing.

Image taken from Skore’s Digital Discovery Platform

What we can do about it?

As process discovery experts we must make it as easy as possible for people to express the pains they feel in context. This means creating a framework. A framework they can use to start with and which becomes the process to which the pains, or requirements, relate to.

Rather than starting with the pains session, it is important to start with defining and agreeing the process as it happens today. This provides a common language that the whole team can use. A common language to describe the pains in the same way, rather than multiple people describing the same pains in very different ways.

As the process is laid out it  will become easy for SMEs to describe pains and requirements in the context of the process. The prioritisation and sizing of the problem can then be captured live at the same time. This also makes it unnecessary for the team to have multiple workshops.

Skore Digital Discovery

At Skore we have specifically designed our platform to capture business processes live in workshops. Along with the process descriptions you can capture pain points and requirements, and quantify them, all in the context of the relevant step in the process. As the information is captured directly into the software there’s no need to take photos and write up notes afterward. Its effortless as your pain points, requirements and quantification data are also stored in the same place so no more multiple spreadsheets.


Instead of starting with a pain points or requirements session, you need to start with capturing the process. This gives you the framework with which to have a much more meaningful conversation about the pains and requirements in context. The conversations are not only more focused but the whole exercise is much quicker, keeping subject matter experts more engaged and onboard.

Skore Digital Discovery is a process capture, improvement and analysis platform designed to simplify the complexity. Click here to find out more about how Skore can revolutionise the way you deal with processes and transformation in your organisation.

If you enjoyed this, please share it:
Visit Us

Leave a Reply