Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

A Path of Quality

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Innovation/Chaos Paradox

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Marshal Extra Forces If...

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Moving Forward

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: The Case for Process

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

MANY READERS OF THIS BOOK WILL BE LOOKING INTO THE DISCIPLINE OF PROCESS IMPROVEMENT FOR the first time. But even if this area is new to them, most readers should be pretty much experts in more than one realm of information technology, perhaps programming, project management, or quality control; maybe architecture, design, or implementation; or, still yet, management, strategic planning, or performance analysis. Those kinds of backgrounds are invaluable when it comes to understanding the roles process improvement can play in organizational success. And they are essential for making the case for process improvement.

In fact, if you are what might be called the "typical" reader of this book, you may well understand more about the potential for process in your organization than most. The reason is simple. Process improvement is about improving the way the organization works. When it comes to that work, you're a pro.

Process is not (or should not be) about adopting new "things" blindly and then hoping that those things do whatever it is they're supposed to do. It should not be a series of new practices that represent what the "industry" says you should be doing. That is the antithesis of the process improvement philosophy. Process is about taking your approach to work and formalizing it into a program others can follow.

At its heart, process improvement is about four basic activities:

1. Looking at what you do
2. Focusing in on the things you do well (or want to do well)
3. Setting tools in place to help everyone do it similarly well
4. Keeping an eye open for ways to make that approach better over time

Those four steps are about as basic as you can get, but they bring me to an important point. Your expertise as a programmer, a manager, an analyst—these are all keys to the success of your organization's process improvement efforts. Your knowledge, experience, and insight should be the crucial components that will form the foundation of your improvement program. Without those, the program has nothing to stand on. And in their absence, even the most recognized of programs—like ISO 9001, CMMI, and Six Sigma—are just words on paper.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

An American Success Story

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In a book like this, it can be tempting to focus solely on what's wrong with the technology industry. After all, there are lots of tools we can use to make IT more effective. So why not point out all the holes that need to be filled? Any serious observer would agree that there are lots of things wrong with how we structure, manage, and execute IT in this country. Plenty. But in my view, that's looking at bent nails. It's handy, but it doesn't tell you much that's helpful.

A better view—the more informative view—is to focus on what the industry does right, to remember that American IT is a story of unparalleled success. In the span of only 30 years or so, it has achieved a level of saturation and sophistication no other industry in history can match. In fact, the main reason we are able to spot so many issues with IT is because of its runaway success. It's taken off in all directions. Look at these 2005 numbers:

• Global IT industry spending: $1.3 trillion
• Revenue of the U.S. Software 500: $311 billion
• Number of electronic cash cards in circulation: 40+ million
• Number of MRI scans: 20+ million
• Dollar volume of online shopping: $38.3 billion
• Number of global Internet users: 1,022,863,307
• Number of wireless cell phone subscribers: 194,500,000
• Number of iPods in use: 10+ million
• Number of cities that went berserk at 12:01 a.m., January 1, 2000: 0
• Number of emails you really didn't get that your cohorts insist they sent you: _____

And if a picture is worth a thousand statistics, Figure 2-1 is a great picture for you.

Figure 2-1: Technology is an unparalleled American success story. Not only are cell phones, email, and laptops de facto ways of life, IBM scientists have been able to harness the attractive properties of atoms to line them up in an impressive, albeit tiny, billboard.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Conscious Organization

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All organizations use process. Many times they are not well defined. Many times they are just embedded in the culture. Often they are the wrong processes. Management may not even be aware of what they really are. But if you look closely to see what these processes are, you can learn a lot about what's important to a company.

Process reveals an organization's values, priorities, and preferences. They naturally emerge from the actions an organization employs to see its work through.

I once worked with a software company that regularly, always around release time, scheduled marathon testing and defect-correction sessions: 12-hour days, weekends included. It was an all-hands-on-deck routine. The company's values, priorities, and preferences were just about all focused on market perception and competitive position. But not so much on planning. And less so on its people.

One of the early benefits of implementing a formal process program is that these values begin to visibly emerge. In the example above, management probably would have balked had it been asked to document the marathon sessions as a matter of company policy. I think if they were asked to consciously commit such descriptions to paper, they would have naturally realized that such routines are not very commendable. Weak management can hide behind a lack of formalized process. But when a company is committed to growth—committed to catalyzing its own growth—the visibility of formal process becomes a welcome opportunity.

