Process Improvement: Sole Survivor: Finding that First Opportunity

This series of Columns is for the BPM expert who has set up shop as a sole practitioner inside a company.  It may be that the organization is brand-new to BPM and this is an experimental venture, or perhaps there is simply not enough money to staff up just yet.  In any case, you are largely on your own. So if you are not handed an opportunity to apply BPM and start to make a difference, how do you get started?  Where does that first opportunity come from?  That`s the focus of this article.

Finding Problems that Can Become Opportunities

In the first Column in this series, we pointed out that the best first step is to adopt an improvement methodology and then find an opportunity to apply it as soon as possible.  The theory is that the sooner you can make a practical difference, the faster you gain visibility and credibility. But having said that, how do you find that opportunity, especially if nobody is knocking on your door and asking for help?

Perhaps you have heard the cliché:  “Every problem is an opportunity”.  Because that`s the answer in short, you look for problems—important ones, urgent ones, frustrating ones—and choose the most promising as your focus.  Allow me to use my own past experience for an illustration:

My first experiences as an internal improvement consultant were at Motorola in the early 1980`s, when the notions of BPM and improving business processes were unknown.  I was involved with Geary Rummler and others at the corporate level in building and piloting the company`s first process improvement methodology and then was transferred to the Phoenix area where the company had dozens of semi-conductor factories and support organizations, all fertile for applying this fledgling approach, or so we hoped.  But my initial attempts at trying to find willing clients were difficult.  I was selling a solution for problems nobody could see or wanted to solve. But gradually I learned how to gain attention to my offering—by finding the problems it could address.

There are lots of ways to uncover organizational problems—by combing through reports, talking to potential clients, observing work, interviewing line workers, and so on.  But eventually I discovered the prime ground for both identifying worthy problems and selling my solution:

Throughout Motorola there was a phenomenon called the monthly ops review.  Every organization of reasonable size held a monthly all-hands meeting in which its results were presented and updates were made on a variety of issues, projects, and the like.  These were not staff meetings—the ops reviews were open to the public, anybody could attend—and they were deliberately staggered at any given site so that people could attend multiple ops reviews if they wished.  So I did exactly that:  I attended as many ops reviews as possible, in rapid succession, attempting to gain a comprehensive understanding of the overriding issues plaguing multiple groups.  I would listen for the repeated themes, the problems that nobody seemed to have a solution for solving, the issues that got the most attention from top leadership.

These monthly events were often brutal affairs.  Middle managers had to stand up to explain and defend their results to audiences that were often hostile, challenging, even downright mean.  Sometimes the most biting comments were made by the bystanders, people who were just sitting in but allowed to have their opinions heard.

As the head of the training and improvement group, I also had to make presentations at these reviews and so I experienced this trial by fire many times.  And I began to realize that the monthly ops reviews were more than just meetings—they were an enactment of the organizational culture in its rawest form.   Careers could be made or destroyed at these events.  They were the single most important happening for the business, the single most significant place to see and be seen.

And so I targeted the monthly ops reviews as the forum where I could find opportunities and to enlist support for addressing them.  You may not anything similar to these events in your own organization–in some places, meetings are all programmed, tightly controlled and artificial.  But somewhere, in some setting, the organization is at its most authentic, where the important decisions are made and the culture is at its most visible.  And that`s where you want to be.

Finding Allies

Once you find an opportunity, where do you go next?  I found that it is important at this point to find someone else who cares about the issue you have discovered, or somebody who can be made to care about it.  To illustrate, let`s continue the Motorola story:

