top of page
  • James Kelly

Insight: Planning for a productive retrospective - 4 steps to better learning

We've all been there before - a project that hasn't gone so well: over budget, late, not meeting everyone's expectations (project death marches springs to mind).  And of course there are those projects which never actually finish - they simply no longer have anyone working on them. The executives and senior management now want to forget, or worse still, want some heads to roll.

At the end of the project, the project manager or director (or some enlightened sponsor) may call a Retrospective (or Project Review, Hotwash, Post Implementation Review, etc) to get to the cause of what happened.

To maximise the value of this type of activity to the company, you need to collect both lessons learnt and data (to support the lessons).  It also helps protect you when the political ramifications start.  

Step 1 - Collect lessons early and often

If you've already started your project, or even getting close to finishing, start collecting lessons now!

Look through:

  • minutes of meeting and records of discussion

  • progress reports

  • project presentations

  • customer feedback

  • project emails - particularly those involving decisions made

  • audit reports

What commentary or narrative from the sponsor or project manager can you see?  What customer responses to decisions stand out?

Even the most poorly documented projects have some material upon which to extract lessons of what worked and what didn't.  You just need to look for decisions and changes in the running of the project (or even if there were no changes despite them being needed).

This might seem like a lot of work and indeed most staff simply turn up to Retrospectives with minimal preparation and view it as a talk-fest to provide their opinions, rather than a serious analysis opportunity. In the absence of hard data and decision points, opinions often count only as loud as the person making them.

Step 2 - Ask reflective questions

Ask a reflective question at the end of each project standup/meeting - "what could we have done differently?"

The answers to these questions often make great sources of potential project and organizational improvements.  It is often difficult to separate egos from answers, however with focus on project and outcomes, the negative effects can be reduced.

Just like any continual improvement, record them in a central location such as a wiki, sharepoint or cloud collaboration tool. Don't mix them up with other organization improvements or the effort may be divorced from the project and will lose any momentum or goodwill built up. Revisit and report occasionally to the project team to ensure the process does not go stale.

Step 3 Collect data

To support the lessons being collected in step 1 and step 2, start collecting data as early as you can - determine the measures that are available (or can be readily computed) and collect these throughout the project.

In many projects, basic measures are recorded and monitored (schedule, milestone, cost, earned value) but are not considered when thinking through lessons.  This is missing a potential wealth of material because by looking at decisions as they occurred during a project we can determine potential cause and effects (this is often rough and ready but is good enough to support lessons).

This may sound burdensome however the metrics are collected anyway and may require simple markups to match decision points to impacts on the project data.

Step 4 Communicate, communicate, communicate

Failing projects can bring out the worst in people - managers, team members, sponsors and customers alike.  All of whom are burnt out and over the project.  Most of all they don't want to be blamed for the failure.  It's critical for the sponsor and managers to step up and sustain an environment that enables staff to call out problems to get them fixed.  Learned helplessness is a corrosive behavior that can destroy a company.  Yet it happens in many companies by default simply because no one stopped it nor took action to prevent it.

By communicating at each and every opportunity, sponsors, managers and team members can build an expectation that problems called out will be addressed and not simply a blame game.  At every meeting and in every presentation and report, make this behavior front and center.  Each decision can be made with a fuller picture of the project and potential ambiguities reduced.

In doing so, the politics of a Retrospective can be reduced and some real value can result.

In the next post, some obstacles and why equal time for positives isn't a cliche.

16 views0 comments


bottom of page