Causas y soluciones al fracaso de

proyectos de TI

Objetivo
Analizar conforme a la temática establecida en la semana, porqué fracasan los proyectos de TI en
las organizaciones.

Introducción
Los proyectos de software son proyectos que tienen características muy particulares: sus
entregables son digitales (programas de cómputo, archivos fuente, diagramas, modelos, manuales,
etc. digitales), requieren mucha creatividad en la mayoría de sus fases, con tasas de fracaso de más
del 70% (según el Standish Group). Los proyectos representan el modelado parcial de la
organización, son de gran complejidad, son muy costosos, son manejados con poca experiencia
administrativa y son de gran importancia para las organizaciones en la sociedad postindustrial
[Zavala, 2004]. En mercado.com [2002] se menciona que, aunque que poco se habla de los fracasos,
es conocido que una cantidad muy significativa de los proyectos de informática que encaran
empresas e instituciones terminan en fracasos. La media docena de estudios de dominio público
realizada en los últimos 10 años ubica la tasa de fracasos entre 40% y 70% del total de los proyectos
iniciados [apoyando la conclusión del Standish Gruop, que menciona Zavala, 2004], ocasionando un
costo sideral y un lucro cesante no menos importante. Si tomamos en cuenta que la inversión mundial
anual en TI estuvo en el orden de US$ 3,3 trillones para 2002, según Gartner, resulta paradojal la
persistencia de este problema. Y también el poco esfuerzo que parece prestarse a su solución.
Según las encuestas realizadas, las causas principales de fracaso se atribuyen a la mala
comunicación entre los grupos humanos involucrados, la pobre planificación y conducción de los
proyectos, la falta de compromiso de los directivos, el enunciado de requerimientos incompletos y/o
malentendidos, y falta de participación de los usuarios.

Desarrollo
a. Realice una investigación de todas las posibles causas por las cuales un proyecto de TI
fracasa e indíquelas.

En el Blog de mugperu.com [2013] se encuentra un resumen muy interesante de diversos grupos u

organizaciones que han analizado diversos proyectos de TI, tanto en cantidad como en tamaño; así,
por ejemplo, McKinsey & Company, junto con la Universidad de Oxford, realizaron un estudio
publicado en octubre de 2012, enfocado a Grandes Proyectos de TI, cuyo presupuesto inicial excedía
los 15 millones de dólares. De acuerdo a esta investigación, de los más de 5,400 proyectos de TI
consultados, 45% excedieron su presupuesto, 7% excedieron su cronograma y 56% entregaron
menos valor que el predicho. International Data Corporation (IDC), tiene un estudio de junio del 2009
titulado “Improving IT Project Outcomes by Systematically Managing and Hedging Risk”, por Dana
Wiklund y Joseph C. Pucciarelli, donde se indica que el 25% de los proyectos de TI fracasan sin más
ni más. Al mismo tiempo, 20 a 25% de ellos no proporcionan retorno de la inversión (ROI) y hasta
un 50% de los proyectos requiere reelaboración. Gartner, en un artículo de enero de 2011 titulado
“How to Increase Your IT Project Success Rate” por Susan Tan, proporciona recomendaciones sobre
cómo aumentar el éxito de un proyecto de TI, basado en el análisis de los resultados de 845
proyectos de TI completados con la ayuda de un proveedor de servicios externo (PSE). Tres
estadísticas de la investigación indican que de los proyectos realizados con la ayuda del PSE, el
42.5% no entregaron todos los beneficios esperados, el 44% se entregaron por encima del
presupuesto, y el 42% no fueron entregados a tiempo. Gartner tiene un estudio más reciente de junio
de 2012 en el que se muestran los resultados de una encuesta realizada en octubre de 2011 a 154
organizaciones de 5 países y de varios tipos de industrias con ganancias anuales sobre los 500
millones de dólares. Los resultados se clasifican por tamaño del proyecto, observándose que el
porcentaje de fracaso de los proyectos de TI era del 28% en los Proyectos de TI Grandes (cuyo
presupuesto excede el millón de dólares), del 25% en los Proyectos de TI Medianos (cuyo
presupuesto está entre 350 mil y un millón de dólares) y del 20% en los Proyectos de TI Pequeños
(cuyo presupuesto era menor de 350 mil dólares). Los que parece indicar que mientras más grande
el proyecto, más porcentaje de fracaso se puede obtener (40% más). Un estudio sobre fracasos en
Proyectos de Sistemas de Información, realizado por el Dr. John McManus y el Profesor Trevor
Wood-Harper, examinó 214 proyectos de TI de la Comunidad Europea en un período de siete años
(1998-2005), y encontró que casi una cuarta parte (51) de todos los proyectos (23.8%) fueron
cancelados después de la etapa de factibilidad y de los proyectos terminados aproximadamente uno
de cada tres (69) estaban excedidos en el cronograma y/o en el presupuesto. El CHAOS Report, del
Standish Group, clasifica los proyectos en éxito (el proyecto fue entregado a tiempo, en el
presupuesto y con todas sus funciones), deficiente (el proyecto fue finalmente entregado, pero bien
por encima del presupuesto, no a tiempo o no completado) o fracaso (nada fue entregado). El último
estudio del 2012 indica que el 39% de todos los proyectos son exitosos, 43% fueron deficientes y el
18% fracasaron. El CHAOS Manifesto del 2013 incluye una estadística sobre pequeños proyectos
de software desarrollados entre 2003 y 2012 y que usan las metodologías ágiles o de cascada
(waterfall). Considerando sólo los proyectos ágiles, el 46% de todos los proyectos son exitosos, 48%
fueron deficientes y el 6% fracasaron. Considerando solo los proyectos en cascada, el 49% de todos
los proyectos son exitosos, 43% fueron deficientes y el 8% fracasaron
A continuación, en la Tabla 1, Zavala [2004] en su artículo “¿Por Qué Fracasan los Proyectos de
Software?; Un Enfoque Organizacional” nos muestra una tabla que resume muy bien las causas por
las cuáles los proyectos se cancelan o fallan. Las causas más frecuentes tienen que ver con
requerimientos incompletos, baja participación de los usuarios y deficiencia de recursos.

Tabla 1. Factores de Falla o Cancelación en los Proyectos (Zavala, 2004)

Factores de Daño o cancelación %

Requerimientos incompletos 13.1
Deficiencia en el involucramiento del usuario 12.4
Deficiencia de recursos 10.6
Expectativas no realistas 9.9
Deficiencia en soporte ejecutivo 9.3
Cambios en los requerimientos y especificaciones 8.7
Deficiencia en la planeación 8.1
Ya no se necesita más 7.5
Deficiencia en administración de TI 6.2
Desconocimiento en tecnología 4.3
Otros 9.9

Por su parte, Gutiérrez [2009] lista entre las principales causas del fracaso de los proyectos de
software a las siguientes:

1. Rendimiento deficiente del equipo (programadores desmotivados)

2. Política (plazos imposibles, poca financiación, inflación de expectativas, intereses
contrapuestos, o contrarios a los objetivos del proyecto)
3. Gestión deficiente de requisitos
4. Gestión deficiente del riesgo
5. Gestión deficiente del cambio
6. Gestión deficiente de la calidad: Mentalidad “calidad si hay tiempo”
7. Ausencia de iteraciones (el SW no se ve hasta el final del proyecto)
8. No-diseño
9. Competencia deficiente del Director del Proyecto (liderazgo, gestión)
10. Requisitos no funcionales: Innovación, escala

Y concluye con esta gráfica, donde se aprecia que las principales causas (59%) son por técnicas y
prácticas, así como por razones de gobernabilidad de TI:
Finalmente, llama fuertemente la atención que rara vez son factores tecnológicos los que determinan
el fracaso. Así, cuando se exploran más detalladamente los factores que están por detrás de las
causas invocadas, resulta posible ordenarlos en cuatro áreas claramente diferenciadas, que son
[mercado.com, 2002]:

a) las que hacen al problema en sí;

b) las que hacen al liderazgo del proyecto
c) los factores humanos y del contexto en que se encara el proyecto
d) la conducción del proyecto propiamente dicha.

b. Tome 3 de las causas investigadas y proponga qué hacer para evitar las causas del
fracaso. Explica y fundamenta la propuesta.

Las causas que serán consideradas en este punto de la actividad son las siguientes:

1. Requerimientos incompletos
2. Deficiencia en el involucramiento del usuario
3. Deficiencia de recursos

En el cuadro siguiente se dan las propuestas que pueden disminuir el impacto que esas causas
tienen en la falla o cancelación de los proyectos:

Causa Propuestas para reducir la probabilidad de

fracaso
Este punto definitivamente tiene que ver con el
hecho de no haber realizado una planificación
correcta y lo que se be hacer para evitar esto es
1 Requerimientos incompletos [Zuloaga, s/f]:

1. Utilizar cuestionarios bien diseñados que ayuden

a cada sector a comprender la perspectiva de los
Causa Propuestas para reducir la probabilidad de
fracaso
otros sectores e incluir todos los requerimientos
posibles
2. Una correcta planificación en cuanto al tamaño del
proyecto, que esté acorde a lo que la empresa
verdaderamente necesita y puede hacer con sus
recursos y ver si es posible cubrir la lista de
requerimientos o si es necesario conseguir
financiamiento o reducir el tamaño y plantear una
ejecución modular de proyectos.
3. Incrementar la comunicación entre los
participantes, de modo que el análisis de
requerimientos sea el correcto de acuerdo con las
expectativas de la empresa en cuanto a su
proyecto.
4. Obligatoriamente contar con el documento de
“Especificación de requerimientos”, ya que ello
indicaría que efectivamente se realizó un estudio
de requerimientos.
5. Tener muy claras las reglas de negocio

1. Esto es una consecuencia grave de la falta de

comunicación, para ello se puede hacer lo
siguiente [mercado.com; 2002]:
2. Convendrá promover entre los colaboradores el
uso de técnicas que ayuden a objetivar y
documentar puntos de vista, criterios y pautas de
valor, para involucrarlos y comprometerlos con el
proyecto.
3. Los problemas residen fundamentalmente en la
interacción de las personas; por ende, la
Deficiencia en el
2 capacitación será fundamental, atendiendo
involucramiento del usuario
expresamente a los problemas listados. Por
supuesto, existen distintas formas de
capacitación, tutoría, coaching, training-on-the-
job, etc., que son adecuadas para el propósito
mencionado
4. Será también fundamental que el Project sponsor
tome en cuenta sus propios sesgos, impaciencias
y eventual desinterés
5. La elección de un adecuado e idóneo líder de
proyecto –con equilibrada combinación de
Causa Propuestas para reducir la probabilidad de
fracaso
experiencia, talento técnico, habilidad para
escuchar y manejo de recursos humanos– será
clave. Oportunamente, también él deberá pasar
por un ciclo de capacitación con respecto a los
temas que lo involucran.

Esto implica que el proyecto demasiado grande y no

fueron consideradas las necesidades reales de la
empresa en su proyecto de TI, lo que debe hacerse
es lo siguiente:

1. Realizar un correcto diagrama WBS, ya que ello

permitirá descomponer todas las actividades en
otras más pequeñas, lo cual ayudará a considerar
la mayor parte de tareas y por lo tanto de
3 Deficiencia de recursos
asignación de recursos.
2. Tener una buena estrategia de gobierno en el
proyecto de TI
3. Plantear expectativas realistas, para ello es
necesaria la interacción con todos los
involucrados, sea a través de entrevistas o a
través de cuestionarios bien elaborados [Noceti,
2008]

Conclusiones
1. Dada las funciones que debe realizar un líder de proyecto, es crucial y parte importante de
los factores de éxito de los proyectos el asignar a la persona correcta como líder en algún
proyecto determinado de la empresa
2. De acuerdo con lo investigado, los factores humanos son causa frecuente en el fracaso de
los proyectos, por lo que es importante desde el principio contar con un plan de comunicación
muy bien estructurado y establecido en cualquier proyecto que se implemente en las
empresas
3. El tener claro los factores que hacen fracasar a los proyectos nos permite plantear
estrategias a priori, cuando tengamos la oportunidad de elaborar un proyecto de TI y ser
además el líder de dicho proyecto. De aquí la importancia de la presente actividad queda
manifiesta y nos alienta a seguir profundizando en la materia.
Literatura citada
Zavala Ruiz, J. Jesús María. 2004. ¿Por Qué Fracasan los Proyectos de Software?; Un Enfoque
Organizacional; In Congreso Nacional de Software Libre 2004. Postgrado en Estudios
Organizacionales Universidad Autónoma Metropolitana-Iztapalapa Mexico, D.F.
Recuperado el 24 de noviembre de 2015, desde
http://claroline.ucaribe.edu.mx/claroline/claroline/backends/download.php?url=L3Bvci1x
dWUtZmFsbGFuLWxvcy1wcm95LWRlLXNvZnQucGRm&cidReset=true&cidReq=NI0215

Gutiérrez Abascal, José. 2009. ¿Por qué fracasan los proyectos Software? In: VII Congreso del Comité
de Calidad en los Sistemas, Tecnologías de la información y las Comunicaciones. Madrid, 29
de septiembre 2009. Recuperado el 24 de noviembre de 2015, desde
http://www.aec.es/c/document_library/get_file?uuid=bf6f2df9-b074-4c1c-9d24-
8b38ce1da167&groupId=10128

mercado.com. 2002. De eso no se habla: Por qué fracasan los proyectos de TI y cómo evitarlo.
Consultado el 25 de noviembre de 2015, desde
http://www.mercado.com.ar/notas/tecnologa/35074/de-eso-no-se-habla%3Cbr%3Epor-
qu-fracasan-los-proyectos-de-ti-y-cmo-

Zuloaga Rotta, Luis. s/f. Análisis de Requerimientos. Recuperado el 25 de noviembre de 2015, desde
http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf

Noceti, Germán. 2008. Evaluación de riesgos en proyectos de TI. Consultado el 25 de noviembre de

2015, desde http://gnoceti.blogspot.mx/2008/02/evaluacin-de-riesgos-en-proyectos-de-
ti.html