De eso no se habla<br>Por qué fracasan los proyectos de TI…

Por Horacio Serebrinsky

Aunque 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, 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. Es llamativo
que rara vez son factores tecnológicos los que determinan el fracaso.

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: 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.

Todos estos factores están ya presentes –aunque sean entonces imperceptibles–
en el momento mismo de inicio de los trabajos; comprenderlos y abocarse a ellos
posibilitaría sin duda reducir la tasa ulterior de fracasos. Asimismo,
aun si esta tarea resultara infructuosa, sería posible abortar tempranamente
el proyecto, con un costo entonces mínimo. A título de ejemplo,
éstos son algunos de los factores que hacen al problema en sí:

necesidad (y carencia) de una perspectiva multidireccional;

las condiciones del contexto en que se aplicará

la solución;

complejidad del problema;

ambigüedad en las definiciones;

participación de múltiples incumbentes;

falta de atención y comprensión de

los riesgos asociados;

requerimientos de objetividad y métricas;

derivación (en el tiempo) de los requerimientos

y especificaciones; y

naturaleza intrínseca de los desarrollos de software

(ingeniería vs. creatividad).

Con respecto al papel del líder (dueño o sponsor del proyecto),
aparecen estos factores:

calidad del juicio; sesgos y preferencias; falta de perseverancia; falta de un proceso objetivo de decisión; debilidad del business case que soporta y justifica el
proyecto. Los factores humanos y de contexto tienen que ver con: continuidad y calidad del liderazgo; juegos de poder y grupos de interés; modas y paradigmas vigentes; presión de proveedores; contexto político-económico. Finalmente, con respecto al desarrollo efectivo de la conducción del
proyecto inciden, entre otros: el papel de los usuarios; presiones de sectores incumbentes; pautas de calidad; factores tecnológicos (performance, integración,
inestabilidad, etc.); factores comerciales (vendor oversell, alternativas
diversas de provisión); y continuidad de proveedores. ¿Por dónde comenzar, entonces? Como en todos los casos de problemas
complejos, hay “mejores prácticas” disponibles que ayudan a
buscar una mejor perspectiva para los proyectos de informática. Existe
multitud de “mejores prácticas” adecuadas para cada una de
las facetas de desarrollo de proyectos: son aquellas prácticas que –si
bien no aseguran el éxito– sí describen y resumen el comportamiento
de aquellas empresas que son ejemplo de un desempeño exitoso.

Una primera constatación indica también que estas dificultades
en la ejecución de proyectos no se presentan de igual modo en las pequeñas
o medianas empresas que en las grandes, o en el ámbito estatal. La primera
responsabilidad corresponde siempre al “dueño” del proyecto
(que será el dueño de una Pyme, el gerente general en una mediana
empresa, el director de Finanzas o Sistemas en una gran firma, el funcionario
estatal de jerarquía, etc.), quien deberá hacerse cargo del delicado
tema en sus manos, esto es, 40% a 70% de posibles fracasos…

Ayudará sin duda el preparar una guía con las eventuales dificultades,
personalizando y completando, quizá, para su caso particular los ejemplos
que hemos listado más arriba. También –considerando que la
falta de una visión multidireccional es tema que impregna todos los asuntos
mencionados– será conveniente utilizar cuestionarios bien diseñados
que ayuden a cada sector a comprender la perspectiva de los otros sectores;
asimismo, convendrá promover entre los colaboradores el uso de técnicas
que ayuden a objetivar y documentar puntos de vista, criterios y pautas de valor
(del tipo análisis de decisión, por ejemplo).

Como ya hemos indicado, los problemas residen fundamentalmente en la interacción
de las personas; por ende, la capacitación será fundamental, atendiendo
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.

Será también fundamental que el project sponsor tome en cuenta
sus propios sesgos, impaciencias y eventual desinterés.
La elección de un adecuado e idóneo líder de proyecto –con
equilibrada combinación de 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.

Finalmente, debemos subrayar que nada ayudará más al éxito
de un proyecto que la temprana toma de conciencia respecto de los riesgos y
modos de su eventual fracaso. Y tranquilizará el saber que –con
enfoques como los aquí sugeridos– muchas empresas han definitivamente
escapado a las otrora inevitables “leyes de Murphy” del desarrollo
de sistemas informáticos.