Putting Lessons to Work

An important phase of the project development cycle which is often discarded along the way, is the unfortunately-named process of "Post Mortem". It is an ugly term, completely inappropriate to it's significance although quiet understandable that it came to be so named.  The correct term should be "Autopsy".  "Post-Mortem" literally means "after death" whereas "autopsy" literally translates as "see for yourself".  The death analogy is a poor one because successful projects do not die and ill-conceived ones do not die fast enough.  On the other hand, a good old see-for-yourself evaluation should be welcomed at major milestones.

This phase is often passed over in favour of more pressing tactical work because the value of this process is misunderstood. Typically, the coroner's jury includes colleagues of superior or lateral rank to those who worked on the subject project. This is practised because more can be learned by an outside observer; the team members are often too close to be able to see which factors contributed to   the various wins and losses along the project path. The team members themselves, those who's work is being vivisected, are often defensive thinking that they are being second-guessed or criticized.  It is an unnecessary concern and often, when egos get involved, works against the process.

The object is simply to identify what worked, what is working and what did not work in terms of both process and technology. We are test-driving new technologies every day and deploying them to production the next. A lot of learning, a lot of research and empirical trial-and-error occurs in the development process (hence the name), and is would be unwise to miss the opportunity to capture the lessons that every new project brings.  No project is ever perfect; there is always a bottleneck, a bit of room for improvement, something to be considered before we launch on to the next project, which will be bigger and more complex.

That next project will very likely be implemented tools very similar to those used on the project before.  While entire development shops have been known to change programming language paradigms, it is not unlike a religious conversion and does frequently occur.  The same management practices will likely also still be in place and that is when your autopsy results will be the most relevant.  Look at the results and recommendations of that report and compare them to the objectives of your current project.  Are any of them relevant to your present undertaking?  Are there patterns of management or decisions being made which led to trouble in the past? Are you leveraging the most productive practices of the past?  

Every project is different, every client unique.  The lessons from one adventure might not map neatly on to the latest venture.  But the building blocks remain the same.  The complexity of requirements continues to grow an an exponential rate and only through continuous research and learning both within and without the organization can one hope to keep up.