Process Improvement Essentials

Chapter 1. Introduction

A FEW YEARS AGO, I ATTENDED AN IBM RATIONAL UNIFIED PROCESS TRADE SHOW, HELD AT A CONVENTION center somewhere just outside Dallas. The center was a sprawling complex—hotels, restaurants, convention halls—anchored by an enormous indoor arboretum, a five-story glass-domed cathedral landscaped with palmetto and live oak, featuring, on its west wall, an exact replica of the Alamo, only at about twice the size.

Naturally it was a Disneyland-clean version of the Alamo. And the stone pathways, trickling canals, and set-aside grottos were all exquisitely manicured to reflect a kind of comfortable glow balanced between true life and cartoon. The theme of the show was something like, “Achieving Your Quality Goals.” As I looked around, I knew this place was the perfect choice for that. Whoever had taken on this landscape project had not let up until every blade of grass had been trimmed to shape, oiled green, and shellacked properly into place.

This was Wednesday evening, after the show’s opening, and the sponsors were hosting a huge cocktail reception in this arboretum. So after an afternoon of moving in and out of sessions and giving a brief talk on tailoring CMMI to organizational size, I found myself in a packed crowd in front of the Alamo, standing just under St. Jerome, at the best bar in the place. That’s where Scott Brenner introduced himself.^[*]

Scott was a senior IT director for a major health-claims processing company, one of the largest in the nation, and he wanted my thoughts on how he might improve the way his people managed IT projects. It seems that he and the company had had a “pretty rough” year last year getting his folks marching along productive lines. Scott didn’t know a lot about process improvement, but his company used a lot of the Rational products and, given his role in the organization, management thought he’d be a good choice to send out into the field to collect some ideas. We chatted for a few minutes about the size of the organization, how it was structured, and what kinds of work its people engaged in. From Scott’s answers, it seemed like a pretty typical Fortune 100-type shop. Then I asked him if he had any ideas about what specifically he might want to improve.

“I guess,” he said, “it’d be our drop rate.”

I’d never heard of that. “What’s a drop rate?”

“That’s the return revenue we lose when our systems misapply or misdirect a payment claim.”

I liked that. That was a tangible metric. And I liked the fact that Scott seemed to have a handle on it. This seemed like a pretty good start toward a meaningful improvement target.

“Do you know what your drop rate was last year,” I asked.

Scott took a club soda from the bartender. “Maybe three hundred million.”

I knew I heard him right because the shooting didn’t start until just after that. In fact, I’m pretty sure the “three hundred million” may have been what started it. But whatever it was, Santa Anna’s men were suddenly swarming all around us, musket balls whizzing through the air, the glint of fixed bayonets throwing off slivers of hard light. I could sense The Defenders somewhere above us, stalwart shadows moving against the wash of cannon smoke, firing bravely over the crest of the chapel. And here we were, right out front. How did we manage this? Had they forgotten us? Could we ever hope to make the wall? Or were we lost? Were we doomed? Was it all a futile...

“James?”

I blinked. Scott was back in front of me, making a slight gesture with his club soda. The ice clinked against the glass.

“Right,” I said. “Absolutely. Project management. Yeah. Well, there are certainly things. Several things, actually. And things for drop rates....” And I can’t really remember what else I said. But I’m reasonably sure it made little contribution to the industry’s overall body of knowledge. I was stuck on that $300 million figure. To me, that’s a fantastic amount of money to misapply or misdirect. And to make things more fantastic, I knew this company. I owned its stock. A good bit of it actually. And I hadn’t heard of any such debacle. Not in the papers. Not from the analysts. In fact, when I checked later, I found that for that “pretty rough” year he was talking about, the stock had actually gone up two percent.

I knew this kind of thing happened, but I had never been this close to it happening in such a big way. Another technological pothole—this one about the size of the Astrodome—cloistered behind the walls of American IT.

As a rule, corporations like to keep their troubles quiet. They prefer to keep their problems from showing up on the street. It can be embarrassing. And it takes a lot of explanation to a lot of people who probably aren’t prepared to appreciate that these things happen. Nobody’s perfect. Defects happen.

Meat packers and car manufacturers probably have it the worst. The defects that enter their products are often miniscule in size: a bit of bacteria here, a missing shim there. And so they can be hard to spot. Often it’s not until the consumers themselves stumble on it (a case of food poisoning, a crushed bumper) that the problem emerges. When that kind of failure goes public, an organization will scramble to locate the source of the problem. The company will divert all kinds of energy to tracking down the problem’s cause and determining how much of the defective product got out. The course of last resort—when the milk’s really been spilt—is usually to set a recall into action. Take your ground beef back to the supermarket; return to your dealership. Recalls are usually massive undertakings, and they can cost millions and millions of dollars. But by the time the error’s in the public eye, the company has no real choice. Public failure is always expensive.

