How frequently should I update my Problem Records?

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
AaronPRBMGT
Newbie
Newbie
Posts: 1
Joined: Thu Jul 17, 2014 8:00 pm

How frequently should I update my Problem Records?

Post by AaronPRBMGT » Fri Jul 18, 2014 9:05 am

Hi All,

I am currently running a new(ish) Problem Management process, it has been running for about 6 months now and it is beginning to mature, I have a dashboard and a regular review board meeting Etc. set up,

I also have broken the Problem Records down by priority and have a few lists based on different criteria to determine which are key and which are the "Nice to have fixed" list ...

The question is, what rules should I now apply around keeping to Problem Records updated?

I think for Priority 1&2 issues, where my main focus lies the answer would be weekly progress updates, but for the priority 3 & 4 records what sort of update frequency would be acceptable?

Also what sort level of detail should I be applying in the updates?

Your thoughts on this matter would be much appreciated



User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Post by UKVIKING » Fri Jul 18, 2014 12:58 pm

Aaron

Once a week for a P1 ?

Obviously, it appears your P1s are not that urgent or impacting to the customer(s).

As to the question, how often.

The phrase - IT Depends must be the answer

If the team involved in the work do nothing on it for a week, yeah, update - no activity, but there should be some sort of update when there is an update
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

User avatar
Tomek
Itiler
Itiler
Posts: 9
Joined: Mon Aug 04, 2014 8:00 pm
Contact:

Post by Tomek » Wed Aug 06, 2014 2:37 am

I do confirm - IT depends.

Mainly on how much time you can allocate to make some progress on Problem Tickets because every investigation needs time.

It also depends on nature of your tickets, whether you can seek for workarounds or to formulate definite solutions as change requests:
* workarounds sometimes need incident patterns (this takes time)
* solutions rather should be complete proposals (technical solution definition also takes time)

I do recommend to have review process in place (at least to define frequency of reactive reviews & proactive identification) and to update problem tickets only when you make some real progress.

Post Reply