GIVEN SOME GOOD PEOPLE, THE RIGHT RESOURCES, AND TIME, YOU CAN PROBABLY BUILD A PRETTY good quality program. If you follow some of the recommendations and guidelines discussed in the last chapter, chances are you'll create a program built to add real value to your business, and one that fits well with your business to boot.
But in the field of process improvement, it's important to understand that building the program is just the beginning. When the program is complete, you've achieved a major milestone. And by all rights you should be proud. But the real work is not finished. It's only about to begin. If you've designed your process program the right way, then you've designed it to successfully improve your business. And as is true with most significant factors in the business world, the measure of that improvement—its degree of success—takes time. The term continuous process improvement holds the key. The trick to the success of your program will not come from merely building something good, it will come from using it: using it over time, refining it, making it better and better, and allowing it to become a permanent part of your organization's business approach.
Most quality programs get through their design and construction phases pretty well. Where they begin to falter is typically in the first six months of implementation. There are some general reasons why this is so.
Sometimes those first months of implementation are seen as anticlimactic. The building phase may have been full of enthusiasm and anticipation. A lot of creative energy was probably energetically spent. Then when it comes to rolling out the program—to broadly disseminating it—the daily rhythm of the business routine may take over, dulling the shine of the new initiative and perhaps weighting it down under long-standing day-to-day concerns.
Sometimes the program suffers because of a simple yet all-too-common oversight: the people in the organization were not properly prepped to use it. Training (as discussed in the last chapter) is a critical ingredient in establishing your process program. It's an equally important ingredient in sustaining the effectiveness of your program. Perhaps it's often overlooked because training can easily be perceived as an add-on or extra (supplemental) activity: something nice to have but maybe not essential. But when this is skipped, for whatever reason, you run the risk of alienating your people from the process. If the process appears dense or intense, cumbersome or confusing, irrelevant or irrational, people will not adopt it. They'll ignore it as best they can. They'll implement it in the lightest way possible. That being the situation, even the best of programs will evaporate over time.
Sometimes process programs fall short because the commitment to their success wanes. This is usually a management issue. During the design phase, management may not have truly realized—despite all the floating wisdom—that a process program is primarily a management program. Only in a secondary sense is it a worker tool. And so for it to be successful, management must back the program as an essential business practice.
But what often happens is that program adoption and use is viewed as a down-line responsibility, something that should rightly filter up from the organization, or that once implemented should naturally take hold across work teams. This laissez-faire approach is rarely successful. It communicates an air of indifference. In that kind of atmosphere, no process program can prosper, much less realize its benefits.
And then there are other common problems, all the result either of weak interpretation, misdirection, or speculative inaction. For example, once the program is in place, management might decide that the resources that brought it into the organization can now be directed elsewhere. Or if resistance is encountered (as it always will be to some extent), no official effort is made to mitigate it. And then, as tends to happen in immature organizations, once the heat gets turned up on a project or on a business initiative, the first thing that gets jettisoned over the side is the process program.
In this chapter, I'll discuss some tips and techniques for sustaining process improvement in your organization to avoid the kinds of situations described above. But when it comes to success, there are really no formulas for process program management. And as far as rules go, there are only two:
Use the program.
Follow rule #1.
But the following series of considerations should be helpful to those starting out on a process improvement initiative, and they are points that I have used successfully and have seen used successfully to help root a process program in place so that it stands the best chance of growing to its potential.
In brief, these 12 considerations are as follows:
Remember what you do (and do it well).
Weld business success to program success.
Participate in the life of your program.
Train your people.
Provide performance incentives.
Appreciate the journey.
One of the first things I do when I'm asked to evaluate an organization's process position is to ask the group for its mission statement. Lots of times I get a blank stare. No one really knows what I'm trying to get at. Sometimes I get a suspicious stare. Those people do know what I'm trying to get at, and they know they haven't got it.
What I'm after when I ask for a mission statement is this group's official take on what it is they do, what they are about, what they're here to achieve. That's what you hope to see in a mission statement.[*] And I always look to see if this statement is prominently displayed around the organization.
I recognize the possibility that these kinds of corporate communiqués may be little more than high-touch management mantras, but even so, even when that's all they really are, I do get one thing out of them: the sense that the members of the organization know who they are (or think they know, or at least want to know). And in cases where the mission statements are genuine, when they have been carefully thought out and committed to, I get a whole lot more.
When I am brought in for a process consulting engagement, I always recommend that we begin with a mission statement. If one already exists, we revisit it, even if only to confirm that it is solid. If one does not exist, I recommend that we put one—even a light one—officially into place. The reason is, I think, clear. Your process program, in order to be effective, in order to be sustained over the course of business life, needs to be intricately tied to what your business is all about. And this link needs to be continuously reinforced across your working groups. And the only way to forge this link is to begin by understanding the mission of the organization, by knowing what its purpose is and what contributions it is equipped to make to the larger business mission. Once this is understood, a process program can be forged that will help sustain this mission.
But for every IT shop that has a firm grasp on who it is, I bet there are 10 that have only the vaguest of ideas. It might be something like, "Serve the IT needs of the organization." Or "Deliver high value to customers." But as missions go, those don't go very far. For sustained process improvement, an organization must know what it does. And I don't think that this is a question of "Do what you do best." It's, "Do what you do the best you can." And that's what I want to see established in an IT shop: the understanding of what is required of the group and a commitment to doing it the best they can.
Chapter 3 looked at techniques for establishing a process program in the organization. One of the first considerations we looked at was the importance of planning the shape of the program around the company's overall business objectives. That's important, maybe preeminently important, for a single reason. For any company in any business, the only real path leads to one certain outcome: providing customers with a product or service. If your customers find value in what you bring them, you can be successful. If they don't, success will be hard to find.
That's a basic business principle. But what's often forgotten is the process end of it. Or, rather, the process beginning.
Think of the fact that there's no such thing as a disorganized organization. There are poorly organized organizations, and there are well-organized organizations. And there are many in between. But all operate according to some guiding principle, even if it's only the uncertainty principle. And that shows itself in the production process, in the steps a group takes to move from idea to deliverable. And so process, like it or not—know it or not—ultimately leads to the customer. By experiencing your product, they experience the processes you work by.
Because business will change, customers will change, and products must change, sustained process improvement means evolving process improvement.
The sharpened critical viewpoint, then, appreciates the link between customer satisfaction and process. And so you should periodically reexamine who your customers are. Reach out to them, talk to them. Try to get the feel of what they might be looking for from you.
In the IT world, there is often a wall set up between the shop and the customer. But go through that wall. The keys to how you should evolve your program are ready to be given to you by your customers. There's a real benefit to be gained here: synergy between your shop and your customer base. This is a proactive focus IT managers should be happy to take. It is not complacency that delivers sustained process performance. It's energy.
Knowing your customers, appreciating what they want, and working to ensure they get it may be the best expenditure of energy you can make to keep your process program on track and delivering the kinds of benefits you designed it to deliver.
You'll see later on that the term voice of the customer is big in Six Sigma. The members of ISO have introduced a similar concept into ISO 9001. This focus on the customer is not really a new thing, but it's refreshing that the idea has moved to center stage in the field of process improvement. All too often it's easy to forget about the customer in the routine of daily business. Many times the people who work in technology environments may even feel that the customer is pretty far removed from them. They might feel that what they do has a preordained customer tie, and they have little influence over what those ties might be. Or they may even feel that what they do won't even touch the customer, that it provides only some other tangential function.
But in reality, everything we do should be somehow traceable to satisfying the customer.
That's why it's so important for an IT shop to know who its customers are and what the customers hold to be valuable. If you can string this philosophy through your processes, you'll strengthen the link between your shop and the customer. Just as important, you'll provide an avenue to help your people appreciate their impact on the client. And when people know this—whether the impact be big or small—you'll find that their job direction becomes clearer. And when they can link what they do to what the customer wants, they can link what they do to business success. And when they have a process that they trust to take them both ways, you'll find that the people use the process more, take advantage of its full attributes, and work to improve it.
By knowing what you do, doing it the best way you can, and shaping it to meet the needs of your customer, you'll be able to shape the kind of process program that will deliver sustained benefits over time, one that can grow with your company as it grows.
[*] I know that mission statements can often become window dressing in an organization. They can even become curtains to hide what's behind the window. But I'm taking the more positive approach in my discussion here. I'm going to assume that an organization's mission statement is at least a close proximity to what the organization really thinks its job is, what its values are, and what goals it is built to address.