Defining the scope for a process project is not like defining scope for other types of projects.  One of the major reasons for this is that processes are always linked to other processes and changes to a process can rarely be implemented without affecting other interfacing processes.  In addition, there are some common frustrations of working on process improvement projects such as:

• Insufficient resources.
• Frequently changing definition:
• Requirements.
• Scope.
• Timeframes.
• Purpose.
• Deliverables.
• Lack of appropriate management involvement and support.
• Real 'problem' not identified (symptoms are seen as problems).
• It's a fire fight.

Why do these issues almost always occur?

What can be done to better manage the scope of a process project?

The change in project scope is often called 'scope creep'.  Scope creep is usually defined as the unplanned expansion in the size of a project.  This can be really frustrating not only for the project manager but for the team as well.  It is possible to control and manage our business process improvement projects more efficiently and effectively.  With just a little structure and some checkpoints, most of the major changes in scope can be avoided.  There may always be some small changes in the project.  This occurs as the team of analysts begin documenting the process which results in an increase of their understanding of the process and discovery of what really happens in the process and where the real problems start.

Scope creep is like those capsules of sponges, which expand when dropped in water.  They usually expand to about ten to twenty times their original size.  This is fun to watch when we're kids but it's not fun when it represents changes in the project definition.  The reason the sponges expand is that the plastic capsule (boundary) around the sponge dissolves.  Project scope creep also happens because boundaries change or were never clearly defined.  In order to prevent problems with project scope we must identify the cause (root cause) of these problems. 

There are seven activities analysts can perform that will significantly reduce changes to a process project's scope.  They are:

• Accurately define process.
• Define terms related to the project.
• Define process boundaries explicitly.
• Right people defining the scope.
• Define high level interfaces between processes.
• Conduct a health check on the process interfaces.
• Realizing that certain aspects of the project still make it too large to manage.

Accurately Define Process

The problem is not related to what we do but rather, what we don't do.  It all begins with how organizations define business processes.  Most analysts will define process as a set of activities that take inputs and create outputs according to policies, procedures, and rules utilizing people, facilities, and technology.  There are variations on the exact wording, but conceptually, this is how most analysts will describe a process.  There are two characteristics of process that rarely, if ever, get mentioned.  First, all processes are cross functional.  Second, all processes connect or interface with other processes.  So, if your project encompasses a "process" that is contained within one functional area, there's a very good chance that your original project scope only encompasses a portion of the process however, as a result of discovery, eventually it will encompass the entire process as well as those that having a negative impact on the performance of the process in focus.  This is the first Opportunity for scope creep!

For example, a company wants to improve the accounts payable "process."  Accounts payable is a set of activities that have inputs and produce outputs.  So a project is defined to discover, model, analyze, and redesign accounts payable.  In order to really understand this "process" an analyst needs to ask questions.  The analyst might start by asking, "What are the inputs?"  One input is an invoice.  Then the analyst might ask, "Why does it have an input"?  It's the same question most of us answer every month when the credit card bills arrive.  I have bills because I purchased something.  Accounts payable only gets invoices for payment if something has been purchased.  Something only gets purchased if a P.O. (purchase order) has been sent to a vendor.  In order for the analyst to understand "accounts payable," they need to understand how the P.O. is issued by Purchasing.  So, the scope expands.  If an organization only looks at the activities in accounts payable, no one would know if what's ordered is actually being received in inventory.  We could be receiving what we order but it never goes into inventory.  Remember the movie "9 to 5"?  That company received a lot of goods that went into someone else's inventory.  Therefore, inventory needs to be included in the scope.  So, the scope expands.  Before an analyst makes the accounts payable 'process' really efficient, we need to make sure that we are taking advantage of all the discounts and terms that have been negotiated.  Let's say that terms and conditions are negotiated by legal.  Now we have the legal department participating on the project.  So, the scope expands.  Next, ask, "Who selects our vendors?  Is there a vendor selection process?"  For the sake of argument we'll say this happens in Marketing.  We could probably develop more scenarios but with just this simple example, how much did our scope change?  We started with one functional area, accounts payable.  When we finish asking questions, we now have Accounts Payable, Purchasing, Receiving, Inventory Control, Legal, and Marketing.  Our project is now five times larger than originally defined.  Can you begin to see the sponge getting larger?

