Proactive Problem Management - how to document/track if the solution had expected results

[Stacey Brannan]

We are implementing a proactive Problem Management worklfow. In thinking about KPIs, we know it will be easy to track high level such as the number of overall incidents for a service, are there less MIs, etc.

Has anyone had experience tracking if the solution brought expected results for the specific issue addressed? Example - A solution was implemented to reduce response time on a particular transaction in an application which is expected to bring significant reduction in the number of incidents related to response time and time-out errors. Initial validation looked good so we resolved/closed the Problem ticket but we want to circle back 3, 6, 12 months later and validate these incidents are truly trending down and staying down. I'm looking for ideas on how others may have tracked and documented this type of follow-up work as we don't want to keep a PTASK and the problem ticket open past SLA for this purpose. But then once the problem ticket is closed, we can't go back and modify it either. 

[Mark Manders]

And there's a reason you can't modify it after closing. You have your Problem and all related tasks to resolve the Problem. You test it and if it's really resolved, you close it. 

Checking on the response time of a transaction in an appliction (your example) is something that should be part of the application's life cycle. You could create a task when closing a Problem on the CI, but I would relate that task to the CI and not to the Problem. And since this is not an OOB solution, you will need some customization (and with that you can design your own process). 

If my answer helped you in any way, please then mark it as helpful. If it resolved the issue, please mark it as correct.

Mark