2
Make Sure You Reengineer the People, Too
Optimized Processes Only Look Good on Paper

Having people to rely on for improvements is all you really need

Process reengineering, and with it, process automation, is where I’ve spent a good chunk of my career. This was the type of work I did when I began consulting, only we called it “operations improvements” before the term “process reengineering” was coined. Although my memories of many client projects all those years ago are a blur, I do remember my first client engagement well because it taught me a great deal about business problems. The client was a small refrigerator manufacturer that was suffering from excess inventory, long lead times, and an inability to meet customer orders. The business had changed over the years from just a few products to a wide-ranging product line that offered customers their choice of features and even some custom designs. The complexity of the operations had increased while the plant configuration had stayed the same. My manager had sold the client very expensive, cutting-edge software to improve its scheduling ability, a large investment for a company of this size. He had promised the software would optimize the company’s plant floor and dramatically improve its production volume. Unfortunately, after following his advice and implementing the software, the company saw only slight improvements. This became a big client satisfaction issue, especially because the company was a client of other services our consulting firm offered, and the partner in charge of the manufacturing practice had to fly out and try to smooth the situation over. The result was that my manager was effectively banned from the client’s site, and we offered to perform a free analysis of the company’s operations and write a requirements definition for an integrated manufacturing, inventory, and financial information system. Eventually, this system would solve the company’s problems because it would integrate its operations.

I found myself at this manufacturer with two accounting consultants who were going to write the requirements for the financial part. They had an office upstairs with the accounting function, while I was a given a space right above the shop floor. Because we weren’t making money on this project and were unlikely to sell any follow-on, the local management basically left us to our own devices. Here I was about twelve months out of college with an engineering degree in electronic materials with absolutely no knowledge of a manufacturing enterprise, trying to solve the company’s problems on my own. Although I was sold as an engineering graduate of MIT (Massachusetts Institute of Technology), my degree was in semiconductors, working at the atomic level with electron microscopes, not exactly the kind of engineering used on a shop floor. (Maybe at a much, much smaller manufacturer!)

I began my analysis with a tour of the shop floor with the supervisor. The first thing I noticed was that there were parts everywhere. Officially called “work in process,” these were unfinished items making their way through the production process. Every machine had two queues of parts—coming in and going out. Because of this, the place was cluttered and filthy. Secondly, every machine operator was busy punching away at a machine. Finally, I noticed several men, better dressed and cleaner than the machine operators, walking around the floor and haggling with the operators. Every time one of these men approached a machine, the operator stopped, and the two appeared to engage in an argument. I asked the shop floor supervisor what these men were doing. He explained that they were expediters. The job of expediters was to take care of rush or high-priority orders by babysitting them all the way through production. An expediter would bring a rush order to the first machine, make sure the first part was produced, bring it to the second machine, and so on until the order was complete. Unfortunately, this process was incredibly disruptive to the production schedule, especially since it had been optimized with expensive software. Each operator had to stop what he was doing, which was making a part for an order, to retool the machine and make the part for the expediter—no wonder the software wasn’t working! After the tour, I started talking with shop floor workers and production schedulers and anyone else who would talk to me. Although I was warned that the workers were “union” and likely to be uncooperative, I found that most were more than happy to talk to me, and some even vented all their frustrations with the situation, being grateful for the opportunity to be heard. Their own management was so busy that they never had time to go down to the floor and talk with anyone.

The company’s procedure to create a manufacturing schedule was to require its customers to submit their orders by the end of the month. The orders were then entered into the computer, which spat out an optimized production schedule for the next month. However, the company had several important customers who submitted orders weekly that needed to be filled as soon as possible. At first, these orders were fed into the computer system and a new schedule was created, but because the old schedule was already underway, creating a new schedule with every new order became disruptive. So the new orders were kept separate and handled by expediters. Though in theory the schedule was kept intact, in practice it wasn’t being followed by workers, who had to halt what they were doing to accommodate the expediters’ requests. As more orders fell behind their commitment dates, more orders were designated “rush” and required expediting, with the result being that the shop floor became less optimized and fewer orders got shipped on time—a vicious circle.

