En este artículo, abordaremos el tema de la gestión de riesgos en proyectos y demostraremos cómo se pueden encontrar equivalentes matemáticos para una metodología abstracta. Cualquier proyecto, grande o pequeño, está asociado con problemas esperados e inesperados. La analogía mencionada anteriormente se puede derivar de la Segunda Ley de la Termodinámica. La Segunda Ley de la Termodinámica se ocupa de un concepto: la entropía. La entropía, en resumen, es la cantidad de desorden del sistema. La entropía también es una medida de la información contenida en un sistema. En tecnología de la información, la entropía se considera como la cantidad de incertidumbre en un sistema dado. Esto tiene una relación definida: “A medida que aumenta la cantidad de información, disminuye el desorden de un sistema (entropía)”. Considerando nuestro escenario de gestión de proyectos como un sistema, podríamos crear un sistema modelo, compuesto por fases micro y macro, cada una con una cierta cantidad de entropía. Considerando que la información es inversamente proporcional a la entropía (bueno, ¡casi inversamente!), significa que aumentar la información, a través de una planificación cuidadosa, comunicación y monitoreo del progreso del proyecto, aumentaría la información disponible para un gerente de proyecto. De esta manera, la entropía disminuye. Como la incertidumbre es proporcional al riesgo, al disminuir la entropía o aumentar la información disponible, se puede disminuir las sorpresas.
Los proyectos típicamente siguen una cierta distribución, que es única para el proyecto en sí. Esto se presta bien para modelar el proyecto utilizando uno de los varios modelos matemáticos probados de la teoría de la información y estudiar el progreso para seguir la distribución. Si el proyecto muestra un patrón, entonces utilizando las estadísticas, se podrían ingresar directamente los valores como las variaciones de costo/programación y/u otros indicadores para monitorear, rastrear y, optimistamente, predecir el comportamiento del proyecto. La situación es mucho más complicada que la gestión de proyectos clásica debido a los avances tecnológicos, que son tanto una bendición como una maldición. Con Internet y la tecnología de redes, la cantidad de información disponible ha aumentado exponencialmente a lo largo de los años, aumentando así la entropía de los sistemas. El procesamiento selectivo de información y los índices disponibles en la literatura existente de gestión de proyectos ya no son adecuados.
Proporcionaré mi ejemplo estándar de tecnología de la información aquí. Los proyectos de TI son técnicamente mucho más exigentes que los proyectos estándar de la industria clásica. Estamos hablando de esfuerzos de gestión de proyectos profesionales en una tecnología muy complicada y abstracta, que tiene varias interfaces abstractas que pueden tomar cualquier forma dependiendo del subconjunto de parámetros que influyen en el resultado en un momento particular. Por lo tanto, estudiar la entropía de dichos sistemas y observar el comportamiento para ajustarse a cualquier distribución estándar te ayudaría a cerrar la brecha entre el alto nivel de abstracción existente y el nivel de información necesario para dirigir adecuadamente el esfuerzo del proyecto.
El cumplimiento es otro proyecto en los proyectos de TI, si no es por ninguna otra razón, que el estado trotante de los proyectos de TI. La tecnología tradicionalmente se ha seguido construyendo sobre la infraestructura existente, pero los proyectos de TI han demostrado refutar este comportamiento estándar. Por lo tanto, el cumplimiento de las metodologías probadas no necesariamente garantiza un buen estado del proyecto. Un proyecto de TI puede quedarse corto de las expectativas un día antes de su lanzamiento. El tipo de datos disponibles y su consumo, así como la toma de decisiones, también tienen una complejidad definitiva, que multiplica el riesgo del proyecto. Además, los programas informáticos tienen un ciclo de vida propio y estos programas “evolucionan” con el tiempo, por lo que es casi imposible asignar un comportamiento particular a los proyectos de TI. Además, el equipo de proyecto que trabaja en el desarrollo del programa puede o no sobrevivir al tiempo de vida del software. Hay un “factor humano” en estos proyectos, que no está probado en el tiempo. No tenemos el “legado” como en otras áreas de aplicación. Segmentar el proyecto en estados micro y macro, estudiar las partes individuales y recopilar los parámetros de estos y analizar su ajuste en el “todo” como un enfoque detallado, sin perder la información del paradigma “grueso”, se complementarían en proyectos de complejidad como los mencionados anteriormente.
Mithun Sridharan trabaja para el equipo de Ingeniería de Proveedores de Software Independientes (ISV) de Sun Microsystems y tiene su base en Walldorf, Alemania. Sus intereses incluyen la gestión de proyectos, la poesía, la gestión general, la filosofía y el ajedrez. Como PMP y apasionado blogger, escribe extensamente sobre gestión de proyectos en su blog: Mithun’s Memoirs.
