El tratamiento post-mortem de un proyecto

Mike Gunderloy dedica un artículo en Developer.com al cierre post-mortem de un proyecto, considerándolo con razón una herramienta de importancia en su manejo en el tiempo, denominándo la técnica "memoria institucional".

Though the name is well-established by now, "postmortem" has somewhat unfortunate connotations. The purpose of a good software postmortem isn't to carve up the corpse of a collapsed software project so as to assign blame for failure (though in dysfunctional organizations postmortems get used this way anyhow). Rather, the goal is to build up an institutional memory and develop a set of best practices that work for your own organization by meticulously recording what went right and wrong over the course of a project.
(...)
The difference between an organization with a culture of postmortems and one without can be dramatic. This is probably in part because of the good effects of postmortems, and in part because companies that lack the discipline to perform postmortems tend to be at a rather chaotic level of practice. When postmortems are institutionalized, you'll find people saying things like "we organize our source code tree this way, because we've found in the past that it works well" or "we stopped using that particular risk assessment practice because it just wasn't giving us any useful information." Without postmortems, developers are more likely to invent techniques as they go along, without much regard for what may or may not have worked in the past - and more likely to be surprised when something fails for the second (or third, or tenth) time.
(...)
Software postmortems, performed consistently, are a key part of bringing a development organization from chaos to smooth, repeatable functioning. In fact, if your development efforts are completely disorganized, postmortems can be a great way to start turning things around, because they will help you identify and keep the good parts while finding and throwing out the bad parts. If you're not already using this essential tool, it's never too late to start.

Gunderloy da nueve sugerencias para su elaboración:
Planear las actividades:

People need to have time to think without being thrown immediately into the next project. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report

No dejar pasar mucho tiempo:

Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the postmortem, rather than waiting for a convenient break in the action (which never comes, anyhow) a month or two later

Registrar los detalles:

Part of the postmortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on. This is not padding, but a way to help people looking for applicable experience in the future. If you build up a library of dozens of postmortems, a team about to embark on a 5-person, 6-month effort can use the project details to look for similar projects that the organization has tackled in the past

Involucrar a todos los participantes:

You need to collect them all to really understand what worked and didn't.

Registrar tanto los aspectos exitosos como los fallos:

It's easy for a postmortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features. But people need to hear positive messages as well as negative ones, and they need to hear what things are worth repeating as well as which things are worth avoiding in the future.

No debe ser un argumento de penalizaciones:

If you want honest postmortems, management has to develop a reputation for listening openly to input and not punishing people for being honest. And the way to get that reputation is by not punishing people.

Establezca un plan de acción:

The written postmortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them

Hágalo disponible:

If you're the one responsible for producing one, you should consider sending out an e-mail at the end of the process saying something like, "The XYZ project postmortem is finished and available at \servershare. We recommend that future teams do a, b, and c and avoid d, e, and f. For more details, feel free to read our whole postmortem."