Roadmap

In more detail, Belts must apply the following tools to their projects in Define:

To initiate the project, the Belt, Champion, and Process Owner meet to construct the preliminary Charter. They will determine the initial scope, the Team that should be used, the likely metrics, and potential benefits. These items are merely a draft, and the Team will work to better define them during the subsequent tools.

At this point, the Project Team will be mobilized and shortly thereafter the first Team meeting will take place. The Champion and Process Owner more than likely will be there for the first stages of the meeting to validate support for the project and answer any questions that the Team might have with respect to the desired outcomes (but not solutions). Beyond this point, the Champion and Process Owner only join the Team for meetings in an ad hoc manner when requested. Useful tool sets to consider at this time are some of the myriad of Team formation tools that generally fall into two main categoriesTeam interaction (or interpersonal roles) and meeting effectiveness tools. Some Team interaction or interpersonal roles include

• Forming, Storming, Norming, and Performing. The stages that all Teams go through during projects

• Belbin.^[2] Roles that individual Team members play in project interplay

  ^[2] Belbin is the trademark of Belbin and Associates. For more information, see www.belbin.com.

• DISC.^[3] Team role characteristics

  ^[3] DISC is the trademark of Target Training International. For more information, see www.ttidisc.com.

An example of a meeting effectiveness toolwhich aids in defining meeting roles, behavioral expectations, and so forth during Team meetingswould be a SPACER. A SPACER is conducted at the commencement of each meeting to run through Safety, Purpose, Agenda, Code of Conduct, Expectations, and Roles.

There are a whole host of other Team formation tools; however, they will not be covered any further here but are highly recommended to help Team interaction, speed up the project (especially in the initial stages), and ensure a higher likelihood of success.

	To help define the process, a SIPOC (Suppliers, Inputs, Process, Outputs, Customers) is useful, especially in understanding the scope and purpose of the process. Although it seems to be a very straightforward tool, the SIPOC will drive a lot of very important early discussion within the Team about "What really is the question we are trying to answer?"
	The central "Process" column of the SIPOC can be extracted and rotated 90° to become a High-Level Value Stream Map. This requires almost no additional work, but the map is a useful linear representation of the process that can help in communications within the Team and to the rest of the organization. When the appropriate performance metrics are added, it becomes a valuable tool for the business.

After a reasonable scope is determined for the process, the next question is what the Customer Requirements are for the process. In the early Six Sigma days, this was decided quickly between the Process Owner and Champion, and the Team progressed on. More recently, the roadmaps have been strengthened considerably using better Voice of the Customer (VOC) tools, which ensure that after the process has been improved, it genuinely better meets Customer expectations. The tools listed next are in fact a subset of those VOC tools used for developing new products and services in Design For Six Sigma^{[4] [5]} (DFSS) and its offspring, Lean Design For Six Sigma^[4] (LDFSS), or simply Lean Design. Because we are not striving to completely redesign the process for a new market here (if you are, you might want to look at Process Design For Six Sigma^[5]), this subset works well for the majority of projects:

^[4] Learn more about Design For Six Sigma, Lean Design For Six Sigma, and Process Design For Six Sigma at www.sbtionline.com.

^[5] See also Commercializing Great Products with Design for Six Sigma by Randy Perry and David Bacon (Prentice Hall PTR, ISBN: 0132385996).

---

[Pages 16 - 17]

	To help frame what questions to ask the Customers regarding the process, it is useful to spend some time as a Team brainstorming the issues around it. This can be done in the form of traditional Brainstorming, or it is preferable to use the tool known as Murphy's Analysis. Note that the output of these tools is absolutely not the Voice of the Customer, but rather the Team's internal insights to help guide the structure of the VOC questioning in the subsequent steps.
	Based on some of the learning from the internal brainstorming, it should be reasonably straightforward to put together an Interview Discussion Guide, Customer Matrix and then go ahead and interview Customers. Richness of Customer data is based on diversity of Customersnot on quantityand thus, 1220 interviews should be enough to frame even the most complex process. Interviewing can take 12 weeks to complete, so plan the Team's time accordingly.
	See "Customer Interviewing" in Chapter 7, "Tools," for more detail.
	Some processes have a vast multitude of Customers for whom the Team would like some input to ensure that nothing key is missed, but really don't want to spend time interviewing in depth. To gain these Customer inputs, use a survey that is either mailed or handed directly to the Customer or, primarily for internal Customers, posted on the wall, and have them write directly on the surveys. Simply posting the survey on the wall might seem a little hit-and-miss, but it is a surprisingly effective way of reaching respondents that might not take the time to answer in another form.
	The survey usually will take one week to get the data back.
	Surveys are notoriously error prone, so do not rely on this as your main source of Customer inputuse the interviews instead.
	One of the hardest parts of gaining the Voice of the Customer is distilling the copious volume of data down into useful information. This can be done with a simple Affinity Diagram or by using a more complex affinity tool such as KJ.[6] For the majority of projects where the number of unique Customer voices is not overwhelmingly large, the simple approach works best.
	After the Affinity Diagram is complete, a simple extraction will yield the Customer Requirements Tree. This Tree represents a simple hierarchical structure of needs from the highest abstract level down to individual facts and measures. At this point, a Team can say it has captured the Voice of the Customer. To successfully create the tree, it is often best to track the noted metrics back to the set of more essential metrics behind the scenes. A useful tool here is the 5 Whys.

