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
- 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?
2 thoughts on “The PIR – Did You Get The Notes From The Last Project?”
Most likely the next team will not benefit from the notes of the last project and here’s why. In any decent sized shop there are hundreds of projects every year. No one is going to read the notes from hundreds of projects. I propose a different model. Run the PIR – that’s a must. Then, take the learnings and embed them in your toolkit. It is much easier to cross something off a Work Breakdown Structure then to try and remember to add it because it is not there. This implies that you toolkit is flexible and not a rigid process.
There will always be a need to think while on a project as new things come up we haven’t had to deal with before. It’s nice when there are some tools that have dealt with some things before.
On larger projects why wait for the end? Take a page from Agile and create touch points to review the progress to date; what should be continued; what we should stop doing; what we should start doing (or Keep, Stop and Start). Apply it to the current project to make change. There is still value to doing a PIR at the end but if all are honest and in a safe environment, this can help teams perform better now.