He estado trabajando en el tema de la gestión de riesgos en el desarrollo de software durante un tiempo. De acuerdo con la literatura diferente, podría haber conocidos conocidos (riesgos típicos), conocidos desconocidos (riesgos relacionados con el producto) y desconocidos desconocidos (cisnes negros).
conocidos conocidos
Tiene algunas estadísticas de la industria y puede usar algunas simulaciones (por ejemplo, RISKOLOGY) para que pueda agregar, digamos, un 20 % al alcance y al cronograma.
incógnitas conocidas
Aquí puede intercambiar ideas con el equipo y elaborar la lista de riesgos relacionados con el proyecto, y proponer acciones preventivas y estimarlas, para que puedan incluirse en el alcance. Pero, ¿qué pasa con el resto de las incógnitas conocidas? ¿Debería planificar para las contingencias? ¿Cuánto cuesta? 10%?
cisnes negros
¿Solo plan para contingencias? ¿Cuánto cuesta? 20-30%?
¿Cómo planifica estos riesgos en el inicio del proyecto o en la fase de planificación, especialmente cuando el cliente solicita estimaciones? ¿Cómo suele presentar todos estos diferentes tipos de riesgos al cliente, especialmente si los riesgos duplican el presupuesto o las estimaciones de cronograma?
Los riesgos se clasifican típicamente en estas dos categorías: Desconocidos conocidos y Desconocidos desconocidos. Puede dividir este último en Unknown Knowable Unknowns y Unknown Unknownable Unknowns. Los conocidos conocidos no son riesgos ya que esto implica certeza.
Tiene dos tipos de impulsores cuando se trata de su presupuesto y riesgos de programación. El primer controlador es de naturaleza aleatoria, o variables aleatorias que impulsarán sus resultados. La mejor visualización es establecer una estimación de 3 puntos, por ejemplo, en el mejor de los casos, $1,000; muy probablemente $1,500; en el peor de los casos, $2800, y dibuje una distribución triangular que conecte estos tres valores. Para simplificar, supongamos que establece su presupuesto en $ 1,600, $ 100 por encima de lo más probable en su estimación. Esto deja el rango de $1,601 a $2,800 como su exposición desfavorable y todo lo que esté por debajo de $1,600 como su favorable.
Su segundo impulsor son los riesgos de tipo más discreto, o riesgos epistémicos. Estas son amenazas específicas que puede identificar y calcular la probabilidad y el impacto. Debido a la especificidad de la amenaza, puede calcular los costos de mitigación, así como el valor que desea proponer para la contingencia, tal vez en función del valor monetario esperado.
Su última pregunta no es fácil de responder. Esto depende de cómo estés contratado con tu cliente. Si va con riesgo, es decir, un contrato de precio fijo, su cliente no necesita saber lo que incorporó en su propuesta de riesgo. Ninguno de sus asuntos. Si es T&M o cost plus, entonces se convierte en una discusión conjunta sobre sus evaluaciones de amenazas, los costos que calculó y una decisión conjunta sobre qué poner en reservas. Tus valores objetivo es lo que pones bajo contrato. Las reservas no están en el contrato, sino que el cliente las tiene para usarlas en caso de que sucedan cosas malas.
De cualquier manera, la presentación de su propuesta no es fácil. Los clientes quieren escuchar un éxito garantizado a un costo cercano a cero. Ese es su desafío como vendedor de servicios.
Los riesgos pueden ser aceptados, controlados o transferidos. Sin duda, el plan de su proyecto debe incluir un análisis de riesgos y los controles recomendados, pero los riesgos pertenecen propiamente a las partes interesadas del proyecto. Como director de proyecto, debe centrarse en documentar los riesgos y proporcionar controles de proyecto razonables para aquellos riesgos que no se aceptan o transfieren.
Todo proyecto tiene un objetivo. En la mayoría de los casos, los objetivos de gestión de los proyectos no son realistas. Por ejemplo, un proyecto que se estima con la programación del mejor de los casos y sin retrasos en el proceso es, lamentablemente, común y representará el mejor de los casos para el proyecto en cuestión.
Una estimación, por otro lado, mide lo que cree que sabe y luego tiene en cuenta su cono de incertidumbre y otras cifras de análisis de riesgo para llegar a una estimación más realista. Cuanto más sepa sobre el dominio del problema y sobre los riesgos que puede enfrentar, más precisas serán sus estimaciones.
En general, puede resultarle útil ofrecer sus estimaciones como un rango en lugar de un conjunto de números fijos. El tamaño del rango implica intrínsecamente incertidumbre, que es realmente el punto: está haciendo una conjetura basada en un conjunto de suposiciones.
Un método alternativo es aplicar un "factor de engaño" a sus estimaciones. Esto se puede basar en medidas históricas (p. ej., sus proyectos generalmente se presentan en +/- 20 % de la estimación realista) o en la tolerancia al riesgo (p. ej., su proyecto puede tolerar un retraso en el cronograma <= 10 %).
Soy un gran defensor de la transparencia en la planificación, por lo que si sigue este camino, ciertamente reconocería que esta cifra es un factor de engaño, en lugar del resultado de un análisis cuantitativo. En Scrum, normalmente aplico un factor de fudge de 0,6 para los equipos nuevos y de 0,8 para los equipos establecidos, pero su millaje definitivamente puede variar.
El riesgo nunca es cero y las estimaciones no son garantías. En general, he descubierto que la mejor manera de manejar esta realidad es simplemente documentarlos como parte de los supuestos de su proyecto.
Por ejemplo, la documentación de su proyecto puede incluir un análisis de riesgo formal o informal, así como un cronograma objetivo o un conjunto de estimaciones. Al documentar las suposiciones que sustentan el plan de su proyecto, mejora las comunicaciones y al mismo tiempo prevé contingencias.
Considere un proyecto imaginario donde asume:
Si alguna de estas suposiciones resulta ser falsa en algún momento durante el proyecto, las partes interesadas pueden volver a evaluar. La organización puede decidir tomar cualquier cantidad de acciones si el proyecto está fuera de tolerancia, incluido cambiar el plan o cancelar el proyecto.
Si está vendiendo servicios de precio fijo, también debe incluir ese riesgo en sus estimaciones. A veces su organización sale ganando y otras veces no. Si su organización no puede tolerar ese riesgo, entonces no haga contratos de precio fijo.
Recuerde que su función como gerente de proyecto es principalmente aplicar controles razonables al proyecto y comunicar de manera rutinaria el estado del proyecto a las partes interesadas. Políticamente, se puede culpar a los gerentes de proyectos si un proyecto se sale de los rieles, pero trate de tener en cuenta que su función es realizar un seguimiento del proyecto y aplicar los controles del proyecto . En realidad, no puede garantizar un resultado final, ni debe intentarlo.
Si desea venderles a los clientes un cerdo en un golpe, cambie al departamento de ventas. De lo contrario, use su posición para educar a las partes interesadas sobre el alcance y los supuestos contenidos en su plan de proyecto, y prepárese para explicar cómo llegó a los números de planificación que la gerencia y los clientes deben aprobar para hacer avanzar el proyecto.
Ruslán
david espina