Section 7.4. Define

7.4. Define

The D in DMAIC is for define. For any process improvement initiative, you must first decide what you are going to do, why you are doing it, how you'll get it done, and what results you'll hope to achieve. Six Sigma places special emphasis on these definition activities. This is because Six Sigma doesn't want you to engage in process improvement just for the sake of process improvement. The understanding behind the program is that tinkering with process is serious business, and so you should not take it lightly. Businesses run on processes. Products and services are released through processes. Company success is based on processes. So what you do to your processes is going to make a difference, one way or another.

If there is a central idea behind this first step, it is to pick wisely. Choose an issue that will make a demonstrable difference in the company's ability to achieve its goals. Look for opportunities to tangibly affect efficiencies, to drive out costs, or to eliminate waste. Look for change that will alter what you produce in ways your customers will notice. A good place to begin is to define what it is that probably should change.

Figure 7-3 illustrates the define phase of DMAIC.

Figure 7-3. In the define phase of DMAIC, the objective is to shape the Six Sigma program so that it can be executed in an orderly fashion, with an empirical focus based on data control. This involves defining the problem to be addressed, shaping the scope of the project, defining the goal to be accomplished, setting functional boundaries in place, and then developing a detailed project plan that will be used to govern the project.

7.4.1. Define the Problem

Lyndon Johnson once said that the tough thing about being a leader isn't doing the right thing. It's knowing what the right thing is. The same could be said of this step in Six Sigma. For your process improvement efforts to be successful, they need to be focused on a targeted problem. In terms of the definition stage, this may be the most important element you'll identify. What do you want to improve?

How you approach this tactical alignment will naturally depend upon the size, shape, and culture of your IT organization. But there are three broad categories of "improvement management" that may be used to help you pinpoint what you'd like your teams to work on:

"It's broke. Fix it." category

This is the easy one. If you have a process or activity that is essential to your business and it's falling apart all over the place, then that will probably stand out readily in everyone's minds as a necessary improvement target. The word improvement here naturally indicates major work, given the degree of failure that so strongly stands out. In most circumstances where Six Sigma is applied, you'll probably find that the obvious targetsthose that scream at you for actionare (thankfully) few and far between. Six Sigma works best, and is most appropriate, when you want to continue making incremental improvements to existing processes performing to a known level of efficiency.

"Opportunity target" category

We've seen earlier that Six Sigma's approach to process improvement is based on data-driven decision making. That is, the organization collects information and measurements over time, analyzes this data, and then uses the results to point to practical and viable improvement opportunities. In these kinds of organizations, you'll typically find that Process Action Teams maintain a queue of improvement opportunities already somewhat defined. In ongoing continuous improvement environments, the teams will methodically manage the queue, adding new items as they emerge in the organization, sorting and prioritizing existing items, and selecting items in the queue to begin work on. Here opportunities already exist. By managing them in an active queue, you and your teams can select the targets you deem ripe for improvement actions.

"Listen up" category

This may be the easiest way to define the problem you want to address. It's easy because you basically have no choice. Management steps in one day and says "Listen uphere is what we are going to work on." No analysis required on your part. No sorting, no prioritization. Bingo, there it is. The "listen up" category of problem or target identification usually springs from executive initiatives or strategic directives that address high-level organizational objectives. In some cases, the assignment will make perfect sense to the process teams. In others, the rationale or logic may seem a little vague; the teams may not be cued in to what criteria drove the choice. But, whatever form it takes, it's an avenue that often introduces improvement opportunities into your domain.

When you are able to define the problem, you are in a position to begin defining how you will address the problem and how you will manage work surrounding a solutions approach.

7.4.2. Define the Project

Once you've defined the problem or the issue or the target you want to address, you are, for all practical purposes, ready to begin a project. I put this step in early on in the cycle of definition activities, but it can occur in many places. Some organizations like to do a lot more analysis and refinement of the idea before developing a plan (see the following two sections). Others prefer to begin with a simple, executive-level plan, get that approved, and then move into more in-depth planning. Whatever approach your organization takes, the basic activity of developing a sound project plan still stands.

