Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Fri Oct 28, 2005 4:41 am Post subject: Change Management-Post Implementation Review (PIR) Templates
Does anyone know a good set of questions that should be asked during the PIR? I've read the blue book and it skips over the details (like so many other topics) . Any thoughts/heklp would be appreciated!
Joined: Aug 15, 2005 Posts: 4 Location: New Zealand
Posted: Fri Oct 28, 2005 8:24 am Post subject: Re: Change Management-Post Implementation Review (PIR) Templ
Hi there, some thoughts for you.
Depending on what you want to assess in your review. If the change was successful you might want to assess what you did well and why, so that you learn from that when repeating the same types of changes in the future, and share this knowledge amongst the support groups.
Certainly for the changes below you would require a more detailed post implementation review.
-those that required the back-out plan to be invoked - at what point did we notice a problem, how did we notice it, what did it impact and how, what exactly was the problem and what caused it, how can we avoid it in the future, was the backout plan adequate, who should we inform?
-those that were implemented but caused some business impact - when was the impact first noticed, how did it impact and to what degree, has it had a ripple effect, do we owe anyone compensation for the loss of service, is it still impacting the business, if we have already fixed it then what was the actual problem, how did we recover it, how did we solve the root cause and what can we do to prevent it from happening again, who should we inform?
-those that failed outright - at what point did it fail, have we backed out, what is the current impact of the failure, is it now causing a problem, if we have already fixed it then what was the actual problem, how did we recover it, how did we solve the root cause and what can we do to prevent it from happening for the next implementation, are we planning another implementation, do we owe anyone compensation for the loss of service, who should we inform?
-those that were implemented but exceeded resource requirements - which resources did we exceed, why did we exceed them, did we plan poorly, did we plan well and were thrown off by things outside of our control, are we able to claim compensation, what can we do next time to ensure we allocate enough resources, what can we do next time to ensure we don't exceed the resources we have to work with, what are the implications following exceeding our resources this time, who should we inform?
Does anyone have a model template that could be used for a PIR. The above details could be used but I believe there are more that a PIR should have. If there is one could you please email it to lakshmi.kamala@gmail.com
As Mary-Anne stated , the details you want to review might be quite different depending on the success or failure of the change...
However, even if the change was successfull , there are quite many things you may want to review. In this case, I think it is important to measure how well your process works , which mainly means being able to identify discrepencies between what was planned and what really happened , especially in terms of costs and delays. This is pretty important, as, as time goes on and more and more changes will be successful, your target will be to deliver faster and cheaper.
The data you gather during the PIR will feed your reporting tool as to provide you with a management view of the process.
So you can basically capture delay and cost for all the phases in the lifecycle of the change, focusing initially on how many exchanges were required between the various entities to provide all the required data
Posted: Wed Jun 20, 2007 12:38 am Post subject: Lessons Learned Log
In my organisation we review implemented changes as an agenda item within CAB. We only have a dedicated change wash up meeting if it was a major release or if it caused a Major Incident. I also keep a lessons learned log to try and prevent the same mistakes from recurring.
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