No Great Leaps Forward?

I have noticed an interesting pattern in some business process improvement efforts. It is a pattern of failure, but it also reveals a path to more frequent successes. Before stating the pattern and its implications, let me use a couple of hypothetical cases to illustrate it.


Steve Mc Menamin

Case 1: An infrastructure construction and maintenance organization. This 3,000-person unit of a large regional firm wanted to improve the effectiveness and efficiency of the way they plan, design, schedule and track the work required to build and maintain their extensive and widely-distributed infrastructure facilities. Prior to this effort, the organization was a fairly primitive user of technology. They had basic supply chain automation, and very rudimentary back-end systems to record work performed. But most of the field-based employees worked with paper, whiteboards, phones, and radios. The field transactions were entered into the back-end systems after the fact by legions of clerical personnel. Yes, this is a style of automation typical of the 1970s and early 1980s, but the case in question happened in 1990s. The organization was slow to change, but had finally decided to upgrade their business processes and use of technology to state-of-the art. A major process-and-system improvement effort was chartered and funded.

Case 2: A rapidly-growing, globally-distributed 1,000-person software development organization. Because the firm had been growing rapidly for most of a decade, their efforts had been focused on meeting customer demand, rather than on improving their internal processes. Consequently, some of their engineering teams continued to work in a relatively informal manner. While requirements were defined and reviewed within local development organizations, there were no strong overall architectural processes. Developers enjoyed great autonomy, both within teams, and across product lines. The organization now realized that it had to introduce a variety of company-wide planning, design, tracking and QA processes to enable it to continue its robust growth into the future. A variety of coordinated initiatives were launched to upgrade the software development processes throughout the organization.

Now, let's talk about the pattern. Observers of organizational behavior in many fields have long noted that process effectiveness and sophistication varies widely among organizations. In the field of software development, the SEI's Capability Maturity Model is one expression of various levels of process sophistication. The CMM includes the assertion that improving organizations tend to evolve from one CMM level to the next higher level over time. (For this discussion, I am setting aside the prescriptive aspects of the CMM; I am citing it only as model of observed behavior.) A few minutes with Google will reveal other models of evolving process sophistication in many fields: supply chain management, heath care, financial services, manufacturing, etc.

The two cases I described above share a pattern that is made up of two parts: First, both organizations had experienced a delay in what might otherwise had been the normal improvement of their business processes. In Case 1, it was due to the essentially conservative, change-averse culture of the firm. In Case 2, it was due to the distractions of coping with rapid growth and expansion. For entirely different reasons, both firms had fallen behind in process evolution. The second part of the pattern is that both firms launched ambitious improvement efforts to make up for lost time by implementing "best practices."

The underlying pattern is the "Get Well Quick" mega-project. Its key characteristic is that it is designed to enable the organization to skip one or more stages of process evolution. In Case 1, a truly primitive organization attempted, in one wave of automation, to move from 1970s-era batch back-end systems fronted by green-screen data entry and inquiry all the way to fully distributed RF-based in-vehicle automation in a near-paperless environment. Not only would the basic transactions of business be fully automated, but all of the business process measurement functions would be performed through state-of-the-art control systems to be operated by managers who heretofore had barely used e-mail. In Case 2, a set of small, autonomous development teams whose processes can only be characterized as CMM Level 1 proposed to convert over a period of a year or so to a single, integrated team operating at CMM Level 3 or better.

These examples are only illustrations of the Get Well Quick pattern. Don't get too focused on these cases in particular. I have seen more than a few GWQ crusades over the past twenty-five years, and very few have succeeded, though to be fair some of them are still in progress. Nevertheless, I have concluded that the GWQ pattern is so effective a predictor of project failure that such efforts should be avoided at all costs.

Why do GWQ projects fail so reliably? I do not pretend to know. My current hunch is this: For such an effort to succeed, you need at least 75-80% of the people up, running and successful from the start, or overall business process performance will suffer intolerably. You can't aim at the average, and there is not enough time for a steep learning curve. Expecting to bring nearly all of your target population up two or more levels of process evolution in one great leap does not appear to be realistic.

Please note two areas that are not the problem:

  • It is not the technology. I recall fondly the days when I thought the tough problems were technical problems. In large-scale improvement efforts, the tough problems are nearly all sociological or political.
  • It is not the front-line workers. Front-line and entry-level workers (not always the same thing) are generally flexible and adaptable (unlike managers and supervisors). They mainly want to know how to succeed. If you can explain the rationale for a change, and make clear to them how to succeed with it, they will do so.

So if GWQ projects are doomed, why do we still do them? Again, I am not sure, but these three factors, at the very least, play a part:

  1. It's not always obvious how much of a leap forward you are attempting. You need to make a cold-eyed assessment of the current state of the organization's practice. This will not be easy, as most organizations are proud and defensive. You also need to determine, work group by work group, including all levels of management, how much change will be imposed by the proposed improvement effort.
  2. It's just plain embarrassing to propose improving to anything less that the most modern processes. Organizations frequently want assurance that whatever improvement effort you are proposing will last them a very long time. It's sometimes difficult to persuade your sponsors to undertake an expensive and difficult process upgrade in the full knowledge that they will have to do so again in 2-5 years in order to take the next step in business process evolution.
  3. Too many suppliers and consultants are only interested in pitching the latest and greatest technology, whether your organization is ready for it or not.

In the face of these factors, it takes courage and skill not to fall into the GWQ trap. But it's worth it, because it may be your only path to success.

    — Steve McMenamin