Joined: Feb 12, 2007 Posts: 27 Location: Minneapolis, MN, USA
Posted: Sat Aug 07, 2010 7:50 am Post subject: Scope of problems
After a major incident review (which our Problem Management team facilitates), we often find opportunities for the future and document them. Some of these are technical in nature and turned in to problems and actioned (e.g. a known error in current version of driver which needs to be fixed, etc), but some opportunities are staff related. Perhaps the DBA on call that evening lacked the skillset to quickly identify or escalate an issue. My director thinks that problem management should track that issue to closure, because if it is not addressed, it threatens our ability to circumvent future issues and is a threat to the environment. I disagree that PM should track to closure. In my opinion, staffing issues should be docomented in the review, then handed off to the owning team and they should deal with it themselves.
We have good visibility to leadership on problems. Handing off to another team makes people uneasy because that visibility would be diminished if we hand off issues like that. However, I don't believe that these are considered "problems" in the IT/ITIL sense. It comes down to a scope issue.
How do other organizations handle it? Are issues with staffing in or out of scope as a "problem" to be handled by Problem Management?
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Sun Aug 08, 2010 7:22 am Post subject:
For me, its clearly a relevant problem.
I'm not absolutely sure I understand what you mean by "hand off", but perhaps the issue is actually what is meant by "track to closure". Tracking involves making sure the solution gets fully implemented; it does not mean doing any of the work and so there is no issue of breaching scope.
The problem is identified as, say, a training issue (it could be something else, doesn't matter); relevant line and training management are charged with arranging the training. They may know when it is complete, but the problem manager needs to as well, and then the review can be done and the problem closed.
In quality management terms this is ensuring that staff have the necessary skills and knowledge for the work they are required to perform. Raising a problem is not dissimilar to raising a non-conformity and in that case it will come back to the auditor (quality manager) in the end to confirm that the corrective action has been done.
In theory you could leave it for the next audit to pick up, but there is a strong case for more active management so that you know exactly when the risk has been reduced satisfactorily. Hence tracking and review by Problem Management.
Confining PM to "technical" issues was never the ITIL intention and it leaves a gap which your situation illustrates. Any latent risk to service quality is a problem. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
I find "lack of user education" to be the RC of a few Problems, now and then. The same with "IT staff education", actually. This points to two weaknesses in our environment, and both are clearly relevant to PM in both reactive and proactive Problem Mgmt.
Such issues just need to be "de-personalized" (as in "no-blame culture") and then escalated in a different way/to a different body within the organization, compared to tech problems.
HTH /Richard _________________ ---------------- bragging line -----------------
V2 Combined Practitioner (service support)
There seem to be lots of IT shops where root cause analysis ends as soon as "the bug in the code" has been identified. And in line with Diarmid and Bluesman, I think that that is a missed opportunity. In our environment one of the common causes behind these technical errors is the lack of proper coding standards (or the lack of enforcement thereof). That is definitely something to track through Problem Mgmt.
Some problems don't have any technical cause at all but come down to people incorrectly handling IT equipment. This too is something for Problem Mgmt to address.
Just think about it. Problem Mgmt aims to prevent/reduce incidents. Nowhere is there an exclusion that says that only technical causes of incidents should be addressed through Problem Mgmt. _________________ Manager of Problem Management
Fortune 100 Company
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum