A medida que un proyecto pasa por las fases de planificación y diseño, se tomarán muchas decisiones. Desarrollar con tecnología X en lugar de tecnología Y. Dejar la característica z fuera del plan para esta versión del lanzamiento para cumplir con una fecha límite estricta. Muchas decisiones, grandes y pequeñas (ya veces las decisiones sobre lo que no se hará son tan importantes como las decisiones sobre lo que se hará).
¿Cómo puede un gerente de proyecto capturar y compartir mejor las decisiones que se tomaron para que no se revisen continuamente a lo largo del proyecto? ¿Deberían documentarse también el "por qué" y el "quién tomó la decisión"? ¿Cómo debe equilibrar el director del proyecto la comunicación de las decisiones clave sin abrumar a las partes no interesadas con minucias? ¿Cuándo está bien revisar una decisión que parecía una buena idea en ese momento, pero que no se confirma en la práctica?
La gran mayoría de las decisiones se toman en el contexto de reuniones. Por esta razón, elijo documentar las decisiones en las actas de las reuniones.
Cada proyecto que estoy ejecutando tiene su propio depósito de actas de reuniones compartidas y visibles en una herramienta de colaboración como un wiki para que todos puedan acceder fácilmente a él y buscarlo fácilmente.
Al documentar las actas de las reuniones, marco los elementos de decisión con el prefijo [Decisión]. También documento la justificación detrás de la decisión, las alternativas que se discutieron y el contexto de la decisión. Dado que la decisión se documenta en el contexto de una reunión, también se documentan los participantes de la reunión y quién tomó la decisión.
Esta metodología permite que cualquier persona busque [Decisión] y obtenga todas las decisiones tomadas para un proyecto.
El punto importante en la pregunta original es documentarlos en algún lugar al que sea fácil volver. Es mucho menos importante cómo los registra, pero debe ser consistente a lo largo del proyecto. También es muy útil poder ver fácilmente todas las decisiones en una sola vista, independientemente de cuándo se hayan planteado, por lo que prefiero realizar un seguimiento de ellas de forma independiente a las actas de las reuniones.
Usamos SharePoint para administrar toda la documentación de nuestros proyectos y, por lo tanto, también lo usamos para realizar un seguimiento de las decisiones. Hemos creado un tipo de contenido personalizado basado en un elemento (pero podría usar fácilmente un tipo de lista personalizada). Capturamos un breve resumen y una descripción más detallada de la decisión junto con la fecha. Luego usamos un flujo de trabajo de aprobación para que las personas adecuadas aprueben la decisión. De esa manera, tenemos un buen registro de auditoría para mostrar quién aprobó la decisión y cuándo.
Yo también registro reuniones y uso una clave para seguir las decisiones; Todas las viñetas en mis minutas comienzan con una de las siguientes:
yo: para informacion
R: Para acción, con el propietario de la acción al final en negrita [Me gusta]
D: Para decisiones
Además, mantengo una diapositiva de suposiciones en mi paquete mensual de la junta de proyecto/comité directivo y resalto en negrita todo lo que ha cambiado desde el mes pasado. Revisamos esto en la reunión de la junta para asegurarnos de que todos estén contentos con las decisiones.
De acuerdo con el PMI, todas las decisiones deben estar documentadas en el Project Charter (creo), junto con el razonamiento detrás de la decisión.
La razón es responder primero a la pregunta que la gente del futuro hace de "¿por qué hicieron X?" y el segundo es mantener un registro documental en caso de que las cosas salgan mal, no para culpar, sino para comprender.
Creo que la forma más fácil de capturar decisiones es en un documento visible públicamente; puede categorizarlos, comenzando con decisiones importantes (como tecnologías o características) y colocando secciones para otras áreas para personas que se preocupan (por ejemplo, decisiones financieras, decisiones tecnológicas).
Es difícil decir algo sobre la revisión de decisiones, así que diré esto: evítelo personalmente (excepto en los casos en los que esté 100 % seguro de que tomó la decisión equivocada) porque permitirlo significa que cualquiera, en cualquier momento, puede cuestionar la decisión y termina hasta tener las mismas reuniones una y otra y otra vez.
Leer Área de Procesos de Análisis y Resolución de Decisiones en CMMI para Desarrollo 1.3 .
Uso una hoja de Excel simple para capturar problemas/acciones y decisiones relacionadas.
Aquellas decisiones que necesitan la aprobación de SteerCo se registran en el Informe de estado del proyecto mensual, actualizado con los resultados de la reunión de SteerCo.
He experimentado con algunas estrategias diferentes para registrar decisiones. Como mencionó Stephen anteriormente, tenía una pestaña en mi hoja de Excel de estado como un registro de problemas. Este registro de problemas es donde realicé un seguimiento de las preguntas/respuestas que surgieron y que podrían no regresar a los requisitos.
Estoy de acuerdo con el cartel de arriba que lo registra en las notas de la reunión. Esta es una buena manera de obtener el contexto. Me gusta hacer eso y también anotar la decisión donde tengo detalles de la tarea que se está realizando. Cuando tiene una herramienta colaborativa como LiquidPlanner , esto puede ser fácil.
Sean Earp
Beto
SBWorks