Beagle 2 was the UK’s first mission to another planet. The huge amount of publicity and hype surrounding the mission came to nothing after the mars lander was lost during it’s descent to the planet’s surface. After the dust had settled on the mission’s failure, the University of Leicester published a report which tells us much about how to learn from failure.
Many of us have been involved with projects that failed to deliver exactly what we hoped they would. Thankfully these failures are unlikely to be on the scale of the $50 million Beagle 2, and be quite so public.
With so much at stake, it is not surprising that the project leaders were keen to learn from their mistakes. Depending on your position in the project it might be difficult to make any far reaching changes or recommendations, but at the very least you can avoid making the same mistakes yourself, second time round.
Rather sadly, the Beagle 2 lander seems to have been found recently, just a year after the death of the project leader Colin Pillinger.
1. Write a ‘lessons learned’ document.
Even if your project is a huge success, there will always be lessons you learned along the way. The first step towards building on the success (or failure) of your project is to take the time to think about what you learned and how you might apply it to future projects. Once you have finished celebrating or commiserating about the result of your project, take some time to think about what you did, what worked and what went wrong.
Leicester University’s report on Beagle 2 is a good place to start.
2. Praise the Project
Maybe you’re looking back at your project thinking or knowing that it was a complete, unmitigated disaster. But force yourself to see what did go well. You will have achieved something. The Leicester report opens by praising the team on a good job well done, and making it very clear what important progress was made and what milestones were reached under challenging circumstances. Those involved in the project will be much more open to your suggestions if they feel that you have acknowledged their efforts and achievements.
3. Write a summary of exactly what the project did
Writing a summary of what you did gives you a chance to lay out the approach your project took, and provide context for the decisions that were made. Questions that you might want to answer in your report include:
- What testing did you undertake? Was it regarded as sufficient?
- How risky was your project? High risk projects offer the greatest rewards, but often fail.
- Was your general approach sensible? Who else uses a similar method or technique?
- Did you incorporate other, previous recommendations into this project?
- What decisions beyond your control led to the failure of the project?
- What specific financial limitations did you encounter?
4. List all the lessons learned
Think of everything that seemed to limit the success, or exacerbate the failure of the project. Write down your lessons learned as positive steps for the future. Examples from the Beagle 2 document include:
- Have sufficient money at start to go ahead at near full speed avoid the “do it in spare time syndrome”
- Conduct shock tests on running and powered systems as during the Mission
- Staffing continuity is important. Improve early links between design and operations teams.
These examples show the extent and variety of lessons that can be learned from a project. From the early planning and financing stages, to personnel issues, to technical aspects relating to exactly how the project will be delivered.
If you label or number your lessons, this will make it much easier for future workers to access and reference your suggestions.
5. Don’t make it too long
If it seems like your project was a failure then dragging over the ashes of what went wrong may seem like the last thing you want to do. But it can really help. The authors of the Leicester report wrote it to
Ease the load on any future teams in terms of designers, integration and test teams and operations staff.
So think of them as you are writing it (the future team may well be you of course), and remember it doesn’t have to be long – the Beagle 2 Lessons Learned document is less than 30 pages long, of which 15 pages is tables of specific ‘lessons learned’. Yours can probably be much shorter.
Image: Geni