Pat O'Toole's Dos and Don'ts of Process Improvement: DO Become a Learning Organization
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In his book, The Fifth Discipline, Peter Senge introduced the term "Learning Organization." While most organizations contend that they are learning organizations, with a bit of prompting most of them would have to concede that they're forgetting organizations as well.
Obviously I'm not talking about your organization. After all, at the conclusion of every project, you conduct a post mortem to capture the lessons learned throughout the life of the project.
That one simple statement raises four primary questions, and scads of follow-ups:
Do you really capture lessons learned "throughout the life of the project?" Look at the output from your last several post mortems – I'll lay odds that there are more lessons captured for the construction and test phases than there are for the requirements and design phases.
Did you really capture "lessons learned", or did you simply document "lessons identified?" Whether or not you learned anything can only be determined based on the behavior exhibited on future projects. Do you really have a mechanism that systematically captures and disseminates project experience such that organizational behavioral change is achieved? (Relax, it was a rhetorical question.)
Why do you wait until the "conclusion of the project" to capture the lessons? If you perceive value in conducting a project post mortem, wouldn't there be value in doing it at the conclusion of each phase?
Is "post mortem" really the right term to use? Did yet another project die? Wouldn't "post partum" (or "post pardon") be a more accurate, albeit less politically correct term to use?
Many organizations religiously capture "lessons identified" and then carefully place these pearls of wisdom into a seldom-accessed file cabinet or write-only database. Aldous Huxley told us, "That men do not learn very much from the lessons of history is the most important of all the lessons that history has to teach." Or as one executive put it, "I don't mind my people making stupid mistakes – that's how they learn. I would just like them to make different stupid mistakes next time!"
SQA is always on the lookout for innovative ways that they can add even more value to the projects. What if they convened a short post-phase meeting to capture the "lessons identified" with an eye toward using this information for ongoing improvement? That is, at the conclusion of the Requirements Phase, SQA facilitates a "whine and jeez" session to document what went well, and what didn't go so well throughout the Requirements Phase. This information could then be submitted to the SEPG and used to refine the existing processes, modify existing tailoring guidelines, identify skill enhancement opportunities, etc.
And what if, during the same meeting, the SEPG conveyed the "lessons identified" by other projects that have recently completed the Design Phase, thereby heightening the current project's awareness to potential pitfalls to be avoided, or value-added insights to be considered for their next phase?
Wouldn't these "phase transition reviews" establish a mechanism that systematically captures and disseminates project experience such that organizational behavioral change is achieved? (This time the question is NOT rhetorical!) High maturity organizations tend to behave this way. Perhaps there is a lesson to be learned here. If not, just bury this article in the cabinet you use to store all those other "lessons learned" reports.