Post Implementation Review Template for Incident Closure
Why do you need a PIR (Post Implementation Review) template?
Once an incident is reported to the IT help desk of the organization, they open a ticket which will follow the incident from report to conclusion. Once the incident has been resolved one way or another, the ITSM methodology says that the help desk must conduct a PIR (Post Implementation Review).
The Post Implementation review will help the organization conclude whether the change made was required, if its implementation was successful and what the lesson learned was. There are many ways to conduct these types of reviews, either internally or with the help of a 3rd part auditor. Not each incident requires such a review, and only ones who were deemed important enough to the organization’s continuous growth are subject to a PIR.
How to use the Post Implementation Review Template
The Post Implementation Review Template includes the following information and details –
Name and Logo
The name and logo of the organization appear at the top
Source Details
The source details of the incident (PIR) appear below them, and include –
- Who submitted the report?
- What their role is
- When it was submitted
- To which team they belong to
- The PIR unique number
- Who reported the incident?
- What the duration of the malfunction was
- What the status of the incident is?
Review Details
The review details include the following –
- A short description of the incident
- What the scope of the PIR is, and which change is the subject of the review. This is a brief history of the incident from start to finish, which includes the problem, the diagnosis, and the solution.
- The actual PIR of the incident which is mentioned in the paragraph above and this section is the heart of the PIR. This includes the outcome of the PIR, whether the change was deemed as necessary, and if the change fixed the initial problem. It also includes how the change was documented, and if any new lessons learned were added to the organizations’ “memory”
- If any new lessons learned were indeed added, then the next field documents them. This includes simple instructions on what to do in future similar cases, and when. This field may contain more than one lesson.
Authorization of PIR
The authorization of the PIR, including any future instructions as a result of the lessons learned. This includes the name and role of the authorizer, their decision, and when it was approved. All of these are made official by the signature which comes last.
How this fits into the ITSM methodology?
Since the cornerstone of the ITSM methodology is aligning the IT with the business needs of the organization, constant improvements, and learning from past mistakes is essential. Conducting thorough reviews and suggesting improvements are vital for living up to this goal, and the PIR is a major step in this direction.
The methodology doesn’t specify whether the PIR should be conducted internally or by an independent party, but hiring an external 3rd party professional is better for recognizing faults which an internal employee may deem as something that has “always been like this”. The downside of this is that the process may be lengthier, and almost always more expensive.