Many, maybe even most, IT shops are what I would call unconscious. They are not concretely aware of how they do things. They can't describe their mode of operations. They're not conscious of the processes at work within their groups, the procedures that drive them to be who they are. And so, they are not adept at learning from their performances. The organization has no viewpoint from which to watch itself. It has no outer perspective. That makes things tough on management and line workers alike. Environments of this kind tend to be reactive. They tend to be driven by heroes: people who can thrive in chaos. There is a lot of firefighting going on, a lot of backtracking. And there's a dearth of hard information as to how things really are proceeding at the micro level. There's little consensus of status.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Some Number Stories

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Most of the IT managers and executives I know have an intuitive appreciation for process, at least in general. What they most often ask me when I am making the case for them to formalize a process program in their shops is, "What's the return?" They want to know what kind of ROI they can expect from the investment they know they'll have to make. And it's not that they need proof. It's that the people around them—perhaps a CEO or a CFO—are trained to support decisions built around those kinds of concrete terms.

The fact is most of us in the process improvement field can't guarantee an ROI figure. We can anticipate a positive ROI. We know how to shape a program to generate an ROI. But each IT shop is different. Each has its own focus, its own culture, its own specialties, its own distinct customer base. All those variables make it tough to predict an ROI.

Most of this chapter will focus on what I call the qualitative benefits of process. And by qualitative, I don't mean "soft." Power steering gives you better control of an automobile, but how much more over manual depends on the driver. Likewise, process can give you better control over projects. That's a safe assumption. How much depends on what you build.

John Brodman once conducted an empirical study of the qualitative traits of process improvement and noted that many soft benefits were often overlooked. These included improved morale by the developers, less need for overtime, smoother day-to-day operations and communications, and increased respect from the customer base (Brodman 1995).

But I do appreciate the need to link process with hard improvement data. The best way I know to do this is by reference. Let's take a look at some companies that have made the commitment to process improvement, studied what they were doing, and then reported their results.

I think the best understanding to take away from these brief cases is that process improvement does have a track history of delivering tangible benefits. And these benefits have a very strong potential to deliver impressive returns for the organization that undertakes the effort seriously.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Six Common Myths

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The way to manage technology business more effectively is to define what it is the business does. Once you have defined that, you can begin to operate the business based on that definition. And once you begin to move down that path, you begin to know the path, and you can start to refine the shape of the path. That is the basis for nearly all process improvement initiatives. It seems logical, even intuitive. So why is it that management will often steer away from implanting process, from adopting process improvement as a goal?

The reason could be that management is often not educated as to what process is about. Or they may have been exposed to only poor examples of the discipline in the past. They may have preconceived notions of what process demands or what process requires, and these may not match up well with what it's really all about. Dealing with this, I've noticed six myths that are pretty common to the field of process improvement. They are often identified as reasons why people don't want to bother with process.

Let's take a brief look at the six.

There's a company in South Carolina that is one of the nation's largest processors of Medicare health claims. I'll call them MetaCare. Annually, they pay out about $20 billion. They have an impressive corporate campus, a solid service reputation, and—for these days—an amazingly low staff turnover rate.

They also serve a very mature and stabilized industry. The management and processing of Medicare claims depends more on compliance with established regulations than on innovation. The company contacted me about helping them develop an internal process program for their IT groups. But what I noticed when I got there was that they already had a program. It just wasn't highly visible to them. The program was embedded in the contracts they won from Centralized Medicare Services. These contracts dictated how projects would be run, what service levels were expected, how changes would be managed, what communication channels would be honored, who could do this, who could do that. You can probably understand that. A federal agency that is going to hand you the combination to $20-something billion in tax funds is wise to attach some strings.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Benefits of Process

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The word "quality" means different things to different people. For some, it's a sign of endurance. For others, it's a measure of innovation. But just about everyone agrees that, in the end, the concept of quality has to do with expectations, usually the expectations of the customer.

When you build something that performs in a way the customer wants or needs, you'll typically be credited with delivering quality. If you miss the mark—no matter how well put-together the thing is—its quality quotient will come into question. In the business of technology, then, it's important that organizations arrive at a definition of quality. The value in this bit of advice becomes clear when you think about process.

