Branimir Valentic I remember this situation of one of my clients: change was implemented and the spotlight shifted to Incident Management (you guessed it – resolving incidents that arose as a consequence of the change). It’s not that the change was uncontrolled; quite the contrary – it was well prepared, managed, and finished just how it should be (but consequences, like incidents, used to happen, and even that is usually considered normal). What was missing was having all stakeholders (e.g., users, change implementation team, Service Level Manager, Change Manager, etc.) sit down together and review the implementation.
Why? Or, better to say, for what reason would we add one more activity (IT has plenty of activities and responsibilities already)? I agree; it could be that everything went perfectly, all requirements were met, the team delivered effectively, etc. But, as I experienced so many times – everything can be done better, and mistakes don’t have to be repeated.
Usability… in case you missed it
Try to recall a situation when you finished something (e.g., fixing something at home). You might remember saying, “It’s good, but next time I will do it this way.” That was your Post Implementation Review (PIR), or “review.” PIR takes place after deployment of new release or change implementation. Every time? No. The Change policy or Release policy are excellent places to define what undergoes formal review, and how.
If you are more knowledgeable with ITIL framework, then I would expect questions like: “But there is a process called Change Evaluation – how is PIR different?” The Change Evaluation process in ITIL is more formal and spans throughout the whole lifecycle of change. PIR takes place when something (change or release) is over and it is a part of the Change Management process (read this article to find out more about Change Management: Elements of Change Management in ITIL). For example, a significant change would be the subject of the Change Evaluation process. The change will not only be evaluated when finished, but most of the major milestones will be evaluated as well (e.g., before the build phase begins).
PIR takes place after change is finished and is used to:
- Ensure that agreed objectives are met – every change has targets to meet. After the change is implemented, objectives should be checked to determine whether they have been achieved.
- Confirm that the customer is satisfied with the changes, i.e., that customer expectations are met. Usually, customer expectations should be translated into change requirements (see previous bullet), but they may not always match up.
- Check behavior after the implementation – what happened to me is that change was affecting certain functionality. After the change implementation, that new functionality worked perfectly, as required, but some of the other (“old”) functionality was “killed.” PIR should determine the effects of implemented change.
Some organizations, usually large ones, have a formal PIR process and responsibilities. On the other side, smaller organizations perform ad-hoc PIR right after the implementation. What’s important is that PIR takes place and that it’s not done pro-forma.
Lessons learned
What if no PIR is done? I know organizations that never look back after the change or deployment. This means that if something was done incorrectly (or less than optimally), the same mistakes will be repeated again in future changes. And again, and again… There is no need for that. Changes are made, providing experience as well as a team or person responsible for change. The only thing that is missing is PIR. After all that struggle with change, any additional effort for PIR should be insignificant. But the effect of PIR – it’s very significant.
When I am planning PIR, there are two approaches I use as guidelines:
- Official/figure-based – comparison of results vs. requirements, number of incidents arising from change, number of users’ complaints/feedbacks. Numbers are written down, which are excellent input for analysis.
- Productivity-oriented – what went wrong, what was good. Honesty and orientation to improvement are the tools here. Honesty excludes blame, which means that the goal of the PIR is to revise our own performance and correct things that were done improperly. On the other side are things that were done well – adapt them as best practice and use them in future changes.
Figure: Inputs for PIR
That’s how you set up a learning organization.
One more thing could help you to establish PIR. When implementing a new release or change, Project Management is often used to manage the implementation. Some of the project management methodologies divide the project into stages and recommend doing the review as each stage is finished. Collect the information and use it in future projects.
If you implement ISO 20000….
…then I don’t have to elaborate on the necessity of the PIR. Whether you find it useful or not, ISO 20000 requires that you perform a review of changes for effectiveness, as well as analyze requests for change on a regular basis and detect trends – reactive and proactive improvement based on review. You have to document results and conclusions from the analysis as well as identified opportunities for improvement.
My experience taught me that there is always something that can be done better, faster, cheaper. Whenever I performed a review with my eyes wide open – I saw results. PIR is the tool that provides the opportunity to establish improvement in a change or deployment process and to show that increasing efficiency and effectiveness is among primary concerns. The next change implementation or deployment will show if this is just a buzzword or the real intention.
You can also check out this free Request for Change and Change Record template to get familiar parameters important for PIR.
