Karen Phelan - I'm Sorry I broke Your Company

This was an incredibly disheartening experience for me. After meeting with the customer and having that brainstorming session, I saw a glimmer of hope that maybe there could be a solution for this client. I felt like I had actually helped someone. When I was forced to follow the recommended process rather than use my own judgment, I went to work sick to my stomach every day. I knew what I was doing was wrong. I had always used methods and tools as a means to an end, not as an end itself. I always thought the point of these methodologies was to supply new insights and challenge conventional thinking. My colleagues and I never saw them as step-by-step recipes for success. What was great about Gemini when I joined was that all of our methods were excuses for getting people to work together better. Now they had become a substitute for getting people to work together better.

The irony is that if you go back to the book that started it all, Reengineering the Corporation , the authors purposely recommend that to be successful, you need to get everyone involved in the solution. They also specifically state that there is no step-by-step method for developing new processes. They recommend starting from a blank slate. The last chapter or two of almost every business book today is an instruction guide on how to implement the solution correctly. What I really like about Reengineering the Corporation is that rather than ending with a recipe, the authors discuss some of the situations where reengineering initiatives have gone wrong. They also have a very useful chapter on typical symptoms of process problems, like data redundancy being a symptom of process fragmentation and inventory buffers being used to deal with uncertainty. The difference between offering an instruction manual and describing mistakes and problems is that the former limits thinking while the latter expands it.

In contrast, Six Sigma starts not with a blank slate but with the current process, and many critics of this methodology complain that it offers incremental improvement and not anything radical or innovative. I think most people are missing the big picture. Six Sigma is a control process that has It's origins in machine control. This is great when you are working with equipment, but what about when you are working with people? I have a reference book for implementing Six Sigma for marketing processes, and it is full of templates for monitoring task completion and documenting stage-gate criteria. The point of these templates is to instill discipline and consistency into marketing processes. Why would I hire smart, creative, psychologically savvy people and have them spend their time filling out document templates and monitoring progress in minute detail when they should be brainstorming new product ideas and new marketing campaigns? Isn’t the marketing function supposed to be chaotic?

Years ago I used to teach problem-solving tools to other consultants. Figure 1 shows one of the tools that is part of the Six Sigma toolkit, an Ishikawa or fishbone diagram, used to identify root causes.

Causes for a Car Not to Start

Figure 1 Fishbone diagram

The car example above bothered me for years, and I often searched for a better one but never found one I liked. Eventually, I realized that the problem wasn’t with the example but with the tool itself. We have five possible categories of causes for the car not starting — man, machine, materials, methods, and milieu. The most obvious answer is that It's a dead battery, a machine problem, but if you ask why the battery is dead, It's from leaving the lights on — ultimately a human problem. Take a look at the methods and the materials categories. The car is out of tune, has no antifreeze, or has been repossessed or the driver doesn't know how to start it — these are really human problems. In fact, pretty much all business problems are human problems. Even many manufacturing equipment problems are really human problems, caused by operator error or poor maintenance. In a human-created world, it is hard to find a problem that isn't ultimately created by a human.

I have spent at least a decade reengineering processes and finding root causes, and I have discovered several that appear over and over again in process problems. I have never seen these discussed in the reengineering literature:

• Mistrust —This is probably the biggest problem in broken processes. When people work in silos and don't communicate, they don't understand why their counterparts in other departments are doing the crazy stuff they do. This misunderstanding sets in motion all sorts of games, controls, cross-checking, and review and approval steps, none of which add value. Mistrust, along with fear and hope, is the fundamental cause of the notorious supply-chain bullwhip effect, where small deviations in demand ripple through the chain and become huge deviations at the end. Basically, customers are bumping up their orders because they don't trust that their suppliers will deliver, and this continues along the whole chain of customers and suppliers. When customers do get their demand filled, they cancel the rest of their orders, which again ripples down the chain. This leads to a cycle of over-and undersupply situations.

• Conflicting goals/working at odds —I'll talk more about this cause in the next chapter, but basically, functional silos often have goals that conflict with other functions’ goals. For instance, Sales wants absolutely no stockouts while Inventory Management is working on decreasing inventory levels; Marketing wants to launch a product quickly while Regulatory insists on extensive product quality checks; headquarters wants to reduce the number of internal initiatives while the regions are running improvement programs that spawn lots of new initiatives. These are just a small sample of the examples I’ve encountered.

• Impatience —This impacts almost every initiative and project undertaken at a company and is becoming more and more of a problem with the rapid pace of work. Most often I see this in new product development when an important new product or a pet project is on the docket and people can’t wait to get started — literally. Unfortunately, stuffing a project pipeline full actually clogs it up. People can work on only a few projects at a time, and starting numerous projects at the same time means none of them get completed. I also see this happen with many corporate initiatives. Impatient to get going, the project team skips the proper analysis to determine the actual causes of their problems and ends up implementing solutions that make matters worse.

• Fear of looking foolish —This is a big problem in new product development. Often, the members of the group working on a new product want to perfect their concept before they share it with anyone else. Unfortunately, what happens is that after spending months perfecting the concept, they discover that it is unviable from a legal or regulatory or manufacturing perspective. They’ve wasted all that time working on an idea that could never launch. Putting incomplete concepts out to everyone involved means you can weed out the bad ones faster, but no one wants to appear foolish.

What I would like to know is which process optimization software and which reengineering methodology deals with these issues? I’d also like to see the flowchart that solves these problems. Like our pretend optimized monthly schedule, these process flows look great on paper but often don t represent the reality of the situation. A big part of this problem is the belief that work processes are separate from people. People do the work and are the work process. For instance, when I was streamlining a new product development process, the senior vice president in charge of development wanted insight into all the product concepts, so we put in an approval step at the beginning. During the project, he left the company, and his replacement didn't want to see product concepts until later in the process, so the approval step was taken out.