Problem Management tool of the trade

Last week i found myself at a Kepner-Tregoe Foundation course. The purpose of attending this course was to learn tools to plug into the Analysis part of the PM process.

I quickly learned something – this wasn’t plug-n-play. This was the classic theory of Common Sense put into a meaningful structure. Kind of like LEAN and ITIL. The theory was invented in the US in the mid 60’s for providing a structured approach when machinery on production lines in factories failed.

Sigh! Why is it that we always take theory of factory assembly lines and try to fit it into IT?

Never the less – it makes sense. Kepner-Tregoe provides 4 structural processes:


(the blue one in the middle is a process too)

  • Situation Appraisal
    • Recognizing that we have a Problem and determine if we need to analyze a current Problem, prevent a Potential Problem – or make a qualified decision.
      • Good for getting a detailed description of a deviation
  • Problem Analysis
    • Getting to the bottom of what is wrong, finding the true cause and consider possible fixes (a ‘trust-your-gut’ operation)
      • Good for documenting why you picked one fix over the other, and for ruling out fixes that seem promising at first glance.
  • Decision Analysis
    • Based on what we want to acheive we weigh the objectives to decide which alternative is the best solution.
      • Really good for making the best possible decision and explaining why. It’s based on math – and numbers don’t lie (do they?)
  • Potential Problem Analysis
    • Based on what action we want to do – what could happen and how do we prevent or handle it? (Did I say Risk Management?)
      • This is the simplest process of all – maybe too simple. But fast in use.

When I got back from the course I used some time to go through the material and pick out the most important parts. And since i like colorful drawings and nice models – I fit it all into one page, which I call : Kepner-Tregoe in 15 minutes.

It should be self-explanatory – later on I’ll provide an example that travels through all 4 processes for further clarification.

But go pick it up in the tools section and see if it will help your PM process along.


Share this:

The lure of jumping to conclusions…

You know her very well – the infamous succubus that is pulling all her stunts to make you jump to conclusions and just do a Change – because you believe it will solve a Problem.

Believing is decieving. Knowledge is key.

What is this about?

This is an example of real-life experience from a Problem Management Team. They’d been tasked with analyzing the root cause for recurring outages on the wireless network. The team consisted among others of a network administrator.

In the course of the analysis the Team came to a point where they had discovered strong indications as to what was the cause of the Problem. And it was very likely that they were right – although they based their findings on assumptions – not real proof.
So – they requested a Change that, with a small effort, would create an automated workaround for the Problem so it wouldnt’t occur anymore.

Alas – when it was time to review, the workaround wasn’t succesfull. There were still outages.

So – lesson learned. Theres a reason that ‘ass’ is the first part of assume. (Yes, i saw “The long kiss goodnight” too…).


Problem Management should find proof – never assume anything on how circumstances seems or appear to be – and never believe, but know!


Share this:

Back from the dead -and- My Problem was a dud

It’s been a while since I last wrote anything here. No excuses – that’s just how it goes. But now it’s time to kick a little life into this blog – I’m back from the dead!

back_from_the_dead“My Problem was a dud”

Problem Management is on a roll – we’re firing up new teams to handle Problems from the backlog and everyone is motivated.

We document how much benefit we expect from a solution to  a given Problem and dive head-first into analysis and diagnosis – only to find that what we thought was a Problem was not a Problem at all – but rather a misunderstanding from someone in the organization.

So – was it a waste of time? I think not. We did our homework and addressed the Problem like any other. That way we have a solid documentation – proof – that it’s not a Problem.

Of course I would like to solve issues to prevent incidents – that’s the main goal. But killing off myths about potential Problems has it’s benefits too.

  • You can prove that a rumored Problem does not exist
  • You can focus on the real Problem areas



Share this:

How to Categorize and Prioritize a Problem

Our Problem Management Team met today to start cracking on our first case (as mentioned in this post). The process we’re following is this:


