Process Improvement: Process Scope versus Project Scope

In order to conduct an improvement project, early on you need to figure out the scope of the effort. What should you include (and therefore exclude)? Where do the boundaries of the effort begin and end? Answering these questions can be challenging but never more so than when the project is a process improvement project. If you haven't done this sort of work before, you might assume that the process scope is exactly the same as the project scope, but that could be an error. Why that might be so is the subject of this Column, Process Scope versus Project Scope.

Process Scope

In order to figure out the scope of a process (its beginning and end, what should be included versus left out), you must have some sort of definition of a process. There are many to be found in BPM literature but most come down to something like the following:

A process is a sequence of activities that convert an input into a valued output (or outcome).

That is not a lot to go on, although it's usually enough to judge the reasonable limits of a given process. But is the “Recruiting/Hiring Process” a single process or two linked together by a common outcome (i.e., the hiring of a qualified candidate)? The use of the hyphen between “Recruiting” and “Hiring” suggests it is two processes but there is no final authority on such conventions. You have to decide for yourself. Developing a process architecture can help with the naming and positioning of processes relative to each other, but there is still considerable arbitrariness to this.

Some process experts use the term end-to-end to identify the boundaries of the large, important processes of a company. This phrase has no exact definition but has come to mean defining a process so that it includes all of the activities (i.e., sub-processes) required to get something visible to an external customer.

For example, end-to-end order fulfillment can be viewed as including everything that must be accomplished to get an order processed and the product manufactured, shipped and delivered. End-to-end product development can be defined as all the activities that must happen to come up with new product concepts, including research, definition, development, testing, and finally roll-out of the new offering. Still, the question will arise, are these activities within one gigantic process or are they substantial processes in themselves but executed in a sequence that suggests they are part of a single process? (It does seem like calling such a major activity as research an “activity” or even a “sub-process” is understating things a mite.)

The solution my colleagues and I have used over the years is to apply the concept of a processing hierarchy to the task of naming processes. If you start at the level of an entire organization and regard it as a giant processing system, then the major components of that system are processing sub-systems and inside of those sub-systems are processes, which in turn consist of sub-processes, and inside sub-processes are activities. Again, a picture of a given organization's process architecture is very helpful in applying this concept.

Project Scope

Even if a process is already well-defined within a process architecture, that is only the starting point of defining the scope of an improvement.

Let's stick with the example of the hiring process, which has been targeted for improvement because of dissatisfaction with the quality of new hires. Should we focus only on hiring or should we look upstream and downstream for causes and possible solutions? If the evidence we have about the current problem suggests that not all the candidates are the best we could get, perhaps we should include recruiting in our scope.

Similarly, we would probably not think of the hiring process as including employee training, but if we were conducting an improvement project whose aim is to increase the number of new employees capable of performing the work for which they are hired, we would want the scope of our effort to include all the elements that might be affecting that outcome instead of just focusing on the obvious target of employee hiring. We would want to examine what's going on all along the chain of activities that brings new employees in the door and readies them for work. There may be deficiencies both inside recruiting, hiring and training and in the white spaces between those processes, so our project might need to encompass all three. That doesn't mean we are combining them into one process but that our improvement project would address a processing sub-system instead of a single process. The project scope thus would look like this:


Then to make clear what links these processes together, it would be helpful to identify the major output or outcome of each process, as shown below:


Defining an improvement effort by working backwards from the improvement goal or identified deficiency can drastically alter the presumed scope, as this example illustrates. We started with the hiring process but then expanded the scope both upstream and downstream in order to adequately address the need. That might not pose much of a problem if all the included processes are owned by the same department. In the above example, if employee recruiting, hiring and training are all being managed by HR, the overall owner of this processing sub-system is the Senior VP of HR. Convince that person that the project should include all three processes and you should have effective executive support.

However, it's not always that easy. When the processes are being managed by different parts of the organization, politics can get in the way. (And even in our example, there could be disputes among the leaders inside HR, with Recruiting arguing that all the problems happen after their outstanding candidates are handed off to the hiring people, and Hiring and Training are also pointing fingers at each other.)