When you read about ISO 9001:2000, you saw how that Standard strongly emphasizes the need for planning. You saw the same attribute with CMMI. Planning is essential to the success of any process program. It's essential to the success of any process environment. When you begin a new Six Sigma effort, you should give the concept of project planning the same degree of focus. The following sections address some items you might consider including in such a plan.

7.4.2.1. Define the mission statement

The plan you develop will be used for three purposes: it will serve as the chief tracking device for managing project resources and team activities, it will serve as a communication and status mechanism to inform management of project progress, and it will serve a similar function in keeping customers and stakeholders up-to-date on how the project is going. And soto aid all three of these purposesit's useful to develop the mission statement for the project. The mission statement will usually describe the problem or opportunity to be addressed, the goals that the organization hopes to achieve from the effort, and the business benefits that can be realized when these goals are met.

The mission of the project should quickly become common knowledge in the organization and among the various working teams. But having it ever-present in the plan serves as a good reminder as to the scope of the work. And it can help reinforce resource and team energies in the event of change requests and shifting business dynamics.

7.4.2.2. Establish executive sponsorship

All business activities require the sponsorship of management. Often this sponsorship is implied. A better path is to make it explicit. So in your Six Sigma project plan, it's useful to identify the branch of the company that will serve as the official sponsor. In the realm of Six Sigma, this sponsor is often referred to as the "champion." That's a good term for the role, but it's not a necessary one. Call the role whatever you and the sponsor would like.

By identifying who the sponsor is in your plan, you help establish organizational support for the project. You can do this by including an organization chart that ties your project to a branch of the organization. You can provide a simple narrative description of the reporting chain for the project. You can include a table of relevant stakeholders, indicating the chain of command there. Once that sponsorship is in the plan, the plan can be seen as representing an official activity, not just for you and your teams but for the whole company as well.

7.4.2.3. Develop the project charter

A project charter is a useful management tool in the same way that an org chart is a useful tool or a departmental charter is a useful tool. An organization is usually made up of a collection of permanent departments. The departmental charters describe the job of each department within the overall company: what roles will be filled and how the department interacts and supports others. The org chart shows the relationships among all departments in an organization. The charters and the org charts are a way to define a new company or to link an existing company together.

It's the same way with projects. Projects are pretty much like company departments. Only they usually aren't as permanent. Like departments, they exist for a particular purpose. They require specific job roles. And they interact with other organizational units in specific ways. That's why it's helpful to set up a charter for your Six Sigma project. The charter, in a subtle way, can make the project "real" in an organization.

The charter will usually describe the objectives of the project, define the roles required for the team and the responsibilities of each role, detail how the chain of command will be structured, and describe what the project's operational scope and reach will be.

7.4.2.4. Define the team and resources

Defining the project and the charter are good steps to solidifying what it is you are going to accomplish with this Six Sigma initiative. But you won't get far without a team and the right resources to get the work done. This may seem like an obvious point, but I have always been surprised to see it handled very poorly (or casually) in some organizations. What happens in these kinds of initiatives is that everyone agrees that there is a problem to be solved, that attention needs to be focused on it. But when it comes time for the rubber to hit the road, people are reticent to commit resources in a specific way. They may give lip service to the idea. They may even casually indicate that so-and-so could help out (usually during "down time"). When resource assignment is handled this way, you can just about bet that the project will hit major snags. People will get pulled away from the work when other "more pressing" needs appear. Tools and facilities won't be available when needed. Things won't happen.

That's why early on you should explicitly define who the team is, what members of the organization are going to fill the roles described in the charter, and what level of allocation will be required of each. This should be followed up with specific communications to these team members so they are informed firsthand of their involvement. Likewise with resources: the tools, facilities, and availabilities you'll need all need to be clearly spelled out.

