Incidents overwhelm problems
Problems suffer from the important/urgent dilemma. They are very important but struggle to get attention in the less mature shops over the incoming bombardment of incidents.
This is over simplistic but cute, from Real ITSM:
Important vs urgent
Without an effective, ring-fenced problem management process, an unstable environment forces Support into total firefighting mode.
Categorising Requests as low/low is highly debatable but it had a nice symmetry about it in Real ITSM - remember I'm talking here about shops that range from the low maturity ones to the completely dysfunctional. When your ass is on fire, requests can wait too.
Introduction to Real ITSM page 58
Made in New Zealand 
Comments
Problem Management a Cultural Problem
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.
Not bad being "The Problem Manager"
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).
I disagree with your diagram
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.
RealITSM is not how it *should* be, but how it is (unfortunatly)
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
Very True
And often "important" Service request don't even follow the Service Desk route as these are made outside the formal process.
a contribution to Real ITSM
Love it! I'm copying this over to www.realitsm.com. Thankyou!
You are welcome to use it
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.
underlying pattern?
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.