Reflexiones de un CIO

Stakeholders es una palabra bastante usada en el mundo del management. El término fue utilizado por primera vez por R. E. Freeman en su obra: “Strategic Management: A Stakeholder Approach” para referirse a quienes pueden afectar o son afectados por las actividades de una empresa.
Luego, el término se extendió hacia otros usos, pues en toda actividad humana, normalmente siempre existen interesados y afectados (para bien o para mal) con cualquier cambio.

Retomando un post que escribí hace un tiempo sobre cuestiones que tienen que ver con buenas prácticas para tener éxito en proyectos (aquel post estaba más orientado a cuestiones actitudinales), me propongo ahora abordar otra cuestión que tiene que ver con la importancia de tener muy claro quienes son todos los stakeholders a la hora de plantear un proyecto y abordar el tema de la complejidad de los mismos desde una visión sistémica dinámica.

Te guste o no, cuando estas planteando un nuevo proyecto, deberías contemplar como impacta el mismo en todos los interesados. Es más, seguramente tendrás que negociar cuestiones al respecto de ese impacto con ellos y alcanzar un acuerdo.

Lo peor que le puede suceder a un proyecto es sufrir un cambio de alcance. Un proyecto mal definido en cuanto a alcance implica indefectiblemente un proyecto que no terminará en tiempo, costo y forma, implica un impacto que puede generar un cambio de norte importante generando muchas veces una gran resistencia y desmotivación entre los participantes activos del mismo. Implica que un buen VAN (valor actual neto) se convierta en un proyecto con retorno negativo.

Desde el punto de vista de la dinámica de sistemas, esto tiene un impacto enorme, que típicamente no se refleja en forma instantánea, sino con un delay en el tiempo (tal cual se comporta muchos sistemas dinámicos) y con efectos muchas veces difíciles de estimar. Todo proyecto se comporta como un sistema complejo donde existen una gran variedad de lazos de realimentación positiva y negativa con relaciones, causas y efectos separadas en el tiempo.

De un paper muy interesante que tuve la oportunidad de leer tiempo atrás sobre la estrategia de administración de proyectos desde un punto de vista de que éstos sean tratados como sistemas dinámicos, rescaté este diagrama de causalidad de la productividad en un proyecto:

Diagrama de Causalidad

El diagrama de causalidad muestra las razones estructurales del comportamiento dinámico de la productividad y la calidad (dos factores que afectan directamente al resultado esperado del proyecto).
Existen dos factores de riesgo que desembocan en el mismo resultado:

El primero, no haber contemplado desde el inicio a todos los stakeholders. Potencialmente, cuando alguno de los interesados se ve afectado por un cambio introducido por el proyecto, intentará introducir un cambio en éste a favor de sus intereses. Si esto se produce en una etapa avanzada del proyecto, la única forma de sumar los intereses del nuevo interesado es plantear un cambio de alcance.

El segundo factor es una falla estructural en el diseño, producida por omisión, por inexperiencia, por una fase de evaluación precaria ó como muchas veces sucede por un planteo de condiciones de contorno ideales que, cuando se llevan al terreno de la práctica dejan de ser válidas generando un impacto en el producto esperado. Resultado: sucesivos cambios de alcances, replanificaciones y revisiones del diseño que finalmente generan que el plan se vuelva inviable ó que exista contradicción entre alcance, presupuesto y programación de tareas.

Volviendo al diagrama de causalidad examinemos la posibilidad de insertar un cambio de alcance en un proyecto en marcha para analizar su impacto.

Toda nueva tarea introducida como producto de un cambio de alcance provoca una reducción en la productividad y calidad esperada sobre el resultado originalmente planteado.
Como resultado del cambio de alcance o diseño (o por un plan inconsistente), el proyecto es probable que se retrase. En respuesta, el proyecto puede sumar más recursos. Sin embargo, mientras que los recursos adicionales tienen efectos positivos sobre el trabajo a realizar, también generan el inicio de efectos negativos sobre la productividad y la calidad.