Process is about inputs and outputs. It is a way to shape inputs in order to generate desired outputs. In any production system, the ultimate output is a viable product. "Quality" then will be imbedded in the thing you've created. And so any process is dependent on first understanding what the output has to be.

The phrase "quality culture" describes an organization that has designed the pattern of its activities to deliver a product (or service) that carries within it the corporate definition of quality. Very few IT organizations would admit to having a weak understanding of what their customers want. And even fewer would admit to having no real way of getting there. But more than a few studies indicate that definitions of quality and the production processes that help ensure quality are absent in many, many IT shops.

Many American technology companies have been slow to embrace quality cultures. I think I know the reasons why; it's a blend of issues. When I have sat with CIOs and other senior IT managers, I hear pretty much a common theme. They listen politely to me and then say, "That's great, James. We really see the value in that. But right now we've got other priorities to wrangle with. This just isn't a good time for us." What can you say to that? If management is focused on pressing issues outside this realm, there's probably little that will change that focus somewhere else. The best follow-up may be to schedule another visit.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

• The American IT business is a $350 billion annual enterprise. Yet every year IT failures negatively impact that figure by $60 billion.
• The business of American IT is not technology; it's business. American IT shops should run their business like a business.
• There are many myths that hinder organizations from adopting process. Among these are that process is too heavy, process will cramp their style, and process is just another flavor of the month.
• Any production environment requires some degree of order and sequence. IT shops are no different. Process is a way to help order the work of technology development.
• There are real benefits to implementing process. Some of these are operational stability, organizational identity, cost reduction, and quality assurance.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Establishing Your Process Program

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

ISO 9001:2000, THE CAPABILITY MATURITY MODEL INTEGRATION, AND SIX SIGMA ARE NOT REALLY process programs, though many people think of them in that way. The better description is to say they are frameworks you can use to create your process program. ISO, CMMI, and Six Sigma wrap a series of practices, areas of focus, and methods into an approach that can support definition, control, and improvement of your technology projects. They are a great foundation, taken alone or in combination with one another. But creating a process program—a big one or a small one—is an effort that requires more than adopting a model or a standard. It requires customization. In fact, one could say it is an effort that relies on customization.

Successful process programs are typically ones that have been carefully tailored to the needs of an organization. They are based on the way the organization works—or knows how it should work. And they capitalize on what it is the organization does well. It may be tempting at times to introduce something "fresh" from the outside, something that may look to hold the promise of addressing many of the issues the IT shops deals with. That may help, but real success rarely lies in something outside the organization. A tool like Photoshop might help someone be a better artist, but it probably won't make them a good artist to begin with. It's the same with ISO 9001, CMMI, and Six Sigma. You can use these tools to make your process program as effective as it can be, but you'll need to set the right foundation in place. If you haven't even tailored your program to specialties of your shop, even the most promising of programs will rattle and roll.

In this chapter, I'll look at some tips and techniques you can use to help establish a process program in your organization, one that fits well with what your shop is and what it does.

I'll look at a series of recommendations that you can use to right-size a process program. Here's a brief up-front look at what I'll cover:

Building through executive sponsorship

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using IDEAL

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The ideas that drive introducing process are pretty standard. People want to help make the workplace more predictable, help it become more stable, shape it for better control—in short, help the environment as a whole focus on its potential. And so it's a good idea to follow something of a predictable path when you want to establish a process program: a method that will help shape the program as smoothly as possible, in an orderly and manageable way. One approach to this can be found in the IDEAL model: Initiate, Diagnose, Establish, Act, and Learn. IDEAL is a general approach to process improvement. You may find it helpful as an approach to your own process efforts. Let's take a look at IDEAL.

IDEAL can be thought of as an umbrella philosophy covering process improvement. In many ways IDEAL is a formulation of the famous Plan-Do-Act-Check mantra. IDEAL isn't a process itself; it's a model designed to help you manage your process management activities. Here is a brief breakdown of how IDEAL is structured (see Figure 3-1).