The Problem was already Detected and Logged, so we ticked those off quickly. Categorization and Prioritization were the first tasks we needed to get done.

We decided on this standard:

Category : Is inherited from the initiating request. If it’s Service Requests behind the Problem Candidate – then the Problem is also categorized as Service Request. That way we keep in focus what the target we’re looking to solve is.

Prority : The Priority for a Problem is defined differently compared to Incidents for instance. This is important to keep in mind. A Priority 2 Incident doesn’t necessarily become a Priority 2 Problem. When setting the priority for a Problem we decided on the following factors:

  • Frequency : How often does this problem cause a request/incident?
  • Request/Incident priority : What is the priority of the request caused by this problem?

To illustrate this, here is the Priority matrix we use for Incidents:


And this is the matrix used to set the Priority of a Problem:



Of course other factors could be considered when it comes to category and priority:

Is there already a known workaround for this Problem?

Is there a SLA for the affected CI and/or Service?

How many users are affected when the Problem causes and Incident?

…and you could probably find several even more relevant parameters. Also – would you consider changing the priority as you learn more of the root cause or the required solution? I don’t know yet.

Our main goal was a simple method that looked similar to what our co-workers already know from the Incident process.

Feel free to let me know what you think of this way of handling the Category anf Priority of Problems.


Share this:

What is Problem Management ?

Some days ago I wrote a post about the launch of the Problem Management Team at my place of work. This is a sequal to that post.

What we did after the launch:

  • Created a mailbox for our co-workers to use as a suggestion box for Problem Candidates (w. an auto-reply to tell people what they can expect)
  • Identified Problem Candidates close to the work areas of the Team members
  • Started a board in the office where our co-workers will later be able to follow the progress of Problem Management

And we met again – this time focusing on selecting a Problem Candidate from our list to take for a test-drive. The Candidate had to :

  • Be in our own sphere of control. Meaning that in the team (or close to it) we possess the tools to handle the Candidate from cradle to grave, so to speak.
    • This is important since we’re using this candidate to learn – which is actually the main goal of solving this issue.
  • It has to have an immediate effect to:
    • The IT Department
    • Our clients in the company

The candidate in this case is a failure in the wireless network service at the company. It happens about once a month and theres a know workaround already.

Next – we discussed how to reach out to our co-workers, and tell them what the Team is about. Is this too early – do we really have anything to tell them? Well – I’ve written my second post about it – so, yearh – we do! Don’t wait until you have results. Invite your co-workers in and let them share their thoughts – early in the process!

So  – we emailed the IT department with a mail explaining:

  • Who is in the Team
  • What is Problem Management
  • What have we done so far
  • What is the next step

Short and precise. For the purpose of explaining what Problem management is, I pieced together a short cartoon to clarify the subject.


(feel free to use this however you please – but let people know where you found it 😉 )


Share this:

Downright funny!

Hi all – I just needed to post this somewhere as it send me laughing from work today 😉

First – I’ll give some insight into the Danish language to explain why it’s funny – and round it off with something about communication.

First. The beautiful Danish language.

“lignende” means “similar”
“ligene” means “dead bodies”
…they’re pretty close, right?

At the bathroom the cleaning crew left this message for us messy desk-people:


Roughly translated the message states:

“Please don’t pour coffee, tea or dead bodies into the sink.. It makes it difficult to clean properly.”

An honest mistake, really. But a prety funny one. Please note: I’m not taking a piss at the cleaning crew for their mis-spelling – as I said, it’s an honest mistake. (Around this blog you’ll probably find a fair share of spelling errors too :-))

But  – if we look beyond what the message is about and focus on the structure and information it sends – there’s something off.

First – they tell you what not to d0.
Then – it tells you why it matters to them.

and that’s it.

What they should have done was:

First – told you what to do differently.
Second – told you why it matters to you.

For example:

“Empty your coffee and tea in the kitchen sink. That way we can give you a spotless sink in the bathroom”

