The PIR - Did You Get Access to The Notes From The Last Project?

The truth is that most of us don’t see the notes from the last project. Why? Because they don’t exist.

Few organizations take the time and effort to stop what they are doing and go through a proper PIR meeting. So, let’s go through the basics. Maybe, after this, you will start to insist on a PIR for all of your projects.

First of all, could we please change the name? The term PIR is latin for "after death", and originally referred to a medical examination of a corpse to determine the cause of death.

I have heard the more appropriate term ‘Post Implementation Review’ or PIR. I think we will go with that for now. 

What is the purpose of a PIR?

·        To identify the things we did right, so that we can remember to try them again in similar situations.

• To note the things that should have been done differently, so that we can refine our techniques in the future.
• To note the things that we did wrong, and to suggest alternative approaches or safety measures that we should employ the next time we face a similar problem.

What is a successful PIR?

A good PIR meeting is any meeting where people honestly share and explore their experiences with the intent of learning from them and doing better next time. It produces a set of action items, each assigned to someone with a set time for completion.

Here are 12 tips for your next PIR.

• Ensure the project review is listed as a task on your project plan
• Schedule the review directly after the project concludes BUT consider mini-reviews throughout the project.
• Set a constructive mindset
• Create an agenda
• Develop a set of possible questions as a guideline 
• Identify the moderator
• Establish ‘Rules of Engagement’
• Keep it relaxed
• Encourage participation
• Leave the laptops behind
• Develop actionable takeaways
• Share the PIR takeaways

I ran a PIR recently on a software development project. We had 12 or so people in the room representing every part of the project life-cycle, including sales at the front-end and technical support at the back-end. In the words of most of the attendees who had never sat through something like this before, “It was awesome. It was great to see what went well and what did not go so well before and after my part of the puzzle.” But most importantly, it stimulated a conversation among everyone on how we could improve the engine to deliver a better product to a potentially happier customer.

How did I do it? I broke up the whole project into phases, from start to finish. I also isolated any outputs or processes that we had to deal with.  Once the list was complete, as a group we gave each area a score: Awesome, Good or Crappy. For the Crappy ones, we created a list of how we could fix it, who would be responsible and when we could see the results.

It actually sounds simple, but it wasn’t. However, it was well worth it.

The PIR. Will the next team benefit from your notes?