Why Project Retrospectives Are Challenging

Project retrospectives are challenging. I spoke a bit about this in lessons learned vs. project retrospectives. You might look at a merger, acquisition, implementation of a new ERP system, or even a major upgrade of an ERP or CRM system. These are non-reoccurring events. A retrospective of this type is quite different from a typical agile retrospective, primarily because on this type of project, people will change and the project will not repeat (the definition of a project is that it is a unique endeavor). At issue here is the fact that if the people will not be the same and the project does not reoccur – then they can’t come up with actions they will apply right away based on what they learned. Ideas for change often just end up in a spreadsheet, a book shelf, or some electronic tool. A big book of “lessons learned” that sits on the shelf gathering dust does not provide much, if any, value.

All that said, there may still be some value. You have to consider a number of key elements when deciding if you want to set up a project retrospective.

Remember that:

• the people may not be working together going forward — at least in the exact same way
• the project will not repeat
• all of the people originally involved may not be available

Determine if:

• enough time can be dedicated to the project retrospective, given the duration of the project — a one year project will take more than a few hours to have a “good” retrospective and avoid recency bias
  • you will be able to use a mechanism(s) to help people remember the things that happened throughout the project. Look at past sprint/iteration retrospectives, calendars, releases, and any other artifacts that will allow people to reflect on the various states of the project. If you determine this can’t be done, consider how this might hinder your goal. Often at the end, the big issue that was a problem for 6 sprints early on is no longer something that is front of mind because it is solved for this project. But did anyone learn from it for the next project?
• the retrospective can include breakouts and ways people can say what needs to be said — often in these sessions there are more people than one facilitator can facilitate
• activities can be planned in a way that deals with people from different parts and “levels” within the organization as well as the fact that many people may not know each other (well)
• the right mix of people can be included in the project retrospective — can the people who actually know about the project attend?
• there are incremental team retrospectives that can be used to help people look back and reflect on what was happening many months earlier?

Based on this list, consider your goal. What do you hope to accomplish with the project retrospective?

If you just want to check a box so that you can close out the project, just schedule a small one, invite a few people, then file your report — it won’t matter anyway.

If you actually care about improvement it will be important to find out what items within the project will reoccur. This is one area you can focus on. I need to point out that many of the elements listed above illustrate why ongoing retrospectives that allow teams to improve as they go are so important! Having ongoing retrospectives that you can learn and improve on BEFORE things are over is always better than waiting until the end!

Consider this situation

Giant Mart is acquiring Mini Mart. Giant Mart has an IT team that will merge Mini Mart’s inventory data into Giant Mart’s inventory system. Giant Mart just finished a different acquisition and the IT team is having a retrospective on that event. What can Giant Mart learn? What can they take action on? What are the challenges in applying a retrospective from one event (project) to a different event?

Giant Mart needs to focus the retrospective on what they know will be the same. They should be focused more on the communication and collaboration process in general and less on the specifics of what they would have improved with relation to the data in the last acquisition. Perhaps in the first acquisition, they ran into a problem because the inventory data they attempted to import on the weekend of the conversion didn’t have a ‘purchased date.’ They were in real trouble with the conversion and developed a formula

based on the ‘enter date’, ‘ordered date’, and ‘product type.’ If they decide in the retrospective that they should always use that formula, they may be making a huge mistake, since this may not work well for the next acquisition.

Instead, they should be looking to the root cause(s). What are the real issues here? What is changing? What don’t they know?

Some questions they might start with: why did we wait until the cut over weekend to run a full data import? When we ran tests, why were they not automated and why was the company being acquired not involved? How can they get the acquired company involved earlier? [This is “always” allowed, right! :)]

I would be asking: “can we bring some of the people from the latest acquisition to the retrospective from the last acquisition?”  There are many more questions here, but this begins to show why project retrospectives are challenging. The people change and the project is not the same!

Decide What You Want

Decide what you want from the project retrospective. Identify your goal. I know someone reading this just started a project or will be doing so soon — if that is you, figure out how to start doing team retrospectives now. Learn and improve as you move through the project!

If you focus on what is the same from project to project, you can be more successful than if you are targeting individual project specific items. And, of course, realize that what you think will be the same may not be! That is where impartial facilitation helps! If you have questions about facilitation or how to deal with some of the challenges noted here, add a comment below or send me an email.