A defined process for project post mortem review

Berna Collier, Tom DeMarco, P. Fearey

IEEE Software · 1996 · 176 citations · 3 references

Concepts

TL;DR

Software project post‑mortems are often discussed but lack clear guidance, and their effectiveness depends on an organizational learning context that treats past lessons as future risks. The paper proposes a tentative standard process for post‑mortem reviews, outlining activities, roles, and artifacts. The process requires management to publicly commit to using post‑mortem findings as inputs to risk management, ensuring issues are added to a risk database and evaluated on future projects.

Abstract

Most of us pay lip service to the need for software project post mortems, but the literature offers little guidance on how to conduct them. The authors propose a tentative, standard process for conducting post mortem reviews and describe activities, roles, and artifacts of the process. The success of the post mortem-or of any learning process-demands a context that makes organizational learning possible. Management must make an honest and sincere commitment to establish this context. This commitment should take the form of a public resolution to implement risk management on subsequent projects and to make all post mortem findings input to that risk management effort. After all, lessons learned the hard way on past projects are, if nothing else, risks for future projects. Participants are empowered when they know that each issue raised during the post mortem process must be added to the risk database and evaluated methodically on each subsequent project.

References

3