Inicio
 > Informes e investigaciones > Blog de TEC > Por qué fracasan los proyectos

Por qué fracasan los proyectos

Escrito por: Olin Thompson
Publicado: junio 11 2005

Introducción

Los proyectos de tecnología de la información (TI) fracasan con bastante frecuencia; no cubren las expectativas, sobrepasan los presupuestos, no cumplen con las fechas límit y en demasiados casos deben ser abandonados por completo. Existen estudios que demuestran que esta es la regla y no la excepción y que explican algunas de las razones para que suceda. ¿Qué consecuencias tiene el fracaso en las empresas, los profesionales de TI y los proveedores de software y de servicios? ¿Se puede remediar?

La verdad sobre los fracasos

En primer lugar, es necesario evaluar los hechos sobre todos los proyectos de TI. Estos hechos dan a las empresas una idea general de los riesgos relacionados con un proyecto de TI. Debido a que un gran porcentaje de los proyectos de TI implica la aplicar productos o servicios externos, investigaremos las razones por las cuales fracasan y el impacto que tienen dichos fracasos en las empresas involucradas.

El Standish Group (http://www.standishgroup.com), que se dedica a realizar encuestas sobre todos los tipos de proyectos de TI desde 1994, publicó los resultados de sus investigaciones bajo el título CHAOS, en donde revela algunos hechos que sorprenderán a la mayoría de los lectores.

Las cifras más recientes disponibles son aquellas para 2001, y en ellas, la base de datos CHAOS del Standish Group muestra que un asombroso 31.1 por ciento de los proyectos se cancelan antes de ser finalizados. También indica que el 52.7 por ciento de los proyectos cuestan 189 por ciento de lo que se estimó originalmente. El costo de estos fracasos y excesos en los presupuestos es sólo la punta del iceberg. No es posible medir los costos que representan las oportunidades perdidas, pero fácilmente sumarían millones de millones de dólares.

Si hablamos de los proyectos exitosos, los que se terminan a tiempo representan únicamente el 16.2 por ciento de todos los proyectos, y aún cuando se terminan, muchos ofrecen sólo una pequeña parte de los requisitos que se especificaron originalmente. Los proyectos que terminan las empresas estadounidenses más grandes, sólo ofrecen cerca del 42 por ciento de las funciones y las características que se propusieron en un principio. Las empresas pequeñas tienen un índice de satisfacción de los requisitos un poco más alto, pero la diferencia sigue siendo significativa. El 78.4 por ciento de sus proyectos de software se desplegará únicamente con el 74.2 por ciento de sus funciones y sus características originales.

Para efectos de la investigación, el Standish Group clasificó los proyectos de TI en tres tipos de resoluciones:

Exitoso: El proyecto se termina a tiempo y dentro del presupuesto establecido, además de que ofrece todas las funciones y las características que se especificaron inicialmente.

Con retos: El proyecto se termina y funciona, pero supera el presupuesto, tarda más tiempo de lo que se estimó y ofrece menos funciones y características de las que se especificaron originalmente.

Disfuncional: El proyecto se cancela durante el ciclo de desarrollo.

En resumen, la investigación que realizó el Standish Group demuestra que exceder el presupuesto es común, entregar los proyectos después de la fecha límite es normal y entregar menos funcionalidades de lo que se planeó originalmente no es nada especial. En pocas palabras, el fracaso de los proyectos es casi un procedimiento estándar.

Las causas de los fracasos

Existen varios estudios que se han enfocado en las razones por las que fracasan los proyectos. Peerstone Research (http://www.peerstone.com) llevó un estudio a cabo enfocándose en los proyectos que implican productos de software de aplicación y servicios externos, comúnmente llamados proyectos de implementación. La investigación que realizaron demuestra que la razón principal para que el éxito se vea obstaculizado es la falta de liderazgo por parte de los ejecutivos de alto nivel. Sin embargo, las demás razones se enfocan en las deficiencias de los vendedores de software o servicios.

A pesar de que el estudio demuestra que la causa principal de fracaso es la falta de liderazgo por parte de los ejecutivos de alto nivel, no esperamos que se declare abiertamente dentro de las empresas cuyos proyectos han fracasado o han debido enfrentar muchos retos. Llamémoslo ceguera o política, pero pensamos que la razón principal normalmente queda implícita. Así, cuando el resto de las razones que aparecen en la gráfica son las culpables, se dice que se debe a razones externas a la empresa, es decir, al vendedor de software o al proveedor de servicios.

Las consecuencias del fracaso

Probablemente muchos profesionales de TI y vendedores no estén de acuerdo con estos resultados. Muchas veces oímos a los vendedores afirmar que “esto no refleja la experiencia de nuestros clientes”.

Podríamos enfocarnos en la precisión de estos estudios, o hasta podríamos realizar otros. Sin embargo, el problema es que las tasas y las razones de los fracasos reflejan lo que mucha gente cree que es la verdad. Estas ideas que tienen los ejecutivos de alto nivel y otros empleados dificultan la aprobación de proyectos nuevos y hacen que los proyectos se vigilen cuidadosamente una vez que dan inicio. El ambiente de los proyectos de TI no es agradable ni productivo para las empresas y sus proveedores.

El que estas ideas existan quiere decir que los profesionales de TI, los gerentes de proyecto, los vendedores de software y los proveedores de servicios tienen que enfrentar la percepción para poder tener éxito. Recuerde que la percepción es la realidad.

Las consecuencias del fracaso y recomendaciones para las empresas

Debido a la percepción que se tiene de las altas tasas de fracaso para los proyectos de TI y a la creencia de que los proveedores de servicios son la causa principal, las decisiones de TI son, con frecuencia, objeto de mucho escrutinio. Los directores de las empresas creen que todos los proyectos de TI implican riesgos y exigen que estos se traten de forma proactiva. Esta gestión proactiva del riesgo normalmente hace que los profesionales de TI y otros encargados de la toma de decisiones tengan la diligencia debida con los proveedores potenciales.

La revisión de referencias es más importante de lo que las empresas creen. Insista en hablar con otras empresas que hayan usado los productos y los servicios que usted está evaluando. Trate de hablar con personas que tengan el mismo rol que usted en su empresa. Al hablar con sus contrapartes, podrá comprender mejor los retos y las oportunidades que se presentan al tratar con los proveedores.

Al hablar con las referencias que el proveedor le haya proporcionado, pregúnteles acerca de los problemas (las razones dos a siete que mencionamos) que el estudio de Peerstone relaciona con los proveedores. Al evaluar una oferta, recuerde que la gente proporciona servicios, así que entreviste al personal del proveedor que estará trabajando en su proyecto. Es posible que el proveedor tenga empleados muy buenos, pero ¿usted estará en contacto con ellos?

Con frecuencia, el fracaso se define en relación a lo que se planeó y no lo que es posible. Define expectativas realistas tanto para el proyecto como para los resultados. Transmita a los demás este plan y las actualizaciones sobre el progreso para mantener las expectativas alineadas con los resultados.

Las consecuencias del fracaso y recomendaciones para los vendedores y los proveedores de servicios

Debido a la idea de que las altas tasas de fracasos se deben principalmente a los proveedores, estos no deben sorprenderse cuando se enfrentan a largos ciclos de ventas, falta de decisiones, un alto costo de ventas y demasiada diligencia debida. Pueden creer que están vendiendo a un ambiente incrédulo, pero es cierto que la preocupación tácita o explícita por los riesgos siempre es parte del proceso de toma de decisiones. Estos son factores que deben tratar los proveedores.

Los proveedores deben comprender las consecuencias que tiene el fracaso sobre los compradores (como indicamos antes) y lo que esto significa para su proceso de ventas. La mejor forma de superar esta percepción del riesgo es demostrando el éxito. Los proveedores deben hacer énfasis en que sus productos y sus servicios han sido probados en circunstancias similares a las del prospecto. Lo ideal es que estas referencias sean del mismo tamaño y pertenezcan a la misma industria que el prospecto, y que los contactos sean personas que tienen el mismo rol que quien hace la llamada o la visita a la referencia. Al establecer la correspondencia correcta entre las referencias y el comprador potencial, este último se siente más tranquilo con la solución y los proveedores.

El miedo al fracaso es parte del proceso, por lo tanto, los proveedores deben transmitir con eficiencia aquello que reduce las probabilidades de fracaso. Deben hacer énfasis en la gestión de proyectos, las pruebas, la educación y las metodologías que han sido probadas. Asimismo, deben hablar acerca de la implicación por parte de los ejecutivos del prospecto que estarán involucrados en mantener abierta la comunicación en este nivel.

La percepción que tienen los compradores presenta un reto para la credibilidad del proveedor. Un proveedor exitoso debe tomar medidas proactivas para mejorar su credibilidad ante el comprador.

Resumen

No todos los proyectos tendrán éxito y, en general, esta es una percepción común entre las empresas. Los profesionales de TI y los proveedores deben reconocerla y enfrentarla de forma proactiva; los profesionales de TI deben trabajar con los directores ejecutivos para eliminar tanto el riesgo como la percepción del mismo, mientras que los proveedores deben demostrar que se puede tener éxito y transmitir de forma proactiva las técnicas para disminuir los riesgos.

Acerca de los autores

Jim Brown cuenta con más de 15 años de experiencia en consultoría de gestión y software de aplicación para las industrias de fabricación. Goza de reconocimiento como experto en soluciones de software para fabricación y tiene un amplio conocimiento de las aplicaciones empresariales como gestión del ciclo de vida de los productos, gestión de la cadena de suministro y ERP para mejorar el desempeño del negocio. Ocupó puestos ejecutivos para empresas de software que se especializan en soluciones de fabricación antes de abrir su propia firma de consultoría, Tech-Clarity, Inc.

Olin Thompson es director de Process ERP Partners. Cuenta con más de 25 años de experiencia como ejecutivo en la industria del software. Se le ha llamado “el padre del ERP de procesos”. Escribe con frecuencia y ha ganado premios por sus conferencias sobre temas como el valor que ofrecen ERP, SCM y comercio electrónico y acerca del impacto que tiene la tecnología en la industria.

 
comments powered by Disqus