Think of process as the life cycle of some type of transaction.  It starts when there is a need and ends when all of the necessary activities have been performed that fulfill that need.  For example, accounts payable is often described as a process, however, the process starts much earlier.  It starts when a stakeholder needs something.  They make a request through purchasing who creates a P.O. (purchase order).  The purchase order is sent to a vendor who fulfills the order by shipping the goods on the purchase order.  The vendor also sends an invoice to the organization's accounts payable department for payment.  The goods purchased don't normally go to the accounts payable department so there isn't any way for accounts payable to verify the receipt of the goods.  They must depend on the receiving department to check the accuracy of the shipment.  The goods may go from receiving to inventory.  The goods must also be distributed to the stakeholder (requestor).  Until the stakeholder receives the goods, the process hasn't been completed.  This is illustrated in Figure 1.

Figure 1.  Acquire Goods Process  

Figure 2.  Potential Size of the Project  

On the other hand we could move forward, as we traditionally have, and just work on improving accounts payable.  After all, to include all these other groups really complicates the project.  It means that someone will have to coordinate all these cross-functional resources and the politics.  (See Figure 2, above.)  In this scenario, we redesign the accounts payable "process" to pay the bills very efficiently.  However, we never take advantage of our discounts, we buy office supplies from ten different vendors, we may pay for goods we never receive and goods that are received may get funneled off to inappropriate areas of the organization or better yet, eBay?  In the accounts payable activity, an analyst can measure increases in the efficiency of paying the invoices, but not the effectiveness.  The real problem occurs when the analyst tries to measure the results of changing the process.  It is impossible to measure any increase in effectiveness.  In order to determine effectiveness, an analyst must be able to measure how well the process is delivering what it's intended to deliver (goods that were requested).  In this example, the effectiveness includes all the activities in all the functional areas that participate from the time a request is made until the goods are delivered.  Only by considering all of the end-to-end activities will the analyst be able to measure changes in the effectiveness of the process of "acquiring goods." 

One organization that improved their "accounts payable" process made it incredibly more efficient, decreasing the cycle time by as much as 75%.  However, it wasn't until they looked at the full life cycle, from request to receipt, that they discovered they had been paying a contract to a consultant, on-time, for the correct contracted amount, to the correct address, that had been dead for five years.  Not a very 'effective' process.

Define Terms Related to the Project

Second, an analyst must spend time discussing terms related to the project to achieve a common definition among all participants and related parties.  Most of the time there is an 'assumption' that everyone understands a 'process' in the same way.  This is one of the many 'assumptions' that are made surrounding process projects and many of them are not accurate.  It means that we assume everyone has a clear understanding of the process and the terms used in the process.  When an analyst begins to ask questions, it becomes clear that not everyone is using the same terms to describe the same things.  Usually that's when an attempt is made to try to accurately define these terms.  Often, this results in a different definition of the project scope as participants realize there are different perspectives of the project.

For example, if a person refers to pizza in the United States, this creates a very distinct image.  However, if a pizza is ordered in Italy or Hungry or some other country there will be some very interesting surprises, like square or rectangular pizzas, or pizzas with fried eggs and corn on top.  An analyst cannot assume everyone understands the terms being used in the project.  Another simple example — I'll tell you my dog's name is 'Fasby'.  You may think that's an unusual name for a dog but unless you're an accountant in the U.S., you won't understand the "play on words."  For an accountant, the term Fasby is translated FASB or Federal Accounting Standards Board.

Even when everyone on the project speaks the same language, there will be difference in how words are interpreted and used.

Define Process Boundaries Explicitly

The third problem is the lack of attention given to explicitly defining the start and end points of the process.  This is accomplished by defining events that occur in the process and gaining consensus on which of those events is considered to be the starting point and which is the ending point.

Figure 3.  Defining Boundaries of a Process  

Let's say that we've been given a project to improve the Order Fulfillment Process.  Does this process begin when the phone rings, the order is taken, the credit is approved, or availability of product is confirmed?  When does the process end?  Does it end when the product is shipped, the product is received, or the product is accepted?  The way that we define the boundaries for the process will impact project over and over again.  It will impact who we get input from, who we include as part of the core team, what we measure, what we set as our vision, and what falls within the scope of change when we redesign or try to improve the process. 

Right People Defining the Scope

