Los aspectos prácticos: Mitigación de los factores de riesgo de fracaso de un proyecto de TI

En cualquier camino de la vida, dos cosas son verdad acerca de los fracasos: son comunes y a nadie le gusta. No pueden ser evitados enteramente por varias razones. No todos los fracasos son absolutos. De hecho, la mayoría de los fracasos son relativos. Los éxitos no enseñan mucho, si es que enseñan algo; es el fracaso lo que proporciona lecciones para hacerlo mejor en el futuro. Por lo tanto, no haber fallado en ningún momento es probablemente una pretensión sin fundamento y, si es cierto, sugiere potencialmente muy poco cambio positivo en la organización. La ironía es que los fracasos vienen con costos asociados. En proyectos de TI, por ejemplo, el costo puede ser en términos de no cumplir con el alcance, no alcanzar el plazo o superar el costo monetario presupuestado. En el lado humano, los fracasos pueden ser desmoralizantes y pueden afectar negativamente la productividad de los empleados en todas las áreas funcionales involucradas en el proyecto fallido.

Un fallo indica que se ha materializado algún riesgo. Dos aspectos de riesgo dominantes de los proyectos de TI tienen que ver con:

1. Inversión (fallar en agregar valor a pesar de la inversión)
2. Propiedad del proyecto (fallo debido a la responsabilidad).¹

En una encuesta mundial del 2004 a 200 profesionales de TI de empresas con ingresos anuales superiores a US $50 millones, el 71 por ciento y el 72 por ciento de los encuestados, respectivamente, consideraron que los factores de riesgo de inversión y de propiedad del proyecto eran “muy significativos”.² Numerosas encuestas inequívocamente han hecho eco de un resultado relacionado: La tasa de fracaso de los proyectos de TI es alarmantemente alta a pesar de las posibles mejoras en las técnicas de gestión de proyectos a lo largo del tiempo.³

Incluso una pequeña mejora en la tasa de falla del proyecto resultaría en un impresionante avance. Los proyectos de TI han ganado un papel cada vez más importante en la mayoría de las organizaciones. No sólo es un habilitador genérico de casi cualquier cosa (por ejemplo, mejoras en la cadena de suministro), sino que también es clave para la innovación y el crecimiento. Por lo tanto, el desarrollo exitoso de proyectos de TI es importante. Cualquier atraso en el cronograma, por ejemplo, puede resultar en una demora en la fecha de lanzamiento al mercado, y cualquier acotación en el alcance puede desencadenar una cascada de revisiones que frustren tanto al desarrollador como a la comunidad de usuarios.

Anatomía de un proyecto de tecnologías de la información

Un proyecto de TI es la culminación de tres subsistemas:

• Proceso (planificación y entrega del proyecto)
• Contexto (sistema a ser provisto)
• Contenido (sistema que entrega el servicio)

El principal influenciador del proceso es el gerente de proyectos (PM), con el apoyo de la alta gerencia; el principal influenciador del contexto es la administración corporativa y los usuarios; y para el contenido, son los profesionales de TI/SI. El primero es responsable de crear la sinergia entre el contenido y el contexto, alineando los dos subsistemas para trabajar juntos; el segundo es responsable del “por qué” del cambio, incluyendo la cultura, el liderazgo y los asuntos organizativos; y la tercera aborda el “cómo” del cambio.

Cuando se introduce una intención en esta tríada, los resultados se materializan. Evidentemente, cualquier resultado deficiente puede tener que ver con el hecho de que el proceso, el contexto o el contenido no funcionaron como se esperaba y, como consecuencia, el resultado es deficiente (por ejemplo, defectuoso, tardío, caro). La complejidad del éxito o fracaso radica en estos tres subsistemas relativamente independientes: su propia madurez y desempeño, su cultura y la eficacia de la interacción a través de ellos.⁴

Con esta cantidad de complejidad, los problemas de comunicación, la claridad en la visibilidad de los objetivos y la responsabilidad del propio rol (hecho bien, a tiempo y dentro del presupuesto) son factores clave en las fallas del proyecto. Cualquier falta de alineación entre estos tres subsistemas significará una degradación de algún tipo, posiblemente teniendo como consecuencia un resultado menos que el óptimo. La cultura, las estructuras de poder e incluso el lenguaje a través de estos sistemas difieren tanto que, mantener en equilibrio toda la iniciativa del proyecto puede ser abrumador.

La causa principal del fracaso de un proyecto en general, puede provenir de cualquiera de los tres subsistemas entrelazados. Por ejemplo, la falta de madurez de los procesos o la falta de disciplina del proyecto, se manifiesta en la planificación del proyecto y su entrega y la traducción y ejecución de los requerimientos del negocio en las especificaciones técnicas, están arraigados en el contenido. Una empresa que tenga incluso el nivel más alto de posicionamiento en el CMMI, Integración de modelos de madurez de capacidades (del inglés: Capability Maturity Model Integration), puede fallar porque los subsistemas responsables del contexto y el contenido no son desarrollados con eficacia.