But sometimes it’s also purging.

Take the Chevrolet Venture for example. This popular minivan ran into something of a quality problem in the late 1990s. At issue was the questionable design of its passenger seat latch. The company received data that indicated maybe the latch had an operational defect. After some study, Chevrolet determined that a general recall of the 1997 Venture was in order. Here is an excerpt from the text of that recall notice: “RECALL NOTICE (1997 Chevrolet Venture): Passenger’s fingers could be severed by latch mechanism that moves seat fore and aft (Consumer Reports 2005).”

Now, as a general rule, severed fingers should not be a part of anyone’s driving experience. What manufacturer would want that picture etched into the brand image of their minivans? Chevrolet no doubt brought its forces to bear. That latch was probably redesigned and remanufactured against the highest standards, with inordinate attention to detail: test after test, exhausting verification runs, complete assurance of unquestionable integrity. It wouldn’t surprise me if that latch today—almost 10 years later—stands as the world-class epitome of efficiency and safety in seat latch technology.

That same call to quality came to poultry processor Pilgrim’s Pride in April of 2002. In the largest meat recall in U.S. history, the company pulled back 27.4 million pounds of cooked sandwich meat after internal tests came back positive for potential listeria contamination. The discovery followed outbreaks of listeria in eight Northeast states that caused at least 120 illnesses.

Pilgrim’s Pride, with encouragement from the FDA, left no tile unturned in its quest to remove even an amoeba’s chance of impurities finding home in its food sources. There was simply too much riding on the outcome. Today, the company has one of the most stringent processes for meat inspection, meat processing, and meat packing in its industry.

Chevrolet and Pilgrim’s Pride are both companies with established reputations. They have not grown to who they are by ignoring issues of product integrity, product performance, and quality. However, the complex nature of their businesses means things will not always go as planned. But with each misstep comes improvement: things get better, and then a little better. In these cases, the companies followed, but the public led. The public, when it’s all said and done, may be the most effective quality-control system anyone could have.

That brings us to one focus of this book: performance improvement in technology companies.

No one screamed at Scott Brenner’s company, because no one outside knew about the fault points of its claims systems.

From my experience, technology industries—corporate software, systems development, and operations—have been somewhat immune from the cleansing light of public failure. It’s common in this industry that users—used to less-than-perfect technology products—will often put up with buggy software. They learn to work around the problems or to find substitute solutions while the issues are being fixed.

Most of the major missteps that occur on technology projects are discovered long before the end product ever sees real-world deployment. People internal to the organization observe that the new payroll system is printing security-sensitive data on checks. State taxes are being calculated at erroneous rates. Systems slow down to a crawl when new functionality is plugged in. The lights go out. Maybe we should back up a step.

In a way, that’s fortunate: some of these potentially disastrous production problems are avoided. But by another way of thinking, it might also be unfortunate. When a project goes up in smoke, no one outside a core group may learn the details. These failures—often by publicly held companies—are all too often discreetly swept under the rug, or quietly navigated back to the starting gate with a no-harm-no-foul attitude. Often millions of dollars have been spent by the time the plug is pulled. Millions of dollars down the drain, with little to show for it.

And then there are the potentially disastrous production problems that do get through. Some folks might say, “Sure, but we aren’t talking road safety here, or botulism.” But given the prevalence of technology today, we just might be. Anyway, the issues certainly belong in the same ballpark.

The general feeling, as I have gathered it firsthand in the technology field, is that these miscalculations, false starts, and first shots are simply part of the cost of doing business. These situations (I have seen my share of them) are often further rationalized with a slew of caveats: we were never given the right resources, the timeline was always unrealistic, the specs were never clear. And because many corporate managers outside of IT assume that what goes on inside IT must be techno-mystery, the level of questioning that might penetrate these veils is seldom undertaken.

As a consultant, I have seen this happen in big ways and in small ways at MCI/WorldCom, Home Depot, GTE, Public Health Software Systems, ALLTEL, and many others. Ten years ago, the Standish Group released what is now famously known as “The Chaos Report.” This was a study of software projects undertaken by Fortune 500 companies—the big players in the game. The results showed that the average project managed by these guys ran 222 percent over schedule and 189 percent over budget, with over 30 percent of planned functionality missing in the final product. Those were 1994 figures. About three years ago, Standish updated its Chaos Study, and though the numbers had improved somewhat, the deficits were still considerable.