One of the worst examples of this resistance that we've seen happened with an American manufacturing company that is well-known to all of you (but who wants to remain anonymous). What is not well-known is that its flagship product contains core components from a Japanese supplier. During a project to improve the speed and efficiency of the company's new product development process, it became evident to us that the Japanese supplier was a critical player, so we suggested that employees from that company be added to the improvement team and that we expand the project scope to include the supplier's manufacturing process. We were barraged with objections about why this was a terrible idea, ranging from concerns about language and cultural barriers to fears that the project would be drastically slowed down. But at the end of the project, when we had come up with a nicely reengineered process, the team leaders had to approach the Japanese, hat in hand, and try to explain why and how they had come up with this radically different approach that would have a major impact on both companies. And of course, the first thing they heard from the Japanese was, “Why didn't you include us?”


It's a simple lesson: Pay now or pay later. If you don't get the project scope right at the beginning, you will suffer problems at some point later on, when it's more costly and will definitely slow things down. A few rules of thumb, then, about how to align process and project scopes:

  • When in doubt, go bigger rather than smaller. More damage tends to be done by defining a process too narrowly and leaving something important out than by including something that may be a little questionable. You can always leave something out of the scope later if you find out during Analysis that the process or activity is unimportant.
  • Look for significant milestones or outputs to identify the process end. The end of the hiring process is implied in the name itself: the company wants good employees. By implication, the end of the process is when the hiring has been accomplished. Then the question is what is contributing to achievement of that objective or getting in the way?
  • Important processes are almost always cross-functional even if they are generally thought of as being owned by one functional area. The hiring process is probably labeled as an HR process in most organizations but in fact it is cross-functional because participants usually include line managers who do the interviewing and make the hiring decisions. You will want support and participation from all the areas that are involved in the process or you risk resistance later when you try to implement a solution.
Alan Ramias

Alan Ramias

Alan Ramias is a Partner of the Performance Design Lab (PDL). He has had twenty-five years of experience in performance improvement and organization effectiveness. Alan was employed by Motorola for ten years as an internal consultant on organizational performance. As a member of the team that founded Motorola University, he was the first person to introduce Geary Rummler's pioneering concepts in process improvement and management to business units within Motorola. Alan advocated and led several of the first groundbreaking projects in process improvement that evolved to the invention of six sigma and Motorola's winning of the first Malcolm Baldrige Award in 1988. Alan was also involved in major restructuring projects at Motorola, and in job design work, compensation planning, workplace literacy, and educational program development. After joining The Rummler-Brache Group in 1991, Alan led major successful performance improvement engagements within Fortune 500 companies. His experience spanned several industries and the full spectrum of corporate functions and processes, such as strategic planning, manufacturing, product development, financial management, and supply chain. Major clients included Shell, Hewlett-Packard, 3M, Citibank, Motorola, Steelcase, Citgo, Hermann Miller, Louisiana-Pacific, and Bank One. After leading many high-profile projects, he became a partner and Managing Director of Consulting Services at RBG. He led development of much of RBG's products and services, and was responsible for selecting, training and mentoring RBG's consultant teams. Upon leaving RBG, Alan founded his own consulting company, where he continued to practice in the field of performance consulting. He was also involved in several organizational restructuring initiatives in the U.S. and in Asia. Alan can be reached at


  1. Jerry Talley says:

    I’d suggest we could take Alan’s idea one step further. In a public sector financial agency I worked with recently, there was an urgent need to review and refine their process documentation, There were 100’s of files to review; it was a daunting task and the chances for omission and duplication were substantial. Listing the work processes behind those procedures was an equally daunting task. But listing out the products (intermediate outcomes, milestones, etc.) was a much more manageable task. Once we got the list of products, we could link processes to products, and then link documentation to processes. It created a “table of contents” for the project that allowed for capturing process assessments (too manual, fluid, fragile, etc.) as well as setting priorities within the sea of smaller projects.

Speak Your Mind