In a recent webinar, Chris Pope and I discussed the barriers to proactive problem management, and good practices, before looking at how problem management thinking and technology is evolving. This blog covers the good or best practices — what would you add (or remove)?
The deck can be downloaded here.
Best practice #1: don't just do problem management, justify it
Don't just do, or say that you do, problem management because ITIL has it as a "required" process.
There are probably 15-20 ITIL* processes you aren't doing so it really isn't a good route to take. As with anything IT does, it should be justified based on a valid business need. So as per my previous statement about the holders of the purse strings needing to understand problem management, the powers-that-be need to understand the impact of not doing problem management as well as the benefits of doing it.
Rather perversely, you might need to undertake some initial problem management activity in order to justify longer-term activity. It can be pretty basic stuff such as the analysis of incident management data and conversations with key customers to identify a sample of problems that will allow IT to establish the business-wide costs (financial and otherwise) associated with problems, faults, or recurring incidents.
When compared to the costs of undertaking problem management activity, the organization is then able to isolate the potential value of proactive problem management. If it makes business sense then push to do it. If not, then don't. But it isn't a one-time analysis — keep checking on the value of problem management for your organization no matter what the first result.
Best practice #2: start small, stay focused
Importantly, organizations shouldn't try to do too much too soon.
Resource should be focused on a prioritized set of initial problems with activity ramped up as successes are achieved. IT also needs an initial problem management strategy that's focused on planning, and delivering, services that are closely aligned to business requirements.
This more business-oriented approach will help keep IT grounded in the real reasons for problem management and hopefully away from "analysis paralysis." As with having an asset database that's 95% accurate, if no one uses the gathered information then what's the business benefit?
Best practice #3: when the time is right, invest further
Once an organization has longer-term corporate commitment to problem management resource, it needs cradle-to-grave processes formalized right across the problem lifecycle (obvious I know). But think about it, there's no point being world-class at problem identification if few problems ever get resolved.
This is where the ITIL best practice processes can help an organization …
Where the problem control process will result in one of three outcomes; that a change is required to correct a problem, a problem cannot be fixed but a workaround has been identified, or no fix or workaround have been identified.
It's important to recognize that these three problem "states" aren't mutually exclusive and that a problem may move between them over time. So for instance, when possible, a workaround should still be made available whilst a problem is awaiting the implementation of a required change.
Best practice #4: understand the benefits and limitations of a tool
Don't get me started on RFPs. That's tooling by the numbers. Do these "required capabilities" look familiar?
- Does the tool differentiate between incidents and problems?
- Does the tool automatically allocate a unique reference to newly created records?
- Can each problem record the identity of the source of reporting of the problem?
- Can you categorize problems?
- Can you prioritize and assign problems?
- … workarounds, known errors, etc.?
Having ticks against 1000 granular problem management capabilities doesn't mean the tool will really help you to "do" problem management without the right focus and people.
Best practice #5: measure and communicate success
As with many business processes, the efficient and effective operation of problem management requires fit-for-purpose performance metrics. For example, critical success factors could include visibly improved service quality, problem-related cost and productivity impact minimization, and the reduction in the cost of problem management.
These should be supported by a basket of appropriate KPIs and metrics that cover operational performance and those that also cover the business perspective. Stuart Rance's problem management metrics blog takes a deeper dive. As a brief aside, in another blog, Stuart also suggests that problem management be replaced by fault management — I have long thought that IT professionals could learn a lot from engineers.
And communicate successes; importantly, not in IT terms but in business terms.
Best practice #6: stand on the shoulders of giants
Learn from those who have succeeded with problem management — those that have been there, done it, and bought the t-shirt. They will offer up gems such as:
- "Identify your business' top 5 or 10 problems and focus on them first"
- "Incidents will always take priority over problems if managed by the same people"
- "This is how we justified investment in problem management …"
- "Quality of information about services and assets, plus knowledge articles (workarounds and known errors), is key to problem and incident management success"
- "This is how we report our success — look at how we point to business not IT factors …"
Help with problem management (and other things) is out there if you know where to look.
Well that's it from me and what I said in the webinar. I'd love you to offer up more best or good practices by way of a reply below.
The webinar can be watched on demand here.
Related ServiceNow Community content includes:
How have you quantified and communicated the value of problem management?
Which problem management methodology do you prefer to use?
Problem Management Webinar Q&A Responses
Learning From Others: How Does One Stand on the Shoulders of Giants?
When is a Major Incident a Problem?
* The ITSM best practice framework formerly known as the IT Infrastructure Library
Image source: Flickr: Photos by Mavis' Photostream
3 Comments
