Improving Patch Management, A Measured Approach Part 2

By Tyler Mullican ·

(Introduction to the Analyze Phase)

After completing the “define” and “measure” phases of the DMAIC (define, measure, analyze, improve, control), organizations following this method will conduct the “analyze” phase. The goal of this phase is to determine why there are problems in the process. Another way of understanding this phase is to ask, “What is the problem’s cause?”

Using information gained in the define and measure phases, you may have a good understanding of what is causing performance problems. Information should not be trusted at this point; the DMAIC seeks to confirm all suspicions with data. Confirming suspicions allows for controlled, prioritized implementation of changes. Additionally, we should focus our process improvement efforts on three to five causes. By focusing on these causes, we do not introduce too much change to the existing process.

There are many commonly deployed tools used in the analysis phase of the DMAIC. When undertaking process improvement of a software update management (SUM) program, an easy way to think about tools is to divide them into two primary categories – identification and organization.

Identification

Identification tools are utilized to help recognize the causes impacting the performance of a process. By employing brainstorming, individuals involved in the process can review the data gathered from the measure phase to theorize about possible causes. Additionally, the popular “5 Whys” tool can be used to determine the root of a problem. The idea is simply to continually ask “Why?” until a root cause is reached. The number five is considered a guideline for this tool and not a set constraint. With the insights gained from utilizing this tool, causes impacting the performance of your SUM program should begin to surface. Compiling and organizing these potential causes will allow for a systematic assessment.

Organization

Utilized for its organization capability, the Ishikawa or Fishbone diagram defines a problem and its major factors. This allows for logical analysis of each cause. By analyzing each cause and verification of the cause through data, informed improvement decisions can be reached.

Utilizing a hierarchical structure, root causes are grouped under major factors. In the case of SUM, common major factors include “people,” “methods,” “technology” and “policy.” Frequently derived from concepts such as 5Ms, 7Ps or 7Ss, the major factors can differ between industry and project and should be a representation of the factors that have been identified as directly impacting the problem.

After the major factors are identified, causes related to these factors are defined. By separating causes into overarching influencing factors, this technique combines brainstorming with mind-mapping, producing an effective tool for analyzing problems.

Building Your Own Fishbone Diagram

As we advance through this series of blog posts, we will spend time on different major factors and causes that comprise a Fishbone diagram designed to improve your SUM program. To start us on this journey, let’s discuss the basics of a Fishbone diagram so you can build one along with us.

1.       Identify the problem

a.       Reference your initial charter and define the problem that you are trying to solve.

b.      The problem should be written down and a straight line drawn out from right to left. This will effectively form the “head” and “spine” of the Fishbone diagram.

 

2.       Identify major factors

a.       Think of this step as the 50,000 foot view, defining major factors that impact the problem.

b.      Each factor should be written on a line extending out from the “spine” of the diagram to form the “bones.”

 

3.        Identify causes related to the major factors

a.       Each cause identified, related to the major factor, will be placed on a line extending from the major factor line. This will complete the “skeleton” in the Fishbone diagram.

 

In the next addition to this series, “Drawing the Methods Line,” we will explore common causes related to the methods line and attempt to confirm each cause through the introduction of measurement tools.