Figure 3-1: The concept of IDEAL is to Initiate, Diagnose, Establish, Act, and Learn. Its circular nature has an important implication. The process is ongoing. Process improvement programs are long-term commitments to evaluation and measurement.

An important aspect to IDEAL is its shape. It is circular, and the meaning of that shape is clear: you cycle through a series of activities, and when you close out the last step, you repeat, either in the same area for continuous improvement or in new areas for fresh improvement. Just about any improvement program can be managed following the concepts of IDEAL. Let's look at each phase of IDEAL:

Phase 1: Initiate

This first stage is one of realization, decision, and then dedication. In the Initiate phase, an organization typically reaches the understanding that it has operational issues that need to be addressed. This realization is often predicated by some symptomatic imbalance within the organization: falling sales, rising costs, increased complaints, low morale, or even the appreciation for general improvement, for strengthening the organization's current position. It can be many things, but it's always a trigger for action.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Establishing Executive Sponsorship

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Establishing executive sponsorship is an activity that is typically cited as a key success factor in the fields of process improvement and quality management. It is specially emphasized in ISO 9001:2000, the Capability Maturity Model Integration, and Six Sigma. These kinds of programs thrive when the broad workforce adopts them and backs them up, but they can only get to that point through a top-down organizational commitment.

Most corporate and IT initiatives work through executive sponsorship. The team that's charged with selecting a new automated test tool will usually answer to some type of sponsor. Committees put together to explore new market potentials or new product lines will usually operate through the guidance of a sponsor. The people who help promote the annual blood drive do so with the help of an executive sponsor. If there's a need for a special effort, if it's going to cost money, if it's going to require dedicated resources, the company will probably want to manage that, and that is typically done by appointing an executive sponsor. The same holds true for process improvement programs.

The executive sponsor is the arm of management that steps up to the plate to shepherd the program into the organization, to give the program the backing and the visibility it needs, and to intervene when necessary to make sure that the program's design and implementation activities are progressing along acceptable lines.

You could make a logical argument that those responsibilities could be handled by someone less senior in the organization. And, logically, that might be right. But the appointment of an executive to the job adds an element of clout that's hard to replicate in any other way. So when you begin down the path of process improvement, ensure that you have executive sponsorship on your side.

Executive sponsorship works best when the executive occupies a position of deep authority in the company. The sponsor should probably not occupy a block on the org chart that has a crowded view of the sky. If you are able to influence this decision, try to promote sponsorship at as high a level as you can communicate. Seek out a sponsor with broad authority, a track record with the IT group, and an ability to bring off strategic initiatives. Capable, empowered sponsorship is essential for three clear (but often unappreciated) reasons:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Aligning with Business Objectives

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Another good, early consideration when you're working to establish a process program is to align the initiative up front with the organization's business objectives. This may seem obvious, maybe even a given, yet it's one that can be easily overlooked. There can be a number of reasons for this. Often the champions that are striving to create the program simply assume that any process will further the business goals. Likewise, management may assume that the team chartered with program development is naturally keyed into the strategic business objectives.

But for an improvement program to be successful, it must not only fit the organization well, it must serve the organization well. It should be designed so that it finds its natural place in the order of the business. To do that, you should work with management to consciously tie the program to the company's business objectives.

And to do that, it's helpful to understand where the organization stands in terms of its strategic and tactical performance goals. You can use this positioning to derive the high-level process needs of the organization and then shape an approach to address these needs. Two activities are helpful here:

1. Elicit the business objectives of your organization.
2. Use these to shape the goals and scope of your process program.

