Facilitating a Process Mapping Team - The Basics

Key Facilitation Tasks

Remember that process mapping is a group effort, and it best done in a group setting. Hence, your role as facilitator is key. Facilitators need not have experience with the process under study. In fact, there are cases in which a lack of experience around the process in question can actually be a hidden asset because it forces you as facilitator to ask many questions that others might take for granted.

As facilitator, your task is to guide events and question the conventional wisdom while keeping the discussions on track. You must depend upon the team members to be the experts in their processes. Regardless of the specific approach or methodology being used, the key tasks for engaging and facilitating a process mapping team can be outlined as follows:

Identify the key stakeholders and process owners. Clearly, you want to know who the players are, their respective roles on the team, and who grants final approval for the finished product. I use a simple spreadsheet to develop a RACI chart and refer to it as needed. In a later installment, I will illustrate a RACI chart and provide guidelines for use based upon my experience. For now, always bear in mind who the process owners are and what their expectation are, i.e. what they intend to receive at the end of the project. You should also discuss the respective roles of the non-management team participants and understand which people have expertise on which particular subject matter, i.e. your Subject Matter Experts (SMEs). While working with the non-management team members, I like to take a nonthreatening approach and try to make them feel comfortable around me. I want them to be willing to open up and discuss their work, including relevant issues that may hinder them in the performance of their tasks and thus help in the overall process mapping initiative. This is particularly true when team members lack skills and/or experience in process mapping fundamentals.  

Define the project scope and deliverables.  You need to know what it is you are mapping: is it a product, a service, or both? Define the tangible outcomes of the project and be sure to understand what constitutes success to your client. During the course of the project, touch base periodically with the process owners to provide the current status and obtain confirmations on the desired end result. You might be surprised to learn that what you feel constitutes success may not be identical to how they envision success; it may even change during the course of the project. Developing a consensus early can make the rest of the engagement cycle go much more smoothly, and it can also help in keeping expectations clear and manageable. Determining which team members are asked to participate in this initial phase can vary greatly, depending upon how the team is being managed and how process-savvy the participants are.

Identify what you are measuring. Unless you can measure it, you cannot improve it. Not surprisingly, this key task aligns with the “Measure” phase in Lean Six Sigma (Define-Measure-Analyze-Improve-Control). A robust discussion of this key task is beyond the scope of this article, and should be addressed in detail in a future installment. For now, just remember to take the time necessary to adequately define the key metrics, what constitutes value-added, and most importantly to identify what gets in the way of achieving the desired end result. What steps will adds value? What steps are unnecessary? Always take time to identify the issues and pain points, and engage your team in a frank and open discussion of the issues. Bear in mind that what brought about the need for the process mapping initiative in the first place could be the need to address inefficiencies such as non-value added steps, poor handoffs, in adequate communication, and so forth. If you have taken the time to make the team members feel comfortable opening up, then you will have an easier time exposing the issues and the team will feel empowered because they had a part in identifying their pain points and get to take part in doing something about it. This can be a powerful positive motivator for the participants.

Determine the method and type(s) of process maps to create. This is the part in which you really get down to business and build your process maps. Methods for mapping process flows can range from pen & paper to projecting a technical drawing program onto a large-format screen and conducting edits onscreen. I have used both methods, sometimes on the same project. I have found that it is best to begin by taking good notes and capturing as many relevant facts as possible before attempting to create the maps. Then, once they have been reviewed once or twice, you can gain a lot of ground by projecting the flows onto a large screen and allowing sub-teams to view them live and make edits. I say “sub-team” because you want to keep the number of participants in any work session to a minimum. I have found that it works best to have only two or three participants meeting together at one time when you are initially mapping the processes. Having too many people in attendance can actually impede progress. And this is the point at which your team can provide the best value. Remember that these are their processes, they are the experts, and you are well served by asking open questions about how their processes work and then let them develop their process maps. This inclusive approach goes a long way toward building morale and confidence. Regardless of how you do it, this is an exercise that is best learned by doing, and you will need to find the methods that work best for you.

Review and validate the process maps. After completing several rounds of interviews and drafting the process maps, they will need to be reviewed and approved by the process owners. With experience, you will begin to have a feel for how many review cycles a process should go through before it is ready to be signed off by the owners. There is a big difference between a process flow that describes processing an invoice and one that describes the process for preparing annual financial reports. On the people side, you need to be aware of certain management styles and how they can impact the review and approval process. For example, some process owners are anxious to move onto the next project and may not take the time and care necessary to ensure high quality; others may become obsessed with details and unable to agree on what constitutes a “final” version. As a consultant, you need to be aware of these tendencies and mitigate them by heading off these issues as they arise.   

Baseline the processes and conduct a formal handoff. Any good technical writer will emphasize the importance of conducting a formal review and validation of the final work product, and applying proper version control (a task known as “Baselining”). As obvious as this seems, experience has taught me that this key task is oftentimes done poorly or, in some cases, not at all. Part of the reason for this is that, while the participants are coming away with a sense of accomplishment, they are often anxious to get on with the next task or project and the momentum for this initiative has faded. Be careful not to allow the momentum to be lost by conducting a weak handoff. Instead, you should clearly define who will maintain the flows going forward, and you should also take care to ensure that the person(s) accepting the role of maintainer is sufficiently competent and motivated to manage the processes going forward. If necessary, provide training and verify that they understand what is expected of them going forward. Not doing so can be a costly mistake, and all too often I see an organization’s processes becoming outdated and eventually obsolete. Remember: if the processes were valuable enough to map in the first place, then they are valuable enough to maintain.