Six Principles of Process Excellence

In our view, the goal of operational excellence does not apply only to operational processes like order fulfillment and production planning. To us, operational excellence means reaching toward excellence -- every day, all day -- in everything we do.

To enable us to move toward excellence in everything we do, we take the position that every single thing we do is a process, and part of a larger process. We look at any action or decision as part of a process, and force ourselves to formally describe what is being done. Then, once we have formally described it, we can measure the process, standardize it, systematically improve it, and delegate it. But if we do not first define a piece of work as a process -- as a definite way of transforming definite types of inputs into definite types of outputs -- we cannot hope to excel at it.

Here are some of the basic principles we return to time after time to remind ourselves how to see a business as a set of processes.

1.     Everything a business does is part of a process. Everything!

This is the lens we choose to use for understanding precisely how a company’s actions relate to the outcomes it achieves. No activity is out of bounds. Every activity taken by every person and by every machine falls within the scope of process improvement and operational excellence. This is because every activity that requires resources, takes time, and achieves something can be described and understood in terms of the process to which it contributes.

By way of analogy, imagine a basketball game. To the untrained observer, individual plays are not distinguishable. He merely sees ten people running around and taking occasional shots. But to coaches, every move on the court is part of a play. Think of each play in the coach’s playbook as a process to be executed on the court. Even the actions of the players during time-outs are thought through in advance. There is nothing that happens during a professional basketball game that is not part of a play.

Sometimes when we look at an outcome we aren’t consciously aware that there was a process that got us there. Seemingly, it just “happened.” But nothing just “happens.” It’s always -- according to this principle -- part of a process.

So we have learned to remind ourselves constantly that everything a business does is part of a process. If we don’t remind ourselves, we sometimes forget.

2.     An unwanted result always indicates a process problem.  

If everything we do is part of a process, then every result we get is the result of a process. It follows, then, that if the business isn’t achieving its goals, there’s a process problem somewhere. If results aren’t satisfactory, a process isn’t producing the results you want. If process x produces result y, and you aren’t satisfied with result y, then you need to change x.

If a goal is not achieved, or a product is defective, we need to remind ourselves not to be fixated on repairing the defect. If our goal is to move constantly toward operational excellence, it is much more important to repair the process that created the defective product.

In fact, the problem that merits our closest attention is almost never in the process that appears to be the problem. The obstacles to operational excellence invariably lie in the processes that create and maintain processes. That is where we want to turn our attention in order to work, day by day, toward operational excellence.

Keeping the sports analogy, think of “bunch ball,” a descriptive term for the way seven year-olds play soccer. They all chase after the ball, bunching up around it, without any clear idea of what they’re trying to do. To focus all of an organization’s problem-solving attention on “fixing a problem” rather than on improving the processes that gave rise to the problem is a kind of “institutional bunch-ball.”

Whenever we find ourselves in a problem-solving situation, we ask ourselves, “Are we chasing the ball because it has stolen our attention, or are executing a “play” to achieve a desired outcome?” Until we know what “play” we need to improve, there is no way of improving our results.

3.     Process execution is in essence a collaboration of people (and robots) using tools.

The essence of any business process is implicit or explicit agreement among a group of people about how they will work together. When a process produces unwanted results, this indicates either that something was beyond their control, or that the “we” that carries out the process does not have a complete grasp of all that’s needed to achieve the results they desire.

In fixing this problem -- let’s call this fixing activity process improvement -- we want to focus on collective learning, and addressing the aspects of the collaboration agreement that were not understood or not fitting. We want to make explicit all that is needed to achieve the desired results. To fix the process we fix the collaboration agreement.

When a problem comes to light, there’s often a tendency to focus on the faults of individuals. This merely takes attention away from the real issue, which is how we collaborate. To focus on an individual’s failure is to break up the “we” who are working toward a shared goal into an “us” who are doing things “right” versus a “them” who are in the “wrong.” As soon as a group of people see themselves as “us and them” rather than as “all of us together,” they create a climate of judgment and blame, not a climate that encourages collective learning. The process of finding fault with an individual is a process that does not effectively address the underlying problem, which is always a problem with a process. Instead it produces unwanted outcomes or side effects.

To continue with our basketball analogy, not all plays are perfectly executed each time. The process of dedicated team practice leads toward operational excellence.

4.     A tool is never the source of a process problem.

When a tool fails, there’s no point in blaming the tool. The tool is not responsible for itself. Look for defects in the processes that put an inappropriate tool in place, or that failed to maintain the tool, or that allowed someone to misuse the tool.