^[6] KJ is known after its inventor, the Japanese anthropologist Jiro Kawakita. For more details, see A New American TQM: Four Practical Revolutions in Management by Shoji Shiba, et al. (Productivity Press, ISBN: 1563270323).

Use of the 5 Whys is important throughout the project. Even though it is a very simple tool, it has potent use in the roadmap. I use a slight derivative, which involves asking "Why do I care?" A very recent example in a hospital client demonstrates the importance of using this at this point. The project focus was on the Prepare Visit made by expectant mothers a few weeks prior to the big day. The Team had identified a key Y to be "% of new mothers given access to the Prepare Visit." By asking "Why do I care?" a number of times, the thought flow was as follows:

• More mothers need to go through the Prepare Visit.

• Education given during the Prepare Visit is more readily absorbed than during the Birthing Visit, and valuable doctors' time is wasted reworking the education during the Birthing Visit.

• New mothers need to understand and retain key learning before they return home.

• New mothers are the ones that are required to give correct care to themselves and their newborns after they leave the hospital.

• Sometimes new mothers or babies, after returning home, have to be readmitted to the hospital for what are essentially avoidable reasons.

At this point, the Team realized that the Prepare Visit was in fact a solution to a problem, and the true underlying issue and associated major metric was "Rate of avoidable returns postpartum." This brought a whole new perspective to the problem and hence the project.

The Team needs to finalize the primary metrics by which project success will be measured. These are known as the Ys for the process, and are a key focus in the project through the equation Y=f(X₁, X₂,...X_n) where the Xs are all the factors in the process that affect the Ys. See "KPOVs and Data" in Chapter 7 "Tools" for more detail.

Determining the Ys is done by taking the output of the Customer Requirements Tree and firming up Operational Definitions of the key metrics. For each metric, a baseline measure is made.

It might be worthwhile to scan through some of the appropriate Problem Categories in Chapter 3, "Global Process Problems," to help identify metrics pertinent to the problem at hand to help complete the KPOVs.

The primary purpose of Define is to make sure this is the right project to be working on. Oftentimes, Belts make the mistake of moving very quickly into Measure and looking at detailed Process Capability studies, when really a simple quick-and-dirty measure of baseline performance would suffice. The purpose of the baseline at this point is just to see if the project is a real project. Later, the Team can look at Measurement Systems and Process Capability and clean up the baseline metric. However, if no baseline data is readily available and the Team has to contrive a sampling regime to get a baseline, it is worth investing time in looking at the validity and reliability of the metric before doing so.

	The Belt and Champion return to the Project Charter to finalize all the fields based on the Team's work. At this point, the decision is made whether to continue or not.
	This is the most important decision point in the whole DMAIC roadmap and is often overlooked. The early commitment to move into Define was not in fact the final commitment to do the project. Only at this point do the Belt and Champion have enough information at hand to make the call.

After the Belt, Champion, and Process Owner sign off on the Project Charter, the project can move into the Measure phase. Before doing that, it will be worthwhile to set up some rudimentary Project Management:

Although not covered here in detail, Project Management^[7] is a key part of project success. The Belt should look to having at least a:

• Milestone Plan for the project

• Risk Management Plan

• Detailed Work Plan for each Milestone

• Hazard Escalation matrix for those unforeseen circumstances

^[7] There are many texts to help projects in general; one method that suits Lean Sigma well is outlined in Goal Directed Project Management by Andersen, Grude, and Haug (Kogan Page, ISBN: 0749441860).

