5 Key Steps in a Process Improvement Project
1.Determine the Critical Business Issue
You shouldn’t pursue Process Improvement because it’s conceptually logical or a noble objecive; you should do it to solve a high-impact problem. The driving force of a Process Improvement project is a Critical Business Issue (CBI) that may be centered on revenue, quality improvement, cost reduction, and/or cycle time reduction. (Since most of these variables are in the mix, you need to agree on which one or two are the primary motivations for the project.)
Once you reach consensus on the CBI, the individual championing the effort should lead the Process Improvement project definition, which results in:
- Project GOALS, including not only metrics around the CBI, but other measures of project success (e.g., role clarity, systems installation, culture transformation)
- Process SCOPE (start and stop points)
- Project CONSTRAINTS, which are the guardrails within which the new process must function. For example, your headcount and safety policies may be givens. Or, perhaps the process must use the enterprise computer system that you just spent millions to install.
- Project ROLES, including:
- The Project Sponsor, who is typically a senior executive
- The Steering Team, constituted of the executives who head up the departments-touched by the process
- The Design Team, which is the (usually cross-functional) group of individuals with current hands-on experience working in the process
- The Design Team Leader, who chairs the group
- The Facilitator(s), who provide the process design methodology/tools, team and-schedule management, and documentation
- Project TIMELINE
Having defined the project, it’s time to go to work.
2.Analyze the Current State
Once your project is structured, the Design Team begins to develop a clear understanding of the current process, which we call the IS process. (If you are creating a new process, it is still useful to understand any activities that are going on, even if calling them a process is giving more credit than is due. In rare cases, there is no process and no individual activities, in which case there is no IS.)
Some people believe that examining the IS is unwise because it consumes time and runs the risk of constraining innovation when we design the future state process, which we call the SHOULD process. They ask, “Why document the way things are when we know they’re going to change?”
There are four answers to this question:
- Capturing the IS ensures that the Design Team members, each of whom typically understands only “a part of the elephant,” see all of the components of the process.
- As the team documents the IS via a Process Map (a cross-functional flowchart), they capture what works today and what doesn’t work. We refer to the latter as “Disconnects.” You want your SHOULD process to build on any strengths in the IS and to eliminate its Disconnects.
- Once the SHOULD is created, the team builds an implementation plan. It’s tough to get to your destination if you don’t know from where you are starting.
- The team—which typically has not worked on this type of project before—gels during the IS phase, making them more effective and efficient when they get to the SHOULD design.
The Disconnects that are captured during the IS phase can include non-value-added steps, redundancies, bottlenecks, unnecessary documentation, and any activities carried out in a linear order that could be completed in parallel. In addition to these process design Disconnects, you should look for process execution Disconnects. These are situations in which steps in the process make sense; your organization just isn’t good at doing them. The cause could be lack of skills, inadequate computer systems, foolish policies, and/or an unsupportive culture.
While it is important to document and analyze the IS process, that activity should not consume more time than it deserves.
In a typical Process Improvement project, the ratio of IS time to SHOULD time is 1:5.
3.Define the Future State
Now it’s time to move from the analytical to the creative phase of the Process Improvement project.
You should involve imaginative people, who while perhaps unfamiliar with the IS, may stretch the thinking of the Design Team.
Creating the SHOULD process begins with identifying the 3-6 high-level subprocesses, which may or may not be the same as those in the IS. The Design Team then drills down on each sub-process, creating a flowchart of up to 20-30 steps. To ensure a breakthrough process, we sometimes structure a “design competition” in which teams develop the new process in parallel. The ultimate result is usually a hybrid that is superior to the solution developed by any one team.
Reaching consensus usually generates heated discussions, considerable sweat, and and sometimes blood and tears. Your Facilitators will earn their money by stretching and challenging the team’s thinking by continually asking “Why?” and “Why Not?” During this part of the process, they will ensure that the team members rise above their parochial interests and keep their eyes on the prize, the SHOULD that is best for the organization.
Once your team members agree on the SHOULD, they will take it to the next level of detail by defining not only the “what” (the steps and outputs) but also the “who” (the departments and systems that will carry out each activity). You don’t want to weaken the design by identifying department roles prematurely—or unless it’s a constraint you’ve been given—lock yourselves into the existing organization structure.
After your Design Team has a draft SHOULD, it should test and refine it by ensuring it captures the strengths of and eliminates the Disconnects in the IS. The Design Team should further test it by running it by the Steering Team, a sample of customers, and people outside the team who work in the process. You may also benefit from investing in benchmarking against world-class processes in organizations that may or may not be in your industry.
At this point, the SHOULD process looks good, feels right, has been approved by management. However, you will want real-world proof that it is functioning as desired. So, during the SHOULD phase, your Design Team should produce a set of measures by which to evaluate the performance of the redesigned process. These measures set the stage for the ongoing guidance and oversight of the process which we call Process Management.
Measure identification begins by answering these questions:
- What is important to the customers of this process? How do they assess its performance?
- In addition to what’s important to the customers, what is important to those who “own” the process?
For example, customers of your order fulfillment process probably care that the order they receive:
- contains the right products,
- is sent to the correct address,
- contains the number of products they ordered,
- contains products that are undamaged and function as they should, and
- arrives by the promised date.
These expectations are turned into numerical measures and goals.
Those who manage the order fulfillment process probably care about not only meeting customer expectations but also about the efficiency of the order fulfillment. If so, they will want to install a goal for the cost of filling an order.
Both end-of-process and sub-process measures should be established so: 1) the individual or team that is monitoring process performance minimizes surprises by having “leading indicators” of performance; and, 2) if an end-of-process goal is not met, there’s a linkage enabling the problem to be traced to its root cause.
Lastly, you will want to install a measurement system that answers these questions:
- What person or system will be responsible for tracking actual performance against your goals?
- How will the performance information be displayed?
- What analysis, if any, needs to be done before the information is distributed?
- Who will receive the information?
- How often will they receive it?
- What are the recipients expected to do with the information?
The old saw, “If you aren’t measuring it, you aren’t managing it,” applies here. If you agree that processes are “how work gets done,” process metrics should be front-and center on your business management dashboard.
5.Move From IS To SHOULD
Your next objective is to build a plan for migrating from the IS process to the SHOULD process.
The first step is to determine your implementation strategy by answering these questions:
- Do we want to pilot-test the new process in a certain location (e.g., the Southwest division), or for a certain type of input (e.g., single-product orders for under 100 units), or for a certain time (e.g., the next 30 days)?
- Do we want a “hard cutover” in which the entire new process takes effect as of a certain date or should we phase it in over time? If we phase it in, should the phases be subprocesses, inputs, or locations?
Next, you will want to build an implementation plan, using whatever planning format you have found works well in your organization. At the bare minimum, it should include the steps to be taken, when each step will be taken, and who is responsible for seeing that the step is taken.
Remember that you are not only installing a new process, but also whatever systems, policies, skills, structure, measurement, and culture need to support it.
Implementation success factors include:
- Preparing customers for the new process
- Ensuring that people who work in the process understand the “what” and the “why” of the new process
- Using robust project management practices during implementation definition, planning, and execution
- Employing change management principles that ensure that the “soft” (behavior) changes get as much or more attention as the “hard” (systems) changes
After The Project
Once the process is in place, you will want to make sure that it not only “holds the gains” but continuously improves and adapts to the inevitable changes in the business. To accomplish this objective, you need to move from Process Improvement to Process Management.
While there is no single prescription for Process Management, it always includes continuous monitoring, reporting, and feedback in terms of the goals that the Design Team developed during SHOULD design.
Other steps that can help you install Process Management include:
- Designating a Process Owner—an executive who champions and ensures the ongoing excellence of each core process
- Regularly scheduling Process Owners to meet in a Process Council that ensures that one process doesn’t succeed in a way that causes another to fail
- Developing process plans. If you agree that processes are “how work gets done,” process plans—linked to your strategy and budgeting protocol—should drive your department plans
- Ensuring that everyone is trained not just in their specialty but also in “managing the white space” (the baton-passing across functional lines)
- Installing a process culture that rewards process understanding and improvement
The Benefits Of Taking The Process Improvement And Management Journey
The immediate return on your investment in Process Improvement is the resolution of a Critical Business Issue.
The long-term benefits of Process Improvement and Management are:
- Implementing your strategy
- Maximizing customer satisfaction
- Eliminating waste
- Breaking down the “silos” that can isolate one department from another
- Enabling the organization to “manage the white space” on the organization chart
- Establishing a structure that best supports the flow of work
- Installing computer systems that best serve the needs of the business
- Ensuring that your people have the necessary skills
- Allocating the appropriate financial and human resources to each part of the business
- Making your organization a more rewarding place to work
- Enabling your people to make the full use of their abilities
- Ensuring that your dashboard includes appropriate leading and lagging indicators
- Providing opportunities for your employees to design the flow of work in which they participate
Process Improvement and Management will focus your organization on “how work actually gets done.”