Performance Improvement: Baby Steps: Making Process Management a Reality

In our last Column we kicked off a series on how to build and install a process management system inside an organization. Let's continue by framing what we think is included in any management system and how process management fits into it. Then we will describe how you can start installing process management on a small scale—when there is not much understanding or belief, or there are other factors that inhibit addressing process management on a large scale.

Our Management Model

Installing process management requires an understanding of the larger management system in which we insert the tools and mechanisms of process management. Our model for management systems in general is shown in Figure 1. It's pretty simple, consisting of two components—performance planning and performance management—that drive performance execution (where the work processes reside). There's nothing miraculous about this model—it mirrors other constructs for management, such as Plan-Do-Check-Act (PDCA) and the classic Plan-Organize-Lead-Control from the American Management Association.

When applied to an organization structure, the management model is replicated at all the levels that exist in a given organization. A simple illustration is shown in Figure 2, where performance planning and management are carried out at the enterprise level, at regional level, and at functional (i.e., department) level. Performance planning is cascaded down from one level to another, finally reaching the individual performers who are working inside processes. As performers do their work, the results are monitored and reported upward where diagnostics and corrective actions take place at the appropriate levels.

When process management is added, as shown in Figure 3, ideally it should be inserted above the functional level, so that performance planning for the organization's important cross-functional processes is conducted before functional planning. That way, process performance drives functional results. On the management side, process performance is included in the monitoring, diagnosing and corrective-action activities.

In organizations that succeed installing process management on a large scale, by including all major processes, processing sub-systems and even the entire process architecture, the resulting management system can look like the diagram in Figure 4. That's the ideal, and the long-term objective of installing process management. But it generally doesn't happen quickly or easily. So where can you start?

A Modest Start

To answer the question we need to introduce the specific elements of a process management system. These are things like:

  • Process performance planning and managing processes
  • Process performance goals
  • Process performance metrics
  • Process models
  • Process management roles and accountabilities
  • Process performance tracking and reporting tools
  • Process performance diagnostic tools
  • Process performance decision-making mechanisms (e.g., policies, rules, managerial forums, etc.)

It would be great if we could get all this stuff in place at once, but that is seldom possible. Most often our starting point is to get a couple of these items established, for just one process, and demonstrate the value of process management on that small scale before attempting to install an entire process management system. Of course it helps greatly if the candidate process is a very important one—part of the business' value creation system which produces goods or services highly prized by customers.

We tend to start by focusing on the performance management side. Delving into the performance planning side can be difficult—you're immediately into the existing planning processes such as strategic planning, budgeting, resource allocation—and it's easy to get run over by data and complexity. So instead we'll often try to simply help managers get a little better at managing the work by seeing and dealing with performance data for a single process.

So for example, we might focus on a single important metric, such as on-time delivery (OTD). If that's important to a company, they are probably already measuring it. But what we're going to do is link that metric to a relevant process, such as Order Fulfillment, and show them how the execution of the steps and phases of that process are contributing to, or detracting from, the achievement of their OTD goal.

So that's baby step #1. In order to accomplish this, you need to have several things from the above list: You need the metric or metrics that you are going to link to the process; you need to have the process mapped in enough detail that you can see exactly how the steps and phases of the process are affecting the chosen metric(s) positively or negatively; you need to have process performance data, enough of it to make your case for how the process is being executed over a span of time; and you need to know who should see this data, who should care about it. Those people are your potential future process management team. Those are the people you show the data to.

Baby step #2 is to help that group of managers diagnose the process data and determine what actions they should take, based on the results. They may need to take some corrective action—providing more coaching or resources, smoothing out the inputs, or whatever—or if performance is highly positive, they may decide to provide some rewards (e.g., praise, bonuses, and so on).

Baby step #3 is when it becomes clear (and this often happens) that not all the right people are in the room to diagnose this performance data and make decisions. An existing management team might not in fact be sufficiently cross-functional—let's say they are mostly from Manufacturing and there is nobody at the table who represents Distribution yet it's become obvious that the “last mile” of OTD rests with them. If you can get someone from Distribution added to the team, you approach comprehensive ownership of the process.

