Blog - IT CSI

Yes, it is different! Project Management practices have evolved into highly professional techniques and tools, but sadly the “managing” part for some reason lagged behind and never enjoyed the same status. This is especially true in the IT community.

ITpreneurs partners with Thinking Dimensions Global, an international consulting and training services organization.

Learn a groundbreaking approach to finding the Root Cause the first time every time.

First seen on Cision PR Newswire.

How to identify the reason an incident occurred by asking just 5 questions? (And these are not the 5 WHYs...)

Our approach is surprisingly simple, single-minded and focused. Every action is based on finding the CORRECTFAULT! Almost every time when our consultants get involved with a Bridge Team trying to restore an action, we find them floundering to identify the correct fault. All we do differently to what has been tried before is ask searing questions of the SMEs that focus on the fault.

(There are little support for our resiliency plan!)

Most IT Professionals do not make the distinction between the Technical Cause of a problem and its Root Cause. These terms are often used inter-changeably or worse case, there is no distinction made between them at all. The IT Professional who “gets this” distinction has a major advantage over his/her colleagues in determining a Root Cause quicker, cheaper and permanently. The trend of recognizing this distinction will grow in the years to come.

I am a professional problem solver. When I started applying my skills set as an Industrial Engineer to the IT environment, I was astonished at the maturity level of troubleshooting skills, specifically Root Cause Analysis, in this sector.  I became aware of a  whole generation of IT Professionals who have never been taught the fundamentals of deductive reasoning or critical thinking skills. There was (mis)use of the “5 Whys” technique and attempts to clone branded solutions to in-house situations, but little else in RCA. That has changed gradually over the last 10 years, but there are still some very basic problems and obstacles in getting RCA properly embedded into the Service Management environment.

Into the Incident Experienced

In an incident situation,we are always looking for that “Silver Bullet” question – the one question that would bring some insight to the incident being experienced. The good news is that there is such a question; in fact there are a few of these questions that could provide you with that insight needed. We call that the “but not” question.

Simple Question, But Powerful!

One of the most important questions to ask yourself in attempting to solve an incident quickly, accurately and permanently is to ask the following three questions:

1. What do you know about the incident?
2. What don’t you know about the incident?
3. How can you collaborate with whom that could provide you with this missing information?

Over the years as a consultant, I’ve learned how to listen to what people are saying, albeit doing it for a different reason you might have had in mind. I am doing it to eliminate the “noise” and “clutter” normally surrounding problem solving sessions. This might surprise you, but the biggest obstacle in solving problems and incidents effectively, is the human nature to “elevate” or escalate things in order to get the appropriate attention of the other person.

We recently had some surprising feedback from one of our clients…surprising to them anyway, and in a good way. We were leading a large continuous improvement exercise for the IT division of a global financial services company.

The key lies in asking the right interrogative questions to the right people in order to identify the correct restoration criteria for a quick and accurate restoration. It is easier than you think when you follow a process that can be used in any type of incident. It is all about three components namely; OBJECT, FAULT and UNIQUENESS of the fault.

What do you do if you need to make a decision and one of your most important stakeholders is on the other side of the world?

VIRTUAL COLLABORATION...

Global organizations find it increasingly difficult to deal with decisions and investigations effectively, especially if some of the stakeholders and information sources are not in the same location. How do you ensure you get the best information at all times, especially if your company is located over different time zones?

Time, Money, Service Quality, and People; these factors and the balance between them are the foundation of any improvement initiative. They are fairly easy to identify and measure but do they address the root cause of your woes?

Which one are you?  The challenge in most organizations today is the lack of efficient and capable problem solvers. Problems are caused by either a combination of three components, namely: People, Process and Communications. When crisis or major issues occur in large organizations, blame game is not uncommon. Hence don’t fire or change your staff, but change the way they think and ask questions.

Why it is so difficult to find an accurate and verified root cause… and what to do about it.

Firstly, there is a great deal of confusion about a Root Cause as opposed to a Technical Cause. Secondly, you cannot really determine a verifiable Root Cause before first identifying a Technical Cause.

It does not matter how good your planning is or how well you’ve put your project plan together, there will always be unforeseen circumstances that need to be resolved!

As a project manager, the problem solving process is normally started when any of the following situations arise:

This is the most misunderstood concept in managing projects.

(Managing Projects blog 7 of 8)

Whenever we get involved with a team to help them to rescue their project, we quickly encounter the term “not aligned.” I mean this happens 100% of the time, which means there is always an element of misalignment. Here are a few examples:

How to Avoid this Pitfall

(Managing Projects blog 6 of 8)

Whenever something goes wrong in a project’s performance it is often blamed on “scope creep.” Scope creep has become such a familiar feature in project management that it is mostly accepted as the correct reason and even worse, being accepted as a fact of project life. The prevailing belief is that it cannot be helped, it is “beyond the PM’s control,” and therefore is part of the necessary evil in managing projects. Not True!!