Any process improvement project, whether its Six Sigma, CMMI, ISO or any other type, is ultimately the work of a team. And a team is a collection of people. Identify the right people, get them committed to the project, ensure that they'll have the right resources, and you'll go a long way to making your project a success.

7.4.3. Define the Goal

Defining the problem and defining the project will help us establish the scope of the Six Sigma initiative. We understand what it is we'll look at and how we will approach what it is we might want to modify. Another important attribute we should define is the goal. What is it we want to achieve?

This activity has a special meaning in the domain of Six Sigma. We have seen earlier that all activities should be planed to fall in line with the Voice of the Customer: what we know the customer wants, what we believe the customer needs. It is the Voice of the Customer that drives everything about Six Sigma. The goal we want to achieve, then, should have a direct and tangible link to the customer. If it doesn't, what we are seeking to do might end up being irrelevant to the company. If what we modify, tweak, or adjust doesn't make the product more appealing to the customer, then there was probably little real impetus to do it. We should care about what we know the customer cares about. When we define the goal, we should think in terms of reaching an objective that will help make a difference to the customer.

7.4.3.1. Identify the (real) customer

The goal we are after should always be a goal our customers would want us to achieve. That's why it's important when we are setting goals for a Six Sigma project that we take time to identify who the customer really is. This can be tricky in large organizations. The people in marketing might think the customer is one person, while the people in engineering might be thinking of someone else. Management might have yet another view. I routinely encounter this issue in technology shops. IT managers think the customers are the business managers who fund their services; those are the people they want to make happy. The business analysts think the customers are the people who will ultimately use the applications they help design; they think the focus should be on the users. The technical architects think the real customers are the people in the data centers; since they have to operate and maintain the systems, architects think those are the folks who should receive the majority of consideration.

If you define the real customer as the person having the closest relationship to your product, then you could make a case for any of the groups mentioned previously. I don't have an easy solution to this business dilemma. And, though it will likely add a degree of complexity, you may be smart to think of all of them as the real customer, each with their own set of expectations, requirements, and influences.

I work with an associate, John Porzio, whose wife Kelli is managing a DMAIC project at the hospital where she works. Her mission is to improve Operating Room utilization. For this project, an unbooked OR equals waste, a booked OR that cancelled inappropriately is a defect, and so on. And in this case, her customers are clearly defined too: they are the hospital administrators charged with keeping the place fiscally efficient. It is their view of quality that Kelli will structure her project around.

7.4.3.2. Define Critical-to-Quality issues

The Six Sigma acronym CTQ stands for Critical to Quality. CTQs are issues, elements, traits, features, benefits, or other product attributes that your customer perceives as being essential to quality. For a pizza shop, one CTQ might be on-time delivery. Another might be order accuracy. A third might be delivery temperature. So far in this activity, we have defined the problem to be addressed, we have defined the project we'll use to address it, and we've defined the goal we want to achieve. As we begin to identify the Critical-to-Quality issues, we want to remember to stick with those that are relevant to the problem at hand. If the problem we want to address is on-time delivery, then we want to focus on issues critical to the quality of on-time delivery. This might include things like store location mapping, phone call routing, and delivery time estimation. But it wouldn't necessarily deal with things like oven temperatures or box insulation. Those issues can indeed be CTQs, but they probably belong in the domain of delivery temperature. They are out of the scope of our current focus.

CTQs are not issues you should dream up on your own. You can, of course. But then they become your Critical-to-Quality issues, not your customers'. CTQs should be collected over time, through interaction with your customer base. They should provide an open channel of communication that allows for the free exchange of information. A good organization will seek out this communication. By learning what it is your customer would like to see made better in your current product or designed into your next generation of products, you can identify what your improvement goals should be. And you can do so in ways that are tangible, actionable, and greatly assured to increase customer satisfaction.

7.4.3.3. Establish a definition of quality

