DMAIC Methodology: Define Stage

The Define stage of DMAIC is where an improvement project is won or lost. In it the team turns the voice of the customer into measurable requirements, writes a clear problem statement and goal, maps the process and agrees scope, team and timeline with a sponsor. Skipping it means solving the wrong problem faster.

“Failing to Plan is Planning to Fail” is a Chinese proverb that fits this stage well.

Picture a chief operating officer reviewing the results of a six month improvement project. The team cut the average handling time of a process clearly, the dashboards look excellent, and yet customer complaints have not moved. Nobody made a technical mistake. The team simply optimized the step that was easiest to measure instead of the one the customer actually cares about. That gap is created in the first weeks of a project, in the stage that most companies treat as paperwork.

The first stage of the DMAIC continuous improvement cycle is to define the problem (“Define”). In general this phase tends to be undervalued, because its result is intangible and does not provide improvement solutions. If you want to run a successful improvement project that is focused on satisfying the needs of your clients, it is better to start appreciating the importance of this phase. The DMAIC and other Six Sigma tools to drive continuous improvement article shows how the whole cycle fits together, and DMAIC, make continuous improvement of your processes a reality explains how to take it from theory to daily practice.

What does the Define stage of DMAIC achieve?

For an improvement project to deliver the expected return, it must be aimed at satisfying customer needs. That means the next step cannot be taken if the customer is not truly understood by the company. Practitioner sources describe the same purpose. A chapter on the DMAIC methodology from Applying Lean Six Sigma in Operational Excellence states that the primary goal of Define is to clearly articulate the problem, set objectives and identify the scope of the project.

In practice the stage achieves four things. First, the team understands the problem by listening to the voice of the customer. Second, it translates the requirements into critical to quality variables (CTQ), also called dependent variables (y). The objective of any improvement project must be to improve these variables. Third, the team gains an understanding of the project and the process, and determines the independent variables (x1, x2, ..., xn) that affect the results the clients expect. This relationship is usually written as y = ax1 + bx2 + ... + e, which simply says that the outcome the customer sees depends on a set of process factors the team can act on. Fourth, the team explicitly determines the problem, the objective, the project team, the scope and the execution time.

Tip. The team must include a professional capable of leading improvement projects, and by capable we mean at least a certified Green Belt or Black Belt. It must also be ensured that the project has the support of a member of the company's leadership team. That person is known as the Project Sponsor, and without one the project will stall at the first conflict over resources or priorities.

How do you define the client and their requirements?

Each improvement project must revolve around the client, who can be external, internal or both. The customer is the person or group of people who receive the product or service that results from executing the process. During the Define phase, the team must understand the company's clients and their requirements in detail. Interviews, ethnographic surveys, data mining and similar techniques can be used for this. The Cleveland State chapter lists surveys, focus groups, interviews and the analysis of complaints and support tickets as ways to gather customer requirements.

Once the information is available, it must be translated into quantifiable requirements that give the team in-depth knowledge about how to approach the solution. A customer who says the service is slow has not yet given the team a requirement. A requirement is that a request must be resolved within a defined number of hours for a defined share of cases. The same source notes that CTQ elements typically fall into quality, time and cost measures, which is a useful way to check that the list of requirements is balanced.

Executives can help at this point with one question. Who exactly is the customer of this process, and how do we know what they value? When the answer is a guess, the project should pause and collect evidence, because every later stage inherits this assumption.

How do you write the problem statement?

The most challenging part of solving problems is determining and choosing which problem to act on. In this phase teams should refrain from looking for an immediate solution. The best improvement projects focus on improving customer satisfaction and make the problem a priority because of its high impact on the business. A practical test is to ask whether the problem can be described without mentioning a solution. If the statement already says “we need a new system”, the team has jumped ahead.

The problem statement should include two elements. The first is customer impact, which means determining the amount of impact on the quality dimension in which customers evaluate the product or service, such as reputation, aesthetics, replacement, service, durability, reliability, performance, characteristics or conformity. The second is severity. How big is the problem? If you have data, reflect the severity from the beginning. It may happen that the data does not exist, and in that case the information will be completed during the Measure phase of the DMAIC cycle.

The ASQ Phoenix Section guide on Define tollgate tools describes the problem statement as an articulation of the problem or opportunity to address, ideally written to meet SMART criteria, and places it inside the project charter together with scope, goals, team members and expected timeline. Keeping all of these in one authorized document avoids the common situation in which different stakeholders remember different versions of the project.

How do you define the goal of the project?

Once the problem is clear, the team proceeds with the goal statement, which should reflect the problem statement. It is recommended to write it in a SMART way, meaning specific, measurable, achievable, relevant and time-bound. The ASQ guide uses the same five criteria. The same logic of clear and measurable targets is applied to commercial teams in Smarketing, tips to align Marketing and Sales.

The goal is not set in stone. It can be adjusted once the root cause of the problem is determined in the Analyze phase of the DMAIC cycle. What matters is that every change is made visibly, discussed with the sponsor and recorded, so that the final result can be compared with an honest baseline.

How do you map the process?

The team should develop a general understanding of the process. Different tools can be used depending on the nature of the process, the problem and the objective. A SIPOC analyzes suppliers, inputs, process, outputs and customers. The Cleveland State chapter describes it as a high level process map that outlines those five elements. Another useful tool is the Value Stream Map, which is very useful when the project is related to reducing cycle time. You can see how it connects with the customer experience in How Value Stream Mapping drives customer experience.

