Whatever kind of company you work in, management is always looking for a better way to spot the best projects, the ones that will make a real difference to the bottom line. This guide shows you how to find problem areas, capture the information you need, and improve your company’s processes, so you can point leadership toward the parts of the business where the greatest benefits are waiting.
Tell management where to go
No matter how good a company is, performing a single task in isolation does not create value for the customer. Value only appears when all of the tasks required to produce a product or deliver a service are performed correctly together. Almost every process involves work done by resources from several functional departments across the enterprise.
So the shift companies need to make is from improving how individual tasks are performed to improving how those tasks fit together to deliver value to the customer.
In other words, companies need to improve their processes. That does not mean abandoning the effort to optimize individual tasks. It means recognizing that, in most companies, the larger opportunities live in the overall process.
Streamlining cross-company processes is the next great frontier for reducing costs, enhancing quality, and speeding operations. It’s where this decade’s productivity wars will be fought. The victors will be those companies that are able to take a new approach to business, working closely with partners to design and manage processes that extend across traditional corporate boundaries. They will be the ones that make the leap from efficiency to superefficiency.
Michael Hammer, Harvard Business Review
The suggestions here are drawn from twenty years of working with project teams on process improvement, with results that ranged from outstanding to disappointing. The two factors that most consistently separated the excellent outcomes from the rest were respect for the methodology and respect for the people with first-hand experience. Treat what follows as a guide, not a script. Use your judgment, and adapt where it makes sense. But heed one overriding caution: never skip the involvement of the people who do the work. They are your link to reality.
Five steps to process improvement
It would be a stretch to claim there is only one path to process improvement. Search the literature and you will find programs with as few as three steps and as many as fifteen. The difference is usually how finely each program slices the work. Almost all of them, though, share the same five global steps.
Identify
Defining and then selecting a process to improve sounds simple, but it may be the hardest of the five. It usually begins not with mapping anything, but with gathering management support for the whole program, forming the change teams, and setting expectations and standards of support across the organization. It ends when process owners and managers agree on the identity of a process and accept that a documentable, fixable problem exists.
Analyze
This step holds the essence of improvement. It generally starts with process flow charts and diagrams and ends with a documented understanding of what the existing process actually achieves, what it is worth, and what could be achieved by changing it. This is also where measurement metrics are defined and where the first recommended solutions to the problems named in step one take shape.
Redesign
Once the existing process is understood, evaluated, and documented, redesign can begin. This is often the most ambitious step. It can run from drawing future process flow diagrams and building models to selecting best practices as benchmarks for new process flows.
This is also the point where alternatives are recognized and agreed on by the management team.
Implement
Possibly the hardest and most critical step, implementation changes process flows, measurement metrics, and managerial responsibility, and that can be traumatic. Without it, nothing from the first three steps matters. The mechanics, though, are fairly straightforward: it begins with an implementation plan and ends when all the planned changes are in place.
Evaluate
The last step, but not the final one, because it is continuous. It begins with the design of an evaluation plan and never really ends. Once the plan is in place, it is continually updated, and the process it evaluates is continually changed and improved in response to what it finds.
Lessons learned
Principle 1: Top management must be supportive and engaged, removing barriers and driving success. A 2017 GAO study found that the number one reason improvement programs fail is lack of management support. What has changed since 2017 to make you think that would not still be true today?
Principle 2: The organization’s culture must be receptive to process improvement goals and principles. Two truths from organizational design apply here. First, cultural change must be led by people inside the enterprise. Second, change is not a start-and-stop event; it is continuous and progressive. What alters one department or activity today may not affect another for days or even months.
Principle 3: The big savings come from a process view, not a functional one. This is the whole reason you are reading this. Some savings can be found by improving single activities in a value chain, but the largest savings appear only when an entire process is evaluated and changed for the better.
Principle 4: Select processes based on customer needs, anticipated benefits, and the potential for success. There is a quiet message hidden here: the biggest gains do not always come from the process that looks most broken. Weigh the risk against the benefit, and look at the value to the customer, before you decide which way to go.
Principle 5: Process owners should run projects with cross-functional teams, hold the scope, focus on customer metrics, and enforce deadlines. The hidden message this time is that the biggest enemy of success is a set of vague, poorly defined parameters. Projects have to be clearly framed, defined, and mapped to succeed.
Where do we start
The five steps are real, but to work in the field you need a slightly more detailed map of the whole playing field, one that lets you see both where you are and where you are headed at any point. Here is what that fuller set of steps and sub-steps looks like.
Step 1: Identify
Start by answering the key questions. Who wants the project? Who is the stakeholder or customer? What kind of project is it? Then begin documenting and evaluating the process, checking that you have the support of everyone affected and that a project definition agreement or problem statement adequately frames the work.
Confirm that the process has been defined, that it spans more than one organizational element, that it occupies a meaningful place in the value chain, and that its value has been defined. Make sure there is a process owner placed high enough in the organization to span every element the process touches, that an improvement team with all the necessary skills has been appointed, and that the process is ready to be mapped.
First meeting
Start by meeting with the person requesting the project to determine the type of project, establish its authority, designate team members, prepare and sign off a project definition agreement, and create a project announcement.
Project types
Be clear on the project type, because a quick relook does not need anywhere near the resources of a full improvement effort.
- Document, model the existing process. Map and model an existing work process, establish the value stream, and identify the value-adding activities. Review it with the people who do the work to confirm it is accurate. These projects clarify processes and build model libraries for training and future work.
- Improve, model and improve. Model the existing process and make changes that do not require major development. A process expert team identifies and tests the changes.
- Reform, an in-depth study and reformation. Model an existing process and overhaul it thoroughly with an improvement team, striving for the best possible result. You will likely model the process several times before arriving at the final goal.
- Develop, create a process from scratch. Generally used to define a previously undefined process. A team with expertise across all affected areas builds a model to simulate the future outcome.
- Re-look, periodic update of a process. Triggered when circumstances suggest an existing process could benefit from tweaking to confirm it still performs to plan. It can be scheduled on a recurring basis or launched whenever management feels it is needed.
Project authority and scope
The person who requests a project should hold authority over the entire project. If it reaches into areas outside that authority, get the approval of someone who does have it.
Project definition agreement
Communication is vital whenever change may result from action by management, a team, or a sponsor. A written project definition agreement firmly documents the parameters of the project. Skip it and you invite real dangers: the true purpose can be missed entirely, the project can creep, and a host of avoidable problems can follow. Use the agreement to make clear what lies beneath the surface.
Selecting a project
Just because someone starts a project does not mean it should be done. According to a 2015 study by Holland and Kumar (Business Horizons, May to June 2015), a high percentage of process reengineering failures came from selecting the wrong process to reengineer. A few rules of thumb help: select projects tied to processes that respond to customer needs, select on comparative benefit, and select the ones with the highest probability of success.
Selecting team members
A simple checklist beats an hour of debate about team composition. Choose members from diverse areas of the process so they represent every skill and activity within it. Be wary of volunteers who are only available because they are not busy. Get the pros, the people who have been around and know the process inside and out, because they will save you enormous time when it comes to defining things. And try to keep an odd number of members.
The process owner’s role
The idea of a process owner is relatively new and does not sit comfortably in most managers’ mental model, which leans hierarchical rather than cross-boundary. Still, the owner carries several significant responsibilities: overall process design, setting performance targets, and budgeting and distributing operating funds.
Project announcement
You do not have to announce every project. The announcement exists to give the requesting manager a chance to explain the project to the people in the affected areas, and its effect is hard to overstate, cutting through layers of red tape. A typical announcement covers why the project is being undertaken, who the team members and leaders are, what each role and responsibility involves, and management’s position along with a clear request for support and cooperation.
The Analyze step
This second step builds on the foundation laid in the first and forms the basis for everything that follows. It begins with process flow charts and diagrams and ends with a documented understanding of what the existing process achieves, what it is worth, and what could be achieved by changing it.
Step 2: Analyze
Map and flowchart the process. Identify the value stream it represents, then model that value stream. Find the activities that waste time, duplicate effort, or create bottlenecks. Define measurement metrics, use them to evaluate the problems first named in step one, and present the simulated process to the improvement team for comments, revision, and approval.
Capturing the essence of process flow
Is there one best way to capture the true nature and direction of a process? There is, and it is a short series of steps that ends only when a fully animated, dynamic model is ready for analysis. Following them saves time and dramatically improves accuracy.
- Marching around, discovering the real flow. It is rare to find a true, correct description of a process sitting ready. Most organizations have a procedural guide describing what is supposed to happen, but when a process spans more than one organizational element, it is rare to find anyone who knows how it performs beyond their own area. Because the gap between the documented process and the real one can be vast, go see for yourself. Walk from one end of the process to the other, taking quick notes as you go. Start with the most common flow, capture the duration of each activity, the splits, the combinations, the resources used, and what actually happens at each step. Collect every data entry form, and if a form is electronic, capture a screen print with the entries highlighted so it can be linked back to its activity step.
Duration is best captured with three points. Ask how long the operation usually takes, then the shortest it has ever taken, then the longest. Those three values form a triangular distribution written T(min, most likely, max), which goes straight into the time field in ProcessModel.
-
Interactive mapping, creating the flowchart. Use what you gathered while marching around to build the flow chart, faster and more accurately now because you understand the terms and context. Arrange the most common activities across the top of the page, the happy path, and use the decision shape for questions and exceptions. Build the flow of activity steps first, then animate the model with default times to show the team and confirm accuracy.
-
Turning the switch, modeling the flow chart. A flow chart, however revealing, is not the end product. Making decisions about a process from a static diagram alone can be disastrous, because of variation. It is extremely hard to predict how even small systems will perform when slight variation is present in how individual tasks are completed. To examine the flow of work, material, ideas, and value, and the impact on your chosen metrics, you need a tool that accommodates variation. Turn the switch and watch the process perform. Beyond duration, mimic the arrival pattern, develop any special logic, and model the resources last.
The concept of value
Every process contains three kinds of task. Value-added tasks add something the customer would pay for, represent a competitive advantage, or add a desired function, form, or feature. Required non-value-added tasks add no value but exist because they are required by law or regulation, required by business necessity, or would jeopardize the process if removed. Non-value-added waste tasks are neither required nor add value. Common examples include rework, expediting, multiple signatures, counting, handling, inspecting, setup, downtime, transporting, moving, delaying, and storing.
The value stream
The value stream is one or more processes that produce value for the customer while consuming resources to do so. It is usually the first place analysts look, either to measure a process’s output or to measure the impact of a change on the organization.
Ten ways to immediately improve a process
Interviews with leaders in major corporations made one thing clear: finding things to improve was never the problem. Finding the right combination of projects that would actually move the numbers was the hard part. ProcessModel helps by automatically identifying the areas that will deliver the greatest impact if fixed.
The red bars mark waste in the system. Eliminate the largest red areas and the system produces more with a shorter cycle time, which means you are always working on the things that affect the outcome of the whole system.
There are countless ways to improve flow. Among the most effective: reduce errors, reduce duplication or fragmentation of tasks, combine similar activities, reduce handling, move sequential tasks closer together, eliminate unused data, standardize forms and instructions, remove artificial delays, and automate.
Measurement metrics
If you are analyzing a process, you need something to measure. Measure nothing directly tied to the process and you cannot evaluate it, and you will have no way to assess the impact of any change. Choose metrics that are logical, relevant, and sound for the process, easy to understand, related to the real world, common in similar businesses, and a natural byproduct of the process itself. Operational-level metrics that measure day-to-day outcomes include throughput, cycle time, production cost, defect rate, and production rate.
The importance of communication
Communication is probably the single most important part of any improvement project. At every step, hold meetings with the stakeholders, team members, and managers so everyone knows what is happening and what is forming. Make sure everyone understands the current state of the chosen metrics, the problem the team is focused on, the project’s organization and workflow, and the process itself, at least from end to end, so everyone is ready to make decisions.
The Redesign step
Once the existing process is understood, evaluated, and documented, redesign can take place. It is often the most ambitious step, running from future flow diagrams and models to selecting best-practice benchmarks for new flows, and it is where alternatives are agreed on by management.
Step 3: Redesign
Identify and chart an ideal “to be” model of the future process. Build a computer model of it. Using the same metrics from the Analyze step, compare new and old performance under identical conditions and assumptions. Bring in best practices from similar processes, identify wide-sweeping alternatives, evaluate the new model against the problems named in step one, and present it to management for comments and approval.
Redesign is a mopping-up process
Redesign does not happen all at once. Even small processes hold surprises, so redesign is iterative. Team members are encouraged to suggest changes, and they are shown a parade of progressive models, one by one, until everyone agrees nothing more can be gained.
To keep that moving smoothly: give each member the common methods for improving flow, the defined metrics, and a summary of all assumptions and findings; schedule meetings right after model runs so no momentum is lost; maintain an active comparison chart of the metrics so progress is visible; and set a Minimum Variation Goal that signals when little more is to be gained. A goal might be as simple as: once ten trials have run and no more than a 0.5% improvement in a given metric has been achieved, no further trials will be considered. Every redesign effort ends with a presentation of results and recommendations, first to the team and then to management.
The value of optimization
Analysts often relax once a goal is reached. An improvement team should never do that. It is not enough to produce a model of the suggested process; it has to be evaluated from several perspectives. Subject the final “to be” model to as many of these as possible, watching the metrics for unusual behavior: a full range of test scenarios built from existing cases, a full range based on expected but realistic extremes, and multiple runs of standard scenarios to catch rare behavior.
Evaluating outcomes
The true value of a revised process is not always obvious. Small financial gains can look bigger than they are once pulled out of the business context that produced them. So always evaluate the impact of a change in the context of other process and project information, since no result is good or bad on its own. Collect measurements as a natural part of the process rather than an artificial construct, keep the detail just deep enough to identify and analyze problems, and be systematic, or you will struggle to tell cause from effect.
Presenting to management
A poor presentation can be the difference between approval and rejection, so here is how to look like a champion. Lead with a concise, honest summary of what was accomplished. Follow with your recommendations, letting the team member whose area is affected make the relevant one. If you are seeking approval, have a summary sheet ready for each recommendation with a signature block at the bottom.
Get the management team involved by using the animation of the simulation to show the principles of the change: introduce how it works, show an area of particular interest, then show the scope of the work behind the recommendations. That single step sets you apart from every other presentation management will see all year, because they see how you reached your conclusions and gain confidence in them. Always be ready to justify a recommendation, offering your strongest reasons first. And if you receive approval in the meeting, sit down and stop talking. I have watched presenters talk their way out of an approval because they would not stop once they had made the sale. Enjoy the moment. Now the real work begins.
The Implement step
Implementation changes process flows, metrics, and managerial responsibility, and it can be traumatic. Without it, nothing from the first three steps matters. The mechanics are straightforward: it begins with an implementation plan and ends when every planned change is in place.
Step 4: Implement
Evaluate the new model for phased or sudden-death implementation. Develop the plan. Appoint an implementation coordinator. Evaluate the cultural impact and build a change program to match the expected response. Get everyone’s fingerprints on the knife. Then present the final plan to management for comment and approval.
Fingerprints on the knife
Cooperation at every level is essential for a smooth rollout. Everyone involved needs to know what is about to happen, how long it will take, the benefits, and how the current process will change. Informed regularly and honestly, the fears that come with change tend to fade and cooperation grows. An informed group takes ownership of a new idea far faster than one simply told to accept it.
Implementation catch points
Two elements cause more implementation trouble than any other: scale and complexity.
Scale. A single-activity process can change in minutes, but a process with hundreds or thousands of activities can take a year or more. Part of a process may already be running under new leadership while another part continues as before. Managing change at that scale calls for computerized flowcharting and project management software; settle for less and you risk losing both momentum and accuracy.
Complexity. Where scale is about size, complexity is about the presence of many tasks that may not be similar or even related. Implementation plans must include supporting activities for every sub-process, and account for the different requirements each activity brings, things like equipment, training, policies and procedures, facilities and workspace, forms, and computer programming.
Sudden death versus phased implementation
“Sudden death” comes from the software world, where a program is put straight into production with no backup or parallel safety systems running behind it. Used for process change, it does not have to mean mayhem, as long as a few rules hold. The more organizations a process spans, the stronger the case for phased implementation. Any process contained within a single department is a candidate for sudden death. The dividing line generally sits around the ten-activity mark: a process with ten or fewer activities can usually absorb a complete revision without meltdown, provided a comprehensive plan is created and followed. And whichever style you choose, the two most important elements are firm deadlines for each change and clear assignment of responsibility for it.
Implementation plan contents
For a single-activity change, the plan can be as simple as an email announcing when and where the change happens. That is rare, though. Most processes carry enough complexity and scale to warrant a detailed plan with supporting documentation. To be fully prepared, the implementation coordinator should make sure the plan contains a copy of the initial flow chart of the old process, a copy of the final flow chart of the new one, a Gantt chart showing each changing activity and its start and end dates, a description of the work needed for each activity where required, a list of personnel by name with their assigned responsibilities, a list of material and support requirements, and a copy of the signed approval letter.
The Evaluate step
The fifth step builds the foundation for a new cycle of continuous improvement through vigilance. It begins with the design of an evaluation plan and never ends; once accepted and implemented, it is continually updated, and the process it watches is continually improved.
Step 5: Evaluate
Develop an evaluation plan that ensures periodic review. Establish goals and triggers that signal the need for further improvement once a cycle review is complete. Build situational standards that would signal the need for an out-of-cycle review. Prepare recommendations for future changes that were not yet possible for technical or financial reasons. And prepare an after-action report, storing all supporting documentation safely.
The purpose of an evaluation plan
An evaluation plan serves two purposes. Because no model can represent every aspect of reality, you can never be completely certain a plan will improve a process exactly as forecast; you can get close, but not perfect. There is also strong evidence that simply paying attention to a process often changes it for the better, beyond what a manager actively alters. So things have to be monitored. The plan acts first as an immediate sensor of how the new process performs while it is being implemented and once it is running normally, and then as an ongoing sensor for changes in performance or conditions that could affect outcomes.
Evaluation plan contents
Tailor the contents to the organization and the process under evaluation. At minimum, include a copy of the process flow plan; the metrics chosen to evaluate performance, with the expected statistical parameters and a description of what each metric means and how it is measured; a sampling plan; a shared copy of the model used to project expected metrics; a schedule for future evaluations naming who collects the data and who receives the results; and a list of triggers, metric values that signal the need for further evaluation, whether internal, external, or situational, such as discontinuing part of a product line.
Take control of your processes
Identify, analyze, redesign, implement, and evaluate. Every process needs a skeleton to hang its activities on, and these five general steps are that framework. Without it, the peripheral information that makes a process understandable can be lost. To get the most from any process, strip away the varnish and look at the value-added steps themselves, the ones that contribute directly to the outcome the customer actually cares about.
That framework, paired with value stream mapping and simulation, is what lets you see the whole picture and make decisions backed by data rather than opinion. When you are ready to put it to work, see how ProcessModel supports process improvement or compare plans and pricing.