At one monthly ops review, I noticed an extraordinary number of change notices reported by one division`s process engineering group.  I knew virtually nothing about the nature of the changes but it simply stuck me as awfully disruptive to have dozens of technical changes being processed in a single month.

So I followed up by interviewing a couple people in the engineering organization and they sent me to a young engineer, Brad, who managed the change notices.  Sure enough, the volume of monthly changes was swamping the organization and the engineer was desperate to find some way to stop the madness.  This conversation led to a discussion about what was being changed, which turned out to be the manufacturing process specifications, a set of documents that directed how every task, no matter how small, was to be performed on the manufacturing line.  It turned out there were more than 1000 “specs”, many of which were being revised almost constantly, hence the huge number of change notices.  And many of the specs themselves were mammoth—dozens of pages of dense text in excruciating detail.  Brad knew the situation was bad but had never had the nerve to say so publicly, so I volunteered to do it for him, at the next monthly ops review.

At that meeting I waited for the right moment, then suggested that the high error rates in this manufacturing area might have something to do with the sheer volume, complexity and instability of the specs.  My comments were met with hostility, to put it mildly, and out of the corner of my eye I could see Brad turning white.  He did not back me up as I was being eviscerated and treated like a spy, but I didn`t expect him to.  The initial attempt at getting support for the specs issue didn`t succeed—but it opened the door to trying again.

Take a Different Angle

Brad and I soon found another way to raise the issue, this time with resounding impact.  Motorola was putting a lot of money and effort into literacy training for manufacturing employees, and my training department was part of that effort.  We had hired a local adult literacy organization, Merex, to develop and teach remedial reading and math classes and the results were positive.  On the other hand, the error rates were still high and dissatisfaction with employee understanding and morale were not great.  So I gave some of the manufacturing specs to the Merex folks and asked them to assess the reading grade level of those documents.  It turned out they often were written at a grade level 15 or even higher (in other words, college or even graduate level).  So many of these specs were being written by Ph.D. engineers for Ph.D. engineers, but not for the line production people who had to follow them to do their jobs.  So perhaps the so-called literacy problem was at least partly a readability problem. Now Brad and I had our issue properly linked to another issue that had broad popular support.

Back to the next monthly ops review, and this time they listened, which led to bringing the Merex people into the factory to work with engineers on cleaning up and simplifying their manufacturing specifications.  A large number of specs were found to be unnecessary or repetitive, and were simply eliminated.  The remainder were rewritten to make them as readable and usable as possible.  The reading grade level now averaged grades 8-10 and the massive amounts of impenetrable text were slimmed down radically and supported by photos, models, line drawings, process maps and other visual devices.  This approach was first used on one factory line and then eventually was applied to all of the 20-some fabrication sites in Phoenix and Austin that employed about 50,000 people.   The improvements in quality and reductions in cost and time were contributors to Motorola`s winning the Malcolm Baldrige Award. And there were secondary systemic effects on many activities inside the factories, including how specs were written, rolled out and controlled (the change notices dropped drastically) and how production workers were trained and supported on the line.

Summary

So what can you take away from this long-ago story about getting started as a BPM practitioner?  For me there were several lessons I was able to apply in other organizations over the years, including:

  • Get in the door – Don`t expect that what you have to offer will be instantly understandable and desired by those who could benefit.  Sitting back and waiting for business can lead to nothing.  You have to get out there and find a way to discover what`s important to your clients and get in on the conversation.
  • Link your solution to client problems – The opportunity I discovered at Motorola was viewed as a documentation cum literacy problem, not as process improvement, although many of the work processes were altered in the course of changing the specs.  But that didn`t matter—the reductions in errors, cost and time were still saleable as improvement, regardless of label.
  • Keep digging – Over the years I have found that the “received” problem is rarely the real problem.  The change notices were a symptom of systemic problems that needed to be uncovered and addressed.  So don`t start and end with the problem as first described to you.
  • Find an ally, and do them a favor – Somebody likely owns a problem that is unsolvable without help.  If you can bring attention and support to their nightmare, you will have a permanent ally.  Going before the knife-sharpeners at the monthly ops review was risky to me but what a payback eventually.
  • Don`t quit too early – If you have found a golden opportunity, a problem with real reward if you can solve it, don`t just quit if you encounter resistance.  Problems in organizations persist because they are imbedded in daily practices.  It often takes an outside-in viewpoint to change the understanding of what is going on before you can enlist support for fixing a problem.  That outsider`s viewpoint is what you can bring to the party.
Alan Ramias

Alan Ramias

Alan Ramias is a Partner of the Performance Design Lab (PDL). He has had twenty-five years of experience in performance improvement and organization effectiveness. Alan was employed by Motorola for ten years as an internal consultant on organizational performance. As a member of the team that founded Motorola University, he was the first person to introduce Geary Rummler's pioneering concepts in process improvement and management to business units within Motorola. Alan advocated and led several of the first groundbreaking projects in process improvement that evolved to the invention of six sigma and Motorola's winning of the first Malcolm Baldrige Award in 1988. Alan was also involved in major restructuring projects at Motorola, and in job design work, compensation planning, workplace literacy, and educational program development. After joining The Rummler-Brache Group in 1991, Alan led major successful performance improvement engagements within Fortune 500 companies. His experience spanned several industries and the full spectrum of corporate functions and processes, such as strategic planning, manufacturing, product development, financial management, and supply chain. Major clients included Shell, Hewlett-Packard, 3M, Citibank, Motorola, Steelcase, Citgo, Hermann Miller, Louisiana-Pacific, and Bank One. After leading many high-profile projects, he became a partner and Managing Director of Consulting Services at RBG. He led development of much of RBG's products and services, and was responsible for selecting, training and mentoring RBG's consultant teams. Upon leaving RBG, Alan founded his own consulting company, where he continued to practice in the field of performance consulting. He was also involved in several organizational restructuring initiatives in the U.S. and in Asia. Alan can be reached at aramias@ThePDLab.com.
Share

Speak Your Mind

*

Share
Share