How to capture lessons learnt after a project

Question

Hi All,

When a project or large body of work has been finished, what's the best way to reflect and learn from what worked and what didn't, and why. I've work on a couple of teams and haven't seen any of this type of information captured in a meaningful way.

I'm thinking wikis, team meetings, formal reports, blog posts???

Answer 1

I think a simple review meeting works pretty well. You can have a set of standard questions to kick things off. But often, simply getting discussion going will give you a lot of ideas.

One interesting question is: who to invite. Your developers definitely. Testers most probably. But you might want to leave management out so that no-one holds back.

Answer 2

I've worked on projects where you have a sit down at the end and everyone gets to talk about what they liked and disliked. What they felt worked and what they would like to change. This is pretty straightforward. However in order for this to be any use the person in charge needs to take these things on board and make sure that they remember them the next time they are running the project.

Answer 3

Anything. The key challenge from teams I've been on is maintaining whatever it is that "anything" manifests itself as. I've been on many a project across many a company/client where issues, both minor and major, will be discussed in some form of post mortem. Wikis, documents, stand up meetings (which useful don't capture the lessons for future reference)--all are useful....until the continuation of that method drops off.

Intentions are always good, but keeping up those good intentions in face of deadlines, fire fights, etc. and good habits like documenting lessons learned via wikis start to fall by the wayside.

I'd suggest choosing the simplest method that is both "permanent" and involves as little effort as possible to continue for the long haul if you ever wish for it to have any chance of getting buy in within any reasonably sized enterprise.

For me personally, it's an internal blog that we host via sharepoint, but YMMV. Good luck!

Answer 4

The most successfully wrap up meetings we have had is were we all send in our causes of project failures and successes, and have a discussion after compiling a list with everything.

The critical factor is willingness to learn. Without it it is impossible to capture it on any medium and add value. Sometimes people will cope with a problem for years that is easy to fix because it is easier to pretend everything is fine since you do not need to admit failure.

I have also used various Wikis (Tiddly, Instiki, Media).

Answer 5

We used a TiddlyWiki to store notes/ideas/lessons etc. during development, and this was then reviewed in a team meeting at the end of each sprint. The wiki meetings were mostly interested in:

• What worked
• What didn't
• What could be done better

Answer 6

I used a diary long time ago (before the wiki). Writing down expectations, results and even emotions. It was very useful and a good investment in the long run.

Answer 7

You also need to make sure you have a process in place where team members actually review any previously documented Lessons Learned before kicking off new projects, otherwise it's a waste of time.

Answer 8

I like the idea of having a post-mortem where everyone can voice their take on the project, what worked well, not so well, and how could the process be improved, in a sense. Someone should be designated to take the notes and followup on the suggestions and criticisms of the project. This doesn't need to be complicated but it does require that everyone understand some of the key points and be prepared for such a meeting,e.g. the good, the bad and the ugly shouldn't be on the spot thoughts but rather things that people have already spent time figuring out for them what they are.

Answer 9

One could do a meeting, with the following agenda:

1. Recapitulate the important things that happend in the project.
2. Collect what was good
3. Talk about the points from 2 that should be repeated.
4. Collect what went bad and could be improved
5. Pick the 3 most important points from 4.
6. Talk about these 3 points in detail.
7. For each of the 3 points write down the actions you want to take.

In particular, I think, the point 7 is very important. Think over, what can be done to improve things. Think about setting up some reminder for the actions that were decided there.

Answer 10

yeah, its a shame how few people do them, especially considering it doesnt have to take hours and hours

i used to use quite a long winded format: Project Post-mortems

...but i found it increasingly hard to get time from my managers to run post-mortem at the end of the project

so working with another project manager, we developed a more streamlined version which can be done in about 3 hours: Super-Quick Project Post-mortems

--LM