No es bueno estar cerca de un proyecto Cisne Negro!
Hace ya algún tiempo escribí sobre el comportamiento de los proyectos TI y su desempeño, producto de ese post tuve bastantes discusiones con mi amigo Eduardo Díaz al respecto, su visión por decirlo de alguna forma era menos alarmista que la mía, como me lo dijo en una ocasión.
Esto me llevó a releer la bibliografía y a buscar otros antecedentes, releí la bibliografía, incluyendo el informe de la consultora Standish Group, me refiero al informe Chaos Repport, el cual el mismo Eduardo se encargó de poner en entredicho.
Dado que nos conocemos hace ya tiempo con Eduardo y conociendo su capacidad y conocimiento en materias de industria y proyectos TI, es que por un momento me hizo dudar.
Pero bueno, como soy porfiado es que seguí inisistiendo en el tema, y a corto andar me encontré con un interesante artículo de la serie Idea Watch de Harvard Business Riview, denominado Why your IT Project may be riskier than you think – Black_Swan.pdf, escrito por Bent Flyvberg, académico de la Universidad de Oxford y director del programa de gestión de dicha universidad, el programa Said Business School. El artículo está escrito en conjunto con Alexander Budzier, consultor de Mckinsey y candidato a PhD en la misma universidad.
Los autores desarrollaron una evaluación de los resultados de 1.471 proyectos tecnológicos, analizando sus presupuestos iniciales y los costos reales de los mismos, los resultados del análisis muestra algunos elementos preocupantes, el promedio de sobre costo fue de 27% para la muestra.
Pero esta cifra, como todo promedio escondía algo grave, unos pocos proyectos tienen sobre costos de 200% y más, los denominados proyectos Cisne Negro (Black Swan Project), 1 de cada 6 proyectos terminaban en esta categoría, los cuales en general tienen consecuencias destrozas para las organizaciones, en algunos casos llegando a la quiebra de las mismas, Flyvberg muestra algunos casos, de empresas bastante reconocidas.
Otro elementos que demuestra el estudio y que rompe la imagen de que el sector privado es más eficiente que el público, ya que el comportamiento de los proyectos es similar, podríamos aplicar mal de muchos…..
Dado que aproximadamente el 17% de los proyectos se transforman en Cisne Negro, toma más fuerza adoptar la recomendación de segmentar los proyectos, y la recomendación de la misma universidad, esto es, moverse desde proyectos del tipo ballena a proyectos en modalidad delfines.
Al menos esto, hace que el impacto y consecuencias de este tipo de fracasos sea menor, por otra parte cada gerente de proyecto debe estar monitoreando si su proyecto tiene potencial para transformarse en un Cisne Negro o no, ya que con 17% no sería raro que en su carrera le toque encontrarse con uno
…siempre había tenido ese tipo de sensaciones. Los porcentajes exactos quizá sean lo de menos: el hecho existe y se suele dar con la frecuencia necesaria para «hundir» un ejercicio económico. Me parece muy interesante la conclusión para los gestores: «cada gerente de proyecto debe estar monitoreando si su proyecto tiene potencial para transformarse en un Cisne Negro o no».
Pero la idea a la que solemos llegar todos conforme vamos acumulando experiencia «Dolphins, not Whales» es la verdaderamente «idea-fuerza» potente en planificación. Todo debería plantearse así, vigilando también el exceso en la «disminución de tamaño» de los «subproyectos», porque eso también los suele hacer ingestionables y consumidores de recursos: ¿cuántas veces no te has dicho: «prefiero un proyecto grande que 10 pequeños»? Y es que tras cada proyecto hay «relaciones personales» y la complejidad de éstas suele ser independiente de la complejidad del proyecto. Gestionar muchos proyectos implica gestionar muchas relaciones personales lo que aumenta el riesgo de «bloqueo»… pero el desarrollo de esta idea quizá diera para otro artículo.
Muchas gracias por compartirlo. Muy interesante.
Creo que sería interesante construir un equilibrio entre ballenas y deflines de acuerdo a la posición de la organización en la carrera de la innovación. Google por ejemplo tiene muchos delfines y uno que otro cetaceo de los grandes… Una lección que Microsoft no ha aprendido. Pero sin duda pienso en mi querido Peñalolén, que además de ballenas y delfines tenemos focas, sardinas y pelícanos.
Pienso en peñalolén porque (y tu tocaste la comparación con sector público) me pregunto cual es la posibilidad de fracaso o sobre costos aceptable. Gracias por compartir tu columna Alejandro, me quedo pensando.
Un abrazo.
Conversando con el mismo Eduardo Díaz, tiendo a pensar que el problema de los proyectos dice relación con implementar software a partir de distinciones equivocadas o falaces. El Relacionalismo, enfermedad similar al martillismo en que con un martillo en la mano todo parece un clavo, ciega a los desarrolladores que sin pensar no dudan en volver Relacional cualquier problema que enfrentan, versiones mas modernas y sofisticadas pasan por el BPMismo. La forma constructiva del software define el tipo de construcción que se puede realizar. Rascacielos son construibles con ladrillos, pero solo la técnica del hormigón armado materializó el rascacielos que hoy conocemos.
A partir de este análisis, es probable que cualquier proyecto «Delphin» mute luego de varias iteraciones a un inmenso y pesado delfín (las 25 tablas del modelo relacional ahora son 200 o 500 y nadie quiere intervenir).
Los desarrolladores no modelan la realidad a través del software, modelan sus propias observaciones del fenómeno. Si sus observaciones y distinciones depende de lo que quiere mirar y a menudo el mismo se engaña entendiendo que su modelo (su mapa) es el sistema (el territorio).
Las distinciones correctas, incluso mal implementadas pueden evolucionar. Las distinciones desafortunadas tendrán siempre el mismo final. ¿Cuales son las afortunadas? … aquellas que no parten de impedimentos y limitaciones que la propia tecnología impone, aquella que habría servido incluso sin computadores, aquella cuyo modelamiento hoy será el mismo en el futuro. Quizá convenga repasar, los planteamientos de Maturana-Varela respecto del observador, el registro de observaciones del observador y la conversación recursiva como la base de cualquier modelamiento.
Gracias Alejandro. Encuentro que con esto entregas aún más bases para convencer a los clientes finales acerca de las ventajas de las metodologías ágiles, o simplemente de dividir un proyecto largo en piezas más pequeñas.
Jota