Esta visión de la gestión de proyectos puede ser bastante útil en el seguimiento de los primeros gatilladores de fallas y para evaluar la mejor forma de recuperarse del fracaso. Si falta un usuario líder influyente y un agente de cambio (en el subsistema de contexto), los resultados pueden degradarse a través de varios factores clave. O bien, procesos de planificación inmadura en el subsistema de planificación y entrega pueden resultar en un análisis de riesgo inadecuado para el proyecto. Y el subsistema de contenido puede estar en falta cuando elige un software débil o inadecuado para la ejecución del proyecto.⁵

Por último, es importante reconocer que los proyectos pueden variar mucho. Tamaño, importancia, duración, costo, profundidad tecnológica, comunidad de usuarios, importancia estratégica—estos son algunos de los factores que conducen la diferenciación entre los proyectos en una organización. En consecuencia, los fallos del proyecto pueden tener un impacto diferente en la organización y en su respuesta al nivel de la falla.

Casos de estudio

Para determinar las causas del fracaso y recomendar medidas de mitigación, se pueden examinar tres proyectos fallidos en diferentes organizaciones.

Caso A
Un proyecto de varios años y multimillonario ha sobrepasado las fechas de vencimiento. Se determinó que el subsistema de planificación y entrega del proyecto era responsable del atraso. La oficina de gestión de proyectos (PMO) falló un informar sistemáticamente sobre el progreso del proyecto. Incluso en el limitado esfuerzo por reportar el progreso, la PMO describió 14 factores de éxito del proyecto, pero algunos no pudieron ser cuantificados. Además, la lista de indicadores para medir el logro de los objetivos y metas del negocio fue incompleta, lo que condujo a un seguimiento mediocre del progreso real.

En términos generales, si un subsistema de planificación y entrega es la fuente de las fallas, los problemas surgirán en muchos, si no en todos los proyectos, debido a que la debilidad reside en la ausencia de madurez y disciplina en la planificación y entrega. Esto podría afectar a muchas partes interesadas en el subsistema de contexto y también frustrar a los profesionales de TI competentes en el subsistema de contenido.

En el subsistema de contexto, se encontró que, mientras que el personal de soporte del área funcional era dedicado, hubo confusión con respecto al gerente funcional responsable de las decisiones clave. En consecuencia, ciertas decisiones se demoraron o no se realizaron. Además, hubo diferencias significativas entre las áreas funcionales respecto del enfoque de la gestión de proyectos. Entre otros factores, esto contribuyó a la desconfianza entre las áreas funcionales, dando lugar a una gran cantidad de problemas.

Los siguientes pasos muestran las acciones recomendadas:

• Definir claramente al gestor responsable con autoridad de tomar decisiones para cada área funcional.
• Asegurar una participación, coordinación y comunicación que sean completas y abiertas entre todas las partes interesadas, incluidos los proveedores, para reforzar las expectativas, aprovechar la experiencia de cada uno y crear confianza y credibilidad en el proyecto.

Caso B
Un proyecto multimillonario de varios años sufrió la demora en la ejecución de las decisiones, causando un efecto en cascada en el costo, el calendario y el alcance del proyecto. La razón clave: socavar la autoridad del PM y de la PMO. Cuando la disciplina y la autoridad respecto de la gestión de los proyectos son marginados, los proyectos sufren. Por ejemplo, se elaboró y se informó un documento de toma de decisiones de alojamiento de servidores fuera de la estructura de gobierno definida para el proyecto.⁶ La oportunidad de ejecución también se vio obstaculizada por la falta de sincronización en el calendario entre la negociación de contratos de proveedores y los procesos de aprobación de proyecto. El factor subyacente fue la limitada autoridad del PM y de la PMO para tomar decisiones relacionadas con el proyecto, escalando muchas decisiones hacia los ejecutivos.

Para resolver la situación, se sugirieron los siguientes pasos:

• Revisar la autoridad en la toma de decisiones del PM, de la mesa de control de cambios, del comité directivo y de los patrocinadores ejecutivos, y ajustarla cuando sea conveniente.
• Establecer un proceso de cambio de contrato, con límites de tiempo claramente definidos para una aprobación de cambio expedita, bajo ciertas circunstancias.
• Asegurar que cada uno comprenda su autoridad y la estructura de gobierno definida, y responsabilizar a los individuos y departamentos de adoptar la estructura de gobierno.

