Having a retrospective (AKA wash-up, post mortem) at the end of a project is a good way to learn from your experience as a project team, to examine what went well, what didn’t go well, what could’ve been done differently in hindsight.
There is a fine balance in the discussions that form a retrospective — on the one hand, it’s not about finding scapegoats for anything that went wrong, and managers are typically very good at making this clear, but on the other hand, the assessment needs to be honest. I find that often, in order to avoid anything that looks like blame, participants in a retrospective avoid pinpointing any issues within the control of the project team at all, and attribute problems to external forces such as “the client” or “the timeline”. But the point of project management is to work around external forces, to manage them, so if the answer goes no deeper than this, then there’s nothing gained.
Here are some examples of questions that help untangle issues related to clients or timelines:
- Were the client’s expectations realistic to start with? If not, how could we have set/managed those expectations better?\
- Were there problems with client communication? Were they disengaged? Are there different ways we could have tried to motivate the client (e.g. was it that they needed a face-to-face meeting every week to feel like they are an important part of the process? Was it that they need to be given a piece of paper to put a signature on to get them to pay attention)? Were there default paths that we could have followed when the client went AWOL?
- Did the problems stem from the client not understanding how a product is designed and built? If so, were there signs of this early on, and how could we have educated them better if we had picked this up?
- Was the project ever going to fit in the timeline with the allocated budget, even if things went without a hitch (or was it over-scoped)? How much contingency was there in the planning to begin with, and did we use it up?
- If the project took longer than expected, was it longer because each planned task took longer, or were there tasks that were unaccounted for altogether? If tasks took longer, is it because it was just more labour than expected, or were there more rounds of reviews and changes that added more work? If it’s the former, what complexities made it more work? If it’s the latter, were there ways we could have reduced the rounds of changes, or iterated more quickly?
In answering any questions, where possible, you should check your answers against available data (e.g. estimates versus actual times on various tasks/phases) — sometimes the data might surprise you and point you to unexpected conclusions. It may also be useful to consider where data might have been useful for diagnosing problems but was not available this time, and whether it’s possible to get that data in future projects at a reasonable cost.
Remember the purpose of a retrospective is to examine the project at hand, not to generalise — the solution to any problem is also inherently tied to a whole lot of assumptions and specific circumstances, and what might have worked in hindsight on one project may not translate directly to another (unless you have a project being delivered in very similar repeating phases — these are perfect grounds for testing process changes!). The real power of retrospectives lies in collecting enough examples of problems, circumstances, and possible solutions that when a new problem comes up, you can find one or two in your kit that are close enough a match to help you predict outcomes and make the right decisions.
Originally published at Throwing Down Tracks.
