This blog post is about collaboration and ‘Wardley Mapping for Good’. How we can understand and improve collaboration with mapping.
I analyse an instance of collaboration to solve a tricky IT problem that occurred a few years ago at a previous employer. The approach explicitly uses some systems and complexity theories that I was learning about, including Clean Language and OODA.
While what was done in this situation can’t be taken and simply applied to another problem the approach contains elements that have worked, so can be considered as parts of future solutions.
Part Cynefin® Complex, Part Complicated
Like most problems, there were elements of this problem that were ‘Complicated’ in Cynefin® language. Complicated problems can be solved by experts. The main issues here was with the available data (there was very little) , and the random nature of the problem (we couldn’t recreate it). But we knew that there was a solution to the problem to be found that would make it go away.
The Complex part of the problem was the bit involving people. The understanding and skills were distributed amongst 6 experts all having incomplete data and who were naturally making inferences and assumptions about what was going on.
The inferences and assumptions were based on previous problems, and an understandable desire for the problem to be not attributable to them. The experts had different managers, different pressures from their normal workload, different collaboration and work styles. If they were blamed unfairly they could have walked away from the problem solving, and would likely have had their managers backing.
So, what’s the problem?
The evidence we have is that
- In a large University, running computer based exams
- In room with 60 computers, 50+ in use
- Between 0(zero) and 8 students have an issue during an exam where their PC loses connection to the exam software and they have to change machine, be given extra time, and usually put in a ‘Extenuating Circumstances’ form…..
- We have exams 9-5, most days for three weeks
- There is no alternative to online exams, every computer room that can run them is fully booked.
- The problem appears to fix itself in a couple of minutes
The problem appears entirely random. We can observe the room for hours, and nothing happens. Then 3 problems happen in a minute where computers lose connectivity. And the connectivity comes back quickly without intervention. Seemingly no pattern, although people think they see them. Days go by without any issues, and we think we’ve fixed it. Then the problem comes back. We can’t recreate the problem ourselves, we’re waiting for the few minutes each day it shows up before it fixes itself.
The frustration is everywhere. No one is happy. Waking up in the morning knowing that the problem is job #1 is stressful. I just want to stay in bed.
Finding the solution takes 3 weeks, and lots of observation and changes to hardware and software.
What I did
This is a Miro of the User Needs that I recognised as needing to be met.
Understanding User Needs and what you do to meet them is the first part of creating a Wardley Map.
We had a shared goal: Solve the IT problem affecting exams. Ideally without being the person who had to fix it.
USER NEED: Engage Colleagues in solving the problem
There was a real bind for colleagues working to fix this. Everyone wanted the problem to be fixed, but no-one really wanted the problem to be in their area. Any inference that the problem might be in someones area that wasn’t backed up 100% with evidence would likely put someone in a fight, flight or freeze response. The organisation wasn’t ‘safe to be wrong’, and there was nothing I could do to change this.
Knowing this I knew our approach had to be evidence based, and that inferences needed to be stated as such and owned by the person making them. This is a facilitation skill, and crucially needs to be done without making anyone wrong.
USER NEED: Experts need to have a shared understanding of the problem
We had documentation and diagrams of the systems we ran, but none showed the ‘end to end’ technology required for a user to run this software in a linear way. Unless you make these diagrams explicitly they may not exist. The diagram below shows the end to end tech. We could design experiments that ruled out half of the tech at a time in a way that is easy to communicate. This also provided reassurance that we were in control.
To make this diagram, I spoke to all of the people involved about the parts of the systems using Clean Language Interviewing. Clean Language questions don’t contain the questioners ideas, assumptions or prior understanding. The questions are also good at getting details that may be overlooked. This was vital in collecting 6 peoples separate understanding of the situation and putting together a shared understanding that everyone could agree with. Of course this is in the Cynefin Complicated domain, so there is a truth to find.
This diagram also contained the places where we could collect evidence for the Observe part of OODA.
Having a visual linear understanding of what needs to happen for a user to take an exam, allows us to look for tests/experiments that split the problem in two – and rule out half of the technology stack.
A key here was getting agreement with everyone involved exactly what the results would mean before we carried out the test. Some tests where the results would be inconclusive were dismissed. This approach removed the feeling that people were being blamed without evidence. As part of the team responsible, I knew that if anyone was going to suggest the problem was mine to solve, they would be doing it with the proper evidence.
This approach – getting agreement on the scope, agreeing on the evidence (and separating it from inference), and agreeing on the outcome of the tests we carried out before we did them was sufficient to make sure colleagues stayed involved and engaged.
It still wasn’t going to be a blame free environment, but it was scientific and agreed in advance. There was no space for anyones inference or favourite scapegoat. This involved considerable facilitation skills in discussions to keep to evidence and not make people wrong when they were making inferences or spotting potential patterns.
I was able to explain the approach using OODA to show how we approached the problem, and to show when we would have information that we could communicate to people. I ended up putting this in a RACI flowchart to show managers we knew what we were doing and had a plan.
This is very context specific. I knew the managers involved would like this sort of diagram. It’s not for everyone.
From this example it’s possible to understand the user needs in a particular collaboration context and look at what was done to meet those needs. There may be better and worse alternatives, and these may require more or less skill, facilitation. There may be some strategies for improvement, and things that may make things worse.
Many more real life examples would be required to get enough data to be sure how to map collaboration, but I think each example in context can be of use.
So what was the IT problem?
It turned out that the network switch for the room was deciding to put ports into ‘eco sleep’ mode, entirely at random, independent of the traffic on the port, and without any communication. 300 seconds later the port was back to normal. Some days it didn’t appear to do this at all. Sometimes it would break 8 times in a morning.
This was fixed in a firmware patch, but the problem was not acknowledged as part of the patch changelog by the vendor.
We could not recreate the issue, and there was no logging of the event anywhere. We just saw network traffic, then nothing, then traffic.
It turns out there were other switches with the same firmware in the organisation. There was lots for grumbling about IT, the network, Microsoft etc, but IT support never saw the problem enough to start to diagnose it.