E. A. P. DE INGENIERÍA GEOGRÁFICA

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERÍA GEOLÓGICA, MINERA, METALÚRGICA Y GEOGRÁFICA

E. A. P. DE INGENIERÍA GEOGRÁFICA

TALLER Nº 2: ANÁLISIS PREMÓRTEM

MARTES 02 DE ABRIL DEL 2013

Objetivo: Identificar problemas potenciales que podrían afectar el éxito de un proyecto (en este caso del Trabajo de Aplicación a desarrollar en el presente semestre académico)

1er. momento: Explicación del docente.

2do. momento: Cada estudiante identificará por escrito diez errores que cometieron para que fracase hipotéticamente el Trabajo de Aplicación.

3er. momento: Los integrantes de cada Grupo de Intercambio elaborarán por escrito, previo análisis crítico, un listado de diez errores cometidos tomando en cuenta lo identificado por cada uno. En cada Grupo de Intercambio se elegirá u Moderador y un Relator.

4º Momento: Plenaria en la cual cada Relator de Grupo de intercambio leerá el respectivo listado de errores.

Nota: Al final del Taller cada estudiante entregará el manuscrito de su respectiva lista de errores. La lista elaborada por el Grupo de Intercambio será entregada a la semana siguiente debidamente impresa, donde incluirán los nombres y apellidos de los participantes en el Taller Nº 2, identificando al Moderador y al Relator.

REFERENCIAS

I. “Premórtem” de un proyecto evita “Postmórtem”

Si un proyecto fracasa, la mayoría de los expertos dirán que es necesario detectar los errores que cometieron para prevenirlos en el futuro.

En vez de hacer una autopsia de su gran proyecto y ver al pasado, haga un premórtem y vea qué puede salir mal antes de que efectivamente salga mal.

Después de exponer el plan del proyecto a su equipo, reúnalos y plantéeles la situación hipotética de que el proyecto ha fracasado, pídales que escriban todas las razones posibles del fracaso.

Este ejercicio ayuda a los miembros del equipo a identificar cómo podrían perder el rumbo y estar atentos a las señales tempranas de problemas en el proyecto durante su ejecución.

Adaptación de “Guide to Project Management.”

http://cliente360.wordpress.com/2011/08/29/premortem-de-un-proyecto-evita-postmortem/

II: Project premortem

A los incautos que compraron Blink, la última cagarruta de Malcom Gladwell, tal vez les suene el nombre de Gary Klein - al menos, debería sonarles, porque fue el autor de los trabajos que dieron lugar a muchas de las anécdotas que cita Gladwell en su "mira-que-cortar-árboles-para-imprimir-esto" [De verdad, si queréis saber sobre el uso de la intuición en la toma de decisiones, comprad 'Sources of power' o 'The Power of Intuition' de Klein o el estupendo 'Simple heuristics that make us smart' de Gigerenzer, que de esto sabe un rato].

Pues bien, Klein publicó en el número de septiembre de 2007 de la Harvard Business Review - hey, tengo muchas cosas que leer, hago lo que puedo por estar al día! - un artículo bastante majo sobre una práctica muy útil que, como es de esperar, se encuentra escasamente implantada en nuestras organizaciones. No busquéis en el PMBOK las sesiones de 'Project pre-mortem', porque no las váis a encontrar, pero creedme cuando os digo que son un buen ejercicio.

Un 'premortem' es la operación opuesta a un postmortem - buen ejercicio de Inversión, que diría De Bono. Su propósito no es otro que identificar las causas del fracaso de un proyecto que todavía no ha, por así decirlo, 'nacido'. Suena morbosillo, lo sé. Por cierto que no se trata de encasquetarse el Sombrero Negro, preguntándonos qué podría ir mal, sino de hacer el ejercicio de situarse frente a un proyecto que YA ha fracasado - repito: aunque no haya comenzado siquiera - y tratar de argumentar lógicamente por qué fracasó. ¿Confusos? Klein nos dice en su artículo que investigaciones realizadas por Deborah J. Mitchell, de la Wharton School; Jay Russo, de Cornell y Nancy Pennington, de la University of Colorado en 1989, sugieren que este ejercicio de imaginación prospectiva 'hacia atrás' - partir de la base de que algo ya ha ocurrido - aumenta la habilidad para identificar las causas del desenlace de un evento futuro en un 30%. En cierta forma, es el mismo principio que anima la construcción de Ramas Negativas en TOC. La diferencia entre un premortem y una sesión de identificación de riesgos preliminar está en lo que pasa entre las orejas de los miembros del equipo. La atención de estas personas está puesta no en mirar hacia adelante - después de todo, ¿quién c.....s puede adivinar el futuro? -, sino en mirar hacia atrás desde una posición 'cierta'.

El proceso, se puede resumir - me permito corregir en algún paso a Klein - como sigue. El Project Manager comienza la reunión anunciando, lágrimas en los ojos, que el proyecto ha sido el más completo de los desastres. Sólo necesita decir eso para poner en marcha la imaginación disparatada de todo su equipo, cuyos cerebros se inundarán de las más terribles imágenes. Todos los participantes deben documentar las razones por las que consideran que el proyecto HA fracasado. Transcurrido un tiempo prudencial - bastan cinco minutos -, el PM solicita a los miembros de su equipo que lean en voz alta, una cada vez, las causas identificadas. Mi consejo es que a partir de aquí se trabaje con 'lógica de condición necesaria', para determinar las cadenas de causas necesarias que conducen desde la causa identificada por esa persona hasta el fracaso total. Lo que os propongo es que construyáis un Árbol de Prerrequisitos y/o una Rama Negativa - Klein no conoce las herramientas, está claro - para el proyecto a partir de la información obtenida en la sesión premortem.

Es posible que se descubra que muchos de esos riesgos ya han sido identificados previamente y/o que ya se han adoptado medidas para eliminarlos, minimizarlos, transferirlos o asumirlos con el mínimo de perjuicio. Pero también es posible que alguno no haya sido detectado antes. Y cualquiera de esos 'riesgos', esas causas del desastre, son 'condiciones necesarias' para el buen fin del proyecto. Basta una sola para acabar con el proyecto.

Posted by Mario López de Ávila Muñoz on 10/25/2007

...