At this point, you are ready to establish a definition of that elusive term quality. This is one of the features of Six Sigma that I like best. In ISO 9001:2000, we see that the focus is on building a QMS, a Quality Management System. And in ISO, there is certainly a strong focus on customer needs and quality. But that Standard doesn't go a long way toward giving you a way to define quality. In CMMI, we see only tangential references to quality. That model operates from the perspective that, if you implement recognized best practices for technology projects (and the customer is indeed included in many of these best practices), then you'll emerge with a quality product. But Six Sigma takes a direct bead on establishing what quality is, and what it is specific to the effort you are working on.

When you establish a definition of quality for your Six Sigma project, you are also defining success criteria. Your definition is born out of the two preceding activities. You identified who your real, or essential, customers are, and from them, you elicited their Critical-to-Quality issues. From this data, you can now pull a subset of those CTQs and build your quality definition around them.

For example, you work in a Fortune 500 IT shop. IT management has been getting burned at executive meetings due to IT's weakness in reasonably estimating project completion times. You formulate a Six Sigma initiative aimed at addressing this problem. You move out into the organization and, through meetings and discussions, you identify the managers of Marketing and Field Operations as being the core customers in this domain. After all, 80 percent of IT's work is delivered to these two groups. They are the ones with the staunchest complaints. With this focus in place, you then identify their CTQs and discover three essential issues:

1. Marketing and Field Ops can live with a two-week variance in promised delivery dates.

2. They appreciate IT's concern over their situation and will acknowledge progress if they can see IT moving steadily to hit that window.

3. If IT will open a broader channel of communication between itself, Marketing, and Field Ops, the customer will assist in ways it can to help ensure delivery dates.

You can now establish a pretty concrete definition of quality from these inputs. Here's one version: for the coming fiscal year, ACME IT will meet its delivery commitments within a two-week window for 75 percent of all system projects, to be managed by a supporting Partner Communication program.

The definition of quality is very serviceable for two reasons of its own:

1. It directly reflects the needs and concerns of the customers.

2. It provides an empirical foundation for improvement and refinement.

With this quality definition in place, we can now define the project's strategic objective.

7.4.3.4. Define the strategic objective

Everything we've looked at in this section has been centered on establishing the goal of the Six Sigma project. In the realm of corporate directives, that goal should be properly expressed as a strategic objective. This strategic objective should be featured prominently in your project plan. It describes the goal as a strategic target with distinct business benefits. The strategic objective is the culmination of all the investigation and defining you have done up to this point.

For this IT example, you might express the mission as a two-point strategic objective:

• Enhance ACME IT's current delivery capability from meeting 52 percent of its commitments within a four-week time frame to meeting 75 percent of its commitments within a two-week time frame.

• Establish a Partner Communication process that will enable ACME IT and its customer representatives to monitor and control delivery commitments across operating groups.

This form of expression gives your project a target to shoot for, and it does so in language that is meaningful and relevant to management.

7.4.4. Define Boundary Conditions

The physicist Stephen Hawking says that understanding the boundary conditions of the universe may be the single most important thing to know about it. If it is positively curved, the universe will ultimately fall back in on itself and end in a Big Crunch. If it is negatively curved, it will expand forever, the cosmos forever spreading apart in an ever-thinning soup until it winks out in cold darkness. Boundary conditions are important to Six Sigma projects, too.

Defining boundary conditions is a way to constrain and manage the scope of the project. It helps you avoid having to look at everything in your quest for improvement. And it is also a mechanism handy for continually focusing your efforts along lines that remain in harmony with the strategic objective. Let's take a brief look at ways to define boundary conditions for your project.

7.4.4.1. Target relevant processes

Six Sigma is fundamentally a process improvement tool. We use it to make our processes better; ideally, they will become measurably better. Once we have established a focus for our project and we know what we want to improve and how, in general, we want to improve it, we can begin to plan how we will move into the organization and make the improvements happen. One of the first steps in this direction is to target the processes in use in the organization that are relevant to the mission at hand. It won't do any good if you spend your time adjusting activities that ultimately have little to do with the problem at hand. So it is important to define just what the relevant processes are. To do this effectively, you will need a solid understanding of the process program at work in the organization. If you and your team lack such a full understanding, you will need access to the people who possess it.

