The IT Skeptic - Comments for "Incidents overwhelm problems"

Very True

M.McEvoy — Wed, 04 Mar 2009 08:21:33 +0000

And often "important" Service request don't even follow the Service Desk route as these are made outside the formal process.

You are welcome to use it

mbuzina — Tue, 03 Mar 2009 12:46:57 +0000

The world needs both, the cynical jokes that make fun of those stopping or slowing progress, as well as the vailliant effort in convincing, explaining, documenting and proving that a professional approach to IT is better.

Unfortunatly professionalism does not always win in direct comparison. Sloppy IT can be much cheaper when you are not looking into the details and well, they throw good parties or can swing a great drive on the green...

Oh, not to forget, for some austere ideas on problem management, read http://buzina.wordpress.com/2009/03/03/itsm-series-2-problem-management/ on my blog.

a contribution to Real ITSM

skeptic — Tue, 03 Mar 2009 10:11:14 +0000

Love it! I'm copying this over to www.realitsm.com. Thankyou!

RealITSM is not how it should be, but how it is (unfortunatly)

mbuzina — Tue, 03 Mar 2009 09:52:56 +0000

That sums it all.

There is also another urgency vs. importance scheme well used in many companies and it is even simpler. It does not take into account what process is triggered, but it looks at the origin of the issue. It is like this:
- Is the request made by the CEO --> Urgent & Important
- Is the request made by direct CEO reports --> Urgent
- Is the request made by well connected managers --> Important
- Is the request made by anyone else --> Who Cares

underlying pattern?

skeptic — Tue, 03 Mar 2009 08:12:57 +0000

i said it is over-simplistic :) And it is cynical. It reflects a tendency, as it is in the ugly world, that they tend to fall out that way. Exceptions can always be found buy maybe it suggets an underlying pattern?? An undesirable one.

I disagree with your diagram

M.McEvoy — Tue, 03 Mar 2009 08:01:34 +0000

I think all four processes can fit in any of the segments and should be prioritised on a case by case basis. It is a mistake to think some processes are more important than others. Changes are not always urgent and high importance and requests can be urgent and high importance as with incident and Problems. A data center move can take up to 3 years and have many associated changes - important but not urgent (unless poorly planned). A request for R&D to access a new source of information that will give the business a competitive edge for many industries is both important and urgent.

Not bad being "The Problem Manager"

mbuzina — Mon, 02 Mar 2009 21:35:26 +0000

If you notice the capital letters, you can immediately see that this is a position of importance. Most organizations I have been to value someone who can go in when the sh*t hits the fan and make sure the job gets done properly.

But yes, this is the single most biggest issue in the immature shops, strength only comes from the hierarchy and working (which is a requirement for problem management as for most other roles in ITSM) is not the common mode of hierarchical types in an immature shop. The expect that being the "Manager of Production" (again capital letters) is enough, except struggling with others for the next promotion....

Suffering incident metrics is one of the many reasons to seperate incident management & problem management responsibilities.

The scenario you provide can be used as the best promoter of pm. I requested the resources to fix this issue before it came and I did not get them on time. Do this a few times and maybe the other managers won't like you, but upper management visibility will be there ;-)

The most important skill for PM is: know your shop (people, the secret decision paths as well as the technology) and don't suffer from business myopia (I hope this translation hits the spot).

Problem Management a Cultural Problem

Glen — Mon, 02 Mar 2009 18:23:34 +0000

I have always said that being the head of PM requires high political IQ/EQ.
Take the following scenario...
So you take the time to build a process to identify and manage the recurrent issues with your infrastructure.
Then something breaks that you had documented already. If you have not got into the workaround, knowledge sharing phase, it can suddenly become your fault. "Since you knew about it and did nothing to prevent it..."

Problem Management has another issue in that by removing the chronic incidents permanently, the incident management metrics can suffer...Why is first call resolution decreasing?

So PM needs to really have a strong champion capable of selling the benefits and making others look good.
It does not hurt to have some formal training in root cause analysis techniques and quality management.

Last thought, does anyone out there want to be known as The Problem Manager?

just 2 cents.