Los Proyectos que Fallan

jueves 19 octubre


Tres causas comunes por las cuales los proyectos de desarrollo no llegan a buen término.


Un estudio realizado por McKinsey & Co. en conjunto con la Universidad de Oxford (2012) para proyectos de TI de gran escala (5.400 proyectos de muestra), concluyó que 17% de los proyectos fracasaron al nivel de poner en riesgo la existencia de la compañía cliente. Además, añadió que los proyectos, en promedio, se pasan un 45% sobre el presupuesto, se tardan un 7% más del tiempo y en 57% de ellos el resultado es menor del esperado por el cliente.

En Nueva Zelanda, un estudio de 100 compañías realizado por KPMG (2010), descubrió que el 70% de las compañías había sufrido la falla de un proyecto dentro de los 12 meses anteriores. Además, el 50% de las mismas afirmó que el proyecto no sirvió para lograr lo que querían lograr.

The Guardian, famoso periódico del Reino Unido, condujo un reportaje que investigó fondos guvernamentales para distintos proyectos (2008), descubriendo que se perdieron 4 billones de dólares en proyectos fracasados.

Y así, las estadísticas se repiten.

¿Por qué, después de tanta preparación, estudio y desarrollo de la disciplina del Project Management seguimos obteniendo tales resultados? ¿Por qué pareciera que, no importa que tan bien se tomen los requerimientos o que tan precisa se construya la Carta Gantt, no podemos lograr que el proyecto resulte un éxito?

No poseo la panacea a esta compleja realidad, sin embargo, a lo largo de mi experiencia como desarrollador web, he podido identificar algunas de las razones que han hecho que proyectos en los que he participado fallen. Quiero enumerar aquí algunas de ellas.

El Estado de los Datos

De las razones que he oído de falla de proyectos, ésta es una de las menos citadas, pero quizá una de las más frecuentes y cruciales.

De cuando en cuando, compañías o entidades solicitarán algún sistema de administración de sus datos, pero sus datos estarán en muy mal estado. He visto este problema incontables números de veces. Ya sea porque no tienen un DB Admin en la compañía, o porque cada departamento pone sus tablas a la manera que quiere y con la nomenclatura que le convenga, o simplemente porque los datos son inexistentes.

Antes de decir que sí a cualquier proyecto de desarrollo, hay que mirar los datos. Pedirle al cliente que muestre los datos es fundamental. Generalmente, yo acepto cualquier cosa que esté bien estructurada en Excel, porque se puede trabajar con eso. Pero lo óptimo sería que cada compañía contara con una buena y ordenada base de datos, y una bien documentada API REST para acceder a los mismos. No tiene por qué ser pública. Puede ser de acceso restringido, pero ésto provee un estándar para el consumo de los datos para cualquier plataforma y desarrollo futuro.

En una era donde el compartir información de manera eficiente es uno de los factores que hace a una organización prosperar, el tener una API REST interna para consumir los datos es fundamental. Y quizás un departamento de Bases de Datos que se asegure de mantener el orden.

"¿Dónde está el que Corta el Queque?"

Una de las causas más nombradas para fracaso de los proyectos es la ausencia del individuo que "corta el queque" o el steakholder, como le dicen en inglés.

Es cierto que la delegación es parte fundamental de la estructura de cualquier organización, pero también es muy cierto el refrán: "Si quieres algo bien hecho, debes hacerlo tú mismo". Como no todos pueden desarrollar software, piden a otros que lo hagan. Pero como bien sabemos, este proceso requiere extensiva comunicación. Si ya es difícil que el que está a cargo del proyecto comunique lo que quiere, imagina cuánto más si éste entrega la responsabilidad a subordinados que no tienen claro todos los aspectos del proyecto.

Esto siempre ha sido un dolor de cabeza, y una de las alarmas más grandes para el fracaso de un proyectos. Empleados no preparados sumado a la ausencia del que entiende el proyecto a fondo en la mesa de reuniones, es una receta para el desastre.

"Tú dile que sí no más..."

Otra de las razones más comunes del fracaso de los proyectos es la falta de experticia de los desarrolladores. Lamentablemente, los desarrolladores tenemos una reputación de no terminar lo que empezamos, o de exagerar nuestro skillset. He aquí el desarollador de software promedio:

No estoy diciendo que dentro de cada proyecto no haya un espacio para aprender, ¡por supuesto que lo hay! Pero una cosa es el aprendizaje y la experiencia ganada en un proyecto, y el otra es no tener la experiencia necesaria para llevar a cabo el mismo. La sabiduría bíblica es inequívoca a este respecto:

¿Quién de ustedes, si quiere edificar una torre, no se sienta primero a calcular los gastos, para ver si tiene con qué terminarla? No sea que una vez puestos los cimientos, no pueda acabar y todos los que lo vean se rían de él, diciendo: ‘Este comenzó a edificar y no pudo terminar’.
~ Lucas 14:28-30

Quizás muchos con esta actitud han llegado a terminar el proyecto. Sin embargo, ¿cómo fue el resultado final? ¿cuán satisfecho está el cliente con el mismo? Un proyecto exitoso no es sólo un proyecto terminado, sino un proyecto que, terminado, cumple las espectativas del cliente.

Quizás debamos recordar la razón por la cual nuestra profesión es importante. Los que desarollamos software, y especialmente aquellos que desarrollan para aplicaciones con muchos usuarios, deben comprender la importancia de su trabajo. El software es lo que mueve al mundo hoy. Interactuamos con software todo el tiempo. No hay nada que no esté a nuestro alrededor que no haya pasado por un proyecto de desarrollo: las aplicaciones que usamos en el teléfono y en el computador y las páginas web que visitamos en ellas, el gps de nuestro auto, las máquinas de nuestro gimnasio, nuestras consolas de videojuegos, impresoras, etcétera.

En algún momento dejamos de creer lo que los pioneros del desarollo de software creían: lo que yo estoy haciendo tiene un impacto real en la vida de las personas. Las ayuda a realizar mejor su trabajo, les comunica y conecta mejor, les provee información valiosa, etcétera. Tu trabajo bien hecho hace la vida de otros mejor. Si no tomas tu trabajo con esa actitud, entonces el desarrollo de software no es para ti. De hecho, quizás ningún trabajo sea para ti.