Monday, 11 May 2009
Last week I blogged about lessons learned, and spent a bit of text talking about 'what makes a good lesson'. I'd like to amplify that, and talk about what makes a BAD lesson, so that we know what to avoid.
I did a google search for "lessons learned from.." and found some good examples, some poor examples, and some mxed examples, but it would be wrong to publically criticise someone else's website, so I will give you some generic examples of bad lessons, and then a specific good lesson.
You can find a lot of lessons that are historical statements.
Example "Organisations may not have anticipated or prepared for the effects of this risk"
Example "The integrated information campaign was delayed by the lack of advance planning"
Example "The boat was late arriving, and the engineer was not suitably qualified"
In each of these cases, I really want to ask the question - "So what have we learned? How do we ensure organisations are prepared? How do we ensure future campaigns are not delayed? How do we ensure future boats arrive on time, and with the suitable personnel on board?" So we need to do a bit of analysis, and look for root causes, and then genericise the lesson for future use. we need to turn it into a recommendation, really.
You can find a lot of lessons that are woolly and full of unquantified terms like "early" and "more"
Example "A project of this kind will require extensive planning, which must be started early"
Example "Budgets for this sort of work need to be larger"
Example "Make sure the project team is adequately staffed, with all the key skills represented, from the pre-tender stage"
In each of these cases, I want to ask for more detail. They are too woolly to be helpful. I want to know, how much planning? An extra year planning? An extra day? How early should it start? How much bigger should the budgets be - double, treble, 100 times bigger? What does adequate staffing look like? Which are the key skills? And so on.
So how about a good Lessons Learned example? You can actually find many of them on the web, for example at the NASA lessons database, from which I have taken this example as an example of a well written lesson.
A 10% budgetary reserve is inadequate for a technology validation mission. The EO-1 experience suggests that 15% is a minimum and 20% would be preferred. Three characteristics peculiar to technology validation missions require this additional reserve. Accurately assessing the maturity of an advanced technology is very important. Considerable reserve can be quickly expended in maturing a technology to reach flight status consistent with the aggressive schedule typical of such missions. In a related way, using reserve to overcome whatever difficulties may be encountered in the fabrication of "first-time" flight hardware is another activity that can quickly consume considerable reserve. Lastly, the exact performance needed to effectively validate the advanced technology may not be fully understood until rather late in the definition process and this may increase the cost of the spacecraft.
Future technology validation missions should carry a minimum budgetary reserve of 15% at the Confirmation Review.
Why do I like this example? It's clear, its quantified, it's written as a recommendation, it's backed up with a good argument, and most importantly, someone reading the lesson would know exactly what to do next time. Which is, I suppose, my primary criterion for a lesson. It needs to be reusable.