LOS SISTEMAS DE ALERTA TEMPRANA APLICADOS A LA DIRECCIÓN
DE PROYECTOS: UNA REVISIÓN DE LA LITERATURA
EARLY WARNING SYSTEM APPLIED TO PROJECT MANAGEMENT: A
LITERATURE REVIEW
Magaña Martínez, D.
Universidad Antonio de Nebrija (España)
Fernández Rodríguez, J. C.
Universidad Antonio de Nebrija (España)
Resumen
La complejidad y la incertidumbre que rodea a los proyectos, dificulta la identificación y la gestión de los riesgos. Las herramientas tradicionales y la habilidad del equipo de proyecto basada en la experiencia, los presentimientos y la intuición no son suficientes para identificar los riesgos a tiempo. Existe, no obstante, en el ámbito del proyecto información en forma de señales débiles que puede resultar de gran utilidad para facilitar la identificación de riesgos e incluso poder prever cómo finalizará el proyecto. El presente artículo hace una revisión de la literatura analizando cómo la comunidad científica y los profesionales de la gestión de proyectos tratan de aplicar la teoría de las señales débiles de Ansoff a la gestión de proyectos. El resultado del análisis demuestra que se trata de un campo de investigación en el que todavía hay mucho por investigar y mucho más aún por poner en práctica.
Palabras Claves
Sistema de Alerta Temprana; señales débiles; gestión de proyectos; identificación de riesgos; revisión de la literatura.
Abstract
subject, analysing and summarizing how scientist and practitioners in project management try to apply Ansoff’s Weak Signals’ theory to project management. It will come to show that this is a research field where there is still much work to investigate and even more to implement.
Keywords
Early warning system; weak signal; Project Management; risk identification; literature review.
1
Introducción
La complejidad que rodea a los proyectos y la, cada vez, más acuciante presión que reciben los equipos de proyecto por acortar los plazos del proyecto hace que cada vez sea más necesario anticiparse a los riesgos que puedan impactar negativamente sobre el cronograma, el coste, la calidad o cualquier otro aspecto del proyecto. Sin embargo, la realidad es que los métodos clásicos para la gestión de riesgos dentro de los marcos de referencia en la gestión de proyectos no siempre se muestran eficaces ante este tipo de situaciones y con frecuencia su respuesta llega demasiado tarde, cuando el problema ya existe (1).
La dirección de proyectos tiene un componente muy fuerte de pronóstico. Al Director de Proyecto se le exige ser capaz de pronosticar cómo acabará el proyecto en cuanto al coste y al tiempo. Una de las herramientas de pronóstico sugerida en los cuerpos de conocimiento, especialmente en los proyectos del Gobierno de los Estados Unidos, es la Técnica del Valor Ganado más conocida como EVM o Earned Value Method. Si bien es una herramienta ampliamente utilizada por el Gobierno de Estados Unidos el origen se encuentra realmente en una fábrica a finales del s. XIX (2). En cierto modo la técnica de EVM puede considerarse un sistema de alerta temprana pues en base a una serie de datos del proyecto y comparando con los mismos valores planificados previamente, es capaz de hacer pronósticos acerca del coste del proyecto y del tiempo a la finalización del proyecto (3).
El método del valor ganado se basa en la premisa de que el rendimiento obtenido para un proyecto en el pasado es un buen indicador para poder pronosticar el futuro. Realmente este indicador es útil cuando se ha superado un 15% del proyecto (2) y cuando se conoce el alcance completo del proyecto.
¿Hay otra forma de identificar los riesgos dentro del proyecto? Más allá de la técnica de EVM y apoyándose en la teoría de señales débiles (6) aplicada originalmente a la gestión estratégica de la empresa, se desprende la pregunta de: ¿si encontrásemos estas señales débiles dentro del marco de la gestión de proyectos? ¿Se podría aplicar la teoría de Ansoff a la gestión y dirección de proyectos? Partiendo de la teoría de señales débiles, son varios los investigadores que han aplicado esta teoría a la dirección y gestión de proyectos. Es objetivo de este artículo realizar una revisión sistemática de la literatura científica existente hasta el momento que relaciona la teoría de las señales débiles con la dirección o gestión de proyectos.
Apoyándose en estas teorías Nikander y Eloranta llevan a cabo una investigación que comienzan en 1997 (1) en la que demuestran que, efectivamente, este tipo de señales se encuentran también en el entorno del proyecto y que, por lo tanto, se pueden interpretar como señales de advertencia preliminares. En su estudio preliminar ya adelantaban que los métodos tradicionales advertían del problema demasiado tarde, cuando éste ya está presente y no es posible actuar sobre el mismo. Las herramientas tradicionales de gestión de proyecto se basan en la planificación, monitorización y control del proyecto, por un lado, que se centran en recopilar la información de lo que ha pasado y por otro lado el análisis de riesgos, que intenta analizar y predecir el futuro. Nikander y Eloranta sugieren apoyarse en la teoría de Ansoff para acelerar el proceso de identificación de problemas (1,7,8).
Fruto del trabajo investigador de Nikander y Eloranta se abrió una nueva línea de investigación relacionada con los Sistemas de Alerta Temprana o Early Warning System que se continúa desarrollando hoy en día.
2
Objetivos
El objetivo de este artículo es realizar una revisión de la literatura y un resumen de los artículos relacionados con los sistemas de alerta temprana o con la teoría de las señales débiles de Ansoff aplicados a la dirección y gestión de proyectos que se hayan publicado en revistas científicas a partir de la publicación del artículo de Ansoff.
El estudio categoriza y resume la aportación científica generada desde la publicación de Nikander hasta la fecha de publicación de este artículo identificando las líneas de investigación futura sugeridas por los investigadores
3
Metodología
Google Scholar
La herramienta Bucea de la Universidad Complutense de Madrid (España) En cada uno de los motores se han realizado búsquedas con los siguientes términos
Early Warning System + project management EWS + project management
Weak signals + project management
Se han buscado los artículos que referencian a Nikander y Eloranta
De los resultados obtenidos tras las búsquedas, se han seleccionado sólo aquellos documentos a los que se tenía acceso al texto completo y que guardaban relación con la temática objeto de la investigación, descartando aquellos que no tenían relación directa con la gestión de proyectos. Para cada uno de los resultados obtenidos se ha hecho un breve resumen del punto de partida, las cuestiones de investigación y las líneas de investigación propuestas en el caso de estar disponibles, señalando los sectores a los que aplicaba e identificando la metodología empleada en cada investigación.
4
Resultados
A continuación, se enumeran, por orden cronológico de publicación los artículos científicos resultantes tras en el proceso de búsqueda.
Tabla 1. Listado de artículos resultantes
Año 1er Autor Titulo Tipo
1997 Nikander IO, Preliminary signals and early warnings in industrial investment projects
Identificación de señales 2001 Nikander IO, Project management by early warnings Identificación de
señales
2002 Nikander IO Early Warnings Tesis
2002 Giegerich DB Early warning signs of troubled projects Identificación de señales 2003 Liu X (Frank)
An intelligent early warning system for software quality improvement and project
management
Diseño de un software para identificación de
señales 2006 Hanna AS, Early warning signs for distressed projects Identificación de
2006 Havelka, D.
Using the Troubled Project Recovery Framework: Problem Recognition and
Decision to Recover
Marco conceptual
2006 Kappelman, L. Early Warning Signs of it Project Failure: The Dominant Dozen
Identificación de señales
2008 Spjelkavik, I.
Project Performance Management System : A Conceptual Framework for early warnings in
projects
Marco conceptual
2009 Noble, J. Early Warning Signs Of Communication
Failure In Is Projects : A Case Study Caso de estudio
2010 Geraldi, J. The Titanic sunk, so what? Project manager response to unexpected events
Respuestas a las señales
2010 Philip, T.
Identifying Early Warning Signs of Failures in Offshore Software Development
Projects-A Delphi survey.
Identificación de señales 2011 Aaltonen, K. Project stakeholder analysis as an
environmental interpretation process
Interpretación de señales 2011 Kappelman, L. Auditing IT Projects: Early Warning Signs of
Material Risk
Identificación de señales 2012 Holopainen, M. Weak signals: Ansoff today Revisión de la
literatura 2012 Piperca, S. A typology of unexpected events in complex
projects Caso de estudio
2012 Williams, T. Identifying and Acting on Early Warning Signs in Complex Projects
Identificación de señales Respuestas a las
señales 2013 Haji-Kazemi, S.
Application of performance measurement as an early warning system: A case study in the
oil and gas industry
Identificación de señales 2013 Haji-Kazemi, S. A Review on Possible Approaches for
Detecting Early Warning Signs in Projects
2013 Haji-Kazemi, S.
Identification of Early Warning Signs in Front-End Stage of Projects, an Aid to
Effective Decision Making
Identificación de señales 2014 Haji-Kazemi, S. Efficiency of project health checks (PHCs) as
an early warning system in practice
Identificación de señales 2014 Meng, X.
Is Early Warning Effective for the Improvement of Problem Solving and Project
Performance?
Caso de estudio 2015 Browning, T. Reducing Unwelcome Surprises in Project
Management
Marco conceptual 2015 Haji-Kazemi, S. Barriers against effective responses to early
warning signs in projects
Respuestas a las señales
2015 Haji-kazemi, S. Detecting Early Warning Signs of Delays in Shipbuilding Projects
Identificación de señales Respuestas a las
señales 2015
Norulhaida, A.
Early Prediction Model To Manage Risks From
Marco conceptual 2015 Silva, M. A Systematic Review of Foresight in Project
Management Literature
Figura 1 Número de publicaciones por tipo de investigación (Elaboración propia)
Partiendo de la base de que los métodos tradicionales llegan demasiado tarde a la identificación de problemas, Nikander presenta la idea de aplicar la teoría de señales débiles de Ansoff a la dirección de proyectos y lo hace a través de la publicación de un artículo pionero en este campo (1). En este primer trabajo de investigación analiza el carácter de las señales, cómo aparecen y con qué tipo de problemas están relacionadas, explicando cómo las señales débiles se pueden utilizar para el control del proyecto. Se trata del primer trabajo de investigación que aplica la teoría de Ansoff a la gestión de proyectos.
En un artículo posterior (8) Nikander presenta un modelo preliminar que permite utilizar la alerta temprana para el control del proyecto y muestra cómo se relacionan las señales con los problemas de los proyectos y sus causas raíces. A través de este modelo los directores de proyecto pueden observar las señales e interpretarlas desde su experiencia obteniendo información de posibles problemas emergentes.
Un año después y enfocado al sector de la construcción el autor enumera (9), en base a la experiencia recopilada a lo largo de diferentes proyectos, una serie de señales que son indicios de futuros problemas o banderas rojas en el proyecto y sobre los cuales es necesario prestar especial atención. El autor agrupa las señales identificadas en:
0 2 4 6 8 10 12 14 Caso de estudio
Diseño de un software para identificación de señales Identificación de factores Identificación de señales Interpretación de señales Marco conceptual Respuestas a las señales Revisión de la literatura Tesis
Retrasos y cambios en el cronograma Dificultades en el diseño
Irregularidades en los pagos Cambios de alcance
Calidad del trabajo no satisfactoria Acciones de los propietarios
Desempeño del personal del proyecto Ausencia de trabajo en equipo
Disputas y reclamaciones
De cara a la identificación de estas señales o síntomas el autor propone hacer un buen uso de las herramientas de control del proyecto y prestar especial atención a los datos recogidos a través de dichas herramientas, especialmente en las áreas que identifica. De los diferentes grupos de señales el autor, a través de encuestas realizadas durante los últimos tres años, destaca cuatro sobre el resto: dificultades en el diseño, cambios, retrasos y acciones del propietario sobre el alcance y finalmente cuestiones relacionadas con la calidad, el desempeño del personal y el trabajo en equipo.
En 2002 Nikander publica su tesis doctoral (7) como continuación de sus estudios preliminares. La tesis doctoral gira en torno a tres preguntas de investigación:
¿Puede encontrarse, en el ámbito de la dirección de proyectos, información en las señales débiles que indica Ansoff?
¿Es posible describir el fenómeno de las alertas tempranas y crear una tipología de las mismas?
¿Cómo afectan las señales de alerta tempranas a los diferentes problemas del proyecto? ¿Pueden relacionarse estas alertas tempranas, problemas de los proyectos y las causas de
dichos problemas? ¿varía el carácter de esta relación en función del punto de vista?
El autor demuestra positivamente las cuatro preguntas de la investigación y fruto de la investigación crea una categorización jerárquica de 11 grupos principales y 68 subgrupos donde clasificar las diferentes alertas tempranas.
Nikander propone un modelo de soporte a la decisión basado en las alertas tempranas, para lo que describe el fenómeno y lo separa en dos fases fundamentales:
La fase de la comunicación, que se divide a su vez en tres partes:
o La detección de la alerta
o La interpretación de la alerta
o La aceptación de la alerta
En el sistema de soporte a la decisión la pregunta fundamental a responder es ¿qué problema o riesgo es que el que detecta la alerta temprana? De la que se derivan otras preguntas que deben responderse desde la perspectiva del riesgo ¿pueden detectarse esas alertas tempranas que implican un riesgo? Y ¿qué tipo de respuestas pueden utilizarse para aportar más información a la amenaza o materialización de un riesgo en particular? El autor recalca el hecho de que la interpretación de la alerta y por tanto la aceptación de la misma depende del observador y que cada uno puede interpretarla a su manera, dependiendo de sus propios condicionantes. Esta interpretación influirá, por lo tanto, en la aceptación y por supuesto finalmente en la respuesta que se genere. Nikander propone futuras líneas de investigación relacionadas con la aplicación de las señales de alerta temprana en las etapas tempranas del proceso de toma de decisiones del proyecto, en la creación y ampliación de bases de datos de alertas tempranas, su aplicación al sector del liderazgo y el desarrollo de una modelo de gestión de riesgos donde se pueda aplicar un sistema de alerta temprana.
Partiendo de la base de que hay tres grandes problemas en los proyectos del software, sobrecoste, desviaciones de cronograma y la baja calidad, el autor crea un sistema de identificación de riesgos en proyectos de desarrollo del software que se apoya en la lógica difusa para gestionar la incertidumbre de las métricas recogidas (10). Generalmente, según la opinión del autor, es demasiado tarde para corregir estos problemas. El autor propone el diseño de un software inteligente para crear un sistema de alerta temprana apoyándose en lógica difusa y un sistema integrado de métricas de software. El software ayuda a evaluar los riesgos asociados a las perspectivas de producto, proceso y organización en las etapas tempranas del proceso de desarrollo de software. El software tiene tres componentes principales: base de datos de métricas del software, base de datos de conocimiento de riesgos, evaluación inteligente de riesgos y traza de riesgos. El software resultante ayuda a evaluar los riesgos asociados a cada uno de los problemas desde las perspectivas de producto, proceso y organización en las fases iniciales del proyecto. Como resultado, es capaz de determinar un indicador general de riesgo agregando varias evaluaciones parciales de riesgo.
La siguiente publicación (12) tiene como objetivo identificar los factores que más influyen en el resultado del proyecto y que permitan determinar, en las etapas tempranas de un proyecto, si un proyecto va a tener problemas o no. Los autores defienden que son muchos los factores que pueden influir en el resultado del proyecto. Cuestiones como la gestión que hace el contratista, la involucración del proveedor, los cambios o errores en el diseño o los retrasos en las entregas de material. El estudio propone un listado de factores que, si están presentes, pueden permitir a contratistas y propietarios predecir el resultado final del proyecto. Para calcular si el proyecto estará o no en peligro se utiliza un modelo de regresión que puede ser aplicado ya en la fase de licitación del mismo. Para llevar a cabo este estudio se revisaron 116 proyectos del sector de la construcción y se analizando, especialmente, los factores que aplican a electricistas y mecánicos pues se trata de los dos oficios que representan entre el 40% y el 50% del presupuesto de los proyectos. Según los resultados del estudio la tasa de éxito en la predicción es de un 70% por lo que se considera que esta herramienta puede ser utilizada como una herramienta de pronóstico.
Más allá de la identificación temprana de los factores que pueden afectar a los resultados de un proyecto, en el siguiente artículo (13) se propone un marco de referencia para recuperar proyectos de desarrollo de software con problemas. De cara a este estudio de campo se establece que un proyecto tiene problemas si: está fuera de plazo en un 30%, está sobre presupuesto en un 30% o finaliza no cumpliendo con los requisitos del usuario. Siendo este el escenario la pregunta de investigación que aborda este estudio es: ¿Cómo pueden las organizaciones identificar problemas en un proyecto de desarrollo del software lo más pronto posible?
El marco propuesto se compone de cuatro fases y doce pasos en total. Las fases del marco son: identificación, recuperación inmediata, recuperación sostenida y madurez, siendo la fase de identificación en la que se centra y realiza un estudio de campo.
Fase1: Reconocer el problema: es el primer paso para poder recuperar el proyecto. En esta fase se identifican cuatro pasos: tomar conciencia del problema, admitir el problema y buscar ayuda, evaluación rápida, decisión sobre la recuperación
Fase 2: Recuperación inmediata: el objetivo es devolver el proyecto a la estabilidad lo antes posible, identificando y aislando los problemas a base de medidas correctivas o que mitiguen el impacto.
Fase 3: Recuperación sostenible: una vez el proyecto se ha estabilizado se pone en marcha esta fase en la que se abordarán acciones como una reducción del alcance, una recalendarización, revisión de las prioridades de los objetivos y en definitiva la planificación a partir de una nueva línea base.
El estudio se realiza por medio de una serie de focus group en el que participan 20 directores de proyectos o consultores agrupados en cuatro grupos: universidad, sector financiero con más de 6 años de experiencia, sector financiero con más de 3 años de experiencia y sector telecomunicaciones. El objetivo de estos focus groups es identificar los síntomas de los proyectos con problemas en el sector del desarrollo del software. Fruto del trabajo de estos grupos se identifica un total de 108 síntomas que se pueden agrupar en las siguientes categorías.
Figura 2 Categorías de los Síntomas y número de síntomas relacionados (elaboración propia) El artículo concluye afirmando que la diversidad de síntomas indica que existen síntomas específicos del sector y de la organización y que algunos síntomas pueden estar más presentes en algunos sectores y que, a su vez, hay una serie de síntomas propios de los proyectos de Desarrollo del Software.
El estudio “Early Warning Signs of it Project Failure: the Dominant Dozen” (14) realiza el examen post-mortem de proyectos de TI en los que se han identificado los 12 síntomas o señales de alerta temprana relacionados con las personas o relacionado con los procesos del proyecto los proyectos de sector de TI. La principal aportación de este artículo es que se centra en las señales de alerta temprana en vez de hacerlo en los riesgos genéricos de los proyectos de TI. Además, la identificación de estas señales se realiza no solo a través de fuentes científicas, sino también a
0 5 10 15 20 25
través de revistas profesionales del sector y por medio de profesionales experimentados del sector de TI. Los autores clasifican en tres grandes grupos los riesgos de un proyecto: las personas, los procesos y los productos. El listado queda finalmente resumido en 12 señales de alerta temprana que son las más importantes a tener en cuenta según concluyen los autores.
Los autores concluyen afirmando que se debe prestar especial atención a la lista de señales enumeradas en el artículo y que cuanto antes se trabaje sobre ellos más altas serán las probabilidades de éxito en el proyecto.
Tabla 2 Dominant dozen Early Warning Signs (14) Dominant Dozen Early Warning Signs Ranking
People-related EWS
Falta de soporte de la alta dirección 1 Director de proyectos débil 3 No participación e involucración de los
stakeholder 5, 10
Compromiso débil del equipo de proyecto 8 Los miembros del equipo no cumplen con los
requisitos o las habilidades 11 Los expertos están sobre asignados 17
Process-related risks
Falta de documentación de los requisitos y/o
criterios de éxito 2, 7
No existen gestión del cambio 4 Planificación y gestión de la planificación
ineficiente 6, 14, 15, 16
Falta de comunicación entre stakeholders 9 Los recursos se asignan a proyectos de mayor
prioridad 12
No existe business case 13
observación de las señales, a efectos del estudio, comienza tan pronto se ha asignado un presupuesto al proyecto y se ha formado el comité de proyecto.
El caso se revisa como si de una historia se tratase, de una manera descriptiva. Para cada una de las ocurrencias de estas señales, se recoge una descripción detallada de la misma, una explicación de las causas, los efectos y una descripción de las acciones llevadas a cabo. De las 15 señales agrupadas en la categoría de comunicación se encuentran 6 en el caso objeto del estudio de las cuales, algunas ocurren más de una vez.
Las señales identificadas en el caso son:
Figura 3 Señales identificadas vs Ocurrencias (Elaboración propia)
En el artículo se revisan las causas de cada una de las observaciones que se pueden resumir en: Se comunican en niveles erróneos o existen barreras en el lenguaje
Un miembro del equipo no es capaz de explicar sus colegas el estado del proyecto, no se tiene un conocimiento suficiente de las tareas del equipo.
Los roles y las responsabilidades no están firmemente establecidas al comienzo del proyecto.
El equipo de proyecto es inalcanzable, las líneas de comunicación no se han establecido
0 0.5 1 1.5 2 2.5 3 3.5 El director de proyecto no dirige de forma efectiva al
equipo y no se comunica de forma efectiva con los clientes Se reporta el estado del proyecto de una forma pobre a los
stakeholder
Ruptura en las comunicaciones entre los stakeholder No hay planes de comunicación o recursos dedicados para
la gestión y la comunicación
No se ha entrevistado a los stakeholder del proyecto para obtener los requisitos
No se han definido los criterios de éxito del proyecto
Los stakeholder están intercambiados sin tener unos requisitos de nivel establecidos o una transferencia de conocimiento.
El mecanismo de comunicación del día a día no se realiza No hay implicación del usuario en determinadas tareas
A modo de conclusión los autores afirman que la falta de soporte, de entendimiento, de comunicación y de compromiso tanto del equipo como de los stakeholder son la causa raíz del problema a la hora de conseguir el alcance, en tiempo y forma. Las observaciones realizadas en el caso de estudio y el análisis de las mismas demuestran que los problemas de la categoría de Comunicación pueden ser prevenidos, pero a la vez hemos de aceptar que al estar el humano presente existe cierta “inevitabilidad”. Los autores sugieren, como líneas de investigación para el futuro, completar el marco determinando cómo y quién debe ser quien mida estas ocurrencias. Sugieren también un segundo caso de estudio, esta vez desde el punto de vista de los desarrolladores.
Partiendo de la premisa de que los proyectos se mueven en un entorno de incertidumbre y complejidad nos encontramos otro artículo con un título llamativo. “The Titanic sunk, so what? Project manager response to unexpected events.” (16). El estudio analiza 44 eventos inesperados que han sido afrontados por 22 experimentados directores de proyectos del sector de la defensa. El objeto de este estudio es analizar las respuestas a los eventos inesperados y no tanto el análisis de las señales identificadas en el proyecto. Cada uno de estos experimentados directores de proyecto compara dos eventos, uno en el que ellos consideran que la respuesta fue satisfactoria y otro en el que no lo fue. Se identifican tres pilares fundamentales en las respuestas consideradas satisfactorias: una estructura operativa y resolutiva en la capa organizacional, buenas relaciones interpersonales a nivel de grupo y gente competente a nivel individual
El estudio se centra en analizar el hueco entre las prácticas y el éxito examinando las percepciones de los profesionales de cómo se gestionaron, de forma satisfactoria, los eventos inesperados. Los autores exploran tres elementos: el evento, la respuesta y la percepción de éxito. Esta exploración se lleva a cabo por medio de tres preguntas, centrándose el estudio en la última de ellas.
¿Qué pasó?
¿Qué hicieron los directores de proyecto y de programa cuando afrontaran un evento imprevisto?
¿En qué difieren las respuestas satisfactorias de las que no lo fueron desde el punto de vista del profesional?
Figura 4 Foco de investigación (16)
A modo de conclusión el estudio afirma que no importa lo buena y completa que sea la gestión del riesgo, los proyectos se enfrentarán invariablemente a eventos inesperados. Los resultados del estudio indican que la creación de equipos aislados para gestionar el evento inesperado puede ser importante para el resultado, pero la realidad es que no siempre es posible. Una respuesta satisfactoria a cualquiera de estos eventos inesperados está muy ligada a la estructura organizacional actual del proyecto. Sin embargo, el punto clave para las respuestas exitosas está en los activos de las personas, especialmente en el compromiso y la participación, la negociación y el liderazgo. Se hace una analogía con el caso Titanic, afirmando que navegaba entre icebergs inesperados, pero algo más de atención por parte de la organización y más empoderamiento podría haber evitado o al menos reducido las consecuencias. Dicho de otro modo, la gente podría haber determinado su propia suerte.
El estudio Delphi se ha diseñado creando dos paneles de expertos, uno para clientes y otro para proveedores, dos de los grupos con mayor impacto en el resultado de un proyecto de estas características.
El estudio se dividió en tres fases: 1. Identificación de EWSs
2. Validación y perfilado de las EWSs 3. Evaluación y comparación de EWSs
En la última fase se evaluaron y clasificaron un total de 21 EWSs fruto de las fases anteriores. Las señales se agruparon en las siguientes categorías:
1. Relacionadas con las comunicaciones: las diferencias culturales, las distancias geográficas entre los equipos domésticos y los externalizados pueden causar una gran cantidad de problemas en lo que a comunicación se refiere. El idioma, generalmente el inglés, que no es el nativo del equipo afecta directamente a la comunicación del equipo y a la transferencia del conocimiento. A esto se suman las diferencias culturales y la ausencia, en ocasiones, de la inteligencia cultural que acaba en malentendidos especialmente cuando no hay posibilidad de tener una comunicación informal como es el caso de los proyectos objetos de este estudio.
2. Relacionadas con las personas: las habilidades y el compromiso de los miembros del equipo es crucial para un resultado exitoso del proyecto. Cuando más débil es más afecta al resultado del mismo. El rendimiento de los usuarios clave es una fuente de señales para detectar el fallo de un proyecto.
3. Aspectos formales del proceso: cuidar los aspectos formales del proyecto es indispensable en los proyectos externalizados en el extranjero precisamente por las diferencias culturales y las distancias geográficas. Si no se cuidan los aspectos formales del proyecto como los roles, la documentación, las responsabilidades se producen problemas como alcances que cambian continuamente, cronogramas ineficientes y falta de control en general.
4. Aspectos formales del resultado: directamente relacionado con los aspectos formales de la gestión de proyectos facilita información del camino que va tomando el proyecto. La falta de documentación de los requisitos, los criterios de calidad o lo ambigüedad de las necesidades puede generar este tipo de problemas.
A modo de conclusión y dado que la mayoría de los indicadores identificados no son exclusivos de los proyectos externalizados en el extranjero los autores afirman que este tipo de proyectos no difieren sustancialmente de aquellos que se realizan a nivel nacional. Sin embargo, sí que tienen particularidades sobre las que hay que poner una especial atención en cuanto a los aspectos formales del proyecto.
los riesgos de los proyectos que se desarrollan es este sector son evitables si uno sabe cómo identificar las señales que plantearan dificultades al proyecto. Propone focalizar sobre las señales de alerta temprana de los riesgos del proyecto de IT como punto de partida para la monitorización, auditoría y gestión de los riesgos del proyecto. Al autor hace hincapié en el impacto que tienen los riesgos en los proyectos de IT cuando no se han podido gestionar a tiempo los riesgos, recalcando la importancia del rol que juegan los auditores en la identificación y prevención de riesgos en este tipo de proyectos. La realidad muestra que los análisis post-mortem revelan que en los proyectos fallidos del sector IT existieron importantes señales o síntomas que pudieron hacer presagiar el fallo. A lo largo del artículo se enumeran las señales más importantes que se deben tener en cuenta en base a la investigación realizada. Se afirma que, además, estas señales son fácilmente identificables si se sabe lo que hay que buscar y además son efectivas si se ponen medidas que mitiguen el riesgo en cuanto se detectan. A efectos del estudio, el autor califica las señales de alerta temprana aquellas que se han manifestado antes de que se llegue al 20% del calendario original del proyecto. Para llevar a cabo la investigación el autor crea un panel compuesto por 19 expertos en dirección de proyectos IT a los que les presenta una lista de EWS.
El resultado de esta evaluación muestra que 17 de las EWS con notas de entre 6 y 7 pertenecen a las categorías de Gente y Procesos y no a la categoría de Tecnología. Finalmente 12 de estos 17 riesgos forman parte de la lista de riesgos más importante y que a su vez se pueden categorizar en stakeholders, requisitos, procesos de gestión y equipo.
Lo más interesante de esta lista de doce riesgos es que cuanto más relacionado esté con la gobernanza, el liderazgo o la gestión de las inversiones en IT más implicados han de estar los CFO’s, los CIO’s y los CEOs. A modo de conclusión el autor afirma que conociendo estas señales y poniendo atención sobre ellas cuanto antes se incrementa las posibilidades de éxito en el resultado del proyecto.
Figura 5 Las EWS de los fallos en los Proyectos de IT (18)
El análisis de los datos demuestra que la mayoría de los eventos inesperados se produce en el círculo interno del proyecto y se deben, en su mayoría, a riesgos que no se han tenido en cuenta. Por otro lado, están los eventos impredecibles generados fuera del ámbito del proyecto que son extremadamente raros y que no afectan directamente al proyecto pero que cuando lo hacen los directores de proyecto no son capaces de ver esta relación. El lugar donde se origina el evento inesperado sigue unos patrones de manera que cuando se producen en el entorno externo más cercano es percibido con una mayor severidad que los eventos generados a nivel interno. Esto se debe al mayor efecto sorpresa en el caso de los eventos externos. A modo de conclusión los autores afirman que los directores de proyecto tienden a subestimar los riesgos de forma significativa, pero con el modelo propuesto esperan que se pueda predecir de forma más precisa el futuro en lo que a proyectos se refiere.
Los autores realizan un estudio sobre cómo las evaluaciones de los proyectos se pueden usar para detectar señales de alerta temprana en proyectos complejos y lo hacen desde la perspectiva del propietario del proyecto. Llevan a cabo el estudio observando cómo los propietarios del proyecto hacen hincapié en poner en marcha marcos de trabajo que están, cada vez más, dirigidos a poder explicar las señales de alerta temprana. El artículo realiza metodológicamente un análisis de las guías metodológicas, una serie de entrevistas y la revisión de casos de Australia, Noruega y Reino Unido. Comienza con la selección de nueve marcos de gobierno con el objetivo de identificar con qué frecuencia se realizan evaluaciones de proyectos y cuáles son las mejores prácticas recomendadas en cada uno de ellos. Los autores revisan, conceptualizan y categorizan las señales presentes en la literatura así como los diferentes tipos de evaluación de proyectos basándose, para ello, en la categorización realizada por Oakes (21): revisiones de proyectos, chequeos de salud del proyecto, benchmarking y evaluaciones post-proyecto. Como conclusión de su estudio aportan un listado de señales de alerta temprana fruto de sus estudios empíricos y que se resumen en la siguiente tabla.
Tabla 3 Early Warning Signs (20)
Project setup In early stages Project execution
Asse
ssme
n
ts
• Sponsor(s) with unclear role
• Lack of an implemented governance framework • Poor project definition
• Lack of clarity in rationale, goals, and
benefits
• Poorly developed business plan
• Poor definition of scale and what resources are
needed
• Unclear what assumptions are valid about the project • Lack of relevance of the
pro- posed solution compared with the needs • The need for development
of new technology • Main risks not identified
• Lack of a good business case
• Deterioration of relations between the participants
• Lack of a common definition of roles and
responsibility
• The project team overlying on the
consultant/contractor’s people to “fix it” • Numbers/information
missing in documents • Assessments not
performed • Documentation not
completed • Inappropriate quality of
information and documentation produced • Missing competence in the
project team
• People in “acting positions” with no authority
to recommend action • Lack of documentation • An excess of “no cost/no time” effects leading to
optimism bias
• Contractor unfamiliar with domain responsibility
• High level of subcontractors’ claims and
extension of time claims • Plans and reports too late
and/or not clear • Contract obligations not
fulfilled • Milestones/activity definitions unclear or
missing
• Guidelines for early phase assessments and “behaviour” not followed • Disputed major decisions
and complications arising from these
• Main risks not identified
• Remaining risks not identified Gu t f ee li n g
• Sponsor(s) having unclear expectations
• Vague or unclear reasons for undertaking the project
(unclear thinking) • Needs considered not real
• Inconsistent arguments about agendas • Uneasy comments and
body language • The way questions are asked and how answers are
given
• Specific conditions exist that will make cultural
aspects important
• Leadership issues • The way answers are given to critical questions, when the answers are vague
• Strained atmosphere • Lack of a culture of
openness and good communication between the
actors
• Confusing or wavering changes in position over
time
• Uneasy comments and body language • Stating uncertainty, unwillingness to conclude • Parties unwilling to share
relevant information • Parties voicing reservations and politically
hedging their positions
• Leadership issues • Lack of commitment to
make decisions • Frequently changing
decisions
• Continually unfulfilled promises
• Vague answers to critical questions
• When people work too much or too little • Uneasy comments and
body language • Not showing trust in the
project organization
determinar cómo pueden ser identificadas, recogidas e interpretadas. Los autores hacen un resumen y evalúan las contribuciones realizadas tanto a nivel teórico como aplicadas a la gestión de las señales. Concluye el artículo sugiriendo algunas direcciones por las que debe evolucionar el desarrollo de las investigaciones relacionado con las señales débiles. Las fuentes de las señales y las herramientas para identificarlas son áreas en las que Ansoff no profundizó con detalle y por tanto se trata de una de las cuestiones que más contribuciones necesita. Del mismo modo el desarrollo de técnicas y herramientas amigables y fiables están en sus etapas iniciales y suponen, por lo tanto, un reto para futuras investigaciones.
El siguiente trabajo de investigación (23) es un caso de estudio que combina diferentes técnicas de investigación para demostrar finalmente que un indicador de desempeño del proyecto puede ser una fuente de señales de alerta temprana. Los autores llevan a cabo su investigación por medio de entrevistas semiestructuradas y a través del análisis de la documentación obtenida tras el estudio post-mortem de un proyecto. El estudio demuestra que efectivamente existe un enlace entre la alerta temprana y el desempeño del proyecto, poniendo de manifiesto la demostración de cómo la implementación de una medida de desempeño del proyecto como sistema de alerta temprana mejora el rendimiento general del proyecto. Concluyen afirmando que los datos necesarios para alimentar estos indicadores de desempeño se pueden obtener fácilmente de los registros del proyecto o por medio de simples encuestas, lo que facilita su puesta en práctica.
Dos de los autores anteriores publican un nuevo artículo (24), esta vez centrado en la necesidad de incluir la identificación de señales de alerta temprana en las fases iniciales del proyecto. Es en esta fase donde se toman las decisiones más críticas del proyecto, ya que es el momento en el que más incertidumbre existe, pero, a su vez, las acciones correctivas pueden corregir mejor los efectos negativos. La investigación llevada a cabo, sugiere que puede aportar nuevas perspectivas para añadir la identificación de señales de alerta temprana en las fases iniciales del proyecto. Para llevar a cabo el estudio se apoyan en un proyecto real, concretamente en el caso de Norwegian High Speed Railway. El estudio trata de identificar los posibles problemas y las señales de alerta temprana basándose en el análisis de los documentos de las evaluaciones de viabilidad del proyecto que han sido publicados en el caso de estudio. Como resultado del análisis muestra que, aunque existe un grupo amplio de problemas del que no se pueden identificar señales de alerta temprana en estas fases iniciales, hay otras que si pueden ser identificadas y que además pueden contribuir, en gran manera, a la toma de decisiones. Por tanto, los autores concluyen existe una relación entre la identificación temprana y la toma decisiones en las etapas iniciales del proyecto. Esta relación además puede contribuir positivamente a la toma de decisiones en esas etapas iniciales del proyecto.
identificar las debilidades y las fortalezas de cada una de las aproximaciones así como sus posibles aplicaciones en diferentes contextos. Los autores han realizado una categorización en base a una serie de criterios como son el tipo de datos que se puede recoger en cada aproximación, el tipo de análisis que requiere, el objetivo, la fuente de información y finalmente la fase del proyecto en la que se puede aplicar. Concluye afirmando que la elección de la aproximación correcta depende del proyecto, de la organización del proyecto y del contexto donde se desarrolle el mismo. Estas afirmaciones son realizadas desde la experiencia de los autores al haber puesto en práctica varios de los métodos citados. El estudio propone, como futuras líneas de investigación, la prueba de más aproximaciones en diferentes casos para conseguir determinar mejor el grado de utilidad de cada una de estas aproximaciones en la práctica real. Además, proponen combinar diferentes fuentes de identificación de señales para conseguir mejores resultados y por último, con toda esta información, ver cómo impacta la implementación de un sistema de alerta temprana en el éxito final del proyecto. A través de un caso de estudio (26) se trata de responder a la siguiente pregunta de investigación ¿Son los Sistemas de Alerta Temprana realmente útiles para la mejora de la resolución de problemas y la mejora del desempeño del proyecto? Para responder a la pregunta llevan a cabo un estudio empírico centrado en el sector de la construcción en el Reino Unido. En el estudio combinan la revisión de la literatura, las entrevistas a expertos y una encuesta dirigida a la industria de la construcción de la que obtienen casi 100 respuestas. Los autores comparan el desempeño del proyecto y la resolución de problemas en proyectos que usan sistemas de alerta temprana y proyectos que no lo usan, obteniendo como conclusión un efecto positivo significativo en términos de tiempo, coste y calidad en el caso de los proyectos que si usan sistemas de alerta temprana. En base a estos resultados, los autores desarrollan un modelo de entrada-proceso-salida para investigar acerca de la relación causa-efecto entre la alerta temprana, la resolución de problema y el desempeño del proyecto. El estudio afirma, como parte de las conclusiones, que si bien los sistemas de alerta temprana en la gestión de proyectos tienen efectos positivos sobre el desempeño y el resultado del proyecto no son realmente la panacea ya que no se muestra eficiente en algunos tipos de problemas, como por ejemplo los recurrentes.
Dos de los autores que más han publicado en esta temática continúan el estudio con la publicación de un artículo que trata de identificar las barreras que impiden poner en marcha respuestas a las señales de alerta temprana identificadas en los proyectos (28). Los autores investigan en esta ocasión acerca de cómo las especificaciones de los proyectos y de su organización influyen en las respuestas a las señales de alerta temprana dentro del ámbito del proyecto. El estudio se basa en una encuesta realizada a directores de proyecto noruegos en la se analiza cómo reaccionan los encuestados a una serie de señales. El estudio pone de manifiesto que existen barreras específicas que impiden responder a las señales identificadas. Estas barreras pueden levantarse por factores de la organización como puede ser el sesgo de los directores de proyecto debido a su optimismo, o asumir como algo normal en la organización el desvío del proyecto o la falta de perspectiva. Los autores desarrollan y clarifican el modelo de gestión de Ansoff poniendo sobre relieve el filtro de mentalidad existente para identificar y definir con más claridad los procedimientos donde se crean las barreras.
Los resultados demuestran que, factores como la complejidad, el nivel de optimismo, una cultura abierta o el grado de eficacia en las comunicaciones influyen con fuerza en los Sistemas de Alerta Temprana. El estudio responde, por lo tanto, a tres preguntas de investigación:
¿Cuáles son las principales barreras para responder a las señales de alerta temprana identificadas?
¿Cuál es el rol de los factores de la organización en la eficacia de las respuestas?
¿Qué aproximaciones permiten a los directores de proyecto mejorar el procedimiento de respuesta a las señales de alerta temprana?
En la literatura más reciente encontramos un artículo orientado a reducir las sorpresas inesperadas en la gestión de proyectos (29) que plantea la pregunta de investigación ¿Cómo podemos reducir el número de desconocidos-desconocidos (unk-unks) que un proyecto afronta?
Los autores parten de la base de que las herramientas existentes para la gestión de riesgos pueden gestionar sólo los riesgos conocidos, mientras que los proyectos, por definición, son nuevos y únicos. El estudio hace una revisión de los objetivos y de las herramientas que se utilizan para hacer la identificación de riesgos. Partiendo de la base de que los proyectos funcionan como sistemas, proponen una lista de seis dominios donde reside la incertidumbre:
Subsistema de resultado Subsistema de proceso Subsistema de organización Subsistema de herramientas Subsistema de metas
Contexto
Complejidad
Complejidad desde el punto de vista del observador Dinamismo
Ambigüedad Sinsentidos
Patologías del proyecto
Finalmente, los autores proponen 11 herramientas que ayudan a los directores de proyectos a reducir los riesgos desconocidos llamados también en la literatura unknow-unknowns (unk-unks):
Descomponer el proyecto Analizar los escenarios
Utilizar la herramienta de checklist Hacer un escrutinio de los planes Hacer largas entrevistas
Capturar las señales débiles Hacer minería de datos
Comunicarse con frecuencia y de forma eficiente
Buscar un equilibrio entre la autonomía local y el control central Incentivar el descubrimiento de unk-unks
Cultivar una cultura de alerta
Los autores concluyen afirmando que algunos de los unknown-unknowns son realmente conocidos o se pueden convertir en conocidos, pero que los individuos y las organizaciones trabajando desde el sinsentido o no eliminando las patologías existentes en los proyectos hacen que se mantengan escondidos y que se conviertan en grandes problemas en el futuro.
De nuevo de la mano de los autores más productivos en esta área de conocimiento, encontramos un artículo con aplicación a un sector muy concreto como es la construcción de barcos (30). Los autores comienzan describiendo el sector como complejo por la gran cantidad de stakeholder a gestionar, por el alto nivel de incertidumbre y por las muchas tareas a coordinar de forma efectiva dentro del proyecto. Identifican como el gran reto de este tipo de proyectos evitar los retrasos en la entrega del producto. Los autores afirman en el estudio que los elementos que generan estos retrasos no aparecen de la noche a la mañana, sino que existen señales de alerta temprana que hacen predecir que el retraso se va a producir. El estudio afirma que si se aplica un procedimiento de detección de señales de alerta temprana es factible que los directores de proyecto puedan predecir los factores de retraso en los proyectos de construcción de barcos y por tanto puedan prevenir actuando sobre dichas señales antes de que se conviertan en problemas reales con impacto.
concepto “previsión” o “anticipación” a la dirección de proyectos. La previsión o prospectiva es una técnica que se está utilizando con éxito en la gestión empresarial orientada a la planificación a largo plazo. El estudio concluye que, tras la revisión sistemática de la literatura y dado el reducido número de publicaciones relacionadas, se puede afirmar que sí existe aplicación específica a la gestión de proyectos pero que ésta está, todavía, en sus etapas iniciales. Sugiere por tanto que es una vía de investigación para futuro ya que las herramientas actuales no se muestran suficientes para abordar la cada vez más creciente incertidumbre y complejidad de los proyectos.
5
Conclusiones
La mayoría de los autores comienzan reconociendo la incertidumbre y la complejidad en la que se desenvuelven los proyectos hoy en día, e identifican la necesidad de buscar nuevas vías para poder gestionar esta situación.
Si bien la teoría de las señales débiles (6) es del año 1975, no es hasta la primera publicación de Nikander (1) en 1997 cuando se sugiere la aplicación de esta teoría a la dirección de proyectos. La realidad es que de las 26 publicaciones identificadas 7 de ellas (23,24,25,27,28,32) son de un mismo autor principal Haji-Kazemi y las tres iniciales del ya mencionado Nikander (1,7,8). La escasa contribución científica en relación a los Sistemas de Alerta Temprana aplicada a los proyectos indica que se trata de una línea de investigación que está en sus inicios a pesar de los años que han pasado desde la primera publicación.
Cuestiones como la identificación de las señales, la gestión de las respuestas, la creación de marcos conceptuales que guíen la aplicación de los Sistemas de Alerta Temprana en los proyectos y sobre todo el diseño de herramientas que permitan, de una forma sencilla, la captura y explotación de estas señales son las líneas de investigación que marcarán el futuro de los Sistemas de Alerta Temprana aplicados a la Dirección y Gestión de Proyectos.
6
Bibliografía
(1) Nikander IO, Eloranta E. "Preliminary signals and early warnings in industrial investment projects". International Journal Project Management. Vol. 15, 1997, pp. 371–376.
(2) Fleming Q, Koppelman JMJ. "Earned value project management". The Journal of Defense Software Engineering. Vol. 16, 1998, pp. 19–23.
(3) Anbari F. "Earned value project management method and extensions". Project Management Journal. Vol. 34, 2003, pp. 12–23.
(4) Shenhar AJ, Levy O, Dvir D. "Mapping the Dimensions of Project Success". Project Management Journal. Vol 28, 1997, pp. 5–13.
phenomenon, it’s time to accept other success criteria". International Journal of Project Management. Vol. 17, 1999, pp. 337-342
(6) Ansoff HI. "Managing strategic surprise by response to weak signals". California Management Review. Vol. 18, 1975, pp. 21–33.
(7) Nikander IO. "Early Warnings". 2002.
(8) Nikander IO, Eloranta E. "Project management by early warnings". International Journal of Project Management. Vol. 19, 2001, pp. 385–99.
(9) Giegerich DB. "Early warning signs of troubled projects". AACE International Transactions. 2002, pp. CDR.02.1 – CDR.02.8.
(10) Liu X (Frank), Kane G, Bambroo M. "An intelligent early warning system for software quality improvement and project management". The Journal of System and Software, Vol. 79, 2003, pp. 1-7
(11) Spjelkavik I, Andersen B, Onsøyen LE, Fagerhaug T, Marheim H. "Project Performance Management System: A Conceptual Framework for early warnings in projects". MEI. 2008 (12) Hanna AS, Gunduz M. "Early warning signs for distressed projects". Canadian Journal of
Civil Engineering, Vol. 32, 2005, pp. 796–802.
(13) Havelka D, Rajkumar TM. "Using the Troubled Project Recovery Framework: Problem Recognition and Decision to Recover". E-Service Journal, Vol. 5, 2006, pp. 43–73.
(14) Kappelman L A., Zhang L, McKeeman R. "Early Warning Signs of it Project Failure: The Dominant Dozen". Information Systems Management. Vol. 23, 2006, pp. 31-36
(15) Noble J, Oates BJ, Griffiths G. "Early Warning Signs of Communication Failure In Is Projects: A Case Study". UK Academy for Information Systems Conference Proceedings. 2009.
(16) Geraldi JG, Lee-Kelley L, Kutsch E. "The Titanic sunk, so what? Project manager response to unexpected events". International Journal of Project Management, Vol. 28, 2010, pp. 547-558.
(17) Philip T, Schwabe G, Wende E. "Identifying Early Warning Signs of Failures in Offshore Software Development Projects-A Delphi survey" Americas Conference on Information Systems, 2010
(18) Kappelman L. Auditing IT Projects: "Early Warning Signs of Material Risk". Edpacs. Vol. 43, 2001, pp. 1–9.
(20) Williams T, Jonny Klakegg O, Walker DHT, Andersen B, Morten Magnussen O. "Identifying and Acting on Early Warning Signs in Complex Projects". Project Management Journal, Vol. 43, 2012, pp. 37-53
(21) Oakes M. "Project reviews, assurance and governance". Gower Publishing, Ltd; 2012. (22) Holopainen M, Toivonen M. "Weak signals: Ansoff today". Futures, Vol. 44, 2012, pp.
198-205.
(23) Haji-Kazemi S, Andersen B. "Application of performance measurement as an early warning system: A case study in the oil and gas industry". International Journal of Managing Projects in Business, Vol. 6, 2013, pp. 714–738.
(24) Haji-Kazemi S, Andersen B, Krane HP. "Identification of Early Warning Signs in Front-End Stage of Projects, an Aid to Effective Decision Making". Procedia - Social and Behavioural Sciences, Vol. 74, 2013, pp. 212–222.
(25) Haji-Kazemi S, Andersen B, Krane HP. "A review on possible approaches for detecting early warning signs in projects". Project Management Journal, Vol. 44, 2013, pp. 55–69. (26) Meng X. "Is Early Warning Effective for the Improvement of Problem Solving and Project
Performance?" Journal of Management in Engineering, Vol. 32, 2014, pp. 146–152. (27) Haji-Kazemi S, Andersen B. "Efficiency of project health checks (PHCs) as an early
warning system in practice". International Journal of Managing Projects in Business, Vol. 7, 2014, pp. 678–700.
(28) Haji-Kazemi S, Andersen B, Klakegg OJ. "Barriers against effective responses to early warning signs in projects". International Journal of Project Management. Vol. 33, 2015, pp. 1068–1083.
(29) Browning TR, Ramasesh R V. "Reducing Unwelcome Surprises in Project Management" MIT Sloan Management Review. Vol. April, 2015, pp. 53–62.
(30) Haji-Kazemi S, Arica E, Semini M, Alfnes E, Andersen B. "Detecting Early Warning Signs of Delays in Shipbuilding Projects". IFIP International Federation for Information Processing. Vol. 460, 2015. pp. 215–22.
(31) Silva M. "A Systematic Review of Foresight in Project Management Literature". Procedia Computer Science, Vol. 64, 2015, pp.792–799.
7
Correspondencia
Ing. Daniel Magaña Martínez Email: [email protected]
Universidad Antonio de Nebrija (España) Dr. Juan Carlos Fernández Rodríguez Email: [email protected]