After a few weeks of mostly talking with the employees, I developed a list of their problems with some recommendations. Even though I was told specifically that human resources (HR) was outside the scope of my analysis, the biggest problem was that the workers were compensated by the number of pieces produced and not by meeting the schedule. This meant that if a machine operator had to change the tools on his machine, which took about two hours, to make five pieces, which took about thirty minutes, he would make more than five parts to compensate for the changeover time. The extras would sit at the workstation and, with any luck, be found when that part was needed again. Making the situation worse, the machine operators would always appease the expediters first before following the schedule because the expediters were breathing down their necks. Again, the operators would make more than one part if they had to change tools. Finally, they would look at the schedule and see how much of that they could accomplish before the end of the day.

All the workers knew that this approach was contrary to meeting their order commitments, but this was how the floor operated. They had incentive compensation based on the number of pieces produced, so they were going to produce as many as they could, even if those pieces weren’t needed. Worse, making these unnecessary pieces consumed the raw materials that were ordered for required pieces, so the operators were always running out of raw materials. This meant that the purchasing department had to order more than the schedule required, which only allowed the operators to make even more unnecessary parts. The net result was a complete disaster—lots of unsellable inventory, few completed orders, and a scarcity of raw materials.

Obviously, my first recommendation was to stop compensating employees based on the number of pieces produced and to move to on-time order fulfillment as a collective goal. I also recommended that the company get rid of the expediters and move to a weekly production schedule because customers were sending in their orders on a weekly basis anyway. It doesn’t matter how nice the optimized monthly schedule looks on paper. If your customers are sending in orders every week and you are incorporating those orders into your schedule, then you are actually working from a weekly schedule. The monthly paper schedule is just pretend. I also made some recommendations for changing the order lead times and creating a separate job shop. I wish I could say that the company implemented these changes, improved its ability to ship orders, lowered its inventory and production costs, and became immensely profitable. However, after I wrote the report and presented it to management, I went on to another assignment. The president and his team seemed pleased with the recommendations, but a year later the company was bought by a larger appliance maker without having implemented much of anything.

Although at first I was a little resentful of having to work on my own at my first client, it forced me to rely on the employees for all my information and on myself to think things through. Normally, I wouldn’t have had the chance to talk with so many people or spend lots of time “just thinking.” In consulting, where you are rated on your ability to hit the ground running, thinking is often considered a non-value-adding activity. What I deliberated on was that, contrary to the advice that the union employees would be unhelpful and even dishonest, I found that most of them knew exactly what the problems were and wanted to help, but not only were they powerless to change the way things worked, they were alienated. The relationship between the employees on the shop floor and the management team was hostile. All it took was one painful labor contract negotiation, and the mutual mistrust soured the relationship permanently. The whole time I was there, I never saw anyone from management on the shop floor, and the workers certainly never volunteered information to their supervisors. Each painted the other as evil, greedy, uncaring, and stupid, and each used the one or two exceptions of purely self-interested people on the other side to define everyone else. Some of the human resources policies were meant to deal with these exceptions, but unfortunately, they applied to everyone else as well. What I found frustrating was that people rarely spoke to others outside their areas, and I often found myself acting as a communications vehicle. Another thing I found very frustrating was “scope creep.” My manager had warned me to stick to the manufacturing operations and avoid the common consulting pitfall of scope creep, but many of the problems had their causes outside the manufacturing area. The incentive system was the root of many of the evils, but the lack of information sharing and poor relationships with customers and suppliers also created shop floor problems. I discovered that some purchasing departments would create duplicate orders at different facilities to get product faster and then cancel what they didn’t need. To really fix the shop floor, you would have to include everyone else in the supply chain.

People should manage the methods and not the methods manage the people

Over the next few years, I spent most of my time improving operations at small manufacturers using some of the methods that were popular then: bottleneck analysis using Eliyahu Goldratt’s theory of constraints, just-in-time (JIT) manufacturing practices from Japan, or MRPII (manufacturing resource planning, the precursor to ERP, or enterprise resource planning) information systems. The funny thing is, none of these methods ever worked perfectly. We always had to adapt. Often manufacturers had multiple bottlenecks that needed to be addressed together rather than one by one. While some JIT principles can be applied, the reality is that you can’t implement pure JIT in this country. Japan is a small country where the suppliers are never that far away. It makes no sense in the United States to try to turn all your inventory in one or two days when it takes two weeks to get raw materials. The same thing was true about implementing manufacturing software. We would never just go in and install software. We always made sure that the processes and information were correct first. Otherwise, you would have a disaster. Even then, the initial implementation usually uncovered more bad data. Based on my experiences, I thought of these methods as guidelines or tools to be used at one’s discretion—the more tools you knew, the better equipped you could be.