So study the processes. Know what parts of the product they touch or influence. Trace your goals and objectives through the program. Map it out. Code a thread. Whatever path you take, identify the processes that are impacting the result or results you wish to modify. Identify these and then verify with the experts that these are indeed the right ones to target.

7.4.4.2. Define what a defect is

This is an essential part of any Six Sigma program. I see it as crucial. The idea is to bind the definition of a defect so that you'll know it when you see it. Think back to the pizza shop. The issue is still on-time delivery. Factors that influence this include such things as effective call routing, counter wait time, and drive time. Call routing concerns the central switchboard's ability to route a delivery call to the store closest to the caller location. Counter wait time deals with how long the pizza waits on the counter before a driver picks it up for a delivery trip. And drive time deals with the window of time between when the pizza is boxed for delivery and when the driver arrives at the customer's destination.

What is a defect with regard to call routing? It could be any number of things. It could be a call that is transferred to a location over a mile away from the caller's destination. It could be a call that is transferred to a store during that store's usual rush hour.

The same is true of counter wait time. A defect here might be counted as a pizza sitting on the counter four minutes or more after it has been removed from the oven. The same with delivery time. Maybe a defect here is a driver receiving a boxed pizza less than 10 minutes prior to the committed delivery time.

Defects can come in many shapes and sizes. Your team will need to look at your processes and define what a defect means in those domains. But however you end up slicing it, remember that your definition of a defect must continue to jibe with two traits. First, it must be a misstep that threatens Critical-to-Quality issues. And second, it must be something you can measure. You are going to structure your Six Sigma project around an analysis of opportunities for defects and the occurrence of actual defects. So defects must always be events you can measure in a practical and quantitative way.

7.4.4.3. Establish the Data Collection Plan

In any system, there are opportunities for defects. You'll often see this acronym pop up in Six Sigma discussions: DPMO. That stands for Defects Per Million Opportunities. If you were to operate a single-thread process rated as performing at six sigma, the process would produce only 3.2 defects for every million transactions (or opportunities) that were run through it. All systems have opportunities for the introduction of defects. Whenever you have inputs and outputs, manipulations or transformations, the risk is there. What you will be looking at in your Six Sigma project is a running process. You should analyze the process to understand how it works and where it has points for defect opportunities. You can map those points and put together a Data Collection Plan.

The Data Collection Plan describes what you'll be looking at, what kinds of defects you'll recognize, and what kinds of collection tools you'll use to capture process performance, measure process variance, and count defect occurrences. The importance of the Data Collection Plan should not be underestimated. Take time to get the detail here right. After all, this plan will cover a lot of the up-front project work. Lots of your initial time will be given to studying the system and making measurements. How you collect this will have a lot to do with the quality of data you end up with and the types of analyses you will be able to apply against the data.

7.4.4.4. Establish the Data Analysis Plan

Here's another acronym you'll encounter in the Six Sigma world: DOE. That stands for Design of Experiments. If you employ Six Sigma to its full extent, then any project can be thought of as a scientific experiment. You come up with a theory: "Something can be improved if we look at this." You put that "something" in a controlled environment and observe iti.e., data collection. Then you analyze the data and draw conclusions as to how you might change that something. Basic science. Design of Experiments is a discipline that helps you set up the right kinds of measures and identify the appropriate type of analyses that will let you make statistically accurate assumptions about what it is you looked at. For example, here's an experiment. You collect a lot of measures on people's height and weight. Then you analyze this data by dividing the average weight in pounds by the average height in inches. You conclude with the assumption that one inch of growth will typically equate to the addition of X number of pounds. That seems logical, but is that a sound methodology? Is that a well-designed experiment? Of course not. It's silly. It's pointless.

