7.4 Activities of the Define Phase

Creating a Project Charter

A project charter is a brief document that includes information about the project team and sets a direction and objectives—establishes a sense of purpose. This document aims to develop expectations agreed upon by the team and the project's sponsor, keep the team focused on the objective, and ensure the project remains aligned with the business’s goals.

The project charter is dynamic. The team will start developing it during the Define phase. However, you will continue refining it throughout the project, especially as the team's understanding of the problem becomes more precise. Figure 7.1 presents the typical elements of an improvement project charter. The idea is to keep it simple. Most of the aspects of the document are easy to understand. Let's take a look at a few of the more substantive ones.

Problem Statement and Business Case

Define the issue you will solve or improve and explain why it is crucial to do so. The team needs to delineate the problem area objectively, precisely, and concisely. In developing the statement, you focus on observable symptoms and do not suggest causes, blame, actions, or solutions. The complete statement also provides a baseline, sets improvement goals, and delineates a project’s time frame. Here is an example:

Below is a checklist that you can use as guidance to develop your problem statement:

• Where did the problem occur?

• When did the problem occur?

• What process did the problem involve?

• How is the problem measured?

• How much is the problem costing?

A cautionary reminder. The more you and your team understand the candidate process, the more you can improve it. The best way for you to understand what is happening in the process is to follow the workflow personally. You can then discuss with the team what you observed. This procedure is called a process walk-through. Specifically, in lean terms, we often say going to the gemba, a Japanese word meaning “the actual place” or the “place where value is created.”

Project Scope

The project scope delineates what you will and will not include in the improvement project. You start defining the range when you develop the problem statement—the information you insert in the statement signals what you will be working on. The scope provides appropriate limits to the work you will do. Critical care here is with scope creep: the tendency to expand a project beyond the specified parameter or include more processes, activities, or tasks.

It is best if you ascertain that the scope is clear. For instance, stating that the content for an improvement project starts at the order stage and ends with fulfillment may not be apparent because separate individuals might consider distinct points as the beginning of the order stage or the end of the fulfillment. Here you might instead list the scope as starting when a customer places an order and ending when the order is boxed for shipment.

Goal Statement

The goal statement describes the team’s improvement objectives. You typically start this statement with a verb such as reduce, eliminate, control, or increase. For example, increase South warehouse’s order fill rate by 20% by the next quarter of the current year. The order fill rate in this example is a customer requirement. In Lean Six Sigma we call it a CTQ—Critical to Quality.

Defining CTQ

Critical-to-quality (CTQ) characteristics are the factors or parameters that are the significant drivers of quality within a process. They are crucial characteristics that you can measure. Their performance gives you information about whether or not a customer will be satisfied. In a process improvement environment, CTQs are essential to narrowing work scope, understanding how to enact change, and managing progress and success.

For an example of how CTQs work, let's think about purchasing an outfit. When you buy a new sports coat to interview for a job position, you usually care about how the cloth will look and fit. A producer would have a hard time creating a “jacket comfort” measure to use in the production process. However, the brand can take various customer feedbacks and learn that a particular fabric with a specific cut is most comfortable. The brand can also determine appropriate measures for each size and the best way to put them together.

Now the brand can use these factors (CTQs) during the production process. The plant will use only fabric that meets the specifications identified through customer feedback, cut to specific measures, and sew it in a particular manner. You, as a customer, will not care about those specific issues but whether the jacket feels comfortable. Note that comfort is a critical-to-customer characteristic that the brand translated into measurable critical-to-quality factors.

You can approach the CTQs of a process as the outcome (Y) of a function with one or more Xs. Taking the example of the jacket, we saw that sewing was a CTQ of the process. Let's assume that the type of stitch, machine operator experience, and operator technique affect the proper sewing. You can translate this as, “quality sewing” is a function of the kind of stitch, machine operator experience, and operator technique. You can write the relationships as follows:

Where the outcome Y (the CTQ of interest) is quality sewing, X₁ is the type of stich, X₂ the machine operator experience, and X₃ is the machine operator technique. The five phases of the DMAIC model seek to find revised methods to modify how we currently perform the Xs to move the CTQ (Y) in a specific direction. During DMAIC's Define phase, you delineate the CTQ(s) using a tool we will see later in this topic—the customer's voice (VOC).

Stakeholders Analysis

Understanding the customer’s needs and requirements is a crucial step in an improvement project. However, you also need to understand the other stakeholders (individuals, groups, or organizations interested in the project and that can mobilize resources to affect its outcome somehow or even derail project’s progress). Each project has many interested internal and external parties. They frequently change, or their interests in the project change during different phases. And each of them may have several non-technical requirements.

You need to discover and then align your project requirements with the communicated and non-communicated needs and expectations of all parties interested in your project. Stakeholder analysis allows you to identify and understand the needs and expectations of significant interests inside and outside the project environment. Such information will help you strategically plan your project, keep stakeholders informed, and ascertain the support you need.

An excellent way to perform your process’s stakeholders’ analysis is to use the diagram shown in Figure 7.2 to brainstorm with your team. The diagram helps you group and prioritize the various stakeholders involved in your project. Creating and using it is quite simple. You draw a grid over an X and Y-axis. The vertical axis portrays the amount of power a person has in the organization. The horizontal axis displays the amount of interest a person has in your project.

In general, a stakeholder with more power can affect the direction of the project, for the best or worse, while a stakeholder with interest cares about the outcomes of the project.

Now you can ask the team members to write down possible stakeholders for the project in sticky notes then place them on a board. A quick discussion of the names that appear will help discard any the team feels are not relevant stakeholders. Once the team finalizes the list, you can start moving the names in the sticky notes to the grid also on the board according to power and interest. You can place a name at the lower bounds of any quadrant to show lower amounts of power than those placed nearer the top of the box.

Each of the grid's quadrants corresponds approximately to a stakeholder type. Why should we care about stakeholder type? In other words, what can we do with that information? You can use this information to guide how the team may interact with each individual or organization appearing on the grid and tailor communication with them. Let's take a look at each.

Top Right Quadrant: Full Engagement

People appearing in this quadrant are crucial individuals playing a role in the process or they are organizational leaders with discretion to assign resources to the project. You and your team need to constantly communicate with them and likely report to them at various tollgates. These individuals play a crucial role in the ultimate success of the improvement project. This group is quite important. You need to manage them closely and carefully.

Bottom Right Quadrant: Keep Informed

People appearing in this quadrant are strongly connected or interested in the project. However, they do not possess the organizational discretion to support the project in terms of resources. They include subject matter experts that you will consult or individuals in related processes. The main team's concern is to keep these stakeholders informed about the project's progress.

Top Left Quadrant: Keep Satisfied

People appearing in this quadrant have sufficient organizational discretion that they could intercede in the project. However, they are not closely interested in the daily routine of the project. You and your team need to manage any interaction they have with the project carefully and keep them satisfied. You may also consult with these individuals throughout the project.

Bottom Left Quadrant: Monitor

People appearing in this quadrant connect only loosely to the project and demand minimal effort from the team. You and your team can communicate with them using general information about the project using newsletters or email. Sometimes you may find it beneficial to move individuals from this box to the lower right quadrant. Your team's concern is to monitor these stakeholders.