At the time, quality initiatives were popular, and I decided to pursue a certification in statistical process control (SPC). Manufacturing automation was becoming sophisticated enough to monitor the multitude of variables in a manufacturing process such as temperature, pressure, and speed. The idea was to monitor all these variables to determine what specifications would ensure the quality of the product. Using performance histories and statistics, you could predict when a machine would likely go out of specification or if a problem was due to operator error. It was an incredible boon to manufacturing quality and productivity. SPC supplied the underpinnings of the Six Sigma movement.

The Six Sigma movement began at Motorola in the mid-1980s when the CEO and a team of engineers realized that their product quality was terrible, and they needed to drastically improve to compete with the Japanese. “Six Sigma” is a statistical reference meaning six standard deviations from the process norm. For high quality, process variations from the desired specification need to be at the six sigma range. Six sigma means only 3.4 defects per million. Typically, people think that 99 percent accuracy is good. However, this means that for every one hundred parts you make, you have one that is defective—not a high quality process. Motorola made huge strides in improving quality and reducing costs using Six Sigma, and both GE and Allied Signal jumped on the Six Sigma bandwagon and mandated it throughout their organizations. Of course, during Jack Welch’s tenure, any program at GE was considered a business best practice and adopted wholesale throughout the business community. This time period also saw the rise of “business process reengineering.” The term is credited to Michael Hammer, who with James Champy wrote a book called Reengineering the Corporation, which became a business best seller. They defined process reengineering as “the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance such as cost, quality, services, and speed.” Soon everyone wanted process reengineering.

I joined Gemini Consulting during this process reengineering heyday. One of the unique features of Gemini’s history was that its methods were based on the work of behavioral psychologists. On each of our engagements we spent a great deal of time on “soft skills,” working with our clients on how to build teams, provide coaching and feedback, and run effective meetings. Each consultant was required to learn several of what many of us number-crunchers called “touchy-feely” techniques, including a team brainstorming method, an emotional cycle-of-change model, meeting facilitation interventions, and a process reengineering tool called “brown papers.” Brown papers were called that because we prepared high-level process flowcharts of the existing processes on a large roll of brown butcher paper. Then we invited all those involved in the business process to add their comments on the process using sticky notes and to elaborate on what was broken. These sessions were incredibly cathartic. We billed the method as “high touch and low tech.”

This method was in stark contrast to the Six Sigma statistical basis, and being an engineer by education, I was skeptical. However, the brown papers were effective. Many of the people commenting on the papers worked in different functional areas and never had the opportunity to talk about what was broken. I found that people needed to vent before they could move on, and venting via sticky notes allowed them to air their worst vitriol without getting personal. It was the process that was broken, not the people working it. There was huge value in getting all those people in a room to discuss why they did what they did, how it impacted people elsewhere, and generally understand the problems that others faced. People walked out of the sessions with a much bigger and more human perspective of the process. There was now a face to the hated customer service representative who had to deal with frustrated customers all day long, and there was a person behind the incompetent inventory manager who had the impossible job of working with constantly outdated information. This venting and humanizing process was the first step to getting the team to work together to create something better. Although we usually had assistants create electronic versions of the brown papers to give the clients for reference, I never used them. The flowcharts weren’t the product; the comments were.

After this catharsis, the next step was to get many of the same people in the room and work on the “To Be” process. I was always uncomfortable with this step because it consisted of starting with a blank piece of paper and brainstorming and questioning how to be better. Gemini always required multiple consultants at these types of meetings because you needed someone to expertly facilitate the group and someone to challenge the level of thinking—a process person and a content person. I was the kind of consultant who always liked to have the answer in my pocket, even if I didn’t share it, but the point of this method was to start with a blank slate. Even though I was uncomfortable with it, it always worked. Once, I tried using a structured approach based on desired outcomes, but we found it inhibited our thinking and scrapped it after thirty minutes. Somehow the teams always created a new and improved process. Sometimes it was radically different and sometimes not so much, but whenever we left the client after implementing the new process, we always left a team of people who had formed good relationships and whose job responsibilities included continuous improvement. This simple method was incredibly effective, and Gemini became well-known for process reengineering. We were even on the cover of BusinessWeek.

