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).