El valle de la muerte de proyectos TI en sector público

El tema de la calidad de los proyectos tecnológicos es un área a la cual le he dedicado muchas líneas en este sitio. Y en la que he sostenido interesantes debates con varios, en particular Eduardo Díaz .

Si bien en evaluaciones recientes sobre el comportamiento de los proyectos TI como es el caso de la evaluación Pulse of the Profession 2017 del PMI, la cual muestra un mejor escenario que la evaluación Chaos Report de la consultora Standish Group, a la cual muchos critican por su falta de rigor metodológico, en que su versión 2015, mostraba un 71% de proyectos con problemas (en las categorías fracasados y challenge o fracaso parcial). La evaluación del PMI mostró sólo un 27% de proyectos fracasados. Según los entrevistados, cerca de 3.000 profesionales de la gestión de proyectos citaron como principales causales: i) poca claridad en los objetivos y resultados (37%), ii) problemas de comunicación (19%), iii) resistencia de los empleados (14%) y iv) falta de financiamiento (9%).

Las principales causas de fracaso según el estudio del PMI

Incluso la consultora IDC en un estudio mostraba resultados similares reconociendo que se trata de un estudio algo antiguo.  Otras evaluaciones más recientes de proyectos desarrollados con técnicas ágiles, muestran tasas de fracaso relevantes, saco esto a colación porque he escuchado en varias oportunidades que los proyectos desarrollados con este enfoque garantizan su éxito, en el estudio de la empresa 6point6 realizado en el Reino Unido, concluyó que “Agile IT in the UK is facing a hidden crisis – 12% of agile projects are failing completely”.

En los últimos meses me ha tocado evaluar varios proyectos tecnológicos de alta complejidad en el sector público, con serias dificultades en diferentes países y realidades de la región, es decir, para ser más preciso, me ha tocado hacer las veces de enterrador.

En estas líneas me gustaría compartir con ustedes, algunos de las cosas que se repiten en estos casos.  Los proyectos corresponden a proyectos de desarrollo de software de plataformas gubernamentales, con presupuestos que van desde los 5 millones de dólares hasta varias decenas de millones. Algunos de los elementos comunes, tratándose de proyectos de diferente índole y tipología, que creo dan una señal de atención a la hora de diseñar y gestionar proyectos de este tipo son:

• Exceso de exigencias técnicas, es común ver proyectos en los cuales se planeta como una exigencia poner estándares técnicos muy altos, en ocasiones expresada a través del uso de productos de reciente lanzamiento al mercado, en algunos casos incluso sin analizar si el mercado local es capaz de proveer personal con las competencias o experiencia necesarias para su desarrollo.

• Pocas iniciativas para reducir el tamaño, desde hace años que planteo el tema de reducir los proyectos en componentes más pequeños, es decir, la lógica de los proyectos delfines en lugar de proyectos ballena. Los proyectos que analice, continúan con la lógica de las ballenas.

• Modelos de gobernanza poco adecuados, es bastante frecuente ver este tipo de proyectos con poco apoyo de las autoridades y centrado en áreas de informática, con una escasa participación de las áreas del negocio. Otro problema frecuente es la falta de instancias decisionales de nivel estratégico de los proyectos.

• Cambios en la estrategia de externalización, no es raro ver cambios en la mitad de los proyectos, en el modelo de externalización adoptado, pero esto no es un problema en sí mismo. Cuando se decide cambiar el modelo de externalización, esto debe ir acompañado de una reorganización de los equipos internos.

• Cambios en los equipos directivos, muchos de estos grandes proyectos en el sector público tienen una alta rotación de personal, en particular a nivel estratégico y táctico, es decir, las autoridades. Si además juntamos esto con que se trata de proyectos de larga duración (varios años) es muy probable que su ejecución coincida con cambios de administración, lo cual llevará aparejado en muchos casos cambios en las autoridades del proyecto, con la habitual consecuencia de que los que llegan quieren redefinir todo, con la lógica del “not invented here”

• Tiempos técnicos y tiempos políticos, la asimetría entre tiempos técnicos, habitualmente bastante más largos, que los tiempos políticos, no ayudan a tomar buenas decisiones en los proyectos, partiendo por definir fechas que son irreales, sólo para darle la razón a la autoridad. He escuchado en muchas ocasiones que me dicen, pero si el ministro dijo que tenía que estar listo en 2 meses, mi respuesta habitual a ese tipo de frases es: “muy ministro será, y aunque sea el mismísimo presidente, las cosas se demorar lo que se demoran y no lo que el ministro quiera que se demoren”

Si bien existen otras razones me parece que estas son las que más impactan en el resultado de los proyectos y en particular en las causas de fracaso.

Pero probablemente la principal causa de fracaso, y que podríamos denominar como el valle de la muerte de los proyectos TI es el cambio de administración, el que llega quiere hacer todo de nuevo, por lo que si un proyecto logra sobrevivir a un cambio de gobierno, ya tiene la mitad del trabajo hecho.

Imagen: https://www.flickr.com/photos/net_guy/