Close Every Technology Project with a Retrospective

When a big technology project, like an AMS or CMS implementation, finally launches, everyone is eager to move on to other things. But not so quick! While memories are fresh, this is the one chance you have as a project team to reflect and discover what your association can do better during your next project.

I can’t stress enough the value of this exercise. Associations that build this retrospective into their project timeline are always glad they did.

Why a retrospective should be a part of every project

Although I call this exercise a “retrospective,” the Project Management Institute calls it a “lessons learned” exercise. Some project managers call it a “post-mortem,” but that’s a bit gruesome for my taste.

Whatever you call it, the retrospective is a critical part of closing out a project. During the retrospective, the project team comes back together to reflect on the project experience and the final results. Together, they identify what went well, what didn’t, and where improvements can be made for next time.

Resist the dangerous temptation of closing the books on a project without first looking back. To improve project processes and avoid repeating things that don’t add value to projects, your association needs the lessons a retrospective brings. When associations don’t do retrospectives, they usually repeat the same mistakes over and over.

During a retrospective exercise, you will:

  • Most importantly, identify the risks and challenges encountered during the project and the steps needed to minimize them in the future. You may not be able to prevent all these problems, but you can anticipate them and figure out how to work around them.
  • Refresh project-fatigued minds and encourage an innovative spirit within the team. Don’t be surprised if you elicit new solutions for long-standing problems.
  • Take a look at issues that weren’t addressed during the project, and perhaps aren’t ever addressed, but could help the association as a whole—for example, communication breakdowns, disagreement on roles and responsibilities, and unrealistic expectations.
  • Evaluate whether your association has the appropriate resources and organizational structure to successfully manage projects like this in the future.
  • Determine if your association has sufficient staff roles or staff ownership with respect to processes, systems, and projects.

Retrospectives have a positive effect on the people involved.

Successes are called out and recognized—increasing morale. Team members feel appreciated because their input is solicited and valued. They can vent (finally!) in a constructive manner. Even if team members don’t work together on another project, their relationships are deepened and a precedent is set for further collaboration.

How to run a productive retrospective

Everyone on the project team participates in the retrospective.

If you think the conversation would be more productive if the group is split, you can do one session with the executive team and another with the project team. You could also meet (in person or virtually) with the vendor’s team for a separate conversation.

You may anticipate resistance.

Team members may want to turn their focus back to their workload and not spend any additional time on a project they see as “finished Or, they may have other reasons for not wanting to participate:

  • They see no reason to change the project process—or why they should be involved in that effort.
  • They don’t want to resurface painful memories.
  • They don’t want to bear the brunt of complaints from other team members.

source: https://www.flickr.com/photos/keithbsmiley/2529252679/Alleviate these concerns by explaining how the discussion will be managed. Emphasize the impact the retrospective will have on future projects. And, for good measure, ask the project’s executive sponsor to make participation mandatory.

As a preliminary to the team discussion, it’s helpful to gather anonymous feedback from everyone involved. Ask each team member to identify the ‘most important’ topics for discussion, the ‘top success,’ and the ‘top recommendation’ for the future. This anonymous feedback should be shared with the group and can be used to start, but not limit, the conversation. Display the feedback on a white board during the discussion. Refer to it when needed to help shift the conversation to topics that haven’t been touched on yet.

Create a safe environment for discussion by establishing ground rules that encourage people to be frank while also emphasizing the need for objective and constructive conversation.

  • Impersonalize feedback. Don’t refer to a team member except when praise is due.
  • No voice has more weight than any other. Everyone must contribute, no matter their role.
  • The goal is to improve project performance, not to cast blame or aspersions for things that may have gone wrong.

Set a positive and constructive tone to alleviate any fear and defensiveness. Listen neutrally. Capture all feedback—you’ll need it to prepare your report.

Start by discussing project successes—this will warm up the group. Then move on to areas for improvement. Elicit suggestions from the team on how to do things better the next time.

Encourage participants to share different departmental perspectives on project successes and challenges. Give team members the opportunity to better understand what their colleagues have been grappling with and how the project has impacted their work too.

Before you end the discussion, make sure all the ‘most important’ topics submitted by participants have been discussed. Usually at this point they have been, but you don’t want to overlook anything considered important.

Should you do the retrospective yourself or have a consultant handle it?

A consultant can take the traditional ‘lessons learned’ process a step further by adding the perspective of a neutral outside party who brings industry insight and best-practice recommendations. I’ve found this approach brings out a heightened level of staff engagement to the exercise. People take it more seriously when an expert is brought in from the outside.

Do a mini-retrospective during the project

You can also do mini-retrospectives during a project, for example, upon the completion of certain milestones. Build time into the project schedule to allow for these discussions.

Mini-retrospectives help the team identify how to improve project processes while the project is still under way, so corrective actions can be taken and benefits realized immediately:

  • What factors have contributed to successes so far?
  • Which tough spots could have been handled differently?
  • What opportunities and/or challenges should you anticipate as you move forward?

What do you do with the lessons learned?

After the meeting(s) with team members, it’s time to get to work—and this is where a consultant can really make things easier for you.

  • Analyze findings.
  • Present and discuss findings—successes, opportunities to improve, and recommendations for next steps.
  • Prepare a final summary or report.
  • Determine actions.

A lesson isn’t really learned until some action has been taken. Determine which recommendations to adopt. What are you going to add to your project protocol? What processes will you improve and how? Be judicious—pick your battles—and get support from the project’s executive sponsor.

Decide how you will implement these action steps. Do you need to add them to a project plan template? (Do you need to develop and distribute a project plan template?) Do you need to revise (or develop) your RACI matrix?

People need to find and use the information you’ve unearthed—these findings are valuable organizational assets. Create an accessible, searchable archive or library of lessons learned. Don’t just dump your report on a shared drive and allow it to be ignored, like the proverbial binder on a shelf collecting dust.

You need a governing policy about who’s responsible for owning that library, maybe a team or a person. Someone must be given authority to enforce these actions (improvements). That person/team could be the COO or CIO, or the IT department or Project Management Office (PMO). The ‘owner’ must be in a neutral position with respect to projects, and have enough understanding of project management to guide the project process.

A retrospective is a rewarding process in itself, particularly because it’s a shared experience—and that also makes it an effective process. People don’t always respond well to changes introduced by a sole project manager or changes pushed down from above. The more involved the team is in the retrospective, the more apt they are to help carry these changes forward. Because they understand the reasons behind the change, they’re more likely to support new project processes and practices.  

Having a well-designed and reflective project management process is a sign of organizational IT maturity. Read more examples and begin to see where your association falls on the IT maturity spectrum. Download our free white paper, Unleash Progress with Mature IT.

Check It Out