Most successful process improvement programs share at least one thing in common: their processes are aligned with the business objectives of the organization. Business objectives—explicit, conscientiously designed, and carefully articulated—are a key component to how any organization operates. Business objectives define the organization. Your IT shop (whether it's a group, a department, or a division) exists with a specific purpose. It has a defined job, and the outcome of that job should promote the goals of the IT organization as a whole. The business objectives encapsulate this purpose. These business objectives then should serve as the foundation of the process program you create.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Identifying Improvement Opportunities

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you're new to process improvement, or if you're creating a new program for your organization, remember that the discipline of process improvement promotes the idea of starting small and growing over time. You don't have to tackle every opportunity at once. There's wisdom in carefully targeting your first improvement steps, shaping a program around those, implementing them, and then, as they take hold in the company, adding to them over time.

Naturally, the scope and push of your initiative will depend on multiple factors: management expectations, your current process position, and the resources made available to you.

But as you begin to identify improvement opportunities, keep these three considerations in mind:

1. Capitalize on your strengths.
2. Understand what you want to do better.
3. Target improvement opportunities with promise.

People are often tempted to move into process improvement with an eraser in one hand and a new pen in the other. They feel an obligation to start everyone off on a clean slate, with a fresh start. That's not usually the best approach, at least not for an organization that's been around for a while. A better place to start is to look at what your organization does well. Process initiatives can easily focus solely on the problems that trouble an IT shop. But it's important to remember that what the shop does well is really the best place to start on a program.

There are three reasons for this:

• First, the organization already understands those things that it does well. Somehow, no matter what the reason, those effective and beneficial activities have taken hold in the company. Your job might be as straightforward as documenting what these activities are and how they usually progress in your shop. By documenting these, you capture the best practices for new members while formalizing the behavior across your working groups.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Establishing the Process Team

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You may need a process team to help carry out your initiative. Or you may not. It all depends on the scope of your program, on what you're trying to achieve. In this section, I'll present a generic look at what you might typically see in a traditional process team. You can establish the process improvement team by either appointing people within the organization or hiring from the outside. But either way, the job of the process team will (in general) encompass a threefold responsibility:

• Interact with organizational stakeholders to shape a set of processes and procedures into a formal process program.
• Set the program into place within the organization.
• Monitor its long-term use throughout the organization.

All three of these are important jobs. They'll require that you put together a team composed of people with the process management skills required to get the jobs done and who have the ability to work together as an effective team.

Because I'm presenting the considerations in this chapter sequentially, you might be wondering about a slight chicken-or-egg question at this point. The activities I've described earlier may benefit from the use of a team. On the other hand, you may not find need for a team until your organization is further along into the process. For some organizations, it may not be until more work is completed that you'll know the scope of you program and therefore the kinds of people you'll need long-term on your team. On the other hand, if you don't bring someone onboard earlier, you may not have resources to apply to the original design and scoping.

The point is to not take the sequencing a rule. Rather, use the descriptions I provide of the team as a way to understand what kinds of people you may require to further your initiative, and then make a judgment as to when is the best time to bring them onboard.

When it comes to putting the team together, there are not a lot of fixed rules. In the field of process improvement, there are no specialized titles you must represent on the team. There is no set team size. There is no single proven structure. The size, makeup, and structure of your team is going to depend on several very qualitative traits, including the scope of your quality program, the resources that have been allocated to the team, and the current process maturity of your shop. There are, however, some guidelines you might follow.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Choose Your Model (or Not)

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

"Choose your model" means now is a good time to select one of the existing process models (preferably one of the proven ones) upon which you can structure the process program you're about to build. For most people in the field of technology development, this means ISO 9001:2000, Capability Maturity Model Integration, or Six Sigma. In coming activities, you and your team members are going to begin looking at the organization from a process design perspective: looking at what process areas to address, deciding what process components to build, and choosing how to build them. If you know a model that will work for you, you'll want to begin tailoring your decisions to that framework so that it and what you build will fit well together. That's the gist of "Choose your model."

Of course, you don't have to choose a process model at all. You don't need to look at ISO, CMMI, Six Sigma, or any of the others in order to create a good process program for your shop. You might decide to create a purely customized process approach, one you build based solely on internal parameters. If that's the course you'd like to go with, go right ahead.

I don't mean that facetiously. I am a firm believer in the three programs I present in this book, and I am a vocal advocate of their use in technology shops of all kinds. But I'm also the first to say that a big part of process success comes from the program's ability to serve your organization well. And if a purely custom approach gets you there, then you've met the spirit of process improvement embedded in ISO, CMMI, and Six Sigma.

Most people working in process improvement today, usually working on highly visible process initiatives, are likely to draw on one of these three established models. But there's a Fire-Ready-Aim issue here I'd like to mention here, and it comes not with how the choice is made, but rather when it's made.

Choosing a process model can be the step where many people begin their process programs. I attend a lot of trade shows, seminars, and symposiums on quality management and process improvement, and invariably I'm approached by someone who says, "We know we need a program, but we're torn between Six Sigma and ISO 9000. Which one do you think is right for us?" Or, "Our systems managers say CMMI is the right way to go, but we've got a couple people in-house now who have already used ISO at previous jobs. So doesn't it make sense to go with a known quantity?" I also hear this, "The CIO says we have to be CMMI Level 2 by next year or no performance bonuses."

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Developing Process Program Components

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This step represents the bulk of the work you'll undertake in creating your quality program. As its name suggests, this cycle is an iterative process. But it begins with a period of extended observation, questioning, and knowledge acquisition. The objective here is to learn the business. You and your team will be working to build standards, processes, and procedures to improve the business, but this can't be undertaken in a vacuum. You need to first learn how activities are being conducted, delve as deeply as you can into the rationale behind the activities, and then evaluate them for improvement opportunities.

I find that a SWOT analysis is usually helpful here. SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. Just about any business strategy, situation, or activity can benefit from a SWOT analysis. In this case, you and your team look for what strengths lay in the current processes—that is, what is working well in terms of management, accountability, and control. Next you identify what appears to be working less well: what might be only partially fulfilling its purpose, what might be lacking structure, what might be missing altogether. Then you can analyze these strengths and weaknesses. You look and determine where you see potential opportunities for improvement. This may become clear with weaknesses, but bear in mind that you can make improvements to strengths, too. It's helpful to list these opportunities, and even prioritize them a number of ways: perhaps by difficulty or effort, perhaps by business criticality, maybe by organizational impact.

Once you have identified opportunities for improvement, you can then assign threats. You can think of a threat as a potential cost to the organization should the opportunity not be addressed. There can be all kinds of threats: internal and external. Some inside threats might be impaired communications, risk of data loss, misalignment, increased costs, or extended correction time. External threats might be regulatory fines, potential loss of market share, or reduced customer satisfaction.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Training

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the phase shown previously, you and your team took the time to create an initial version of your process program. Because you did this through tight interaction with the partner groups, you should all share something of a common understanding of the program. This understanding is good, but it's probably not enough to ensure smooth, wide use of the program. In the next phase, you are actually going to run the program through a pilot, and pretty soon, you're going to roll out the program to the whole enterprise. And so it's very important that you think about providing some degree of training and education in the use of the program. If you have been working on a finely targeted program with a small group of support players, then your training needs may be somewhat contained. If you have been working on a large program, with many contributing groups, you will undoubtedly face a larger training challenge.

But be careful not to skimp on training. The lack of training may well be one of the chief reasons process programs fail. It's not that people don't want to follow the program; it may be that they don't know how to follow the program. To figure it out on their own may seem like too much extra work. That's why adequate training is so important. It gives people the background and the tools they need to use a new program. And it gives them a chance to become familiar with the program and with how it will impact, and hopefully improve, their jobs.

The success of your process program will rest largely on the relationship your people have with it along three lines:

• Understanding
• Accessibility
• Comfort

First of all, your people are going to have to understand the program. They are going to need to know its contents, appreciate what parts apply to them, and understand how to use these parts. Next they are going to need direct and unfettered accessibility to the program. This aids understanding. Especially in the early stages, people will be moving through your process components a lot, finding their way through tools and forms, learning where things are, and establishing paths of common access. For this reason, accessibility needs to be focused on ease and speed. If you put up barriers to getting to the program, you'll quickly find that people stop trying to get there. The final trait is comfort. There's a parallel relationship between the success of your process program and the degree of comfort your people have with it. The more comfortable they are with the program, the more they will take advantage of it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Program Rollout

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The activities you have engaged in so far (and I have certainly condensed them here) have brought you to the point of having a quality management system in place, backed up by a supporting process program. You have entered into the project with executive support and have chartered a process team. You have focused your efforts along very distinct lines, and then you and your team have built a program with the active help of the people who will ultimately use it. Then you piloted the program and fine-tuned it based on the results of the pilot. Now you are ready to roll out the program into the day-to-day business of the organization.

Program rollout is not so much about sprinting out of the blocks as it is about preparing the organization to move with you. To do this, you need to make sure you have a sound implementation plan in place. The implementation plan is a roadmap you can use to integrate the process program into the company's way of doing business. Such a plan typically includes the following:

• A description of the scope and contents of the process program
• An identification of the impacted groups and managers the program will touch
• An identification of any additional training or coaching set into place to support the rollout
• A description of the support team (the process team) that will shepherd rollout activities
• A schedule for the rollout of program components across the groups
• A description of process support materials available to the groups
• A description of the milestones and target dates used to define a successful rollout

As early as a draft is available, the implementation plan should be reviewed by executive management, by the partner groups, and by any potentially impacted parties. The plan is a significant change agent within the organization and thus needs the blessing of all these groups.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Institutionalization

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A final consideration to think through for your process program is institutionalization. Institutionalization is a word you'll encounter a lot in the field of process improvement. The word implies a way of conduct that becomes firmly ingrained in the culture of the organization. Institutionalization is the hallmark of organizational commitment. It is the ultimate goal of any quality management program.

Naturally, institutionalization takes time. It is not an automatic process. And it can be a temptation, sometimes after a series of initial successes, to announce "mission accomplished." A quality program, however, needs the continued and ongoing focus of management. It should be seen as one of the foundations on which the company operates.

Institutionalization may be the hardest implementation step to accomplish, simply because it does take time and there's no checkered flag to let you know when you've gotten there. But once you've achieved this mark, your program will be integrated within the whole organization, able to function at peak efficiency.

It's your people who will accomplish the work of institutionalization. And in the next chapter, we'll look at some techniques and tips you can use to support your process program and to help it take hold in your organization. But the focus shouldn't veer too far from your people.

In fact, you might want to take a look at who you'll be turning the program over to once you have it designed, in place, and ready to use. More than likely, it will be one or more managers in the organization. The approach used to nurture the program once it's been deployed will have a large impact on how well and how soon the program becomes institutionalized.

Let's look at five general categories of the kinds of managers usually called on to institutionalize a process program.

This type of person represents the least effective way to institutionalize a process program. We've probably all seen examples of the Blind Victor through the course of our careers. These types are initiative-driven. They need a specific project with a specific shape to it in order to feel that they are being productive. They are called "blind" because they cannot see beyond the initiative. To them, the project is everything. They are tactical, go-do-it types. They are not as good at strategic thinking or long-term forecasting. And they are called "victors" because their myopia causes them to declare victory as soon as the final project deliverable materializes. Blind Victors often lack the ability to appreciate the depth of organizational change, are unable to appreciate the need to shore up an initiative with support, or simply lack the capability to appreciate the multifaceted aspects of change.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Helpful Change Agent Skills

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Process improvement at its most fundamental is about organizational change. And the application and management of change, as a major consideration in the business world, is more essential than ever. Today, technologies and technological capabilities are evolving at such a rapid, pervasive rate that businesses, even those not labeled as technology companies, have to continually deal with the choices, challenges, and strategy shifts that constant change brings. The considerations that revolve around change management have been pressed to stay up with the speed of the change in business environments. Change management and change agency are now more than ever seen as strategic considerations in many companies. And since process improvement begins with change, the same considerations might well be recognized when you begin such an initiative.

As with all change, when you begin to introduce process into a group, you may face varying degrees of resistance, frustration, insecurity, doubt—a host of reactions. To help minimize these and make the way smoother for your program's acceptance and adoption, here are some tips to help you usher in change.

Effective change management begins with professional readiness. Whenever you introduce something new into an organization, it is, by default, unproven and so it is usually open to wide scrutiny. In the technology field, where the "latest and greatest" is all too often overhyped, this can be especially true. And so you should not move prematurely to introduce your new process program. It's important to make sure that it is professionally ready to go. That's not to say it has to be perfect from the outset (no one should expect it to be). But it does need to be in a solid state, ready to be used to the extent it was purposed for.

To begin, it's important to check that your program components are in place, that they are complete (even in an early form), and that they are well-organized. These components will likely be the first elements that the various groups experience about your program. So they need to show that they have been carefully considered, and from a presentation perspective, they should appear polished. Resist sending them out into the world if the components are incomplete, if they might appear to look thrown together, or if they contain errors or omissions (even slight ones) that might confuse users or give the impression they have yet to be finalized.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Summary

Content preview·Buy PDF of this chapter|