Fixing the tool will not move the organization closer to operational excellence. It will merely restore it to operation.

5.    Accountability for process excellence belongs with line business executives or process owners.

In our view, the person accountable for the operation of a process is the logical person to be held accountable for the improvement of the process. This responsibility cannot be delegated successfully to process improvement specialists or to information technology (IT) specialists.

It follows, then, that process improvement is not IT’s job. Yet in the absence of accountable and effective “process owners,” IT personnel have often taken it on themselves to drive the business to consensus on processes. They felt they needed such consensus as a prerequisite for process automation. In our experience, this is a classic example of trying to “save people from themselves.”

That doesn’t work. If the line business executives are not ready, willing, and able to take responsibility for improving their processes, that’s up to them. Trying to do another person’s job for them is no more effective than trying to live someone else’s life for them. Whenever we take on process improvement work on behalf of others without their full involvement, commitment, and accountability, we are merely enabling them to keep acting as if process excellence is not their responsibility.

           

6.     Process accountability cannot exist unilaterally.

Ultimately, accountability is itself a set of processes. When performed effectively, these processes produce  actions and decisions that lead toward operational excellence. Accountability manifests itself as a set of agreements among people, as a framework for collaboration, and as collaboration in action. A necessary condition for accountability, therefore, is a culture in which the terms of accountability are mutually understood and respected.

You will find that a person acting on his own can claim accountability, but that will be only partially effective unless there is an overall culture of accountability such that others understand his accountability in the same terms.

In an effective, multilateral culture of accountability, an organization provides forums in which people come together to work out changes that meet all their needs. Without such forums where collective learning can occur, the only options are: a) never change, or b) make unilateral changes and hope people will accept them.

These principles serve as helpful reminders. They continually guide us back to the path toward operational excellence. They remind us how to think clearly when clear thinking is most difficult -- those times when something has gone wrong, there’s a lot at stake, and everyone is focused on what hurts. That’s exactly the time when we need these reminders to shift our focus from the problem, as it painfully presents itself, to the processes that lie at its root. 

A Suggestion: Stress-Test Your Accountability Culture

Organizations put a lot of accountability structures in place to make sure that people do their jobs correctly, and that projects succeed. These accountability structures include reporting hierarchies, project plans, documented responsibilities, and performance metrics.

These structures can have an unintended consequence: by holding people accountable for specific tasks and outcomes, they may discourage folks from holding themselves, and one another, accountable for their collective success. The small issues all have owners, but the big issues can slip right through the cracks.

Who is accountable, in your world, for the effectiveness of the accountability structures overall? Who has the job of looking for weaknesses or failures in these structures? Each time an issue erupts into a crisis that requires drastic action, that’s a sign that a big problem slipped through the cracks, or flew under the radar, for far too long.

Lets think about accountability in terms of business processes. I take the position that:
a. everything that happens in an organization is part of a process
b. When a result is not satisfactory, that indicates a defect in a process.
c. when there is a defect in a process that no one is addressing, there is a lack of accountability for the process.

I’ve been involved in lots of process improvement projects, and I’ve seen many of them fall far short of their goals. In my experience, the most common cause of failure is that managers turn a blind eye to early warnings of a problem. This happens especially when the early warnings suggest a problem that is too big or too awful to contemplate.

Jerry Weinberg calls this “The Titanic Effect.” When your project is too big to fail, people refuse to see the warning signs, and they forge ahead at full steam - right into an iceberg. The belief that failure is not an option, or that “we’re too indestructible to sink,” is strongly correlated to catastrophic failures.

What can we do to address this kind of unwillingness to face unpleasant possibilities? There’s a concept widely used in product design processes called Failure Mode and Effects Analysis, or FMEA. It seeks to identify known ways that a product or process can fail, understand the severity of each type of failure, and decide how to prevent such failures.

What do you suppose you and your colleagues would learn if you conducted a Failure Mode and Effects Analysis of the way process improvement projects (or information technology projects) can fail? What kinds of failure would your colleagues agree are  absolutely predictable, but continue to happen anyway?

I’ve heard people say countless times that a critical success factor for their project is strong executive sponsorship. But how can you test the strength and effectiveness of your executive sponsorship before a crisis occurs?

I’m suggesting that you all come together and share your experience by means of a Failure Mode and Effects Analysis. If strong sponsorship is critical to the success of your initiative, then why would you not take every reasonable step to make sure you’ve got it?

Are Your Accountability Structures Working?