Why does it matter?

The same message is delivered and the effect for the cleaning crew is the same

The most probable question is already answered (“where do I empty the cups then?”)

It matters to the people who are instructed to do something different

Less negation (DO instead of DON’T)

AND – we address the Body-type first and then the Heart-type (as explained in this post)

All of the above helps delivering the message and making sure it’s recieved properly. And yes – you also need to consider this for a short message glued to a bathroom mirror.

Really? Dead bodies? ….


Share this:

Launch of the Problem Management Team

Today was a big day!

We launched the Problem Management team. With launch I mean three guys in a conference room trying to figure out how to get the waggon rolling…

But it was a good experience and I know it went well ’cause I walked away inspired. There’s lots of things to do!

We touched base by defining what a Problem Candidate is – and what it’s not.

“A Problem is the root cause of one of more incidents.”
“An incident does not have to become a Problem Candidate.”
“We do not solve incidents when they happen – we look at the wreckage afterwards to determine the cause.”

We decided on how to get Problem Candidates:

  • A mailbox for our co-workers to write to*
  • By asking the Support staff for re-occuring incidents
  • By traversing the Operations log for re-occouring incidents

*: So – when people write us, they’ll get a short ‘Thank you’ auto-reply telling them how the Problem Management team works, and what they can expect from us.

We decided on a visual reprensentation og the teams work on a board. And we looked to LEAN for inspiration. The board has to be operational, frequently updated – and make sense to those who look at it.

Here’s a crude hand-drawing of what we have in mind:


A : Is the Problem Management Process.
B : Is notes with Problem Candidates (and probably improvements to the process)
C : Is an Effort-Effect diagram we’ll use to prioritize the Problem Candidates
D : Is a PDCA (Plan-Do-Check-Act) wheel. The idea is to have the Problems we’ere working on placed in the wheel for our co-workers to see.
E : The fasttrack. Some Problems can be solved without an overhead of planning etc. Just-Do-It.
F : Closed Problems
G : Maturity. A meassure of how mature the Problem Management process is. The score is 1 to 5 (we’re at a 1 right now).
H : The performance of the Process. Here we display the CSF’s, KPI’s and PI’s (Critical Success Factors, Key Performance Indicators, Performance Indicators) of Problem Management.

I believe it was a good start. The team is focused and work well together. Next time we meet we’ll look at the Problem Candidates we’ve gathered, and find a Candidate that:

  • Has an immediate effect
  • Is within out own sphere of control

We’ll use this to try out the process our-selves – learn from it while we bring results to the IT department.

We’ll also discuss : Communication. What shall we tell the rest of IT about Problem Management – and how?

All of this in just one hour. I think this is going to be good 😉


Share this:

In the presence of the inevitable

Note : I started writing this post on April 8th.

This is personal. This doesn’t concern ITIL, Lean or Communication. This is about me and my family.

My mother is dying from cancer. She turns 65 in a few days – if she makes it that far. I am in a world of hurt and distress. I try to keep things together – I have to, ’cause my family depends on me. I have to show up at work and try to deliver as expected. But it’s hard. I thought i could busy myself at work and forget about death. But no. I find myself staring out the window at nothing in particular. But somehow I pull through.

I the morning I have to get the kids out of bed and ready for school etc. – and at night read them stories and tuck them in. And somehow I pull through.

We have had to take some difficult talks lately. Talks concerning all the practical aspects of someone dying. And that someone is my Mom. It weighs heavily on my mind and I find it hard to sleep, I’ve lost my appetite – and whereever I am I feel like I have to be somewhere else.

This is not a post for you. It is a post for me. This is my outlet. I have to write – move some of the words out of my head and unto the screen. I don’t know if it makes any sense – it’s just how it is, being me.

So – this was a personal post. I ripped open my ribcage for you to see my beating, bleeding heart.

Day 0 : Last breath

April 9th my Mom drew her last, ragged breath. I held her hand and told her that I love her. I hope she heard.