The fourth major root cause of process improvement project scope creep is not having the correct participants defining the process.  The participants should be high-level managers in the related functional areas who have a very comprehensive understanding of the business and its issues.  These must also be the people who have resource allocation authority.  If the functional managers are not subject matter experts (SMEs) then we also need these resources as well.  Too often the boundaries of a project are defined and then the project goes looking for resources and can't find them.  When the correct group is defining the scope they are also making resource commitments.  Never send someone else to do your job! 

Define High-level Interfaces between Processes

Fifth, we must define the high level interfaces.  Since all processes connect to other processes or stakeholders, it is essential to understand not only where the real problems are but also how large the project must be to fix those problems.  To do this we must understand these interfaces to the other processes — in other words, which processes are affected by or affect the process in question and what creates that interface, or what flows between processes or other stakeholders.  We define these interfaces as our IGOEs (Inputs, Guides, Outputs, and Enablers).  Often organizations have difficulty defining these interfaces because they don't have their processes defined.  So, if an organization doesn't have their processes defined, how do they establish the scope of projects?  Typically it's done based on which functional pieces of the organization are involved in the project.  We recognize from our first opportunity for scope creep (lack of accurate process definition) what this can mean.  So, we really must have some high level definition of processes, sometimes referred to as the, "process architecture."  The next question is "How long does defining your high level processes take?"  We have a limited amount of time for projects and we can't invest much time in activities that aren't perceived to be directly related to the project.  Experience has shown that with the 'right people' in the room a high-level architecture can be created in a half day.  It's well worth the investment to define your high level process first and ensure you know where your process improvement project fits into the big picture.  The real value of the process architecture is that we can use it over and over again in other projects.  When we understand all of the process interfaces we have what is called the scope of analysis.  We also avoid most of those "unintended" consequences that occur when changes are made to one process that affects one or more of the interfacing process without the team knowing that it's going to occur.

Figure 4.  High-Level Process Interfaces (Stakeholders)  

Sixth, we need to analyze all these interfaces to determine the health of each one.  Unhealthy interfaces are where a majority of the 'real' process issues can be found.  We need to understand what works well, what doesn't, what will be impossible to change or what will just take too much time given our project resource and time constraints.  The result is a more accurate understanding of the 'true' opportunities for improvement as well as project constraints.  This will be called scope of change.  This means that everything included within this boundary may potentially be changed or altered in some way.  This is our project scope definition in terms of the end product of the project — what will change.

Figure 5.  Health Check on Interfaces (Scope of Analysis)  

Figure 6.  Project Scope Boundaries (Scope of Change)  

Realizing that Certain Aspects of the Project Still Make It Too Large to Manage

Finally, an analyst must incorporate realism in the 'project scope'.  For example, if the project scope is the payment process for a very large financial institution, then the analyst needs to consider whether it's feasible to initially examine "all" payment types (45) or just a few major payments that have the greatest impact on the organization from a risk and reward perspective.  Perhaps it's appropriate to conduct a simple version of a cost/benefit/risk analysis.  We would want to know which payment types are the most essential from a risk and/or legal perspective.  We would want to know which payment types are the most profitable for the organization and finally, we would want to know which payments cost us the most to fix when they are not handled correctly.

Figure 7.  Too Many Payment Types  

Conclusion

In conclusion, most of an organization's frustration with results from process improvement projects can be traced back to the initial work that should've been done at the very beginning of the project:

• Accurately define process.
• Define terms related to the project.
• Define process boundaries explicitly.
• Right people defining the scope.
• Define high level interfaces between processes.
• Conduct a health check on the process interfaces.
• Realizing that certain aspects of the project still make it too large to manage.

The advantage in taking the time to go through all these activities is a more accurately-defined project from the perspective of expectations, reduction in the occurrence of unintended consequences, and the ability to measure not only efficiency but also the effectiveness of the changes made to the process.  It also ensures that the real problems are being addressed versus the symptoms of the problems.  In addition, it saves a great deal of time in the project due to the elimination of rework or redefinition.  Also, the resources and timeline are more accurate than any process project that skips any of these activities.

Frustration with process improvement projects is often the result of issues with project scope and not knowing how to control or manage changes to a project's scope.  Now that analysts have the knowledge, they have the power to control projects more effectively and efficiently.

# # #