10 Top Tips for Mapping a Process
Facilitating a process mapping session can take you down rabbit holes, sap time, be frustrating and quite boring, the following 10 top tips should help you avoid this.
All improvement methodologies use process mapping as a tool to understand, baseline and agree on how the current process runs, they also use mapping to agree on how any improvements will fit together by mapping the future process. Mapping is hugely useful, it brings the team together around a problem, it externalises the process avoiding finger-pointing, it makes clear the real problems causing the process to fail and it is a backbone on which the team can hang other data and information; think costs, lead times, and even who does what.
1. Agree on the owner of the process and assemble the right team
Often you will have a manager come to you with a problem asking you to help, sometimes this person doesn’t own the process, an example might be a Quality Manager saying that a certain process that their team has audited isn’t working properly. To effectively map the process, you will need the support of the manager in charge of the process. Process Mapping is a team effort, it requires the agreement and trust of everyone involved in the process for it to add value. The key to that is the leadership from the owner of the process. In the case of the quality manager pointing his finger at a process, they would need to approach the manager in charge of it, a manager at high enough level to allow a cross-section of representation from each step and each management level to attend the mapping session. The higher the mapping level the higher the manager needs to be.
Ensuring the right people on the team is paramount, there needs to be representation from each process step (ideally the people who actually do the work) and there needs to be representation from each management level from the producer level to one level below the process owner.
When you have managers in the room you will encounter ones who have been told to be there but think process mapping is trivial compared to their very important “day job”. This is where your process owner is essential, the manager will constantly take phone calls, leaving the room, or may just not come back after a break, you will need to have agreed upfront with the Process owner what the protocol will be for this eventuality. In the past, I have agreed with the Process Owner that if someone displays unengaged behaviour, I will call them, and they will either come to the room or go and find the individual and tell them to take part in the session properly making it known how important the session is to them personally; “what is important to my manager is important to me”.
I had a case where I was mapping with some very senior managers and one was always late coming back, I had to break the session to take him aside and discuss with him the example he was setting to his peers and subordinates and to remember back to the introduction the process owner gave (in this case it was the managing director) where he laid out the importance of everyone taking part properly. It was a very uncomfortable discussion for both of us but that it had to happen for the session to reach its goals.
2. Agree on the problem before starting to map
Clearly understanding the problem will help you decide the process that you need to map, and the level at which you should map.
I was facilitating a mapping session. I had agreed on the problem statement with the process owner and had assembled the team. As a professional Lean/Continuous Improvement coach I didn’t know the subject process in-depth, but I was experienced enough to know a good problem statement. The process owner had sent out the charter (on which the problem statement was provided) requesting everyone to read it an come back with queries.
Normally I would have the team interpret the problem statement into their own words on a flipchart to ensure that they had read and understood the problem. This time I didn’t do it, it was supposed to be a quick mapping session to pull out general issues. What I didn’t know was that only a couple of the people had read the charter the others just pitched-up expecting to attend but not participate. The people who had read the charter were the quiet ones, so from the beginning, I was getting the information from the louder team members who hadn’t read the problem statement.
We mapped half the process before the quite ones finally spoke-up saying “we are mapping the wrong process” (by that time I too was having concerns). I opened the concern up to the room and we agreed to start again. This time we mapped the correct process but we had wasted about an hour of our one-day session.
3. Agree on a Value statement
Another pre-mapping exercise I usually run is having the team define what value the process is supposed to deliver. I do this by having them, as a team, write a value statement on a flipchart that we then put on the wall next to the process map.
In Lean thinking the first principle is Value. This is manifests during process mapping by designating each process step as either, Value-Adding (VA) or Non-Value Adding (NVA) (*Lean-Six Sigma adds a “business Value-Add” (BVA) category). When the team are evaluating the process, depending on the problem, they are likely to evaluate each step as VA or NVA, Green or Red. This can lead to dissension, as individuals are challenged in what they do, VA is if the step needs to be done, it is about the value of the step in the eyes of the customer. Also, people will have put steps into a process as a reaction to a problem they have had in the past, checks, tests and approvals are common ones, so if you are facilitating you will have to challenge these deeply held assumptions or paradigms. Having an agreed Value Statement makes this discussion much easier, when there is resistance you can direct the individual to the Value Statement and ask them “does this step take the product or service any closer to reaching this value?” Usually, the individual will make the right call, seeing the definition for what it is and not a personal attack.
4. Control the room
One of the worst things a facilitator can do is have their own writing on the process map, for this to happen the facilitator would have to interpret what was being said which might not be correct and may lead to accusations that the “answer” on the wall was what the facilitator said, not the sentiment of the team.
For a long time, to avoid this I would facilitate from the back of the room, cajoling people to be “scribe” and do the writing. Getting people to volunteer is incredibly difficult, takes time, it means taking them out of the discussion. They are likely to write in too much detail sapping time and energy so people become bored and begin to think their time is being wasted.
I facilitated with a friend about 6 years ago and he showed me a different way to facilitate the process map. That is to stand in front of the map, split the post-it-note pad(s) amongst the team and provide everyone with a pen (I have found that Sharpies work best). I then tell the team what we are going to do, then have them tell me what the last process step is, this will take a few minutes, during which I will be monitoring behaviours for who is speaking (and who is holding back), is the speaker taking the team down a rabbit hole? and listening for the phrasing the team wants to use on the post-it-note. Once agreement on the wording begins to form, I will repeat it back to the team so they can confirm (or not) that they agree, I will then direct one of them to write the exact words. As that individual is writing the rest of the team will move on to the next post-it. When the scribe finishes they hand it to me and I stick it onto the map.
Being this directive at the start gets the team used to the facilitator, reduces resistance to the plan the facilitator has worked out for the session by building trust that there is a plan (this trust really useful when something is discovered which means the plan needs to be reformulated “on the wing”). Now rapport and trust have been built the mapping process can be run much quicker, the facilitator can introduce games like scoring when people write their post-its upside down or on the sticky side, so the team have a bit of fun, and boredom is reduced.
One of the biggest drawers of time is the rabbit hole, this is where someone drags the discussion off-topic. What the person is saying might be very important but out-of-scope. This is where a Car Park (or Parking Lot for my friends in America) flipchart is useful. The facilitator monitors the discussion for rabbit holes and respectfully directs the individual to write the issue on a post-it which can be added to the Car Park to be reported to the Process Owner for action at a later date. This allows that individual to remove the issue from their mind and refocus on the process map.
5. KISS (Keep It Simple Stupid)
Like an investigation let what you discover lead you where you need to go. In general, a basic process backbone (the process steps) and issues make-up the most simple process map. However, a strength of a process map is that it uncovers problems not recognised before, so you may decide to add things to the map, for instance: SIPOC, VA/NVA, data tickets etc. Often you won’t know what you will need before the need is revealed during mapping, for example, during the discussion around the process map you might pick-up that there are a lot of IT systems that need to be fed, this might be something to explore on the map by indicating what systems need to be updated at each process step. If you only add to the map based on what is revealed, much like a detective following clues, the team are much less likely to feel that their time has been wasted.
6. Map only what happens (not what should happen)
Often people will give you what the “book” says they should do; managers might even say “I don’t need to provide people to help you map just look at the procedure, that’s what my people do”. With any procedure, no matter what it is there are things that people do that might not be in the procedure, even the really good ones, that’s why we have people doing it and not machines. People can deal with unforeseen difficulties much better than machines; perhaps there has been a quality issue that needs to be dealt with, or something has arrived late, the human will need to do stuff not covered in the procedure, even if they still comply with the procedure, to make the process work. It is these actions that we are trying to find. Coping with the day-to-day business of doing work is not bad, but it is likely to be NVA and very frustrating, these are where the real savings are to be made and gives our problem solving the focus it needs.
7. Allow the team to add issues
The point of mapping a process is to eventually make the process work better, it will be the team who will eventually carry out the implementation actions to put any solutions in place, you will also need them to be the ones who will persuade their colleagues that the changes are necessary and useful and, in most cases, going to make lives easier. I could talk to the other stakeholders until I am blue-in-the-face but will never have a hope of generating support the way one of their colleagues can.
How do we generate this true empowerment? We give everyone a say. Once the process backbone had been mapped you can allow each individual to write all the issues with the process (from their own individual point of view) on post-it-notes sticking them under the most relevant process step. If you give people a say and, in the case of a Kaizen event, allow them to work out solutions they will be much more likely to be an advocate of any improvements and have much more enthusiasm to complete the implementation actions.
8. Test the future process and then ‘test’ the future process
If you are using the process map to join all the solutions into a process you can test this future process in two ways: as a process on the wall and as a trial run.
Edward de Bono, the guru on thinking about thinking, developed a technique about people donning different colour “hats” that correspond to viewpoints, e.g., Yellow-hat is positive, Red-hat intuition, White-hat facts and data, Black-Hat caution and weaknesses. Of these, I mostly use the Black Hat point of view.
So once the future process map has been created you look for the most negative person, the person who is always finding fault, this person can be your black hat. Show them the future state map and ask them to tell the team where the problems and difficulties are; where the process is likely to fail, have someone poised with a flipchart to list all these issues and risks.
Once “black hat” has listed the difficulties the team can then work to either solve them or mitigate them. Incidentally, it is useful for “Black Hat” to be one of the stakeholders but not part of the team as they will have fresh eyes and not be subject to the “group-think” that will inevitably be built up in the team through the improvement process.
The next stage would be to set-up the new process and do an actual physical run through, have a flipchart close to the process and as issues are revealed during the test run, they can be recorded for the team to solve or mitigate.
9. Map to the right granularity
In Lean Six Sigma the different levels of mapping are clearly defined: Management View, Worker View and Improvement View, each giving an increasingly detailed view of the process. The Management View is very high level with little detail but a wide view across the business, the Worker View shows the general process steps, decisions and interactions and the Improvement View shows detailed steps, such as “operator walks from work station to Kanban shelf”, where inputs, outputs and tools and materials can be appended. The strategy is to map at the highest level to identify which part of the big picture should be focused on next, then map this focus area and do the same until we are down to the improvement view. In the early days of an organisation adopting CI or Lean the strictly nested view is quite difficult to pull off because the leadership of the organisation have not yet seen the value of this activity. So, you may not be able to get the right people in the room to map at each of these levels. This means you would have to estimate the level, defining it from the problem statement. Sometimes you get it wrong. I have had a case where we mapped the process and were finding it difficult the find any issues, the team could only see a handful of trivial problems, but the data showed there were real issues, so as a team we identified a section that we thought might throw up more issues and broke it down into much more detail. With greater granularity the team were able to identify many more issues all relatively small but when “affinitied” and root cause analysed they provided great potential for improvement.
So, if you are having difficulty identifying issues drop down a level.
10. Map the process in less than 9 process steps
Mapping a process requires each step to be analysed, as I discussed above getting the detail right is important but keeping the right level of detail is important too. Each mapped process step will need to be examined and you need to be careful with your time.
As the discussion goes on the team will drag itself down into the weeds. There are two ways I have found to manage this. First is to tell the team upfront that we need to only map the process in 9 steps or less, then challenge each process step as they suggest it, this is difficult to do without losing rapport with the team and them losing faith in your impartiality. The other way I have found is to let the team put as many process-steps up as they like, but once they have agreed on the process, challenge them to bring the process steps back to the 9 steps by combining process steps. You can clump the combined process steps above the main process map, these clumps can be used later to help define their step when going through the next process analysis tools.
So, using these 10 top tips should help you manage your team to complete their mapping task, getting the outcomes they need in as short a time frame as possible. Also, you are more likely to keep the interest and energy of the team without frustrating or boring them.
Darren Clyde has spent 15 years working with organisations and teams to reduce cost and effort of doing business. He has facilitated many teams in different countries from a wide range of backgrounds including, aviation, military, medical and energy organizations in mapping their processes.
* Business Value Add are process steps that must be done to be legal. For instance, financial auditing activity would be a business value add. Lean views Business Value added as “Value Added” as the customer wants the process to provide the value to them legally so any illegal or unethical practices don’t come back to the customer as brand damage; think of the large companies that have used child labour in the past.
References:
De Bono, E. (1956). Six Thinking Hats. Cambridge: Little, Brown and Company.