I doubt there was a public recall in the bunch.

A Path of Quality

Of course the fault does not lie solely within corporate IT. Those numbers just cited are symptoms of multiple conditions: constrained resources, disconnected business objectives, changing market forces, new statutory and regulatory climates, finicky boards, and so on. But while that might help explain the result, it doesn’t change the result. If that’s the sea IT must sail on, it’s better to adapt practices to make the sailing as smooth as possible.

The point I’d like to put forward here is that the poor technology performance that produces unusable software, severely compromised systems, or delayed business objectives has a real corporate cost no matter how often it is resettled into new projects or new initiatives. The failures may go away, but their impacts don’t.

Today, technology has become too much a part of overall corporate success for its effectiveness to be left to chance. The stakes are too high. Fortunately, more and more companies are beginning to embrace this idea. The idea of “quality management” is being reinvigorated. Recognized and proven quality programs, such as ISO 9001:2000, the Capability Maturity Model, and Six Sigma, are rising in popularity. More and more technology managers are looking for ways to help remove degrees of risk and uncertainty from their business equations, and to introduce methods of predictability that better ensure success. But before I move into that topic, let’s look at why it’s even relevant. Let’s look briefly at how the worlds of business and technology can no longer be considered separate, or complementary. They are not even two sides of the same coin. They are the same side of a one-sided coin.

The Innovation/Chaos Paradox

Today’s IT is big business for sure.

According to the Gartner Group’s Worldwide IT spending report of 2004, the amount of money being funneled into this field will grow 5.5 percent a year for 2006, 2007, and 2008 until it reaches nearly $3 trillion. Gartner Dataquest’s Software Support Portfolio Review looked at current revenues for the worldwide software support services market. That market alone is worth $52.3 billion.

Those numbers tend to separate IT from the business operations they support. That’s simply a convenient separation. Today’s IT is the business. IT has become woven into the fabric of every business transaction. Remove cell phones from the picture today, and what adjustments would businesses have to make? Take away email. Take away word processors. What would become of the deal?

People in technology—the people who plan, design, develop, install, maintain, monitor—are as key as any other component to the success of business enterprises. And at the macro level, the success story stands out. But the focus of the discussions in this book is not on the macro level but on the micro level. To begin focusing toward that point, I’ll take a step back.

Data processing has been around in American business since the late 1950s. The computers then weren’t what we would recognize today as powerful. But by the early 1970s, these machines had become entrenched as core business tools. They were especially big in transaction-intensive industries. Banks, insurance companies, utilities, and reservation systems all found computing to be an effective way to process and manage mountains of data. Data-processing centers back then were somewhat removed from the daily bustle of the business. They were set off in climate-controlled rooms, set on raised floors. Access to these resources was strictly controlled. And those people who did have their fingers on terminal keyboards or worked the centers were either highly trained engineers or mathematicians, or they were working along rigidly codified lines. And the tool set was quite small: MVS, tape storage, COBOL and JCL, dumb terminals. These were the ubiquitous elements of just about any data center. And even though things did not always run as they should have, the centralization helped in the management of any problems that did crop up.

That was 30-plus years ago. Things began to change in the late 70s and early 80s, with the introduction of the personal computer and the runaway success of microtechnology. In fact, by 1990, data processing was gone. Information processing had replaced it. Walk into any American company today, and PCs are everywhere, bounded by mini and midrange systems. More than that, software is everywhere. And nearly everyone is using all this technology, using it everyday, automatically, without giving it so much as a thought. We now operate in the field of Information Technology Management. What are we managing?

We’re managing servers and server farms, networks, routers, gateways, databases, spreadsheets, security profiles, email, word processors. And the developmental tool sets now available have grown so diverse as to be almost impossible to keep up with. What was en vogue seven years ago is passé today. The pace of change in IT is relentless. Innovation has become a fixed characteristic of this discipline, and that has pushed it more and more away from the bounds of discipline.

Back in the 70s, maybe a handful of people in an organization were devoted to data management. Today, everyone has a voice in it. The capabilities have become so flexible that applications have the potential to be cranked out in incredibly short spans of time. The process-centric approach that was required to manage a data shop in 1975 has been displaced through innovation. I am not a programmer, but using a tool like Microsoft Access, I can build a database system that tracks project risks, and I can have a working prototype of it ready to look at before lunchtime. That innovation has shaped a technology field that many describe as weakly linked, reactive rather than proactive, and poorly focused. DataQuest reports that 70 percent of today’s IT workers are between 22 and 37 years old. The average length of experience is 11 years. All those people—talented as they probably are—were raised in environments of click, fast, flash, and cash.

