What is process scoping?

Process scoping is the means of identifying what is and what is not to be addressed by and included in the process map. In other words, process scoping is how you “begin with the end in mind.”[1]

Who knew grocery shopping could be so complicated?

If you were to write a process for grocery shopping, what would it look like? Would it be simple to understand and use? Would it be helpful? Take a moment to think about it.

Perhaps you are already thinking about specific conditions. Things like: What items are on the list? What grocery store (or stores) will you need to visit to get those specific items? What day or time of day will you be going? What is your budget? Now, admittedly, I am not an expert at grocery shopping, so this list of conditions might be much longer. The point is, as simple and straightforward as “grocery shopping” may sound, the content and complexity of that process is greatly dependent upon specific conditions to be included in it.

Understanding process conditions is a necessary component - or should I say, ingredient - for creating a process that is accurate, simple, and helpful. This is where process scoping comes in. The minimum level of process scoping needed will vary based on your goals and objectives. However, in keeping with the theme of this website, if you would like your processes to be simple to understand and helpful to the worker performing the process, it is almost always best to scope the process as narrowly as possible. As Karen Martin and Mike Osterling affirm:

“This narrowing activity enables a more detailed and focused study and avoids designing a general solution that doesn’t adequately address the specific issue at hand.”[2]

Below, we will seek to explain why process scoping is important and outline the steps to perform it accurately.

First things first

Scoping at a process level assumes certain foundational BPM puzzle pieces are already in place, not the least of which is an established process framework. A process framework “essentially lists all of the key processes performed in an organization, grouped hierarchically to show how they relate to each other.”[3] Many organizations choose to create their framework from scratch while others choose to leverage a pre-built framework (APQC’s Cross Industry Process Classification Framework is one of the most popular). Regardless of how you develop an organizational process framework, the important thing is that you have one. Your framework will establish a home for all the process level work you will be doing. Think of the process framework as your house and process scoping as your plan for decorating the living room.

It is also best practice to have prioritized what processes you will seek to map first within your framework. Assuming that your organization is like most, you will not have the capacity or resources to attempt an enterprise wide mapping exercise and will therefore need to build out a scope of work for “phase one” of your BPM implementation based on value to the business. A decision matrix can often be a helpful tool to prioritize processes and communicate your reasoning to others within the business. There are countless resources on the web for how to set up and use decision matrices – here are two of them: What is a Decision Matrix? and Decision Matrix Analysis.

Why process scoping is important

In case you have not already arrived at this conclusion, process scoping is important because it defines the objective of your mapping project. It sets the boundaries and rules of engagement. Process scoping makes the mapping exercise effective. It keeps you on mission and helps limit the amount of sidebar conversations and rabbit trails that occur while mapping by clearly stating the conditions that are “in bounds.” When conditions arise that fall outside of the stated boundaries, the team can make a note of them and move on following the clearly defined scope that was set before the mapping began.

Scoping also helps assure that the mapping team is assembled with the appropriate subject matter expertise. If we have identified the “Pay Vendor Invoices” process for mapping and have scoped it down to focus only on the Americas vendor payment process, then there is no need to pull a global team together when the scope is clearly limited to how this process is performed in the Americas region. Furthermore, lets imagine that there existed significant differences for the vendor payment process depending if payment was to be issued to a service provider or a supplier. If we are scoping our process narrowly, we would want to pick only one of these conditions. This again would allow us to further refine the subject matter expertise required to map the process and help us select the best participants for the mapping exercise. Obviously, the Americas supplier payment process will be much easier for us to map compared to the global vendor payment process.

Finally, good process scoping produces a process that is simple to understand and, in turn, actually helpful to the process performer. An attempt to map out all possible conditions of a process on a single map will inevitably result in multiple parallel paths of logic, numerous decision diamonds, and dozens and dozens of activities (process steps). This can lead to information overload and deter the process performer from using and benefitting from the process. Effectively, the presentation of the process compromises the content of the process. Scoping reduces the number of scenarios that a process map contains, thus making the process engaging for the user.

So, how do you scope a process?

It is possible to scope too narrowly, so to ensure effective process scoping you should separate high-level process conditions that need to be understood before mapping the process from low-level conditions that can be addressed during the mapping exercise itself. Consider the high-level conditions in our grocery shopping example mentioned above, our process may also have many low-level conditions or exceptions that can be addressed within the process. Some of these low-level conditions might include things like: Do we use plastic or reusable bags? Do we use self-checkout or wait in line for a cashier? Are we paying with cash or credit? Because these conditions do not impact the majority flow of the process, we can address them in the process detail using specific capture techniques. 

With that established, below is a list of high-level conditions and definitions – with examples – that should be scoped before mapping a process:

Process name: Use the verb-first format to emphasize action

Pay Supplier Invoices

Objective: What the process aims to achieve

Receive, review, and issue payment for Supplier invoices in the Americas region

Business specific conditions: Any high-level conditions that refine the process objective. This can include items such as product or service line, business unit, location, client, etc.

Process is for Supplier invoices only. Process is for the Americas region only

Triggers: The situation or signal that starts the process

The 1st of every month

Inputs: Items needed to begin the process

All Supplier invoices for the previous month

Outputs: Value created by the process

Payment issued to Americas Supplier upon approval of invoice

Process audience: The group in the business who is expected to be the main user of the process. This is typically the line-of-business performer or a specialty group like the automation team who needs a process to inform the building of automation components for the business

Accounts payable team

Areas outside of scope: Use this category to state negatively what was stated positively in the categories above. Any conditions not included that could potentially be assumed by the mapping team should be listed here as out of scope

Service Provider invoice payment is outside the scope of this process. Any region outside of the Americas is also excluded.

Some closing thoughts; no charge of course

• Completing a process scoping worksheet is recommended before commencing any mapping exercise. This will help define the high-level conditions for the process and get the team thinking about the details of the process. Download our free template here: Simplifying Processes - Process Scoping Template

• Really focus on the “Business specific conditions” category. Many process mapping challenges arise from organizations failing to identify these categories of variations before starting. Ask yourself if the process being scoped is ever performed differently across the organization. If it is, then determine why. Then choose the specific condition you intend to map and list the others under the “Areas outside of scope” category.

• Having clear synergy between the process name, objective, and output is critical in keeping the mapping team focused and for communicating the finished process to the business.

• It is best to scope the process before establishing the mapping team. As mentioned above, a narrow scope makes assigning process governance less challenging.

• There may be times when the mapping team needs to expand or alter the initial scope of the process. If this is done, be sure to understand the impact any changes might have on commitments already made.

As tempting as it might be to immediately grab your sticky notes and start mapping a process, it is always best to pause and create a clear picture of what success look like. Process scoping will help you do just that. Laying the proper foundation and setting obvious process boundaries will help you map faster and ultimately increase the usefulness of your finished process.  

[1] FranklinCovey. https://www.franklincovey.com/the-7-habits/habit-2.html (accessed July 15, 2020)

[2] Karen Martin and Mike Osterling, Metrics-Based Process Mapping (Boca Raton: CRC Press, 2012), 17

[3] APQC. https://www.apqc.org/process-performance-management/process-frameworks (accessed July 13, 2020)