He sido "ascendido" de un puesto de desarrollador de software a un puesto de gestión de proyectos en un pequeño proyecto en solitario (alrededor de 200h). Todo el trabajo de desarrollo lo haré yo, y también hablaré con el cliente, documentaré el proyecto, haré los presupuestos, etc.
He leído que el peor error que cometen los nuevos PM es que no administran los riesgos del proyecto. El problema es que no se por donde empezar. ¿Cómo detectar los riesgos? ¿Qué tengo que ver con ellos? ¿Algún ejemplo?
La gestión de riesgos en un proyecto individual será bastante diferente a la gestión de riesgos en proyectos típicos.
Simplificar un poco las cosas un riesgo es algo que posiblemente puede salir mal, aunque no puedes estar 100% seguro de eso. Las probabilidades de materializar un riesgo pueden ser tan altas como casi seguras o muy, muy bajas y, por supuesto, cualquier cosa entre esas dos. El impacto del riesgo también variará, lo que significa que a veces estamos dispuestos a aceptar que un riesgo específico se vuelva real y no hacer nada al respecto.
De todos modos, normalmente identificamos los riesgos, luego los evaluamos para saber qué riesgos tienen el mayor impacto negativo y luego tratamos de mitigar los pocos que son las mayores amenazas para el proyecto.
Ahora, lo específico de un proyecto en solitario:
Identificación de riesgos.Por lo general, invertimos mucho esfuerzo para hacer que la identificación de riesgos sea una actividad colectiva, lo que significa que queremos saber qué es lo que todos en el equipo consideran un riesgo. Por lo general, PM no estará al tanto de los riesgos técnicos de bajo nivel hasta que los desarrolladores los llamen, y los desarrolladores rara vez se preocupan por los riesgos organizacionales. En un proyecto individual, debería ser mucho más fácil, ya que eres el único miembro del equipo del proyecto, por lo que unir el conocimiento de todo el equipo es básicamente tu conocimiento. Otra cosa buena es que debe ser consciente de las diferentes perspectivas de un proyecto (técnica, organizativa, comercial, etc.) lo que hará que sea más fácil señalar los riesgos que están en el límite de dos áreas diferentes, por ejemplo, el cliente no entiende el forma en que trabajamos, lo que puede afectar el proyecto, ya que necesitamos su aporte en las sesiones de planificación durante cada iteración.
Evaluación de riesgos. Nuevamente, la evaluación de riesgos debería ser más fácil en un proyecto en solitario, ya que básicamente todo el conocimiento sobre qué tan probable es que el riesgo se materialice o cuánto se dañará el proyecto si eso sucede, eventualmente debería estar en tu cabeza. Digo eventualmente, ya que la evaluación correcta puede requerir algunas consultas de su parte para verificar los objetivos de las partes interesadas, etc. nadie que te desafíe. Por otro lado, definitivamente evitará discusiones inútiles sobre el impacto de los riesgos, ya que sería solo su decisión arbitraria. Recuerde evaluar los riesgos periódicamente.
Mitigación de riesgos. Esto es básicamente lo que hacemos para evitar riesgos o reducir su impacto negativo una vez que se materializan. Y esta parte en realidad no difiere tanto.
También puede leer mi artículo anterior sobre los conceptos básicos de la gestión de riesgos que puede ser útil .
¿Qué preguntas tienen usted u otros que aún no han sido respondidas? ¿Qué suposiciones han hecho usted u otros que aún no han sido probadas? ¿Qué se puede hacer mejor? Donde tienes una predicción, ¿qué no es 100% seguro? ¿Qué indican las autopsias en proyectos similares completados anteriormente? ¿Qué te mantiene despierto por la noche?
Finalmente, escuche atentamente a sus partes interesadas. No dirán, tenemos estos riesgos. Sin embargo, le dirán claramente a qué le temen y cuáles son las amenazas de formas muy indirectas.
La gestión de riesgos es parte de todo lo que hace. Cada acción que realizas, cada problema que planteas, cada decisión que tomas... riesgo.
Recomendaría hablar con algunos de sus colegas de Desarrollo y PM que tenían proyectos similares, ya sea por el modelo de entrega o por tecnología y ver sus lecciones aprendidas o sus registros de riesgo.
Uno de los "riesgos" que he encontrado que ocurre es no dar un paso atrás para tener una visión general del proyecto, especialmente cuando el proyecto está en pleno desarrollo y usted está muy concentrado en su ejecución.
No conozco otra forma de evitar esto que no sea la estricta autodisciplina al hacer un informe semanal y un informe de estado. El informe de estado debe estar lo más cerca posible de los hechos. Lo digo porque es difícil de hacer. Es mucho más fácil evaluarlo a través de una tercera mano.
Comience por hacer una lista de todo lo que podría salir mal con el proyecto en términos de plazos incumplidos, ser más costoso y no poder entregar el producto final deseado.
Luego, decida qué tan malo sería si cada uno de esos riesgos ocurriera y cuál es la probabilidad de que ocurran.
Para aquellos que tienen una alta probabilidad de suceder y un gran impacto, planifique con anticipación cómo abordaría ese riesgo.
Entonces manténgase atento a esos riesgos que ocurren. Asegúrese de informar a sus partes interesadas cuando un riesgo tenga un 50 % de posibilidades o más de ocurrir.
Es la planificación anticipada para ocurrencias de riesgo lo que hace la mayor diferencia en la gestión de riesgos.