At this point, the Team should know enough about the process and the problems it has from insight gained from the VOC tools. The Team does not need to know why the problem is occurring (that will come later in the Analyze phase), but the basic understanding of the problem (often captured in a Problem Statement in the Project Charter) will allow it to identify the type of problem apparent. A list of generic Problem Categories is shown in Table 2.1. To proceed further in the Lean Sigma roadmap, the Team should select the most appropriate Problem Category from the list in Table 2.1 and go to that section in Chapter 3 (as indicated by the letters AY).

Table 2.1. Problem Categories for the process as a whole

Section	Issue	Description
A	On-time delivery problems	There commonly is a failure to have the right entities at the Customer at the right time
B	Process capacity too low	The process cannot generate entities quickly enough to keep up with the pace of demand from the Customer
C	Process defects too high	The process generates too many imperfect entities. Rework or scrap too high. Quality is being "inspected into the process" rather than entities being right the first time
D	% Uptime of process too low	The process is down (not doing value-added work) too much
E	Pace of process too slow	When the process is performing value-added work, it isn't doing so quickly enough
F	Process fails intermittently	The process has enough capacity to keep up with demand, but fails every so often, perhaps missing an entity entirely
G	Process lead time too long	The capacity of the process is sufficient, but lead time through the process is too long
H	Individual steps meet the pace of downstream demand, the process as a whole does not	Despite individual steps within the process all meeting Takt and hence theoretically being able to keep up with the pace of demand, the global process does not meet Takt and therefore cannot keep up
I	Customer demand too variable	Customers demand entities in a highly irregular pattern, making planning and inventory control extremely difficult
J	Too many products	The portfolio of different types of entities that the process can generate is too large, keeping inventory levels high and making planning difficult
K	Process deviating from schedule	The process of generating a future schedule is highly inaccurate, thus leading to large variance from plan after the fact (note this is different from Deviation from Forecastsee U)
L	Measurement system is broken	A key measurement system used to judge process performance exhibits high variation and is thus ineffective
M	Performance characteristic not meeting specification	Entity performance metrics (e.g., product strength, purity, accuracy, etc.) are not hitting required target levels
N	Planned maintenance takes too long	When the process is stopped to perform planned maintenance, the associated downtime is too long
O	Setup/changeover takes too long	Process changeover time between individual entities or different entity types takes too long
P	Too much unplanned maintenance	Maintenance conducted is reactive (unplanned) and there is too much of it
Q	Process fails to make product at all	All entities the process generates are defective or the process generates no entities whatsoever
R	Resource usage too high	Headcount used to run the process is too high
S	Process inventory too high	The inventory in the process, whether standard work-in-process or unplanned, is too high
T	Process waste/loss too high	Mass loss (waste) from the process is too high, giving low process yield
U	Process deviating from forecast	The process of generating a future forecast is highly inaccurate, leading to large variance from plan after the fact (note this is different from Deviation from a Schedulesee K)
V	Not enough sales	There are not enough sales of entities from the process
W	Backlog of orders is too high	The process is lagging behind sales, creating a backlog of orders
X	Payments made to suppliers not optimized	Accounts Payable is too high for the businessthe timing of payments to suppliers is too variable
Y	Accounts Receivable is too high	The business isn't collecting payments for its products and services quickly enough

Following the roadmaps as indicated in Table 2.1 will home in on the particular problem and identify a means to a solution. This might involve at some point scoping down to focus on one particular process step, identified as the root cause of the issues, rather than treating the process as a whole.

Sometimes we are fortunate enough to have such a clear problem that the individual process step causing the problem is absolutely obvious. In these (albeit rare) instances, it is possible to shortcut the preceding roadmaps and go straight to the Individual Step Roadmaps, as shown in Table 2.2 and described in detail in Chapter 4, "Individual Step Process Problems."

Table 2.2. Problem Categories for a single process step

Section	Issue	Description
1	Process step does not meet Takt	A single process step cannot process quickly enough to keep up with the pace of demand
2	Pace of process step is too low	When a single process step is performing value-added work, it isn't doing so fast enough
3	Cycle time of process step exhibits too much variation	There is too much variability in the time it takes a single step to process an entity

In general (except for the instances listed in Table 2.2), the roadmaps to tackle problems at a single step level are entirely analogous to those for the whole process. If you do not see your Problem Category listed in Table 2.2, refer back to Table 2.1 and select the roadmap from there.