In theory, any service offered by IT could be subject to an SLA or an OLA. As problem management is generally an internal IT service, it is generally subject to an OLA. According to best practice, the deadline for problem resolution is generally based on its priority, which is generally determined by its impact and its urgency.
In practice with OVSD (at least, with 4.5), the out of the box functionality depends on using Service Calls or Incidents. The product does not really manage the OLAs that might govern Problem (or Change) Management. So you have to build the functionality yourself, typically with DB rules that send mail, change deadlines or reassign tickets.
The question of how you "should" manage this depends on the objectives of your organization and its level of maturity. Many organizations are happy just to have a Problem Manager and a Problem Management process. As they become more mature, problem management can be subjected to deadlines, typically based on priority, as mentioned above.
Remember that while the work is being done on the change, the change managers ought to be accountable. When they close the change and return responsibility to problem management, the problem managers become accountable again.
In my experience there are two approaches to handling the closing of a change that has been triggered by a known error:
1. Change Management is reponsible for the Post-implementation review, followed by closure of the change. This is an elegant and consistent solution, but might not be logical from the point of view of problem management.
2. Problem Management does the Post-implementation review, which is logical, but makes the workflow for closing the change and the known error more complicated.
I suggest you do whatever your organization is most comfortable with. In any case, OVSD has no out of the box functionality to really support this. You need to create it yourself.
Hi Amy, Good question. The Problem Manager should be weighing up all the open Problems to determine which are most important (which causing most pain and cost). There will usually be more problems than resources to solve them so I don't believe it's practical to put a deadline on every problem the way you do with SC and IN's. And that's why you usually don't have SLA's around problem resolution. (Besides, some problems can't be resolved or aren't worth it). The Deadline should be determined individually for each Problem - that's were a good Problem Review Board comes in. When you do have a deadline agreed, then that should include the time to apply Changes. We usually have a Change Deadline field as the "drop-dead date" - ie the latest time the Change must be implemented. Can be done earlier of course. So this would be set a short time before the Problem Deadline to allow for post Change review. And wherever a Change is implementing a Problem solution, we say that the PIR would be done jointly. Either Change Manager or Problem Manage can chair but both are stake holders. This is an important point where the two porcesses come together. HTH......Ken.