Nobody really cares about standards… until suddenly they do. When a standard reaches some threshold of adoption, a tipping point is reached. Then, if you’re not on the standard you’re proprietary....

Creating Momentum for Process Change

In our consulting work at the Performance Design Lab (PDL), we have frequently talked with clients who describe the following scenario: “Our improvement projects usually seem to get stuck between current and future state. We get the ‘is’ process mapped out okay, but we can’t beyond that.”

The question we always ask is, “Why did you start the project in the first place?”  What we find out is that processes often get mapped without any clear purpose, other than to map them. There is no momentum to advance to improvement because in most cases the conditions for a successful project have not been put in place.

So in the remainder of this article are some of the things we try to make sure have been established at the beginning of any process improvement effort that we engage in. With these conditions properly established, there is usually sufficient momentum not only to get from “is” to “should” but to drive the effort to an effective implementation of the redesigned process.

Imperative 1:  Define the Business Problem

Every improvement project should start with a well-defined statement of the business problem (what we at PDL call a “critical business issue or opportunity”).  This is not a statement about the process that may need to be redesigned; it’s about the business need that fixing the process would help to address. Whether the need is to increase revenue, improve product quality, increase customer satisfaction, reduce costs, or compete more effectively, the CBI provides focus for the entire project, drawing the appropriate level of sponsorship and funding. Without a CBI, a project will drift and die away.

Imperative 2:  Define the Process Problem and Project Goals

Once the CBI is established, the process can be identified and the need for improvement (versus the CBI) can be agreed to.  Note that we do not try to identify the process or its major shortcomings (which we call the Critical Process Issue, or CPI) until the CBI has been nailed down. All too often, the selection of the process has been the first step, but it could turn out that to have adequate impact on the CBI, this particular process is not the right one, or perhaps not the only one, that should be addressed.

Imperative 3:  Define the Project Scope

This step follows logically from Imperative 2. When you examine the relationship between the selected process, the CPI, the project goals and the CBI, you have to make a decision about what to include in the project scope. Perhaps to make a real difference, you have to include the upstream process, or an enabling process, or the underlying policies and assumptions that drive process behavior.

Imperative 4:  Define the Executive Sponsorship

Too many projects are attempted without adequate executive support, or without any executive involvement at all. The reasons given are that senior executives don’t have the time or are not interested, or this project is “too technical” for them.  But lack of sponsorship is a guarantee of later failure. I’ve not seen a single instance of successful redesign and implementation of a significant process change without the knowledge, involvement and support of senior leaders, and the earlier they are on board, the smoother the project itself will go.

Taken together, these four imperatives have more to do with getting from current “is” state to future “should” state than anything you can do once you have reached that critical juncture. There is no tactic or tool that can repair a flawed beginning. As simple and obvious as these imperatives may seem to be, they are the ones lacking, again and again, in the process improvement work we see being attempted inside organizations today.

As the old saying goes, you can pay now or pay later, but you will certainly pay (for a bad project start).

Alan Ramias is a Partner of the Performance Design Lab ( PDL). 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, which led to several groundbreaking projects that contributed to Motorola’s winning of the first Malcolm Baldrige Award in 1988. Joining The Rummler-Brache Group in 1991, Alan led major successful performance improvement engagements within Fortune 500 companies, then became a partner and Managing Director of Consulting Services. Upon leaving RBG, Alan founded his own consulting company, where he continued to practice in the field of performance consulting, before joining PDL.

Back to Articles, including BPM, SOA, BDM, BA & OP