Proyectos TI y los entusiasmos peligrosos
Motivado por una creencia interna y por una discusión siempre desafiante y de larga data con Eduardo Díaz, sobre el desempeño de los proyectos TI, llegué a este libro con un nombre muy decidor y provocativo a la vez, se trata de Dangerous Enthusiasms (entusiasmos peligrosos) escrito por Robin Gauld y Shaun Goldfinch, quien resume algunas de las ideas del libro en el paper adjunto – Dangerous Enthusiams (S Goldfinch) -, muy en la línea de los denominados proyectos Cisne Negro que mencioné en un post anterior.
En todo caso según Robert Charette estos problemas se darían tanto en el mundo público como privado, como lo plantea en un artículo en la IEEE denominado Why Software Fails.
El libro de Goldfinch aborda la problemática de los proyectos TI en el sector público, si bien hace una revisión a nivel internacional, destacando varios casos fundamentalmente en el área de salud, finalmente se centra en proyectos desarrollados en Nueva Zelandia, sólo para dar algo de contexto cabe señalar que Nueva Zelanda está raqueado en el lugar 13 del ranking de Naciones Unidas de gobierno electrónico (UN eGov), lo cual muestra que estamos hablando de uno de los líderes mundiales en materias de digitalización del estado.
En su introducción el libro entrega algunos ejemplos y cito:
Enthusiasm for large and complex investments in IS continues unabated despite decades of failure. Indeed, the largest-ever public sector project was initiated in 2002 by the United Kingdom’s National Health Service at an estimated cost of US$11 billion…
Cabe señalar que ambos autores, no vienen del mundo de las tecnologías de información, Gauld del sector salud (políticas públicas en Salud) y Goldfinch de la ciencia política, ambos académicos de la Universidad de Otago, universidad con la posición número 133 en el ranking de QS. Por lo tanto su background no está en la Ingeniería de Software como le gustaría a algunos, pero que les ha tocado vivir en carne propia algunos de los proyectos que mencionan en el libro. Si bien no comparto todos los argumentos y planteamientos que se hacen en el libro, con una mirada más bien tecno-pesimista, hay algunos elementos muy interesantes a la hora de evaluar el comportamiento de los proyectos TI. Los autores describen lo que llaman los 4 tipos de entusiasmos, que han llevado a grandes proyectos TI del estado neozelandés a estrepitosos fracasos, de hecho los autores van más lejos y los llaman fiasco y engaño. La categorización de entusiasmos que hacen son:
- Primer entusiasmo – enamoramiento: los autores lo centran en la idealización o enamoramiento por la tecnología, en el cual gerentes y directivos públicos esperan que las TI cambien por completo el negocio del sector público.
- Segundo entusiasmo – technofilia: se produce cuando los tecnólogos le asignan propiedades a las tecnologías de información más allá de su real potencial y que pueden resolver todos los problemas asociados a las prácticas del sector público. Es lo que podríamos denominar el enfoque geek.
- Tercer entusiasmo – lomanismo (lomanism): expresión correspondiente al arquetipo del vendedor (Willie Loman) del libro La muerte de un vendedor de Arthur Miller. El lomanismo (si es que lo podemos llamar así) es entusiasmo fingido o real que un vendedor tiene por los productos/servicios de su empresa (integradoras, TI, consultora), sin evaluar las reales restricciones de sus productos/servicios y las condiciones de borde de un proyecto en particular. Esto es, empresas que venden más allá de sus reales capacidades.
- Cuarto entusiasmo – moda gerencial: la tendencia de consultores y gerentes por abrazar tempranamente las nuevas tendencias gerenciales, metodologías, o ultimas modas de algún gurú del management en general del mundo privado. Muchas veces esta mirada pone las TI como una forma de resolver casi todo, habitualmente con el sesgo del análisis de desempeño de grandes empresas tecnológicas (Apple, Google, …).
Según los autores estas patologías del entusiasmo y perdida del sentido de realidad generan la mayoría de los fracasos en los proyectos TI.
Lo que los autores recomiendan como una receta para un fracaso seguro en los proyectos es seguir las siguientes directrices:
- Un proyecto muy ambicioso con un gran alcance, que requiere de tecnologías no probadas
- Aumentar la complejidad con un cambio organizacional importante y vincularlo esto directamente al éxito del proyecto
- Un contrato largo y complejo asumiendo que el contrato resolverá todo si el proyecto tiene problemas, en lugar de contratos más pequeños y manejables, separando componentes de diferente naturaleza
- Creer sólo en lo que icen los proveedores, sin contar con adecuada contraparte
- Proyecto con una duración muy larga en su desarrollo y que tiene riesgos importantes en términos de cambios normativos y/o de obsolescencia tecnológica
- Creer en todo lo que le dicen del grado de avance del proyecto
- Esperar que los problemas se van a resolver más adelante y no asumir los costos de la decisión hoy
- Poniendo más recursos (técnicos, humanos o financieros) pensando que eso va a resolver el problema.
Algo que en el libro se insiste en forma majadera es, y cito:
The New Zealand public sector has learned the key lesson of this failures: large projects always fail
Lo cual me recuerda el modelo de delfines versus ballenas, que describo con más detalle en polisDigital en su capítulo sobre Modernización del Estado.
Si bien sigo siendo un tecno-optimista, lecturas como esta permiten una mirada más amplia respecto de los cuidados a tener, y dejan claras enseñanzas, los autores recomiendan un cierto nivel de pesimismo sobre los proyectos TI;
dejo finalmente a ustedes decidir.
Alejandro en ciertos puntos el software IT para gobiernos especialmente locales, a mi criterio debe ser en su mayoria del tipo SaaS (software como servicio) donde el desarrollo y el costo se licua entre varios compradores, y por el otro lado el comprador no necesita «comprar» sino que paga por lo que usa en una modalidad de arriendo, cosa que la convergencia actual nos permite con la «nube» y su flexibilidad.
Esto como dices permite dar soluciones del tipo «parte por parte» y sumadas entre varios proveedores y formulas PPP aceiten el proceso, generando una sana competencia y actualizando los productos día a día, en base a la demanda.
Tu que crees ?
Revisando cada elemento de la receta, al parecer Transantiago estaba destinado a fracasar.
Mi dudas son:
¿Como reparar una gran proyecto fracasado? ¿Como mostrar que una serie de soluciones tipo delfin generarán la solución a un gran problema sin parecer ser soluciones parche que nadie está dispuesto a empezar a invertir?
No comprendí mucho las ideas planteadas por método delfín y ballena
Gracias por el comentario, se refiere a las estrategias de abordaje de los grandes proyectos, la diferencia reside en segmentar los proyectos en pedazos más pequeños incrementales (delfines) en lugar un gran proyecto (ballena).
Saludos
Alejandro