Por qué fracasan los proyectos de TI y cómo evitarlo

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