Claramente, este caso apunta a los problemas de madurez y disciplina de los procesos y a la falta de influencia del liderazgo en el subsistema de planificación y entrega. Como resultado, todos y cada uno de los proyectos iniciados por la organización corren el riesgo de un bajo desempeño.

Caso C
Un proyecto multimillonario de varios años sufrió de una identificación débil respecto del riesgo del proyecto. Algunas de las observaciones realizadas durante el análisis de causa raíz incluyeron:

• Los requerimientos del negocio que se definieron carecían de claridad, entendimiento común, completitud y calidad. Esto afectó la definición y comprensión del alcance del proyecto y, a su vez, impactó en las expectativas de desempeño y en la estimación del calendario, del esfuerzo y de los costos.
• Las partes interesadas no entendieron sus compromisos.
• La revisión, verificación, validación y aprobación de los requerimientos fue inmadura.
• La trazabilidad de los requerimientos fue inconsistente.
• La omisión de la funcionalidad crítica y los atributos de calidad, probablemente causó un diseño inexacto o incompleto.

Para resolver la situación, la empresa debe considerar los siguientes pasos:

• Establecer un proceso formal de desarrollo de requerimientos que incluya la revisión, la aceptación y los compromisos asociados a los requerimientos.
• Establecer un proceso de gestión de requerimientos maduro para mejorar la trazabilidad (por ejemplo, funcional, técnico, interfaz, hardware y software).
• Asegurar que el proceso de revisión de pares de los requisitos realmente agregue valor.

Auditorías de proyectos de TI

El papel de los auditores en los proyectos de TI tiene que ver con asegurar de que los proyectos críticos de la organización se gestionan adecuadamente para lograr el éxito.⁷ Los proyectos de TI definen esencialmente el futuro de la organización; asumiendo que fueron priorizados y seleccionados correctamente, su éxito es fundamental para construir un futuro próspero. Los proyectos de TI, en este sentido, son los precursores de que se espera del futuro. El rol del auditor de SI en proporcionar una opinión experta sobre el estado de los proyectos de TI, incluyendo el riesgo emergente y sin mitigar, debe ser valorado por la organización.

Implicaciones prácticas

El “triángulo de hierro” de la PMO (personas, procesos y tecnologías)⁸ y recursos (por ejemplo, CMMI for Development V1.3)⁹ demuestran que un tema clave que impacta el desempeño y el éxito del proyecto es la gente. Los casos descritos aquí ponen a la luz el hecho de que incluso la madurez del proceso y la adopción de las mejores prácticas de la industria a lo largo del tiempo puede ser insuficiente para resolver problemas culturales.

Organizaciones con énfasis en los procesos invierten fuertemente en el establecimiento de plantillas e instrucciones, y, aun así, la institucionalización de estos procesos puede ser débil. Una alta tasa de fallas en los proyectos sugiere que no se percibe en todos los niveles que los procesos asociados a los proyectos agregan valor, ni se alinean con la cultura organizacional. La dirección (en los casos discutidos anteriormente) implementó posteriormente las recomendaciones basadas en las áreas de procesos específicas del CMMI, lo que a su vez resultó en una mejora medible en la tasa de éxito de los proyectos y en un cambio favorable en la cultura organizacional hacia los procesos, como se evidencia en evaluaciones posteriores de aseguramiento de calidad.

Finalmente, debido a que la capacidad de recordar en la organización es limitada, es difícil aprovechar las lecciones aprendidas de los fracasos a menos que las causas y los remedios de todos los errores importantes de los proyectos sean debidamente documentados. Cuando se comparten con las partes interesadas, este historial de casos reales y específicos de la organización podría minimizar los fallos futuros.

Nota del autor

Las opiniones expresadas en esta columna son de los propios autores y no de sus empleadores.

Notas Finales

¹ The Economist Intelligence Unit, Global Study on Information Risk Management, 2002
² IT Governance Institute, Information Risks: Whose Business Are They?, USA, 2005, p. 9
³ See, for example, The State of Project Management Survey, Wellingtone Project Management, 2016
⁴ Yeo, K. T., “Critical Failure Factors in Information Systems Projects,” International Journal of Project Management, vol. 20, iss. 3, April 2002, p. 241–246
⁵ Op cit, Yeo
⁶ IBM, Global Making Change Work Study, 2008, https://www-07.ibm.com/au/pdf/making_change_work.pdf
⁷ Ibid.
⁸ Project Management That Works, “The Iron Triangle of the PMO: People, Processes, and Technology,” 3 June 2011, www.pmthatworks.com/2011/06/iron-triangle-of-pmo-people-processes.html
⁹ Chrissis, M. B.; M. Konrad; S. Shrum; CMMI for Development: Guidelines for Process Integration and Product Improvement, 3^rd Edition, Addison Wesley, USA, 2011