Skip to main content

Improving Patch Management, A Measured Approach Part 2

April 07, 2015

(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 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.


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.

Improving Patch Management 1


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.”

Improving Patch Management 2


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.

Improving Patch Management 3


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.

Related Blogs

April 16, 2015

East-West Visibility: Seeing the Peripheral Threats

East-west visibility refers to the ability to see traffic or malicious activity that is contained within your network. After an internal or external a...

See Details

April 20, 2015

Leveraging IPAM in your Security Program

Internet protocol address management (IPAM) is a task often reserved for the networking or telecommunications team, and most security practitioners ar...

See Details

February 19, 2015

Improving Patch Management, A Measured Approach

Organizations face a daily barrage of new vulnerabilities identified in a host of applications and operating systems. Through the deployment of a soft...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy

Related Insights

June 14, 2017

Incident Management Plan Development

We have the experience and knowledge required to help your organization develop a strong incident management plan.

See Details

July 21, 2015

Data Security Solutions

Learn how we can help secure your date throughout its lifecycle.

See Details

November 12, 2014

Empowering the CISO

A security-focused business culture can empower the CISO to effectively perform their job, and allow them to become a respected member of the “C” leve...

See Details

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.