As I mentioned earlier, this book if not designed as a full treatise on process improvement, ISO, CMMI, or Six Sigma. It is designed to give you a working orientation to what the field is about. What I have found is that people who know they need some kind of quality solution or approach for their organizations want to get a feel for what's involved in such a move. They would like to get a taste of each of the three popular programs they've been hearing so much about so that they can begin to direct more concentrated efforts along focused lines.
But just because you want to implement a quality program in your company (and in my book—this book actually—you should be commended for that), there are real conditions that can derail even the best of intentions. Take a look at what I have found to be the five most potent situations responsible for quality-program disruption. If you're faced with one or more of these, you might want to work with your management to see if you can minimize their impact.
This is probably the most common reason why quality programs fail to take hold in companies. Someone—usually a high-level executive, and usually responding to lagging sales, a falling reputation, or some other pain point—mandates the solution. She may have read about ISO, or CMMI, or Six Sigma, about how these programs have been runaway successes for other companies that adopted them. Maybe she worked somewhere previously that used one of these programs, and she remembers that place working pretty well. Whatever the cause, the executive mandate is made.
I have been consulting in the field of process improvement for about 20 years, and it's amazing to me how many programs get started this way. One major telecommunications infrastructure company brought me in because some distant senior vice president released a directive that the entire 6,000 person IT organization would be ISO 9001:2000 compliant within nine months. In spirit, that may have been an honorable objective, but in reality, it was outrageous. Maybe 60 people of those 6,000 even knew what ISO was. Maybe 20 of those 60 thought it was a good idea. The requirements of 9001:2000 aside, just the basic logistics of moving that mass of people down that kind of change path over such a compressed span of time was in itself just about impossible.
In a smaller organization, it might have been done. I have done just that in smaller organizations. But where I succeeded, an additional dynamic was present: the organization as a whole—large or small—wanted the quality program. That is the biggest success factor with any quality initiative. When you think about it, that makes sense. Any process improvement program is made up of a series of planned activities, and it takes people to carry out those activities. Line workers, supervisors, managers: all have a part in the program's operation. If these people—the heart of any organization—do not have their hearts in the program, the program's in trouble. If you don't believe in something, if you think it's superfluous, if you think it just makes your job more complex or cumbersome, you probably won't do it, or you'll do the barest minimum to get by.
Often with these kinds of mandates, passive resistance is what kills them off. People just ignore the thing. They let it wither on the vine. And because there's no active champion for the program (that senior VP is off solving other problems), it quickly dissipates. Soon, like the amoeba that cannot fossilize, no evidence of it even remains.
Just outside of Arlington, Virginia, there is a large systems-integration company that has been doing business with the U.S. Department of Defense for over 25 years. The company has been very successful. But over the last eight or nine years, senior management had been noticing an emerging DoD trend. The Department is, more and more frequently, requiring that vendors wishing to bid on prime contracts—the multiyear, multimillion dollar contracts—have to be recognized as CMMI Level 3 organizations.
Senior management queried down-line management. How many of these restricted contracts did we have to walk away from last year? The answer came back: nine. Nine contracts worth a total of $412 million. The company had the contacts; it had the experience and the expertise. It even had the political pull. But without the "seal" (as the company considered it), it couldn't even bid.
There was no question of commitment here. Everyone agreed. The company had to be Level 3, and it had to be Level 3 now.
I would guess that 50 percent of my business comes from situations like this. Companies realize that without a recognized quality program in place, their chances of being trusted with large, top-dollar projects dwindle down to, at best, long shots. So there's an economic imperative to transform overnight. Every day in the old way is seen as fiscal degeneration. The problem is that process improvement is not a quick-fix hit. It is not low-hanging fruit. For a program to be designed, documented, rolled out, and used enough so that its benefits begin to emerge—that takes time. How much time depends on many things: the type of program, its scope, the size of the organization, the number of available resources, the range of expertise in-house, and so on. But the bottom-line rule is that you simply can't rush it. By its very nature, process improvement is a long-term commitment. Those who want it now—who want to be it without becoming it—almost invariably sprint down the same dead-end path. They reallocate resources (often inexperienced resources), they may bring in high-end consultants, they establish deadlines they euphemistically label as "aggressive." They then set this uncoordinated machine into motion, cranking out processes for the sake of process, rarely matching them up with identified needs or considering their fit into the culture of the company. After an expanded burst of energy, a program emerges: flowcharts, procedures, policies, forms. But there has been no real foresight guiding the implementation. And so these artifacts are pressed upon teams that are usually pressed already. They are employed halfheartedly. No synchronization methods are in place. The burden of using these unwelcomed processes is exaggerated by their unfamiliarity.
Ironically, the end of this path usually sees an organization worse off than before. Morale has been dealt a blow. Faith in the value of process, if it existed at all, may have been permanently crushed. The quality program sits on a shelf collecting dust. The company's competitive position has not improved.
Insisting that it materialize now may be the surest way to make any quality program vanish.
Not to catch. To fry. In oil. In other words, the organization is in trouble.
There's a well-known marketing story about the Sunkist Company. This was back in the 60s. Sales of Sunkist's boxed prunes had regularly trended slightly upward from year to year, but now they were going nowhere. So management hired the famous advertising consultant Stan Freberg to see if he could help them out of this jam. He took a look at their marketing strategy and saw the problem right away. Sunkist was promoting the product mainly by putting prune recipes on the back of the boxes. Things like prune pies, prune breads, and prune pudding.
Freeman said, in so many words, "Look guys, get rid of the recipes—before anybody's going to go for prune pudding they've got to go for prunes." So he engineered a now classic television spot with a stuffy Englishman noting that the prunes were awfully wrinkled but still awfully good. Maybe they could do something about the wrinkles. The strategy worked. Prune sales were regular again.
Sunkist didn't have a quality problem; it had a marketing problem, and so it's likely that no quality program would have stimulated prune sales. Today, even if an organization does have a quality problem, it might be symptomatic of other more systemic problems. I've seen this often enough that now I look for it at the start of any process improvement engagement. If you're in trouble because for some reason the market doesn't want your product, delay the quality program. Work first to change the product. If your management is at one another's throats, there's every reason the product may be falling apart, but a quality program won't fix it. If your CFO is cooking the books, or your cigarette lighters have a penchant to explode, or you've got the lowest staff retention rate in your industry, maybe it'd better to focus your efforts there.
This is not always an easy call to make. An organization is a dynamic entity. Its parts exist in symbiosis, so cause and effect is not always easy to determine. The point to remember is that a quality program is in place to enhance an organization, to help make it better. But in order for the program to work, the organization as a whole must at least be ready to move down the success path. If your organization is rife with these other factors that impede not only quality but the company's viability as well, you'd be better served by first removing (or minimizing) those obstacles so that your quality program will have the best chance of achieving its goals.
To be blunt, businesses don't exist to produce quality. They don't even exist to produce. They exist to invoice, to bring in money. If they could make money by making nothing, plenty would do so. If they could make money by producing garbage, plenty would do so. (Plenty do do so.) Fortunately the pattern that's emerged is that quality and profitability tend to go hand in hand. The companies that do well tend to do what they do well. But not always.
This past autumn, I advised the board of directors at a young company. The company, Sector Inc., designed software that could prowl the perimeters of any computer network and set off alarms when an approaching intruder was detected. The unique quality of the software was that the alarms would go off before the intruder had breeched any portion of the network. By using heuristic profiles, the software could pinpoint likely intruders and shine a spotlight on them while they were still a safe distance away.[*]
The CEO, Sherrie Kinkaid, wanted to know my thoughts on process programs and the business advantages of implementing quality controls. She had a sincere desire to grow her enterprise as a quality-conscious company from the ground up. After all, the product—even though it was still in an alpha form—was beginning to attract a lot of attention, mainly from major credit card companies, banks, and insurance outfits. So, in her view, quality from the outset was essential.
Two weeks later, she had changed her mind. In the span of six days, her sales people had closed deals with seven major commercial enterprises, all worried about security, all willing to take on this new product even in its early stages. There was no time to create a new quality initiative within the company. All energies had to be focused on getting the product ready for the field—patched in any way that would hold it together.
The venture capitalists were not far behind. They saw a bright future for Sector Inc. That future was one filled with expanded programming teams, enhanced product features, a beefed-up marketing organization, and a speed-to-market philosophy that left little room for anything as esoteric as quality. Finally, $58 million in upfront funding with incentives for a series of three more infusions sealed the deal.
Now Sector Inc. was a solid company. And its product was the best in the industry. The advertising said so. And Sherrie Kinkaid agreed. After all, she had Alexander Hamilton, Thomas Jefferson, Ulysses S. Grant, and Benjamin Franklin to vouch for her.
Companies that are doing well are rarely motivated to initiate process improvement programs or quality initiatives. They tend to equate "doing well" with cash flow. If the money's coming in, why change anything? In my view, that's false security. Many organizations that appear to be firing away on all cylinders are burning fuel at a wasteful rate. Once you got past the new marbled foyer, Sector Inc. was a rodeo on fire. People wore either cowboy hats or fireman hats, galloping off into new directions or putting out fires. Planning was dismal. Rework was constant. The company (and this is an estimate I got simply from internal comment) was spending about 93¢ to earn $1. In the software industry as a whole, that figure should be closer to 61¢. In that sector of the software industry where process is embraced, the figure falls to around 49¢.
The issue is, why believe me? As a process advocate, I can't guarantee those numbers; I can only promise improvement. And it's hard to persuade a company to invest in improvement when things appear to be going according to game plan.
Then there are the companies at the other end of the Sector spectrum. These are the ones with fish to catch. Not fry. Catch. They are those small technology shops that can't afford to turn down any business. They are in it for the money, and in the types of jobs they get, their clients typically don't care about the company's quality initiatives or process improvement goals. They are hired to crank out code. Or test product. Or design solutions. Any way they can do it. Period.
A final major reason why quality programs suffer short lives and then die is because there's no one to control them. Programmers control the keyboard, so code gets generated. Project managers control the schedule, so dates get adjusted. But if no one controls the processes, the processes are going to stagnate.
What many organizations fail to understand is that process improvement requires action on the part of most of the organization—certainly most of the members of the project teams. Instead, they feel that if they can hire a process analyst or two, the program should be able to run itself. That's a point I try to bring up early on in any initiative. A lot of people are going to have to be onboard. They are going to have to get involved. But that's often difficult in today's organizational environment.
A very common trend today is the matrixed environment. Technology organizations here are segmented into functional units, not focused teams. For example, there may be a Project Management Office that farms out project managers to new projects. There may be an Engineering Division that farms out architects and programmers. There may a Creative Services Division that supplies the UI and graphic designers. The same could be true with the technical writers, the testers, and the business analysts. All of these groups report to their own supervisors.
There are valid organizational design reasons for matrix structures. But the structure requires a firmer degree of commitment to a quality program. If your teams are essentially matrixed away from your control, you may find it difficult to negotiate the processes they follow. You may find that they feel no obligation to comply with your methods or to support your procedures. This may be further complicated when there is competition between these stovepipes. As immature as it sounds, managers often choose not to cooperate with fellow managers.
Cooperation, then, is yet another success factor for any process improvement program. As you'll see later on, programs such as ISO 9000, CMMI, and Six Sigma are able to reach across broad areas of organizational structure. Because of this, support of the program will need to come from all corners of the organizations—especially where the corner offices are. That unity is important because any kind of improvement effort requires harmony along three lines: 1) the participants are working toward a shared vision, 2) there is an appreciation among parties as to the value each party brings to the table, and 3) there is a common understanding of what the ultimate destination is and belief in the map that's been designed to get there.
If these elements are missing, the program is at risk to be torn apart from the inside.
So, examine your own organization if:
You've been given a blind mandate to implement a process improvement program, realize you're probably going to have an uphill struggle.
Your organization needs a program so desperately that it will cut corners and shave edges just to bring it in, understand that it may very well fail to live up to expectations.
Your organization is suffering from troubles that come from areas other than product quality, you might want to improve those areas first.
You realize that, ultimately, quality is not a core value in your organization (at least not at this time), maybe you should plan the effort for a later time.
You want a quality program, but management in your organization is not positioned to provide you the backup and cooperation needed for its success, you might decide to scale back its scope or delay the initiative altogether.
[*] I've made the company name up. And the CEO's as well. I'll be doing that again throughout this book. While all of the anecdotes I relate are true, as a practicing process consultant, I am often allowed to look deeper into a company than management would want the general public to see. So I want to stay clear of airing anyone's errors, missteps, or poor decisions. Especially because in many cases I was not privy to all the facts myself. For this reason, then, all names of people and companies mentioned in these chapters—unless specifically noted—have been changed.