How to run project retrospectives

How to run a project retrospective

When the last tasks have been completed, and the project has been delivered, that’s often the end of the story. But it shouldn’t be.

Whether the project was a success or not, there will always be lessons to learn that you can apply on future projects.

It’s human nature to want to move on once something is finished, but failing to review the project means you will end up repeating the same mistakes again and again, even on very different projects.

Lessons learned sessions (or retrospectives), to identify what went well and what did not, can be done at various stages throughout the project or, at the very least, as a final review.

It's not something that you only need to do on big projects. Even simpler projects can learn important lessons from throughout the process. Learning lessons should be your final stage in

any project (discover other stages of managing a project by getting a hold of The Six Step Guide to Practical Project Management).

What to ask in retrospectives The questions you'll likely want to ask at a retrospective meeting are: - What worked?

- What didn’t work?

- What do we want to carry on doing?

- What do we want to stop doing?

- What do we want to do differently?

When to hold retrospective meetings The MindGenius development team are well versed in flagging up issues throughout projects. They follow the Kanban approach to agile project management where daily 'stand up' or status meetings are a chance to flag up issues of what went well or could be improved.

However, regular focused meetings are a chance to go deeper. As Fraser McMillan, Product Design Manager at MindGenius, explained: "Once the dust has settled and in the clear light of day you can always identify process improvements, technology enhancements, scheduling issues and so on that weren’t apparent while you were delivering the project."

How to foster a culture of sharing In an ideal world every member of the team would give their cold rational feedback, but then we don't live in the real world. People are ruled as much by their emotions as their reason, perhaps even more so.

As Fraser pointed out, there are a number of reasons why team members may be reluctant to raise issues: “It's often a self-confidence thing. They think: 'the boss or project manager knows how to run this project, and the concerns I have must be because I don’t understand properly', or that it's to do with respect: not wanting to question the project manager because they say it should be done this way.

“Particularly relevant to agile projects when retrospectives are held throughout project delivery is the fear of slowing the project down. Resolving issues with the schedule, delivery order or the process of how things are being done costs time and money. There is a fear that slowing down is bad, when in reality sometimes you need to slow down to go quicker.”

So, how do you deal with these issues to stop the team from holding back and to unlock the crucial insights?

Fraser explained that they need a “sense of mastery”.

“If someone feels like they have an equal share in something, an equal responsibility for its success or failure and have played a key role all along they will speak up,” he said.

One of our customers, Stephen Scott, PMO Portfolio Manager for Doosan Information & Communications Europe, also pointed out: “It is important to avoid creating the perception that a lessons learned process is simply a vehicle to apportion blame, therefore, the meeting invite and the meeting kick-off needs to reinforce the message that this is a forum for a constructive and honest critique of the project that is intended to strengthen our intellectual capital for the next projects to come.

“I clearly state in the meeting invite that it is not a channel for finger pointing or blame being apportioned. Then at the start of the Lesson Learned meeting I repeat the message and facilitate the meeting in a manner that stops any negative comments or friction being created.”

What to do with the lessons learned Of course, gathering the lessons from team members is one thing, actually putting the knowledge to good use is another. Stephen makes the lessons learned documents available in an “electronic library accessible by all employees”, and because it’s a small organisation he also emails the documents to each employee.

Crucially, those documents should be an asset when planning your next project. As Stephen pointed out: “Why waste time learning what we as an organisation already know?”

A simpler and easier approach to project management The above information is just one step in a six-step process that makes managing projects from start to finish simpler and easier.

The Six Step Guide to Practical Project Management strips back professional project management processes to the absolute basics without sacrificing the vital ingredients for a successful project – to hit your deadlines, stay in cost and deliver big benefits to your organisation (and career).