Do you even know who they are and why they are important to you?

(Managing Projects blog 5 of 8)

It is a serious mistake to assume that all resources allocated to your project are equally motivated to see your project becoming a success. It could be possible that a critical resource does not have any insight or interest in your project whatsoever and they are one of the resources to deliver a critical component at a particular time.

There are two components important here. Firstly, you need to know who your resources are and you need to align them in an appropriate way. Secondly, you need to make sure you know who are your important resources that could make or break the success of your project. We will discuss the importance of both and what you can do to “arrange” this for your own project.

Better the devil you know than the devil you don't. 

(Managing Projects blog 4 of 8)

We normally say, “The devil lies in the detail” and that is the exact same impact if you are not being specific in what you do in project management or even more precisely when you are managing projects.

You don’t know what you don’t know is very true, especially if you are dealing with complex issues and relationships in project management. So, when managing a project you will rely heavily on factual and exact verified information, otherwise you would be doomed to failure. We suggest very specific process questions you could ask that would help you to derive explicit statements from staff, vendors and customers.

Why is this so difficult to get?

(Managing Projects blog 3 of 8)

Accountability is normally not fully understood and we’ve found in many cases this continues to be the situation for not having adequate accountabilities for project objectives and outcomes. There tends to be a misunderstanding between the terms accountability and responsibility.

...or be prepared to deal with a toxic fall-out!

(Managing Projects Blog 2 of 8)

Is this a Freudian slip or is it different than PROJECT MANAGEMENT?

Yes it is different! Project Management practices have evolved into highly professional techniques and tools, but sadly the “managing” part for some reason lagged behind and never enjoyed the same status. This is especially true in the IT community.

The Acid Test for Finding Effective Root Causes

If you cannot develop a useful hypothesis for a specific problem situation, you do not have a worthwhile cause to be considered. A hypothesis in itself is a test of your ability to link a cause to that of the incident/fault experienced.

If you want to put fear in the hearts of IT Professionals, ask them to “think out of the box.” It is not that they cannot do it rather than the fact that they are not used to doing that in dealing with IT problems and Incidents.

...is a Common Problem Solving Process

How do we ensure we get the best information at all times for virtual collaboration, especially if our company is located over different time zones?

Global organizations find it increasingly more difficult to deal with decisions and investigations effectively, especially if some of the stakeholders and information sources are not in the same location. What do you do if you need to make a decision and one of your most important stakeholders is on the other side of the world?

This will get you and your team to the core in minutes!

If you could not restore a service within three hours there is something unique about the fault being experienced – do you know what it is?

It is a fair assumption that if you experience an incident that is typical and normally has typical causes then all you have to do is to find which cause is the culprit this time. An example would be when you cannot get logged in to your normal email service. You know from your own experience that only a few things could cause you to be unable to get access. You quickly check these normal factors until you have found the cause and “solved” the situation. 

Into the Incident Experienced

In an incident situation,we are always looking for that “Silver Bullet” question – the one question that would bring some insight to the incident being experienced. The good news is that there is such a question; in fact there are a few of these questions that could provide you with that insight needed. We call that the “but not” question.

Simple Question, But Powerful!

One of the most important questions to ask yourself in attempting to solve an incident quickly, accurately and permanently is to ask the following three questions:

1. What do you know about the incident?
2. What don’t you know about the incident?
3. How can you collaborate with whom that could provide you with this missing information?

Over the years as a consultant, I’ve learned how to listen to what people are saying, albeit doing it for a different reason you might have had in mind. I am doing it to eliminate the “noise” and “clutter” normally surrounding problem solving sessions. This might surprise you, but the biggest obstacle in solving problems and incidents effectively, is the human nature to “elevate” or escalate things in order to get the appropriate attention of the other person.

Many IT Professionals look at the same set of data and come to the conclusion that the raw data as it is represented at the time does not add any clue for a conclusion. That might be true, but if you know what to do, that same set of data could be transformed successfully into highly useful insights into a problem situation. The secret is to use a process that would allow the investigator to transform the data into useful information. How do we do that? Like I said, using a specific process such as the following:

Over the years as a consultant, I’ve learned how to listen to what people are saying, albeit doing it for a different reason you might have had in mind. I am doing it to eliminate the “noise” and “clutter” normally surrounding problem solving and root cause analysis sessions. This might surprise you, but the biggest obstacle in solving problems and incidents effectively, is the human nature to “elevate” or escalate things in order to get the appropriate attention of the right person.

"Hearing the words "outage" or "crash" in an I.T. environment is not something you would like to hear on your watch..."

Do you have the majority of incidents being caused as a result of project or other releases into production?

Do you often have a 'Bad Feeling' about a changes that are going in? 

Thats right, the dreaded RISK word. In most cases Risk analysis conjures up bad thoughts and ways to quickly address the risk tabs in the change record adequately enough to get the change approved. Maybe a quick 'cut & paste" from a similar change? I have seen this, been guilty of doing it, and seen many other poor practices in companies I have worked for and consulted with over the last 28 years in my career.

