Process improvement approaches, such as Lean Six Sigma, have no shortage of powerful tools to apply in trying to assess a situation and then implementing change. How, then, to pick those that may have the most bang for the buck for someone relatively new to the field or on their first PI project?
Complex methodologies tend to have project stages or phases — for example, DMAIC (Define, Measure, Analyze, Improve, Control) in Six Sigma. A plethora of tools are available to choose from during each of the above stages of a PI project. Many beginners, and some not so new to the field, complain about feeling overwhelmed by this ‘abundance’ of options. Can we help novice analysts sort these tools into some logical order and perhaps choose a subset of these, so that analysts can start to get some traction early on and perhaps use what they already know to grasp the essentials of the problem at hand?
Process improvement skills required
In thinking broadly of a palette of skills for our novice PI analyst, we require:
- to be able to generate, sort, group, and prioritize ideas
- to be able to visualize what is going on (ex. a process over time, etc.)
- to be able to understand which aspects of a problem may be correlated and which situations may cause others to occur
- to be able to match actions taken and outcomes to situations and to keep track of these in orderly fashion
- to be able to share our insights with others.
These are broad skills in understanding, planning, acting, and communicating, that are easily migrated across disciplines and are needed by almost everyone who is faced with a problem to solve.
Suggested process improvement tools
I list here 5 tools that will allow the PI novice to get going quickly and make some progress that does not hinge on proficiency in advanced statistics. The tools below match the skills requirements listed above one for one.
- SORTING AND GROUPING — Affinity diagram: this is a means of getting from a chaotic morass of competing ideas of varying worthiness to a more ordered view of things. It is suitable for gaining insight as a result of the typical brainstorming sessions that occur early on in a PI project. It starts with Post-It notes — each one with a single idea scribbled on — spread all over a wall or table, and proceeds, over several days, as participants move the notes about so that the more “affine” (similar) are closer. At the end, a few clusters (groups) of related sub-topics tend to emerge from the many original and seemingly disparate ideas. These sub-topics can be further ranked by perceived relative importance.
- EXPLORING CAUSATION – Cause and effect diagram: this is a diagram that relates items in terms of causation and tries to draw arrows from those that are perceived causes to those that are perceived effects or consequences. A type of cause-and-effect diagram is the fish-bone diagram, which takes a perceived problem and helps to drill down to several root causes, which are grouped by categories useful to the business (ex. policies, people, environment, machines, etc.) The problem is shown at the fish’s head, and the different categories branch off the spine. One can also do root cause analysis by asking “why?” as many times as needed until a root cause is identified that can be worked on (see any reference to “5 whys”.) See also my posts on mistake-proofing.
- VISUALIZATION — Swim-lane diagram: this is a flowchart, enhanced by matching roles and actors to process steps or activities, and annotated with a timeline. It is indeed true that a picture is worth a thousand words. Swim-lanes allow us to lay out process steps, their sequence and precedence or simultaneity, and so on. Because we can draw swim-lanes at different levels of detail (ex. we can expand a process step in one diagram into several sub-steps in another diagram), we can depict a process in layers of complexity, going from the more general to the specific. This is an invaluable aid in managing complexity and gaining understanding. Engineering drawings for buildings do something similar, with electrical and piping diagrams on different ‘sheets’ (whether on mylar or on a PC screen) that can then be overlaid. We do not need to be graphic artists to ‘flow out’ a process. The most common used symbols are the oval or circle (start/stop), the rectangle (process step), the ‘diamond’ (decision/branching step), and the arrow (link between steps), as well as the ‘connector’ (any symbol that can ‘link’ two or more diagrams, and therefore allows for decluttering.) We always depict a process “as is,” not “as hoped for.” I discuss swim-lanes in earlier posts. NOTE: in parallel with a process view obtained via swim-lanes, one also needs to be able to simply plot data over time. This is needed, and beneficial very early on to get a sense of things, before more formal data collection.
- MATCHING SITUATIONS, ACTIONS, AND OUTCOMES — PDPC, or Process Decision Program Chart: this is a diagram in a form similar to that of a multilevel org-chart, expanding in inverted tree-like fashion from the top. Each level is linked to the one above and the one below. The top level shows a box describing the overall action plan. The next level down shows several boxes listing the main activities to be performed. The third level down shows more boxes, one for each task pertaining to a specific activity on the previous level. The fourth level lists “what could go wrong” for each task. The fifth level lists the fixes or countermeasures to each of the problems in the previous level. This is also a project-oriented tool of the “divide and conquer” school of thought, in that it breaks up a big problem into smaller, hopefully more manageable ones. The first three levels of this diagram are similar — in fact, identical — to those found in a WBS (Work Breakdown Structure), a tool you may already be familiar with from software development and other fields.
- SHARING AND COLLABORATION — A3 tool: this is as much an approach to solving a modest-sized problem as it is a presentation, documentation, and collaboration tool. Think of it as a mini-project control document that brings together the insights garnered from using the above tools and presents them in a cohesive fashion that all stakeholders can benefit from. I have a complete series of posts here on A3 development, and I refer you to them, in addition to the texts on the topic that I have listed on my Reviews page. Note that, by using it to document requirements, the A3 also acts as a Voice-of-the-Customer elicitation tool of sorts. It remains of primary importance to make sure that these requirements are massaged into critical-to-quality indicators and metrics.
As is clear from the above, these graphical and collaboration tools are not just suitable for the early phases of a PI project. While more complex analyses can and should be done with the proper statistical and modeling tools on the computer, a not insignificant amount of work can be done by understanding the basics and sharing this understanding with other stakeholders on the project if one uses the few tools suggested here.
Because defining a problem is key to solving it and because it is human nature to rush and skip steps in our hurry to get to “the answer”, learning to use these tools will serve PI novices well and provide worthwhile returns, helping them focus on making sure that the problem is properly understood and the right questions are asked early on. In line with a key Lean tenet, this will reduce the all too common waste — both in time and money — arising from having to rework a poor or incomplete problem definition phase downstream. As well, proficiency with the underlying skills required (see above list) will serve any of us, regardless of our field of work and our level of experience.