Agregar nuevo personal reduce el nivel de experiencia media. Ahora las personas menos experimentada cometen más errores y trabajan más lentamente que los más experimentados. Por otro lado aumentar el número de horas de trabajo en favor de recuperar el tiempo perdido puede aumentar la eficacia del equipo de proyecto durante algún período de tiempo, pero también se generan lazos negativos dado que normalmente se suman más horas de trabajo que pueden provocar fatiga, que reduce la productividad y la calidad.

Debido a los efectos secundarios, el proyecto tendrá menos progresos de los que se esperaban. Como resultado, la productividad y la calidad de los trabajos aguas abajo sufren. El proyecto se retrasa aún más. Debido a esto se agregan más recursos y se agregan nuevas tareas para intentar «emparchar» los problemas, continuando así la espiral descendente (reinforcing loop).

Además de añadir recursos (ya sea sumando gente o sumando tareas de «patching de fallas»), una reacción natural a la insuficiencia de progresos es ejercer «presión en el calendario» del personal. Esto resulta en más presión física a los recursos lo que trae aparejado más errores («la prisa genera residuos») y más tareas fuera de alcance. La presión en el calendario también disminuye la moral, lo cual disminuye la productividad y la calidad llegando a aumentar en casos extremos la rotación del personal. Perder personal explícitamente o en motivación refuerza los lazos de retroalimentación negativa.

¿ Como evitar todos estos dolores de cabeza ?

• Contemplar a todos los stakeholders desde la fase más inicial del proyecto (antes de plantear la solución). Acordar y negociar los intereses de todas las partes para que el diseño contemple el 100% de los acuerdos alcanzados. Cuanto más grandes sean las organizaciones y más áreas involucradas haya en el proyecto, esta etapa se tornará más dura, pero es imprescindible invertir tiempo y esfuerzo para fijar un alcance certero al momento de iniciar la fase de diseño.
• Tratar de capturar la mayor cantidad de problemas en la fase de diseño: la etapa de diseño de cualquier solución no sólo tiene por objetivo generar la propia solución, eso es sólo uno de los objetivos. El segundo, es verificar la factibilidad de la misma en campo. Fallar rápido tiene que ser un objetivo permanente. El mindset en el equipo de diseño es que aún con los mejores sobre el tablero de diseño, siempre existirá algo que puede fallar, alguna condición no contemplada, algo siempre fallará. Pero la ventaja de diseñar en función a este mindset es que muchas de las posibles fallas de campo las capturaremos en un early-stage que nos permitirá decidir si la solución es viable o no. Fred Wilson hace un post interesante al respecto en «Events often overtake companies» referenciando a un post de Albert Wenger «Making vs Planning» donde expone el valor de «salir a la cancha rápido» cuando se está en la etapa de prototipo:

I would spend as little time as possible on the planning and focus instead on turning their prototype into a working system and getting that out into the real world.  They will learn more about the viability of what they are working on (and more about business) then any amount of planning could tell them.

• Los anteproyectos de factibilidad no suman en el VAN: si un proyecto tiene VAN positivo pero el mismo depende de una etapa de análisis de factibilidad de solución, esa etapa no suma ni resta al VAN. Es un costo hundido para la organización. Si algo en el proyecto lo tengo que ejecutar más alla de que el proyecto se haga o no, ese algo no suma en el VAN.
• En la etapa de proyecto, Cash is the King. Un proyecto de VAN positivo que comienza a sumar cambios de alcances y parches por un deficiente diseño o hasta un replanteo por la aparición de nuevos intereses generado por stakeholders no contemplados puede convertirse en un proyecto inviable. Matar un proyecto a tiempo es a efectos del cash lo mejor que la organización puede hacer. Lamentablemente en las organizaciones tradicionales los costos políticos suelen ser altos y en lugar de suspender un proyecto mal concebido se lo hace avanzar a la fuerza. Esta es una práctica perversa habitual, tal vez una de las peores que veo a diario en las organizaciones.

Post relacionado: Claves para tener éxito en proyectos – Parte I