How do fighter pilots (top guns), firemen and other emergency workers deal with a crisis situation? They go onto “automatic mode” which was drilled into their psyche over a period of time…

Ever wondered why pilots are trained on simulators? They are trained to quickly ascertain a snapshot of what is happening and what is not happening. Based on these nanoseconds of bits of factual information they are trained to make “snap” deductions and produce the most appropriate actions.

There is another answer to my “WHY?” question and that is rooted in the physiological set-up of our bodies. When faced with a crisis situation our adrenalin pumps excessively and everything we do become an automatic reflex and not necessarily a rational response. We need to get the brain to reconnect to our bodies (including our speech) and the best way to do it is through a renewed intensive focus.

“The most effective decision in modern business today is a decision that consists of various actions implemented over a period of time.”

Making a Choice

When people skills are discussed in respect of Root Cause Analysis, the remark is often heard that it should be easy to use and also that it should be quick.  From this perspective, often the choice is to use the “5 Whys” method, since it is ‘easy’ and ‘quick’.  This approach to selecting a problem solving tool clearly demonstrates a fundamental misunderstanding in respect of not only root cause analysis, but problem solving in general.

When deciding about root cause analysis and problem solving skills, we need to start with the issues we need solve and not people.  Not all problems are the same, it is common that problems differ vastly and that some are more difficult to solve than others.  Keeping the foregoing in mind, the nature and level of difficulty of a problem must therefore dictate the selection of the problem solving tool, rather than the fact that the tool may fit the desire of being simplistic and easy to use.

On a day to day basis our attention is consumed by events and incidents to which we react.  In response to some of these, we drill down and do root cause analysis to ensure that an incident does not recur.  Somehow it does not cross our minds that whilst we are doing the right things, we are only doing so reactively based on what has already happened.  We are in a perpetual cycle of fire fighting!

"It's not that they can't see the solution. They can't see the problem." - G.K. Chesterton

According to the Standish Group, a successful project must be completed on time, on budget and deliver the promised quality.

Of the many Standish Group reports published since 1994, two of the top five causes for failed IT projects have been given as:

• > Incomplete Requirements
• > Lack of User Involvement

Now that we have identified these two causes for failed projects, let’s examine what can be done. We could look at the project from a proactive or a reactive perspective but as the title of the blog is “Rescuing IT Projects,” the assumption is that we are looking back on faults/incidents that have occurred

Dealing with end user incidents dominates service management environments.  Once the incidents are resolved, the service environment relaxes.  Resolving an incident implies less pressure from users, because no problem exists. 

IT Service Desks have a primary responsibility to “Maintain End User Satisfaction with IT Services”. Think of internet banking services: if the end user could not use the service at the time they wished to do so, it would be unacceptable to him/her.  The end user never accepts that “we met Service Level Requirements and are therefore performing well.” If the desired service is not available and functionally working, we are simply not meeting end user client requirements.

The foregoing is a dilemma; our service management can never be fast enough and we need to continually find ways to deliver faster without compromising quality of work.  Unless we become blazingly fast, the end user client will not only lose faith in us, but in this day and age will be very vocal about it, possibly causing reputational damage to the service provider.  

“We thought that we had the answers, it was the questions we had wrong.”

 Edward de Bono

What Edward de Bono had to say rings very true with a high percentage of the problems that we are presented with, if the right questions are asked at the outset of the process it can save you a great deal of time and a lot of unnecessary tears and frustration.

How to gather, what to gather, where and when to gather

“People ask me questions, lost in confusion
Well – I tell them there’s no problem, only solutions”

John Lennon – “Watching the Wheels “

We at Thinking Dimensions Global have our own definition of Convergent Thinking and yes it does fit in with John Lennon’s lyrics – though he did pen the lyrics before we came up with the definition. We see convergent thinking as “reflecting a tendency to analyse relationships between several parts of a problem and to find useful links, connections or patterns.”

“The problems are solved, not by giving new information, but by arranging what we have known all along.”
Ludwig Wittgenstein Philosopher (1889 – 1951)

As we approach more complex problems to solve we acknowledge that we cannot provide all the information ourselves to work through the required processes.

Using the same old key to unlock IMPROVEMENTS in the IT performance? Want a new key?

How good is your IT incident investigation? CIO’s may answer this question by having this thing in mind: “We seem to fight fires all the time and never have enough time or resources to resolve critical MIS issues permanently.”

Nothing beats a well-trained skilled team with specific roles and good leadership.

We see teams like these all the time in various sporting events. The skilled team using a specific model with a resolution process, including the appropriate tools and techniques, will beat a chaotic situation every time.

Lessons from a client

Does your staff have the right tools to Investigate and eliminate unwanted IT costs? The most challenging question for CIO’s and CTO’s to address.