As we became more successful and the economy dipped into a severe recession, our engagements became larger, and we started our pursuit of business transformation. In our rapid growth phase, our leadership also pushed for more intellectual property, and thought leadership became one of our rated competencies. We wanted to compete with the likes of McKinsey, and to do so, we would need to become more analytical and systematic in our approach. Other companies were developing proprietary methods and tools and using automation, and we looked like amateurs with our brown papers. We started to develop comprehensive methodologies in all our service areas as part of the business transformation strategy. At the same time, we changed the type of people we were recruiting. One of Gemini’s differentiators was that our consultants came from diverse backgrounds, and many came from the industry. Now we were hiring straight out of brand-name business schools like our competitors. We started moving away from the touchy-feely approaches to more analytical tools.

It was on a large transformation engagement where I had my worst consulting experience ever. We had teams of people working at numerous sites to improve the manufacturing and supply chain at a textile manufacturer. Because of the size of the engagement and the promised quick turnaround, each functional area of the supply chain was its own project. Instead of an end-to-end process, we would have to fit the pieces together. I was assigned to a small plant on my own where my task was to reengineer the scheduling function. The situation was very similar to my first client experience—the factory was unable to fill its orders on a timely basis and had lots of angry customers. When the plant was built, the industry had much more demand than supply, and this plant took all the rejected spools of thread from the other sites and respooled the product onto much larger spools that fit on weaving machines. This way the plant could sell initially rejected product to get more revenues. However, the nature of the industry had changed, and the plant was now making lots of customized spools with different sizes, thread counts, and so on. In short, over the years, the product line had become very complex. An initial consulting assessment had promised a vast increase in machine uptime and hence significantly larger throughput. Instead of expensive software to solve the plant’s problems, we were offering process reengineering.

Left to my own devices, I did what I usually do—I toured the facility and interviewed the employees. The problem was pretty obvious. There were about twenty huge spooling machines. On one end, a worker placed about a hundred small spools of thread on spindles and then manually threaded the machine that wound the thread onto the big spools. It often took days for a worker to thread one machine, and some of the runs lasted only a few hours. Many of the machines were idle because they were being threaded or because they had a complicated setup and were waiting for an order with that particular setup. To make matters worse, because the plant was built to repurpose rejected spools, many of the spools of raw material were only partial, and the workers were continually shutting the machines down to restring new thread. To say this was a labor-intensive operation is a huge understatement.

Like the refrigerator manufacturer, this client had sophisticated scheduling software, but its customers frequently changed their orders. The customers served fashion houses, which reserved the right to change their orders on a whim because that’s just how the fashion business is. Demand changes rapidly. Ideally, the client wanted customers to send their orders in monthly so that the schedulers could enter the orders into the software to create an optimized monthly schedule. The schedulers were constantly trying to protect the monthly schedule, while their customers were constantly trying to change it to meet changing demand. This meant the machines were constantly down. At the other sites, where chemicals were poured in one end and thread came out the other, improving maintenance and machine schedules would improve the uptime; however, this was not the case here. The problem was much bigger. It wasn’t the process that was broken; it was the business model. When the plant was built and the product was more expensive, the labor costs were much lower, and only a few types of spools were sold. It made sense to retool the rejected spools into something sellable. In the current world, where the product was more widely available and the margins were much lower, it made little sense. Now every spool cost more to make than it was sold for. Gemini had promised that we could lower the plant’s manufacturing costs by increasing its uptime as if it were a process plant like all the others.

As soon as I understood that improving the scheduling algorithm would have little impact, I called the project manager to tell him the situation. Getting the schedulers and workers together to work on “As Is” brown papers didn’t seem to have much point. The plant had a small staff who were well aware of the problems but were powerless to address them. The problem was with the relationships with the customers—mainly one customer who was responsible for at least half the orders and most of the changes, so we decided that we would visit the customer. I organized a daylong meeting where teams from the client and the customer could start to address the problem together. People from both companies took turns discussing their problems and, in a nonthreatening way, their frustrations with each other. We spent the morning venting and getting to know each other on a professional level. We ate lunch together and started to learn about each other on a personal level. During the lunch, the customer team admitted that sometimes they ordered more than they needed to ensure that they would get enough product. At first, my client was furious that they were trying to optimize phony orders. I chimed in that I’d seen this practice at other companies, and others in the room admitted that this was common. This little confession set the tone for very candid communications.

