Lesson learned: Seek out root-causes of project failures, not just surface symptoms.
Category: Retrospectives / Organizational learning
The following post is a “Lesson Learned” that comes from the analysis of the failed projects documented in the “Catalogue of Catastrophe” or from the experiences the editorial team have had working with clients around the world. The post is published here to spark discussion and help individuals and organizations think about what it takes to improve project success rates.
In project management practice retrospectives are the feedback mechanism by which lessons learned are fed back into the organization’s collective body of knowledge. In principle it’s a good idea, in practice, the sad truth is that retrospectives often achieve very little.
The acid test of an organization’s retrospective process is whether or not the lessons identified are really “learned” and the true measure of “learned” is whether or not the organization behaves differently in the future. Unfortunately, in all too many cases, the harsh truth is that the percentage of lessons that are truly learned is extremely low.
An industry in which lessons learned is taken extremely seriously is the commercial aviation sector. Rigorous investigations are conducted following every accident that occurs in the developed world. The lessons taken from those investigations are habitually fed back into the industry as a whole and the success of the process is undeniable. Despite continual growth in air traffic, on an annual basis, statistics show a continual downtrend in the number of people killed in commercial flying accidents.
Although most technology projects don’t involve the risks the aviation sector faces (and hence no one would be willing to invest the amount of money in project retrospectives as the aviation industry invests in its reviews), it’s still interesting to consider the differences in the way the two industries approach lessons learned. Having read lessons learned from both IT projects and aviation incidents there is one difference that immediately pops out. While both industries identify where things went wrong, the depth of analysis in the aviation sector is considerably deeper than that found in a typical IT project.
That additional analysis allows the aviation industry to view issues within a much broader context than is typically done in the IT sector. By seeing issues in their broader context, accident investigators don’t just look at what went wrong, they also look at the management practices, cultural issues and training components that contributed to the failure.
While you can argue that the reasons for the aviation industry’s success lies in the fact that there is a regulatory regime that enforces the recommendations accident investigators make, I think a part of the success lies in the industry’s willingness to accept that changes to management practice, organizational culture and training procedures are an integral part of avoiding future failures.
Perhaps because of politics, the IT sector has historically been less open to such discussions and the failure to face up to such issues often undermines the value a retrospective could bring. In many cases, if an organization truly wants to benefit from retrospectives, they will need to take a really hard look at whether they are really willing to learn the lessons that need to be learned.
Resolution strategies to consider:
Hire an independent facilitator to conduct retrospectives / Create a standard set of questions to be answered during a retrospective and ensure those questions get below the surface / Use the 5-Why’s technique.