I helped design and run a remote Event Storming project to train an internal team from a govenrment department to run their own activities and also provide a reference example, focussed on an existing challenge they had in migrating off a legacy information system.
I had taken part in Event Storming activities before but had found them unsatisfying in terms of the progress they achieved. In the context of short in-person workshops, the whole thing seemed a bit "hand wavy" to me. Fun to take part in but difficult to discern any actionable outcomes from the blizzard of post-it notes. As it turns out, the reason my previous experiences were bad was because the workshops were poorly planned and implemented, without sufficient time or structure. I can credit my colleague Tom Glover for changing my views on Event Storming as he helped shape an activity that was the opposite of this. We had enough time to plan and execute a great workshop over a 3 week period and in teaching others to do it, we had to focus on how best to structure the knowledge transfer process.
What follows are my own reflections on Event Storming as sensemaking tool for organisational change. As is always the case, the things I learn from doing work on specific projects get bound up with stuff I have read and found interesting as well as thoughts that I have already had but found myself revisiting in a new context. Forgive me if I jump around a bit - I've added some headings to hopefully provide a little structure.
Reconciling organisational cultures
Organisations are never homogenous in terms of their culture. This is true for just about every organisation with more than a few people in it. Nowhere is this more true than in very large, traditional organisations like the government.
As it turned out, the "event journey" we intended to map required an understanding of two different domains - prisons and probation. Within the Ministry of Justice, these represent two distinct areas of operation with their own leadership, budgets, systems and ways of working. Our focus was mostly on prisons with most of the people involved in the Event Storming sessions coming from this part of the organisation. From an early stage, it became clear that there was a big knowledge gap in understanding how probation worked however and the impact this would have on both the provision of service and exchange of information across the organisational boundaries.
The folks that we were working with from the Ministry of Justice were variously, a product manager, two delivery managers and an technical architect. Despite their different roles, it was clear they all shared a desire to take some practical steps towards implementation and believed that Event Storming would help with this. A lot of effort had already been invested in doing service design, as is the guidance from GDS when considering new digital services. What became clear was that there was some tension between the design and delivery culture within the Ministry of Justice, with design being seen as a more centralised function relative to the more localised concerns of those people responsible for delivering working products. Despite agreement on the value of doing service design, relatively small differences in perspective on the outputs of service design were magnified by considerations of ownership across professional boundaries.
Many of the people involved in the Event Storming sessions worked in the prison service and used existing IT systems. They were able to provide valuable perspective on how things worked on the ground. However, they were unfamiliar with the ways of working within digital and technology teams, where making use of tools like Miro to collaborate on things like Event Storming is a more familiar experience. We were able to translate their expertise onto the Event Storming artefacts but I did wonder what they made of it all and whether they believed or hoped that such a workshop would have any real bearing on their day-to-day work. At the end of the day, collaborative activities like Event Storming represent one method for sensemaking. It doesn't replace the need for more intimate forms of research like one-to-one interviews, where we meet people in their working environments rather than require them to come to ours.
Limits of existing artefacts
As I alluded to above, there was gap in understanding between the professional culture and practices of service designers and tech architects, to take the two most extreme ends of the spectrum of professionals we engaged with. This gap was manifest in the way that each regarded their own artefacts as somehow the closest representation of truth. In the case of service designers, journey maps had been researched and presented in the form of polished design artefacts. The technical architecture was throughly abstracted and included the detail of all known systems. Respectively, these artefacts represented why the work needed to be done and where but neither could provide the answer for everyone as to how the work should be done.
Boundary visuals for shared meaning
In the book Visualising Business Transformation, authors Jonathan Whelan and Stephen Whitla present a diagram they call the Visualisation Continuum. They divide up lot of different types of visuals according to two axes:
concreteness of visual language
contraint of visual language
The resulting division makes it clear that there are two communities who are seeking meaning from visualisations:
People and Change community
Technical Implementation community
What we saw with service designers and tech architects from the Ministry of Justice is just one real-world example of how this division plays out. People's professional roles carry with them a lot of hidden bias based on different types of expertise.
The Visualisation Continuum, Visualising Business Transformation 2020 - Jonathan Whelan and Stephen Whitla
The real value of Event Storming as a visual artefact, is that it represent a boundary object that sits on the dividing line and can provide meaning to both communities. Although it's roots are in a more technical domain, the resulting visual follows a horizontal journey that is concerns events (that people want to make sense of) happening over time, something that everyone can relate to given it's roots in our everyday experience.
Organisations as material for design
The final reflection I have is a selfish one as a designer. When I was on a project for the Co-op a few year back, we were helping them design a new service for their members. This required us to basically go door-to-door throughout the organisation asking departments what they could offer members and what help they would like from them. It was a bit of revelation for me and opened my eyes to how much untapped potential exists within a typical, large organisation. I started to think of all these opportunities as "material" for design, in the sense of needing to first know about their properties before you can craft something with them.
I had a similar feeling in relation to the Event Storming. So much information about operations, artefacts and experience was captured on a single canvas that it represented a kind of "cheatsheet" for any who wanted to quickly absorb and understand a lot of high-level organisational context.