The point is, you can spend just as much time on a useless experiment as you can on a productive experiment, so you should make sure up front that you have a well-supported Data Analysis Plan to control the design of your Six Sigma experiment. Design of Experiments is a big topic, and I don't have the space in this short-form review of Six Sigma to go into it as much as it warrants. But keep in mind the importance of your Data Analysis Plan.

The Data Analysis Plan is just as important as the Data Collection Plan. Here you should identify what statistical techniques you will use to analyze the data, why those techniques are appropriate to the kinds of data being collected, and what the results will tell you within a statistically dependable degree of confidence. There are many simple forms of data analysis that can be applied. Averages, modes, and medians deal with normal distribution. T-tests, chi-squares, regression analysis, and ANOVA are more sophisticated techniques. Six Sigma routines employ formulas for predicting percent noncompliance and for generating process sigmas. The data analyses you elect will naturally depend on the problem you're trying to understand, the kinds of business environments you're in, and your team's own statistical and quantitative abilities.

7.4.5. Document the Project Plan

With the problem defined, and with the mission, sponsorship, team, and resources established, you are now able to begin putting together a plan to carry out and manage the project. You may elect to include the previous items as a formal part of the plan, or you may elect to keep them separate. (In the next two sections, I'll describe some additional sections of information that you might find useful to feature in your plan.) But as you build your plan, make sure that at least the fundamentals are in place. There is a set of generally accepted items that are typically considered fundamental. One is the project schedule. This is typically expressed as a work breakdown structure, a running series of activities that, taken as a whole, describe the project effort. Another is the budget, which details the costs of personnel, facilities, tools, and other resources. There are benchmarks and milestones, representing significant points of anticipated project progress or work product delivery. There might be a communication plan detailing how the project team will communicate status and progress to management, the customer, and other relevant stakeholders. And you may consider adding a section on assumptions, constraints and risks: issues you may have to deal with as the project moves forward and begins to evolve over time.

The depth of your plan and the type of plan you produce will depend on your own culture. If you build a realistic plan, one that reflects that culture, it should work well for your project.

7.4.6. Initiate the Project

Planning tells the tale of the project. If you've planned well, your project should run well. Here we have established the following things: we defined the problem with the issues we want to address, we defined the scope and mission of the project, we defined the strategic goals we want to achieve, we defined the boundary conditions that will guide the project efforts along focused lines, and then we used all of that to create a project plan.

The following sections cover the rest of the DMAIC methodology. But in a very real way, you've looked at it already. The methodology should be reflected in your plan. Specifically, the steps to measure and analyze have been detailed in the plan. How you improve and control will come from the results of the project.

But at this stage, you are ready to implement the project. And the first step there is to go out into the organization and begin to measure the performance of those processes you targeted.

7.4.7. Tools for the Define Phase

Some common managerial and statistical tools that can be used in the define phase include:

• Process analyses

• Flow charting

• Value stream mapping

• Check sheets

• Pareto analyses

• Cause-and-effect diagrams

• Failure mode effect analysis

Quick Take

DEFINE

The first phase in DMAIC is Define. The intention of the activities here is to establish the purpose, scope, and structure of the Six Sigma project. This typically includes:

Defining the problem

Define what it is that the project should target. This may be an existing problem, a newly surfaced problem, or a strategic mandate.

Defining the project

Establish the scope of the project in relation to the problem. Begin to assemble the appropriate team, seek executive sponsorship, and begin initial planning activities.

Defining the goal

The definition of the goal provides the project with a focused path to guide activity. The goal establishes the success criteria for the project.

Defining the boundary conditions

The boundary conditions help constrain the scope of the Six Sigma project. These conditions establish limits as to what will be measured, what will be analyzed, and what is subject to improvement.

Developing the project plan

With the above areas addressed, the team is now ready to develop a detailed project plan. The plan contains all of the information needed by the team, management, and organizational line workers concerning the purpose, scope, duration, and reach of the project.

Initiating the plan

With the plan developed, it should be reviewed and approved by all impacted parties. Once this is done, the plan is used as the central tool to execute and manage the project.