Once the process has been mapped in a general way, the team must walk through it step by step to understand each stage in depth. During this walk, the team asks questions of those responsible for executing the different activities of the process, in order to obtain a complete overview. A flowchart can be used to diagram the findings. The people who do the work often know about workarounds and exceptions that never appear in the procedure manual, and these are exactly the details that explain why results differ from design.

How should the team report progress?

The team should update and report progress to the project sponsor on a regular basis. A useful communication tool is the A3 document, which communicates the status of the project quickly and easily on a single page. A regular rhythm of reporting is also the best protection against scope creep, because every change in scope has to be justified in front of the person who sponsors the work.

The same discipline applies to sectors with strict controls. If you want to see the whole cycle applied to a regulated environment, read Use Case, Apply DMAIC in the Finance Industry.

Which mistakes weaken the Define stage?

The most common mistake is to rush. Pressure to show results makes teams jump to solutions before the problem is understood, and the project drifts toward the opinion of the loudest person in the room. A second mistake is to define the customer too narrowly. Many processes serve both an internal and an external customer, and an improvement that benefits one at the expense of the other only moves the problem to a different department.

A third mistake is a goal that cannot be measured. “Improve the experience” or “reduce delays” does not give the team a target, and it does not allow the sponsor to say later whether the project succeeded. A fourth is a scope that is too wide. Projects that try to fix an entire end to end process at once usually exhaust their sponsors. It is better to choose a bounded part of the process where the customer impact is clear, achieve a visible result and then extend the approach.

A fifth mistake is to treat the sponsor as a figurehead. The sponsor is the person who removes obstacles, protects the team's time and decides when the scope should change. A sponsor who only appears at the final presentation cannot do any of this. Agreeing the sponsor's role in the charter, including how often they will meet the team, prevents the project from losing momentum.

How does Define connect with the rest of the cycle?

Each later stage depends on the quality of the work done here. In the Measure phase the team collects the data that confirms the severity of the problem, and if the CTQ variables were poorly defined the team will measure the wrong things with great precision. In the Analyze phase the team looks for the root causes among the independent variables identified during Define, so a good process map saves days of searching. In the Improve phase the solutions are tested against the goal statement, and in the Control phase the same CTQ variables become the indicators that keep the gains in place.

Seen this way, the Define stage is not a delay before the real work. It is the design of the project. The time invested in understanding the customer, framing the problem and agreeing the goal is recovered many times when the team does not have to argue later about what success means. That is why mature improvement programs review the charter at every stage gate, and not only at the start.

What this means for the C-level

For an executive team the Define stage is the cheapest point at which to change the course of a project. Corrections made here cost conversations. Corrections made after the Improve stage cost rework, delayed benefits and credibility. A sponsor who asks for a clear problem statement, a measurable goal and a validated view of the customer is protecting the investment before it is made.

It is also the stage where priorities are decided. Every organization has more improvement ideas than capacity, and the Define stage forces a choice based on customer impact and business impact instead of on who proposed the idea. For a chief financial officer this is the moment to ask how the benefits will be measured and by whom. For a chief operating officer it is the moment to confirm that the team has the time and the authority to access data and people across departments.

What can you do on Monday morning?

Choose one improvement project that is already running or about to start and ask its leader for three things. The first is the problem statement in two sentences, without any solution in it. The second is the list of customer requirements expressed as numbers, with the source of each. The third is the name of the sponsor and the date of the next progress report. If any of them is missing, hold a short working session to complete it before more resources are spent.

Then check that a first process map exists, even a rough one, and that someone who executes the process has reviewed it. This simple review often reveals activities nobody had listed. If your team wants a guided format for describing activities and processes, the ICX Define Activities and Processes toolkit can serve as a starting point.

Finally, schedule a thirty minute conversation with two or three customers of the process, internal or external, and ask what they notice when it works well and what they notice when it fails. Compare their words with the requirements written in the charter. If the language differs, the requirements need to be rewritten before the project continues. This small exercise costs very little, and it is the most direct way to confirm that the team is working on something the customer truly values.

How ICX helps

ICX supports organizations that want to make continuous improvement a routine rather than a campaign. The team helps leaders select the right projects, prepare the charter and problem statement, capture the voice of the customer, map processes with tools such as SIPOC and value stream maps, and coach Green Belt and Black Belt project leaders. You can learn more on the ICX DMAIC service page, and see how the same tools improve customer touchpoints through digital experiences design.

Frequently asked questions

What is the Define stage in DMAIC? It is the first stage of the cycle, where the team clarifies the customer requirements, the problem, the goal, the process, the scope, the team and the timeline before measuring or improving anything.

Who should lead a Define stage? A professional capable of leading improvement projects, at least a Green Belt or Black Belt, supported by a Project Sponsor from the leadership team.

What is a CTQ? A critical to quality variable is a measurable characteristic that the customer considers essential. It becomes the dependent variable (y) that the project aims to improve.

Which tools are common in Define? Voice of the customer methods, the project charter, SIPOC, the value stream map, flowcharts and the A3 report are common tools. The choice depends on the process, the problem and the objective.

Can the goal change later? Yes. The goal can be adjusted once the root cause is determined in the Analyze phase, as long as the change is agreed with the sponsor and recorded.

A well defined project is half solved. Talk to an ICX consultant to review the definition of your next improvement project.