So that’s how it is. What’s the answer? Do we return to glass-walled rooms? I don’t know anyone who would advocate that. But the paradox lies not with the click or the fast or the flash. It lies with the cash. We’ve already mentioned the size of the IT industry: trillions of dollars as a single enterprise. And most of that money is public money, channeled into companies through stockholders, through investors. Most of them know nothing about how the dollars allocated to IT are being spent. On top of that, I have seen that even top management has little clue as to how well those dollars are being spent. The core issue is that the dollars are in all likelihood being spent less than efficiently, with little control, with little insight into best practice, with little knowledge of crossover or hidden failures.

Philip Crosby, one of the leading process improvement pioneers, says in his famous book Quality Is Free (McGraw-Hill) that it’s cheaper to do things right the first time, that it always costs more to have to go back and fix something. And process improvement is all about getting it right the first time.

The theme I want to put forward in this book is that process—the process that was born with this industry—can make a difference in today’s technology organizations. The thoughtful implementation of a considered process improvement program can help a technology shop operate more effectively, with increased focus, with reduced waste, with a better bead on its mission and the overall goals of the company.

More and more IT managers are adopting this mode of thought. I am not a John crying in the wilderness. Today a renewed interest in management through process has arisen. In the last decade, process programs have become more and more prevalent. And out of all the available options, three have moved to the top of the chain. These three are as follows:

• The 9001:2000 Quality Management Standard from the International Organization for Standardization

• The Capability Maturity Model Integration from the Software Engineering Institute

• Six Sigma, a methodology for improvement shaped by companies such as Motorola, Honeywell, and General Electric

These programs are not esoteric philosophies; they are not whiteboard theories. They offer practical, tangible guidelines. And they aren’t fads either. Over time, each has proven itself in measurable, quantitative ways. They have been shown to visibility open the production process, to heighten management effectiveness—not through increased control but through commonly designed and measured controls. And, ultimately, they have been shown to increase the quality of the products you produce, not only external products (those you ship) but internal products as well.

Marshal Extra Forces If...

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.

Someone Somewhere Upstairs Said Do It

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.

You Want It Now—Tomorrow at the Latest

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.

You Have Bigger Fish to Fry

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.

It’s Just About the Money

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.

Your Teams Are Matrixed Away

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.

Moving Forward

Every day we can see how process helps businesses build business. Successful banks balance their portfolios of risky loans and secured loans using proven processes, ones that mitigate risk, provide for flexibility, and, in the end, average out in the plus column. Builders of tract homes rely on what they call “packages”: highly reliable inventories of what goes into entry and mid-priced houses. The Big Mac you get at a McDonald’s in Knoxville tastes exactly like the one you’d get in San Diego. That’s because McDonald’s has worked out a stable process for putting Big Macs together. You can purchase a Dodge Neon—a machine that consists of over 12,000 integrated components—for under $12,000 and expect to drive it for over 100,000 miles. Daimler Chrysler has meticulously engineered a detailed process that can bring those 12,000 components together in a highly predictable way.

Process works. And process can work in your technology organization, too. You’ll find that with process—even light, malleable process—your planning becomes more accurate, your estimates are more dependable, and your expectations tend to remain aligned with those of your client. There are many other benefits in implementing process, and I’ll take a look at these in Chapter 2.

You have taken a smart step in moving forward. The processes contained in programs like ISO 9001:2000, CMMI, and Six Sigma are proven to deliver distinct benefits, whether you’re designing software, integrating systems, building components, or architecting solutions. Acquiring a good, beginning understanding of process improvement and of these three widely recognized programs will help you establish a process program in your organization that moves you toward your goals of quality, predictability, efficiency, and success.

Summary

• The business of IT has evolved to mesh more and more closely with business itself. Today IT supports the business more than it ever has before.

• Corporate IT shops are annually accountable for billions of dollars in spending, shaping projects that will guide the futures of many companies. Yet many struggle to embrace or implement basic project and process controls.

• The use of process—shaped to the needs of the organization—can raise accountability, increase efficiencies, and improve quality.

• This book presents a primer in topics on process improvement by looking at fundamentals of process programs, then presenting overviews of the ISO 9001:2000 Standard, the Capability Maturity Model Integration, and Six Sigma.

---

^[*] The name has been changed. Throughout this book, I’ll be citing stories and case histories that illustrate many facets of process improvement. Most of the names and companies I cite are real. You’ll probably recognize them. But when an event might be embarrassing or the individuals involved have specifically requested I not use real names, I use pseudonyms. The details, however, are all as accurate as I know them to be.

^[*] 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.