Eventually, as this management team understands the process data better and better, they will see that some of the problems emanate from the performance planning side of the management system and they will want to migrate over there.

And if you began by focusing on one significant metric, as in our example of OTD, the team naturally will begin to see there are other important metrics that this process is affecting and they will want to expand the data being collected.

And if this is working well for a single process, eventually they will want to enlarge this approach to more processes, to big processing sub-systems (such as every process related to product research, development and launch, for example), or even to the entire business or enterprise. But that's a story for next time.

Some Guidelines and Caveats

  1. It's okay, even preferable, to start small with process management. Applying it to a single process, especially one that is being redesigned, is what we do most of the time.
  2. Make sure the process is truly cross functional. So many organizations attempt to build process management systems around “functional processes” (which we know are really just sub-processes). Then what they are trying to install becomes redundant with the functional management that is already in place. We are talking about adding a level of management where one doesn't already exist in the organization – one that looks across all the functions contributing to a major value output or outcome – like order-to-cash or new product development.
  3. Don't be too quick to throw around new roles and titles. While our example above is based on identifying a management team and getting them to start doing process management, it is unnecessary to call them a “process management team”. This labeling can sow confusion and resistance. Let people come to their own conclusions about how they see themselves and what they want to call their role of doing process management. It's doesn't necessarily have to be labeled anything; it's just management work.
  4. Building on point #3, you notice that we didn't start up a new team; instead, we identified an existing one. Our aim is to integrate process management into the existing management system. The danger of setting up a new, separate process management team or owner is that now you have set process management to one side instead of integrating it into the existing management system and into the jobs of current managers.
  5. Do some educating on the basics of process. If you use a process improvement project as the platform for launching process management, the people involved in the improvement effort (including a steering team, which typically consists of the managers who are the candidates for process management) have an understanding of “process-speak”. If you don't have this foundation, getting into process management can be nightmarish. We saw this happen in an organization that wanted to install process management for an important process but there was not widespread knowledge of process basics. The folks leading this initiative brought in a SIPOC model to frame the discussion of process metrics and process performance but found themselves in fruitless debates about the meaning of things like “input” on the SIPOC model because the meeting attendees were new to all this. Bad result.
  6. Also consider starting with an existing metric or goal, as in our example of OTD. Trying to install the mechanics and behavior of process management while also coming up with a lot of new metrics (which might eventually be sorely needed) can confuse the heck out of the management team when they are starting out on this journey. Plus if you are focused on a metric that everyone already knows is important, you'll have their attention.

In summary, it's okay—even desirable—to start small with process management. It's as much an education effort as it is the installation of tools and components, so going slowly and explaining what and why as you go is the most effective approach we've seen and experienced.

Next time, we'll give you a few examples of larger-scale process management and how to get it in place.

Figure 1. Our Management Model


Figure 1. Our Management Model

Figure 2. Management Model Applied to an Organization's Management Hierarchy


Figure 2. Management Model Applied to an Organization's Management Hierarchy

Figure 3. Management Hierarchy with Process Management Inserted


Figure 3. Management Hierarchy with Process Management Inserted

Figure 4. Management Hierarchy with Multi-Level Process Management


Figure 4. Management Hierarchy with Multi-Level Process Management

Alan Ramias & Cherie Wilkins

Alan Ramias & Cherie Wilkins

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 aramias@ThePDLab.com. Ms. Wilkins is a Partner of the Performance Design Lab, where she specializes in the design of Measurement and Management Systems and the application of the Performance Logic methodology to strategy formulation and performance improvement. She has extensive consulting experience in implementing measurement and management systems in the financial services, retail, chemical, petroleum and manufacturing industries. Cherie also has extensive experience in leading Business Process Architecture Definition efforts as the foundation for making the transformation to a process focused/process managed organization. Prior to joining PDL, Cherie was involved in Technology Development and process improvement consulting with the Rummler-Brache Group. Before joining RBG, she consulted in the area of communications, specializing in internal communications for organizations undergoing large scale change efforts. Prior to that, Cherie worked eight years in the television industry, five of those with the McNeil/Lehrer Newshour.
FacebookTwitterGoogle+Share

Speak Your Mind

*