PIR's - What process does a PIR belong under?

[jpmackl]

I thought V2 said it was Change Management?
It appears that V3 puts it under Problem Managment?

Maybe I miss understood this in the past.

Any input?

Thanks!

[AlphagamerTyson]

I would say a PIR is part of Change Mgt in V2 , buti would have to look it up to see where it is discussed in V3 ..

[jpmackl]

Thanks for the feedback - I did find it - it's stated clearly under Change Management in V3 and that the CAB members should be involved with the PIR since they approved the Change.

Our problem is the Change Manqement Team would like us to do a PRM everytime they need to do a PIR. This seems crazy. Is anyone willing to share what is covered in a PIR? Our CM team only wants to review the content of the Change Record and I believe this to be a small portion of a PIR meeting. They prefer to have Problem Management to complete a Problem Review Meeting instead of a PIR.

Any help is appreciated!

[Fabien]

Off the top of my head, we need to clarify the difference between a Post Implementation Review and a Post Incident Review. That may be where your discussion is stuck.

A Post Incident Review is held by Problem Management after a Major Incident because when a Major Incident occurs, it is the Problem Manager who takes over the incident resolution.

A Post Implementation Review should be held by Release Management after all implementation to understand what went right, what went wrong, what should be changed next time, etc. This one should be chaired by the Change Manager when it makes sense to do so, which is most likely when you release a large project or when you have user acceptance involved.

Hope that gets you a step further.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[jpmackl]

Thanks for the follow-up.

Our situation is during scheduled change activity.

Example, we shut down an application, add memory to server, recover the system, compelte a check out and something happens to be missed on a san connection. This is not picked by automation and the next morning the system is not available. Plus we had collisions with multiple changes occuring and some users could not sign in to complete check-out.

Since this was a scheduled change with an upgrade to hardware memory. Would we do a Post Implementation Review or Post Incident Review on a Major Incident?

Thanks

[Fabien]

I think it's time for powwow actually. Your Change Management process does not seem to work very effectively, or you may be missing a Configuration Manager that freezes CIs under change, or you may be missing pieces in your release plan as to what needs to be tested before any other change should be implemented.

Your post-implementation review should highlight that. It should definitely be chaired by the Change Manager and your Release Manager needs to gather all the data to explain what happened during that Release.

You could also define criteria as to when a PIR should be held so as to stay mindful of everybody's time. When a release goes wrong, I think there should be no discussion as to whether you hold a PIR or not.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek