PRO-BDT-007 Monitoreo del Plan de Riesgo
v 11.2 / PMC, PP, RSKM
Propósito
Monitorear el plan de riesgo y tener un registro de los riesgos que surgen en el proyecto
Notas introductorias
Es importante realizar una revisión periódica de los riesgos para que se pueda mantener un estado estable del proyecto
Involucrados
Todos los integrantes del equipo
Entradas
Salidas
Estrategia para dar un seguimiento continuo al plan de riesgo y/o el documento de Plan de Riesgo actualizado
Descripción
| Fase | Actividades | Responsables | Prácticas Asociadas al CMMI |
|---|---|---|---|
| Identificación | Si cualquier miembro del equipo encuentra un riesgo o problema, tiene la responsabilidad de informarle de inmediato a su equipo sin importar su magnitud y registrarlo en el Log de Riesgo del proyecto correspondiente, registrando la fecha de identificación, el ID del riesgo identificado, la persona que lo identificó, el estatus del riesgo | Team Member | PP SP 2.2 PMC SP 1.3 |
| Identificación | Si un riesgo nuevo es detectado, se tiene que agregar a la tabla del Plan de Riesgo del proyecto correspondiente, identificando a qué categoría DAD corresponde, la fuente del riesgo, el ID y el nombre del riesgo, una breve descripción de ese riesgo, sus consecuencias, su probabilidad, impacto, plan de mitigación y un plan de contingencia. Después, actualizar la versión de ese plan de riesgos indicando quién agregó, qué riesgo, y cuándo en el control de cambios que se encuentra en la parte inferior del plan. | Team Member PVG Owner Program Manager | PP SP 2.2 PMC SP 1.3 PMC SP 2.1 RSKM SP 1.1 RSKM SP 1.2 RSKM SP 1.3 RSKM SP 2.1 RKSM SP 2.2 RKSM SP 3.2 |
| Identificación | En el caso de los proyectos del desarrollo, PVG Owner y en el caso del departamento, el PM deberá de revisar las magnitudes actuales de los riesgos cada lunes y jueves, haciendo un análisis de acuerdo a la probabilidad de que el riesgo suceda y el impacto que este tendría en el proyecto. Si se identifica que el riesgo cuenta con un valor "alto" de acuerdo a su probabilidad e impacto (guíarse de la tabla al inicio de la hoja), El PVG Owner lo comunicará en la daily del equipo para poder asignar responsables de aplicar el plan de mitigación. | PVG Owner Program Manager | PP SP 2.2 PMC 1.3 RD SP 3.4 RSKM SP 1.2 RSKM SP 1.3 RSKM SP 2.2 RSKM SP 3.1 RSKM SP 3.2 |
| Registro | De igual manera cada lunes y jueves, el equipo del proyecto revisa el Log de Riesgo durante su reunión diaria, registrando el número y la magnitud de los riesgos activos por el momento y discutir sus futuros decisiones para disminuir estos números | Equipo del Proyecto | RD SP 3.4 RSKM SP 3.2 |
| Control | Si al estar haciendo el análisis, los encargados se dan cuenta que cambia la magnitud de un riesgo, lo deben de modificar de acuerdo al estado del proyecto. Seguido de esta acción, deben de registrar en el control de versiones los cambios a las magnitudes de los riesgos realizados y la razón del mismo. | PVG Owner Program Manager | PP SP 2.2 PMC 1.3 RSKM SP 1.2 RSKM SP 1.3 RSKM SP 2.2 RSKM SP 3.1 RSKM SP 3.2 |
| Control | Los miembros del equipo asignados de llevar a cabo el plan de mitigación del riesgo registran en el Plan de Riesgo la fecha en la que llevaron a cabo el plan de mitigación y se aseguran de comunicarlo en la daily del equipo. | Team Member responsable | PP SP 2.2 PMC 1.3 RSKM SP 1.3 RSKM SP 2.2 RSKM SP 3.1 RSKM SP 3.2 |
| Control | En caso de que el plan de mitigación del riesgo no haya sido suficiente y ya esté generando consecuencias, se considera un problema en lugar de un riesgo y por ende, se debe seguir la GUI-BDT-019 | Team Member responsable Equipo del Proyecto | PMC SP 1.3 PMC SP 2.1 PMC SP 2.2 PMC SP 2.3 |
| Control | Modificar y actualizar el plan de mitigación de acuerdo al resultado de ese riesgo que se convirtió a un problema en el Plan de Riesgos, para actuar de una mejor manera si es que se vuelve a presentar el problema. Se debe identificar en el log de riesgos la persona responsable de ese riesgo de acuerdo a lo definido previamente. | Team Member responsable | PP SP 2.2 PMC SP 1.3 RSKM SP 3.2 PMC 2.2 PMC 2.3 |
| Solución | Si se implementa el plan de mitigación o de contingencia, actualizar el estatus del riesgo en el Log de Riesgo, registrando qué plan de acción se implementó (M en caso del plan de mitigación, y C en caso del plan de contingencia) y quién implementó ese plan de acción. Si el plan de acción no fue exitoso se debe modificar con una propuesta o la manera en que se haya manejado el riesgo. Además se debe marcar la columna que indica que el plan cambió después de su definición inicial al tomar acciones correctivas. Si el plan fue exitoso la fecha de resolución indica que funcionó sin cambio alguno. | Team Member resposnable | PP SP 2.2 PMC SP 1.3 RSKM SP 2.3 PMC 2.2 PMC 2.3 |
Control de cambios
| Versión | Cambio realizado | Análisis | Autor | Revisor(es) | Fecha de cambio |
|---|---|---|---|---|---|
| v 1.0 | Creación del proceso | N/A | Yuna Chung | Sebastian Flores Juan Pablo Cabrera | 27/02/2024 |
| v 2.0 | Definición del proceso más detallado | Como es un proceso para monitorear todo el plan de riesgo, más detalle fue requerido para ayudar a todos los integrantes del equipo entender mejor el proceso | Yuna Chung Sebastian Flores | Juan Pablo Cabrera Sergio Garnica | 04/03/2024 |
| v 3.0 | Prácticas asociadas al CMMI definidas de manera más específica | Algunas prácticas específicas que se identificaron no fueron asociados con el proceso | Juan Pablo Cabrera Yuna Chung | Sebastian Flores Sergio Garnica | 07/03/2024 |
| v 4.0 | Probar el proceso con un Team Lead y un Team Member; Actualizar el proceso de acuerdo a los puntos de mejora | N/A | Yuna Chung Carlos Velasco | Sebastian Flores | 11/03/2024 |
| v 5.0 | Corrección de prácticas asociadas al SCAMPI | N/A | Mafer Moreno Armando Rosas Uri Gopar Ramona Nájera | N/A | 21/04/2024 |
| v 6.0 | Mejora del proceso | El proceso tenía secciones que no estaba funcionando de acuerdo a la forma de trabajo del departamento, entonces se hicieron modificaciones a los pasos | Yuna Chung | Ricardo Fernández | 28/04/2024 |
| v 7.0 | Agregar notas introductorias | Para que sea más fácil de entender la importancia de este proceso, una nota introductoria fue incluida | Yuna Chung | Diego Sandoval | 28/04/2024 |
| v 8.0 | Mejora del proceso | La descripción de las actividades que se tienen que realizar para monitorear los riesgos no era muy fácil de seguir causando la duda de varios miembros del deapartamento, entonces se hizo el cambio especificando un poco más el proceso | Yuna Chung | Ricardo Rosales Diego Sandoval | 06/05/2024 |
| v 9.0 | Mejora del proceso | Se agregó apartado para gestionar los riesgos que se hayan convertido en problemas | Mafer Moreno | Diego Perdomo | 11/05/2024 |
| v 10.0 | Cambio del proceso | Se hizo que el proceso sea menos tedioso, logrando un mejor seguimiento de los riesgos | Juan Pablo Cabrera | Yuna Chung | 23/05/2024 |
| v 11.0 | Mejora del proceso | Faltaba todos los pasos que seguir para registrar los riesgos en su log, entonces se agregaron algunos detalles para que todos los planes tengan la misma información teniendo un burndown del riesgo estandarizado | Yuna Chung | Juan Pablo Cabrera | 24/05/2024 |
| v 11.1 | Corrección de ortografía | reunión diaria tenía un error ortográfico, entonces se corrigió | Yuna Chung | Alejandra Cabrera | 24/05/2024 |
| v 11.2 | Añadir la columna de si el plan tuvo cambios | Mantener un historial de las acciones correctivas que funcionan y cuáles no con base en esta columna y la de fecha de resolución | Alejandra Cabrera | 26/05/2024 |