- Overview
- Intended Audience
- Prerequisites
- Basics
- How to Use This Book
- And Finally . . .
How to Use This Book
The intent of this book is that it be used as a tool to help Project Leaders guide a project, and thus it needs to be structured in a form that best helps the reader start with the problem in hand and quickly progress to the solution. I’m sure it is possible to read it from beginning to end; however, it is not designed with that purpose in mind. Its layout probably will be perceived as a little unorthodox, mainly due to a few simple issues:
- There are a multitude of different Problem Categories.
- Each Problem Category has a different route to a solution.
- The same tools are used in the solution of multiple Problem Categories.
- The application of each tool can vary subtly, depending on the problem.
This book is structured into three main parts (shown graphically in Figure 1.2):
Figure 1.2 Structure of this book
Part I: Project Roadmaps: There are many different incarnations of roadmaps, depending on the business need, and it is necessary to determine up front which is the most appropriate.
Process Improvement Project: In this case, there is an identified project. The current process is deficient in some way and therefore a change is required (this requires more than just the process to be standardized). However, that change isn’t obvious or unanimously agreed upon by all the key stakeholders, and therefore some data and analytics will likely be necessary. This type of project follows the ubiquitous DMAIC roadmap, as shown in Figure 1.1.
For this type of project, Chapter 2 describes the route through the DMAIC roadmap. Part II (Chapters 6 and 7) supports this journey by describing the route to a solution for a wide range of problems and in essence the journey through the Measure and Analyze phases. The text lists some 25 or so Problem Categories with titles such as “The capacity of the process is too low.” Generally speaking, this is at an overall-process level (considering the process as a whole), in which case the categories are listed in Chapter 6. However, there are rare projects in which a significant amount of work has already been done on the process. In this case, the Problem Category might be at a within-process level where a single process step has been identified as being the problem area, in which case the categories are listed in Chapter 7.
The text lists which tools to use (in italics like this), in which order, and why and in essence forms the detail behind the roadmap shown in Figure 1.1. The Belt/Team should follow the roadmap that best describes the process problem that they are encountering, based on key decision points listed in the text. For more details on a tool listed, the Belt/Team should refer to the tool detail in Part III (Chapter 8), where the tools are listed in alphabetical order.
Standardization Project: Here too there is an identified project. The current process, however, is not necessarily deficient; the issue is more that the operators aren’t consistent in their approach (this is a very common situation in service industries and healthcare). Since the goal is more one of standardizing the process versus changing it, no heavy data/analytics are necessary to understand the change. This project can follow the DMASC (Define, Measure, Analyze, Standardize, and Control) roadmap.
For this type of project, Chapter 3 describes the route through the entire project to completion. The text lists which tools to use (in italics like this), in which order, and why. For more details on a tool listed, the Belt/Team should refer to the tool detail in Part III (Chapter 8), where the tools are listed in alphabetical order.
Accelerated Improvement Project (Kaizen): In this case again, there is an identified project. The current process is deficient in some way and therefore a change is required. The change itself, however, is limited to a smaller subset of problems involving just streamlining or a reduction of complexity, rather than needing heavy data and analytics. This type of project can follow the Kaizen roadmap and if desired can be conducted in an event-based format, as opposed to a drawn-out project.
For this type of project, Chapter 4 describes the route through to project completion. In addition, Part II (Chapters 6 and 7) describing the route to a solution for a wide range of problems can provide guidance for which specific tools to use. The text lists which tools to use (in italics like this), in which order, and why. For more details on a tool listed, the Belt/Team should refer to the tool detail in Part III (Chapter 8), where the tools are listed in alphabetical order.
Discovery Project: In some instances there is no obvious project related to a process or area of a business. This is often useful to businesses that are new to Lean Sigma and are not sure how to identify good projects to work on.
For this type of project, Chapter 5 shows a Discovery roadmap used to identify potential projects in a process where there are no obvious targets. The text lists which tools to use (in italics like this), in which order, and why. For more details on a tool listed, the Belt/Team should refer to the tool detail in Part III (Chapter 8), where the tools are listed in alphabetical order. After the project or multiple projects have been identified in the process using the Discovery roadmap, one will be selected (based on the project type: DMAIC, DMASC, or Kaizen), and the Team will follow the project roadmaps described in Part I.
- Part II: Routes to a Solution: Chapters 6 and 7 provide project roadmaps describing the route to a solution for a wide range of problems, particularly relevant in the Measure and Analyze phases in a DMAIC project or in support of a Kaizen Event, both described in Part I. The text lists which tools to use (in italics like this), in which order, and why. For more details on a tool listed, the Belt/Team should refer to the tool detail in Part III (Chapter 8), where the tools are listed in alphabetical order.
- Part III (Chapter 8). Individual roadmaps explain in detail how to use each tool.
Problem Categories
To use this book effectively, it will be necessary to identify the Problem Category based on the process issue(s) at hand. This might seem awkward to novice Belts, but it is an important skill to develop. Belts need to be able to step back from the process and see the bigger picture before diving into the detail. Quite often, the inexperienced Champion and Process Owner can be a hindrance at this point by pushing the Belt down a road to a solution before truly understanding the underlying problem. The purpose of the Define tools, for example, is to provide an understanding of what, from the Customer’s perspective, the problem truly is and frame it in a measurable form. Only after the Define tools have been applied can the Belt confidently say which Problem Category he or she is dealing with.