I see a lot of effort to create accountability in organizations: reporting structures, performance metrics, and project plans. These accountability structures lend the appearance of control as people routinely report progress, review and resolve issues, and adjust their plans. In my experience, though, these accountability structures often fail when they are needed the most.

I saw this happen recently. A team of 100 people had worked for 18 months to launch a new application. The project managers met every week to review progress and address issues. They used formal tools and processes to identify risks, assign actions, and measure progress. The project, though complex, looked very well organized.

Then a crisis erupted into view. Just 30 days before the go-live date, management decided to postpone the launch. During their weekly risk review, they determined that one issue might not get resolved in time. This single risk was deemed serious enough to justify postponing the launch, even though the delay would be costly.

Project managers were directed to mitigate the risk and come up with a new launch date. After a two-week scramble, the new plans were announced. The launch date had been pushed out 120 days. And there was uncertainty about the new date; several teams worried aloud that they might not be able to finish their work on time.

It took courage for managers to make this decision, and take the heat for it. I admired the way they conducted themselves. But I also wondered how it was possible, despite all the control structures, for a big problem to take root and grow so big before it got the attention it required.

To me, this story suggests a failure of accountability when it was needed most, when the problem was still small. When was that? If the project was 120 days behind schedule, then the first signs of slippage probably appeared at least 120 days before the No-Go decision was made.

At that time, the problem appeared small. There was the appearance of plenty of time. There was an unwillingness to make an unseemly fuss at that early stage. There were other problems at that time that looked a lot more serious, and required more urgent attention.

I’m left with this question:

What can we do to create environments where early

indications of problems get the attention they deserve,

so that little problems don’t grow up into big ones?

Hold Me Accountable, Please!

My friend Stefan was sharing his thoughts on what it takes to achieve process excellence, and he kept coming back to the word accountability. “The key to process excellence,” he said, “is accountability.”

As soon as I heard the word accountability a red flag went up for me. I didn’t want to admit this to Stefan, but accountability has been an elusive concept for me. I’ve struggled for years to make sense of it, to find a crisp, clear, actionable definition for it. Without success.

Years ago I was introduced to the RACI model of standard roles and responsibilities with respect to a process. RACI stands for Responsible, Accountable, Consulted, and Informed. People who like the RACI tool, and there are many, claim that it’s an effective way to clear up confusion about who’s in charge and who is merely involved.

That hasn’t been my experience, because I could never draw a clear distinction between responsibility and accountability. (The other two concepts don’t trouble me. I get that some people might get consulted during a process, even though others get to decide what to do with their inputs and suggestions. I also understand that sometimes there are people who need to be informed when a decision is made, but who won’t have a role in making the decision.)

But what, exactly, is the distinction between being accountable and being responsible? I concluded years ago that there couldn’t be a single “right” answer to this question because these words mean different things to different people. These two words seemed to fall into the category of “words people believe in but cannot explain clearly.” I learned a long time ago to steer clear of words of that sort, because they generate a lot more heat than light.

But now my friend Stefan is insisting that “Accountability is the key to process excellence,” and he won’t let go of the idea. So it seems I have no choice but to try once again to make sense of accountability and responsibility. I tackled the problem by writing about it. I’ve often found that when I try to explain a concept to others, it suddenly becomes clear to me. I wrote several rough drafts, explaining the many ways these concepts confuse me.

Stefan reviewed my drafts, and commented on them, but the ideas still weren’t coming clear. Until one morning I woke up to an email from Stefan that said this:

“I talk about accountability because in my work as a consultant I want to be held accountable.

“I’ve learned from experience that unless I’m willing to let you hold me accountable for something, I probably won’t hold myself rigorously accountable. And if I’m not willing to hold myself accountable, that’s a sure sign that I don’t believe in my own ability and commitment. So I need for you to hold me accountable to bring out the best in me.”

Then Stefan referred me to a blog he’d found, which referred me to another blog, which offered this simple clarification:

I TAKE responsibility and you HOLD me accountable.

Aha! This simple sentence goes right to the heart of the matter. These words – accountability and responsibility – have to do with creating agreements between people. When I accept responsibility for an outcome, I’m telling you that it’s OK with me for you to hold me accountable for my progress, success, or failure. We’re entering into an agreement.

If you tell me I’m responsible for a task, that doesn’t create an agreement. All that’s happened is that you’ve told me what you want. I have to accept responsibility for an agreement to come into being.

Here’s the next question Stefan has offered for me to ponder: What do you want to be held accountable for?