In the afternoon, I led the teams through a structured brainstorming session, where we developed lots of ideas on how to work together better. After fully immersing ourselves in each others’ problems, we tried to generate ideas that would help both companies. At the end of the day, we left with a list of possible solutions and actions to find out how we could make them work. One of the suggestions was to let the customer schedule some of the machines and take responsibility for determining which orders to fill first, and another was to provide spooling as a service rather than as a product, where the plant would sell the customer the time and labor involved. Then it wouldn’t have to struggle to optimize throughput. We walked away from the meeting with a new understanding and some hope for finding a way to work together better. I was very pleased that we had moved beyond the “blame game” and now had the beginnings of a fruitful relationship.

When I returned to the plant, the project manager had been reassigned, and a whole new consulting team was now working there. Apparently, my alert that I would probably not deliver the promised benefits set a whole chain of events in motion. It was deemed that the challenge was too much for one consultant, and an entire team who had worked at another site was brought in. At this time, Gemini was starting to standardize its service offering and its methodologies. This team had brought tools and solutions from the other sites, and they were going to use them to do a full diagnostic and repair. The first thing that my new manager asked to see was my documentation for the As Is scheduling process. I explained the situation and that I really didn’t see the point in documenting the current scheduling process. He was quite furious with me for going way out of scope and for not following our standardized process. That was why I couldn’t find the benefits. I was directed to immediately stop what I was doing and to create the process flowchart. A little at a loss because I was unable to explain the real problems at the plant, I embarked on the As Is process, which consisted of about four steps: send orders-due reminders to customers, input the orders into state-of-the-art scheduling software at month-end, print an optimized monthly schedule and send it to the floor supervisors, and revise the schedule as new orders arrive. The last step had a loop back into the previous one.

When I showed this to the manager, he was again furious. What kind of documentation was this? Clearly, I was incompetent. He asked another consultant to show me what a scheduling brown paper was supposed to look like and to show me the tools I needed to use to develop the new process. The problem was, these tools and solutions were for simple process plants that had only a few products. This manager had yet to tour the plant or talk with the employees, but already he had the solutions because they had been successful at other plants. I was incredulous at his insistence that if I did the documentation correctly, the problems would be solved. When I was equally as insistent that these tools wouldn’t work, I was asked to leave the project. Normally, this is a consulting career ender, but I already had some other successes under my belt, so I was given another chance. I switched from supply-chain processes to new product development, where I had more leeway to use my judgment. Eventually, it became well-known that that project was a disaster, and the partner who ran it was let go a year later. The manufacturer never realized the promised benefits at that facility, and it was eventually sold. (Are you sensing a trend?)

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.

In a human-created world, most of the problems are created by humans

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 its 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.

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.

It’s hard to optimize a person

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.

The idea behind all this analysis and documentation and charting is that this discipline will uncover the roots of your business problems. However, the best things about human-based problems are that we are self-aware and we can communicate. We can tell you what’s wrong, but you do have to ask. In my experience, for the majority of business problems, at least one person knows exactly what is causing it. If not, partial knowledge of the cause resides in multiple heads, and you need to bring them together to get the full problem. These root cause and problem-solving tools are effective when you bring people together who normally don’t have a chance to communicate with each other. The tools by themselves are pretty useless. Using a tool or a methodology or a piece of software as an excuse to hold a meeting or kick off a cross-functional team is an effective problem-solving method. People like to use tools. That’s how we evolved into a civilization. The caution is thinking that the tool holds the solution and can be effective without bringing the people together, and unfortunately, that’s how many of these methodologies evolve. They start out as people-based techniques, and then someone decides to eliminate the messy human variable. The next thing you know, you have a data- and documentation-heavy methodology that requires an inordinate amount of time for consulting analysts to complete, and if they are lucky, their analyses will stumble upon the right answer. But all that effort could have been used to just ask the people involved and to work on the problem together in a creative and collaborative way. Yet we don’t have time to work on process problems together because we are too busy inputting data, documenting flowcharts, installing software, analyzing data, and creating reports to do any meaningful improvement work.

Documents, reports, and plans are not the real deliverables. As with strategic plans, the value is in the thinking, learning, and creating and not in the resulting paperwork. The document will be obsolete before you print it anyway. Any tool, method, program, or initiative that promises to solve your business problems without including everyone involved in your business problem will fail. Whether it is a software program or change initiative, the only way to improve your operations is to get all your people together to work on them. Then it doesn’t really matter what tool or methodology you choose. Your people are both the problem and the solution.