Problem solving is a very human specific capability that can be honed as time elapses. Most of us are great solvers yet have difficulties isolating what really is the problem. Lets look at the root cause for this and how organizations take it.

Roots by Eva the Weaver at Flickr - Some rights reserved

More context for problem management is in order. On Rob England’s Review of recent ITIL studies paper, one of the studies analysed gives this quantitative information:

“problem management – a process that requires organizational maturity and commitment – is the ITIL process most firms are currently [2010] implementing (24%) or planning to implement (24%). Furthermore, 43% currently follow ITIL problem management processes, reflecting a 91% adoption/soon-to-be-adopted rate among those surveyed.”

It looks as everyone has joined the tribe. But as Karen Ferris comments, from her own experience, organizations have problem management in paper but not in practice, actually having major incident activities going on and calling it problem management as opposed to regularly applying root cause analysis techniques.

I’ve found this to be true here in Portugal too. There’s a blur between incident and problem activities. Due to greater visibility (and pressure from business) on incident resolution, IT folks avoid problem solving and keep a reactive operational attitude while at the same time mortify themselves for not having done it using problem management techniques.

Truth be said, reactive problem management activities are pretty similar to incident management lifecycle, even though it introduces Known Error handling. Incident management and service desk, are the traditional first wave on service management adoption. This means that when problem management concepts and activities are introduced, technical oriented people will already have an incident-centric mindset way of doing things that has to change. Separating cause from symptoms activities is hard because they are so interdependent and before the coming of problem management all was incident management territory.

So care should be taken to clarify it’s own goals, focus and activities so it’s not confused with incident management on steroids. It’s on the proactive facet that problem management really stands on its own, thus a culture of preventing coupled with problem solving techniques has to be instilled.

Besides solving problems because they are causing impact right now, one can look at weak points of our management resources and capabilities in order to effectively remove latent causes of under performance or failure. So, it is an organizational capability that can switch from chaotic OPEX costs to predictable CAPEX costs (for more on this do check this article from Antonio Valle).

This systematic, proactive error seek and eliminate path deliberately walks way of ingrained reactive incident modus operandi, thus providing a new frame of work where people can truly adopt problem management without preconceived habits.

More on this topic here:

• A deceptively simple book on problem solving by Ken Watanabe (not the actor):
• Hank Marquis wrote good posts on this
• Mush and Room take on the problem versus incident

My three things for this week... inspired by J.D.Meier

From a quotation I read this morning I met again J.D.Meier’s blog and found his 30 days of getting results manifesto [in J.D. Meier words this ebook "is a collection of little lessons you can use to improve your personal productivity and personal effectiveness"].

Broke the rules. Read day 1 and day 2 at once! I will tell you how it went for me next Friday. And in 30 days.

Have a phenomenal 2012!

Até já,

Rui

Security by Loopzilla at flickr - some rights reserved

[from: http://www.flickr.com/photos/loopzilla/2073400408/]

How should one go about regarding security for IT services?

One can look at it taking in account the service lifecycle approach from ITIL and concentrate on the Design phase, when we can invest early in order to achieve that honorable goal of having the minimum (avoidable) surprises and rework when service finally goes live. In other words, reduce operational costs by designing services right.

Some ideas (in no particular order):

1. Ensure external partners and suppliers that contribute to the services know and formally agree to their responsibilities (Underpinning Contracts)
2. Also get internal groups/teams formally agree on their responsibilities (Operational Level Agreements)
3. Changes to the services must include security impact assessment
4. A procedure for receiving and acting on security vulnerabilities reported from vendors of components that support the service
5. Include an explicit security section regarding security requisites in the initial analysis phase for new or changed services
6. Link the security requisites to service level targets so the SLA covers them
7. Check those requisites with customer when feasible (or at least with yourself if you’re a good candidate for using the service)
8. Make sure security tests are covered in the test plan
9. Then, while transitioning the service, perform the security tests
10. Have experts trying to break your service from outside and inside
11. Use the tools. There are technical tools and best practices you can apply thus avoiding reinventing the wheel or forgetting important checks
12. If a security incident happens is it clear for everybody who must be involved and what to do?

Yes, some of these will happen in the Transition and Operation phases even though their planning occurs before.

Love to hear about more ideas!

ISO/IEC 20000:2011 Service Management System and its Processes diagram

This time you can have the ISO/IEC 20000:2011 diagram showing the current structure for this service management standard.

ISO/IEC 20000:2011 Processes Diagram (PDF – English)

Use and share.

Infinite Wisdom by Ksioninc at Flickr - Some rights reserved

As before, this official Glossary is a quite useful and free reference on ITIL. You can get this on other languages here (on this post date the list included: Brazilian Portuguese, Simplified Chinese, German, Korean, Romanian, Russian and Latin American Spanish).

ITIL v3 2011 edition Glossary  [English]

ITIL v3 reloaded (the 2011 edition)

Room for a timely review on ISO 20000

Service Strategy

• Key concepts and diagram clarification
• New two processes: Strategy Management and BRM (at last! Business Relationship Management existed on ISO/IEC 20000 and was missing on ITIL)

Service Design

• New process: Design Coordination
• Service Catalogue clarification

Service Transition/Operation

• Little changes to Service Transition/Operation
• Some workflows were corrected (e.g., incident management)
• Proactive Problem management expanded

CSI

• CSI Register: New concept, to register all CSI initiatives going on
• 7-step improvement process changed
• CSI/Deming cycle and Knowledge Mgmt links clarified

ITIL v3.1 - 2011 edition covers

The ITIL v3, 2011 edition comes out next 29th of July.

Drive: Mastery

So. So as Daniel H. Pink states I suggest one approaches all in life with a learning attitude, regardless of how mundane and repetitive the task you’re focusing on may be .

Drive: Mastery - Learning versus Performance