Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
Chapter 12. Project Closure
The software has been delivered and installed successfully. After working long hours and weekends for many months on this project, the project manager and his team heave a sigh of relief that this not very successful project is finished. But did the project manager learn any lessons? Will he and the team members be able to avoid repeating the problems they got into in this project? If the project ends now, it is likely that the story will be repeated in another project, perhaps with minor improvements.
For the project manager, the team, and the organization, the project does not end until a postmortem has been done to uncover what went wrong and why, and what worked and why. This analysis will enable the project manager and the team members to cull out key lessons on project execution. In addition to helping the team members in their future projects, these lessons will also help other projects to improve their execution.
A project closure analysis, or postmortem analysis, is a golden opportunity for process improvement that should not be missed.1,2,3,4 Indeed, this exercise is considered a best practice of software engineering.5 One step in the quality improvement paradigm of the experience factory6 is to analyze the data at the end of each project to evaluate current practices, determine problems, and so on. But despite its benefits, a postmortem analysis is not a "standard" activity.7
This chapter describes the contents of a project closure analysis report at Infosys and gives the closure report of the ACIC case study.