Facilitating a Process Mapping Team, Part 2: Conducting a Process Maturity Assessment By Stephen Mercer

This is the second in a series about facilitating a process mapping team. The first dealt with the basics of setting up the team and preparing for key facilitation tasks. The current article covers the concept of the organization's Process Maturity, defines the organization according to the type(s) of processes they are mapping, and provides key questions that you can ask to assess the organization's overall process maturity.

Below is a quick review of the key tasks that were listed in the last article:

• Identify the key stakeholders and process owners.
  
• Define the project scope and deliverables.
  
• Identify what you are measuring.
  
• Determine the method and type(s) of process maps to create.
  
• Review and validate the process maps.
  
• Baseline the processes and conduct a formal handoff.
  

OK, now that you have assembled your team, you are ready to forge ahead by performing the key tasks as listed. By following the key tasks, you will be able to develop a set of processes for the organization.
 
Questions to consider:

• What kind of team are you working with?
  
• How experienced are they at developing process flows?
  
• Do they follow predefined standards and/or templates?
  
• Do they think in terms of processes, or do they think in terms of functional units?
  

Before you move into defining the scope, identifying measurements, and determining the process mapping method, there is one step that will help to understand how to approach your team. It addresses a key concept that you will be hearing more of in the years to come, namely the concept of Process Maturity. 

Similar to maturity models utilized for software process improvement, such as the Capability Maturity Model (CMM), there are existing maturity models available that address process improvement. In 2007, Dr. Michael Hammer introduced this concept in an article for the Harvard Business Review. The article introduced a new comprehensive framework entitled The Process and Enterprise Maturity Model (PEMM™), which is used to evaluate the maturity of a business process and to determine how to improve its performance. You can learn more about this model by going to their website.

Conducting a Process Maturity Assessment 

A complete process maturity assessment is beyond the scope of this article, but you can conduct an assessment or "mini-audit" that is effective in helping your team to scope out the deliverables and build an effective process. This can be done as part of your interview questions rather than a formal audit. The remainder of this article addresses key tasks and questions to ask when conducting a Process Maturity Assessment for the organization. Some of these items are my own, and some are derived from the PEMM™ model. Bear in mind that this is not intended to be a formal Process Maturity Assessment, but it goes a long way toward determining the maturity level of your team and the organization.

Let's begin by defining process types from the perspective of the model. The PEMM™ model defines three main categories designed to help an organization assess its overall process maturity and to begin thinking in more process-centric terms. The three main types of processes are defined as follows:

• Core Process: Defined as core processes that convert inputs into outputs of greater value to customers, e.g., supply chain, order fulfillment, prospect to order. This may mean faster turnaround time, lower manufacturing costs, and/or higher quality.
  
• Enabling Process: Defined as enabling processes that support one or more other processes, typically by supplying indirect inputs, e.g., hire to retire, design to automate. This is where cross-functional processes come into play. If you are doing hand-offs to other organizations and depend upon them to support your processes (and vice-versa), then involving a cross-functional team is of paramount importance. Most enterprise-wide strategies sponsor initiatives that span across organizations and impact many employees. At this point you can begin to break down the silos and help the organization make a shift in thinking from departmental/functional to process-oriented.
  
• Governing Process: Defined as governing processes through which the work of the enterprise is directed and controlled to ensure success.
  For example:
  
  
  As an organization becomes more mature in its process mapping efforts, you will see more of these tasks incorporated into its processes. Has your organization adopted this viewpoint? Does it represent a long-term goal for the organization or enterprise? Is management taking a process-oriented perspective, and have they formally assigned a process owner to ensure compliance and follow-through?

Key questions to ask when performing a Process Maturity Assessment

• Who are the contributors?
  Is the team balanced as far as those who will contribute, or is it weighted toward any one or two functions? It is important to understand that processes are sequences of activities working as a whole to produce something of tangible value. Processes need to transcend organizational boundaries; hence it is critical to involve participants from all organizations involved with the process. Once you have identified your stakeholders take note of their level of contribution to the project. On some teams, the Subject Matter Experts (SMEs) and process performers provide most of the input. By contrast, I have seen projects in which the manager provides nearly all of the input with no team effort involved. This may be due to busy staff schedules, a more simplistic goal, or the presence of an over-controlling manager. Whoever your contributors are, it is crucial for them to know that their ideas are respected; after all they are the ones who know the process the best and are able to provide the most useful input.
  
• How much experience do they have at mapping processes?
  Does your team understand the difference between a functional and process-based organization?
  This is critical to understanding how good business process mapping works. Functionally aligned organizations do not lend themselves well to process-oriented thinking. In fact, it is precisely the doing away with functional divisions (i.e. silos) that can enable an organization to improve its processes and overall performance.
  The PEMM™ model reminds us that the concept of enterprise process is end-to-end work across the organization. It is a designed group of related tasks that work together to create a result of customer value. Processes are not merely new names for traditional departments; they are cross-functional sequences of activities rather than groups of people, transcending organizational boundaries.
  
• How often has your team used cross-functional processes to improve performance?
  This is a good follow-up question to the one above. I have found that very few people have formal process training, but are expected to map process flows without no experience. This can make the task seem daunting and even cause people to back away from providing input. In this case, it may be useful to conduct a basic training class in process mapping. I have found that investing as little as an hour to train the participants can help them to develop better processes, feeling more empowered and better equipped to provide input into the process mapping effort.
  
• Do you have external and/or benchmarked metrics to use for comparison?
  Does the end-to-end process have end-to-end metrics derived from external customer requirements? There is a great deal of research available that can help determine adequate performance levels for organizations which provide similar products or services. The question from a process maturity perspective is to determine to what extent the organization uses benchmarks to define metrics and set goals. It may be necessary to help the team to define metrics (to be covered in a later article).
  
• Are there other organizations that are part of the process?
  Does your team need to hand off deliverables to someone outside of your immediate organization, or vice-versa? If so, are SMEs from the other organizations participating in the development of the process maps? This should be a standard practice to include representatives from any organizations that play a part in the process. One of the key principles of process management is to look at the process end-to-end and, where possible, break down the barriers that keep an organization fragmented. Remember that enterprises that are structured as functional organizations generally do not perform as well as those that have adopted a process-oriented perspective.
  
• Is your process part of a larger initiative, such as an infrastructure improvement or an onboarding and provisioning initiative?
  Does your process deal with materials and supplies, or are you dealing with HR processes? Will this be a phased implementation in which new processes are introduced and/or improved over time?
  
• If your process involves technology, does your team have good representation and support from the IT organization?
  Has the solution taken into consideration the manual tasks and handoffs? Will the new technology enable more efficient operations? Your process performers may have difficulty navigating through a new user interface or they may need to depend upon someone else to provide them with the correct information or documents at the right time. Be sure to ascertain whether the technology is driving the process, or the process is driving the technology. All too often, technology solutions are adopted that do not consider the non-technology part of the overall process. This can cause trouble during the implementation and may be indicative of a poorly defined process.
  
• Is your team prepared to adapt to significant changes in their work processes?
  This topic is beyond the scope of this article, but I will mention that changing the structure and/or management of an organization is a significant undertaking and may well necessitate the skills of an outside consultant.
  

Your answers to these questions will tell you a lot about your team and give you valuable insight into the most efficient way to work with them. Once you have performed a Process Maturity Assessment, you will have a much better picture of your team and how the enterprise functions. In addition, by performing this assessment and analyzing overall process maturity, you may be laying the groundwork for future implementations. It is often this "extra mile" that results in better end products and happier clients.

Our guest contributor, 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). 

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).