Day 2 : Anger

I’ve spent the last few days in sadness, choking on tears. They are still there threating to wet my eyes and roll down my unshaved chin.

But today I’m angry. I want to scream and punch something. I want to say something hurtful to someone and make them suffer – I want someone to pick a fight with me so I can transfer some of my pain onto them, spewing harsh words and waving clenched fists in their faces. Fuck. The. World.

But instead, I stay at home, alone. I do the laundry and busy myself around the house. The last days of turmoil has left the house in complete disarray – I think it looks the way it would if Gremlins lived here.

I write emails and messages telling people about the state of things and thanking them for their kind words. I have a job ahead of me, getting practical about the financial state of my parents. No, my Dad. Mom is dead. I push it in front of me, postponing it – because I don’t really want to talk to anyone. I just want silence and not to talk – not to figure things out. But I have to. People depend on me.

So, I’ll sign off now. There’s things that needs to be done. Right now everything is about someone else – it has been for quite a while. I look forward to finding myself again. Maybe when I do, I have changed and it will take some time for me to get to know me again.

But I’ll be back.


Share this:

E-Book on Feedback published today!

I am proud to announce the publication on my very first e-book (ok, it’s an e-pamphlet)!
It builds on my previous post on feedback and intends to give you, the reader, tools to start using feedback – today!

Check it out on Amazon – it’s completely free the next few days!
After this limited offer the cost is 0.99$ (I won’t get rich – you won’t get poor, and so the balance of the universe is maintained)

Feedback – 5 minute guide


Go get the book today  – and leave me your feedback – either as a comment to this post or as a review of the book on Amazon.
Let that be your first practical use of feedback based on this book!

All the best!


Share this:

The five signs of Divine will

The inspiration for todays post comes from a book I’m currently reading. It’s the “Malleus Maleficarium”, also known as “The Witch Hammer”. It’s written in the 12th (or was it 13th?) century by a couple of monks – and I stumbled upon the following passage, concerning will:

“Through his own agency he expresses it in two ways, either directly or indirectly. Directly, when he himself does a thing: and then it is Operation. Indirectly, when he does not hinder someone else from acting, and this is called the sign of Permission. And the human father signifies his will through the agency of someone else in three ways. Either he orders someone to do something, or conversely forbids something: And these are the signs of Precept and Prohibition. Or he persuades and advises someone to do something: And this is the sign of Advice. And just as the human will is manifested in these five, so is God’s will.”
Quote from “The Malleus Maleficarium” (a.k.a. “The Witch Hammer”), Heinrich Kramer and James Sprenger


I thought when reading this that it was actually a set of tools for getting a certain task done – or a way of leading a work-force even.

Operation : Do it yourself
Permission : Let someone else do it on their own
Precept : Tell someone to do something
Prohibition : Tell someone not to do something
Advice : Advices on how to do a thing

We could play around with these words – put them in order. A given task needs to be done, and it’s initiated by a manager.
First he advises his employees on how to start on the given task, and they start out on designing a solution. He then gives permission to execute the given solution, and tells them to do it.
They screw it up, and the manager tells them to stop what they’re doing and does it himself.

1. Advice
2. Precept
3. Permission
4. Prohibition
5. Operation

Given the circumstances a manager will lean more towards one expression of will more than the others. It all comes down to the type of task, it’s urgency and severity – and possibly other factors.
So where am I going with this?
Nowhere actually – I just found it interesting that a religious paragraph 6-700 year old could be used to describe different ways of initiating execution of a task today.
Next time a tedious task lands on my desk – should I Advice someone else on how to solve it?
When faced with an abundance of tasks concerning moving changes to Production systems – should I give the developers Permission to execute the move themselves?

I feel there is something here – it is not quite operational, but I think I’ll try to consider the 5 signs of will next time I start out on a task.
Think it over and leave your feedback!
Does it make sense or am I just rambling?


Share this: