Facilitating a Process Mapping Team: The Basics By Stephen Mercer

When I volunteered to write an article about facilitating a process mapping team, I quickly realized that the scope of this topic far exceeds the limitations of this article. I have plenty of articles, books, and white papers on the subject and have collected hundreds of pages of project notes spanning years. Therefore, I have decided to present the topic by providing a summary of key tasks and then, in later installments, address each of them as a separate standalone topic. Finally, depending upon how receptive the audience is to this initial installment, I will expand on each topic in later articles.

Key Facilitation Tasks

Remember that process mapping is a group effort, and it is 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 with 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 Responsible Accountable Consulted Informed (RACI) chart and refer to it as needed. In a later installment, I will illustrate a RACI chart and provide guidelines for its use based upon my experience. For now, always bear in mind who the process owners are and what their expectations 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 in which particular subject, 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 performing 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 confirmation on the desired end result. You might be surprised to learn that what you think 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 add 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, inadequate 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 and 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 the maps 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-teams” 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 by letting 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, the process owners need to review and approve the process maps. 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 often 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 through 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.

Blogging with Bliss guest blogger, Stephen Mercer, is an organization and process consultant. Stephen has diverse experience in a wide variety of industries. His background includes ten years as a senior technical writer, skilled in collecting, analyzing, reworking, and disseminating information tailored to specific audiences, and software process improvement and methodologies (e.g., Capability Maturity Model; CISA designation).