GESTIÓN DE PROYECTOS COMPLEJOS 1

Arce-Labrada, Sigifredo
arcesigifredo@gmail.com.

Introducción

Este es el primero de una serie de artículos sobre la gestión de proyectos complejos. La razón
básica para desarrollar esta serie es que se ha prestado poca atención a la complejidad de los
proyectos. En este primer artículo de esta serie parto de la matriz What – How conocida como
la “matriz de objetivos y métodos” original de Turner y Cochrane quien sugirió dos
parámetros para la clasificación de proyectos: ¿qué tan bien se definen los objetivos? Y ¿qué
tan bien están definidos los métodos (solución) para lograrlos? David Dombkins en 1997
acuño el término WHOW para descubrir una matriz de 2x2 que ayuda a comprender la
complejidad del proyecto y cómo esto afecta la gestión de los ciclos de vida del proyecto.

Problemática d en la gestión de proyectos

Las actividades de las organizaciones pueden dividirse en dos grandes categorías:

operaciones y proyectos. Las operaciones se ocupan de la producción de bienes y/o servicios,
actividades que son repetitivas y continuas. Trata de la gestión de procesos que transforman
entradas (p. ej., materiales, componentes, energía y mano de obra) en salidas (p. ej. productos,
bienes y/o servicios) (PMI, 2017), mientras que los proyectos involucran iniciativas únicas,
como el lanzamiento de nuevos productos al mercado, llevar a cabo una campaña para un
político, construir un puente, represa o acueducto municipal. Los proyectos impulsan la
innovación y el cambio empresarial; de hecho, la única forma en que las organizaciones
pueden cambiar, implementar una estrategia, innovar u obtener una ventaja competitiva es a
través de proyectos.

Los resultados de la encueta para Pulse of the Profession® 2020 de PMI revela que un
promedio de 11.4 por ciento de la inversión se desperdicia debido al bajo rendimiento de los
proyectos. Y las organizaciones que infravaloran la gestión de proyectos como una
competencia estratégica para impulsar el cambio informaron que más del 67 por ciento de
sus proyectos fracasan.

Puede pensarse que los proyectos fracasan debido a una mala planificación, falta de
comunicación o recursos inadecuados; pero como la evidencia sugiere, el fracaso a menudo
se encuentra incluso en proyectos bien gestionados por gerentes experimentados y
respaldados por organizaciones de gran prestigio. Podemos encontrar situaciones similares
en todas las organizaciones, donde los proyectos bien gestionados no cumplen sus promesas
y terminan decepcionando. El tema común es que tanto el patrocinador, el gerente y los
equipos de proyecto no pudieron reconocer de antemano el grado de incertidumbre y
complejidad involucrados (o no se comunicaron entre sí) y no pudieron adaptar su estilo de
gestión a la situación.
Los equipos de proyecto a menudo intentan seguir un conjunto de pautas bien establecidas
que se ha convertido en estándar en la disciplina de la gestión de proyectos, tales como Guía
PMBOK, APMBOK, P2M, BS6079. Aunque los cuerpos de conocimiento convencionales
de gestión de proyectos constituyen una buena base para la capacitación básica y el
aprendizaje inicial, puede que no sea suficiente para abordar los problemas complejos de los
proyectos actuales.
Simplemente preguntado, si aplican las técnicas y herramientas estándar y se siguen las reglas
y procesos según lo prescrito, ¿el proyecto tendrá éxito? Como hemos encontrado, la
respuesta es, no siempre. Los problemas surgen del marco y la mentalidad que impulsan el
enfoque tradicional de la gestión de proyectos, en lugar de la falta de proceso o práctica.

Hass (2010) y Wysocki (2014) proponen:

1. Diagnosticar la complejidad del proyecto utilizando un modelo de complejidad

2. Asignar líderes competentes acordes con el perfil de complejidad.
3. Seleccionar el enfoque del proyecto acorde con el perfil de complejidad y
4. Gestionar las dimensiones de complejidad presentes en el proyecto

Nuestro objetivo es ofrecer, a través de la serie de artículos sobre la gestión de proyectos,

cómo pasar del pensamiento tradicional a, un marco que represente un enfoque nuevo para
ayudar a los gerentes a ser más exitosos y agregar valor en nuestra era VUCA (volatilidad,
incertidumbre, incertidumbre, ambigüedad).

Veamos algunos conceptos claves de proyectos, antes de abordar los conceptos de

complejidad y la complejidad de los proyectos:

• Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto,

servicio o resultado único (PMI, 2017).

• Un proyecto es un conjunto único de procesos conformado por actividades

coordinadas y controladas con fechas de inicio y fin, que se llevan a cabo para lograr
los objetivos propuestos en el proyecto. (ISO 21500, 2012).

• Un proyecto es una organización temporal que se crea con el propósito de entregar

uno o más productos comerciales según un Business Case convenido. (Axelos, 2017).

• Un proyecto es una operación en la cual los recursos humanos, financieros y

materiales se organizan de forma novedosa, para realizar un conjunto de tareas,
según unas especificaciones definidas, con restricciones de costo y plazo, siguiendo
un ciclo de vida estándar, para obtener cambios beneficiosos, definidos mediante
objetivos cuantitativos y cualitativos. (IPMA, 2015).
Ciclos de vida del proyecto

El ciclo de vida del proyecto ilustra las distintas fases que toman una idea inicial, capturan
los requisitos de las partes interesadas, desarrollan un conjunto de objetivos y luego los
cumplen.

El ciclo de vida del proyecto puede verse afectado por los aspectos propios de la
organización, de la industria, el método de desarrollo o la tecnología empleada. Mientras que
cada proyecto tiene un inicio y un final, los entregables específicos y el trabajo que se llevan
a cabo varían ampliamente dependiendo del proyecto. (PMI, 2017).

Los objetivos de la gestión del ciclo de vida son:

• identificar las fases de un ciclo de vida que coinciden con el contexto del trabajo;
• estructurar las actividades de gobierno de acuerdo con las fases del ciclo de vida.

El ciclo de vida más simple es el ciclo de vida de un proyecto que solo se ocupa de desarrollar
un resultado.

Gráfico 1 Representación genérica del Ciclo de Vida de un Proyecto

Fuente: PMBOK 2017

Todo comienza con alguien que tiene una idea que vale la pena investigar. Esto desencadena
la gestión de requisitos de alto nivel y la evaluación de la viabilidad de la idea de crear un
caso de negocio. Al final de la fase hay un portón donde se toma la decisión de proceder a
una definición más detallada (y por lo tanto costosa) del trabajo.

Si la idea es lo suficientemente buena, el trabajo continuará con una definición detallada que
produzca una justificación completa del trabajo. Una vez más, esto termina en un portón
donde se toma la decisión de proceder o no a la fase de entrega. En el punto de control, se
evalúa el estado del proyecto, revisando el acta de constitución del proyecto, el caso de
negocio y el plan de beneficios, para asegurar que el proyecto se mantiene viable y para que
se pueda tomar una decisión en cuanto si ha de proceder (PRINCE2, 2017)

Una vez que se ha producido el resultado, generalmente está sujeto a un proceso de

aceptación antes de ser entregado formalmente a su nuevo propietario. El ciclo de vida llega
a su fin con el cierre del proyecto. Todos los resultados están destinados a ofrecer beneficios
para la organización.

Para gestionar un proyecto a lo largo de su ciclo de vida, los procesos de la gestión de

proyectos (inicio, planificación, ejecución, monitoreo y control y cierre) deben ser empleados
para el proyecto como un todo, o para las fases individuales de cada equipo o subproyecto.
(ISO 21500, 2012).

Los dos enfoques principales para las fases del ciclo de vida son secuenciales (lineal) y
paralelos o iterativos. La diferencia fundamental entre estos es si los requisitos y las
soluciones pueden definirse por adelantado o pueden evolucionar a lo largo del ciclo de vida.

Dos factores influyen en si se utilizará un ciclo de vida en secuencial o paralelo.

En primer lugar, donde los entregables pueden, o deben ser, sustancialmente especificados
antes de que comience el trabajo en el momento de la entrega, el ciclo de vida será
predominantemente secuencial. Cuando una especificación evoluciona a medida que avanza
el trabajo, el ciclo de vida será paralelo.

En segundo lugar, incluso si el trabajo pudiera especificarse completamente por adelantado,

puede reducir la duración total de un proyecto o programa si el trabajo de especificación y la
entrega se ejecutan en paralelo. Esto a menudo se llama 'seguimiento rápido'.

Los ciclos de vida paralelos facilitan métodos de entrega tales como ingeniería ágil y
concurrente.

Clasificación de los proyectos empresariales

Arboleda Vélez (2013), presenta un resumen de la clasificación general de los proyectos

empresariales, como se observa a continuación:
• De acuerdo con el carácter del proyecto
• De acuerdo con el sector de la economía al cual están dirigidos
• De acuerdo con el objetivo del proyecto
• De acuerdo con el ejecutor del proyecto
• De acuerdo con su área de influencia y
• De acuerdo con su tamaño.

Muchas organizaciones optan por definir una clasificación de proyectos basada en tales
características del proyecto como las siguientes:

• Riesgo: se establecen niveles de riesgo (alto, medio y bajo).

• Valor comercial: niveles (alto, medio y bajo).
• Duración: establecen varias categorías (como 3 meses, 3 a 6 meses, 6
a 12 meses, y así sucesivamente).
• Complejidad: establecen categorías (alta, media y baja).
 • Tecnología utilizada: establecen varias categorías (bien establecidas, utilizadas
ocasionalmente, se usa raramente, nunca se usa).
• Número de departamentos afectados: establecen algunas categorías (como
uno, algunos, varios y todos).
• Costo

Los proyectos también pueden clasificarse según la certeza tanto para el alcance
(QUE/WHAT) como en el método de entrega (COMO/HOW)

MATRIZ WHAT-HOW
SOLUCIÓN
(¿Cómo implementar objetivos?)
Claro Poco Claro
¿Qué objetivos hay que lograr?

C D
Poco claro
OBJETIVOS

A B
Claro

Fuente: CPM Competency Standards V. 4.1

Gráfico 2: Matrix What-How

Estos cuatro cuadrantes resultantes, definen proyectos que son muy diferentes y que
requieren muy diferentes enfoques de gestión.

Wysocki (2014), define cinco modelos diferentes de Project Management Life Cycles
(PMCL). Cada uno está construido para satisfacer las necesidades específicas de un tipo de
proyecto con el que está alineado y así, entonces tenemos las siguientes cuadrículas, que
brevemente se explicarán:

• Proyectos tipo A: Proyectos tradicionales – TPM

• Proyectos tipo B: Proyectos Ágiles – APM
• Proyectos Tipo D: Extreme Proyectos – xPM y
• Proyectos tipo C: Emertxe Proyectos – MPx
 MATRIZ WHAT-HOW
SOLUCIÓN
(¿Cómo implementar objetivos?)
Claro Poco Claro

¿Qué objetivos hay que lograr?

Complejidad creciente
Emertxe Extreme

Poco claro

Alta
OBJETIVOS Proyectos Projectos
MPx (xPM)

Proyectos Proyectos

Baja
Claro

Tradicionales Ágiles
(TPM) (APM)

Fuente: Adaptado de CPM Competency Standards

V. 4.1 y Wysocki, R.2011
Gráfico 3: Matrix What-How

La cuadrícula (gráfico 3) se usa para clasificar el proyecto en un cuadrante y dentro de ese

cuadrante para seleccionar un modelo de ciclo de vida del proyecto de mejor ajuste.

Los proyectos TPM (tipo A) son impulsados por planes, procedimientos, métodos y sistemas
escritos para replicar lo que se ha hecho en el pasado. El esfuerzo durante las fases de
concepto y diseño se centra en el diseño detallado y la coordinación utilizando herramientas
y técnicas bien establecidas, en lugar de la innovación. Es un proyecto repetitivo, los
stakeholders están seguros de lo que hay que hacer y del cómo se va a realizar el proyecto.
Generalmente siguen una metodología fija. Se desarrolla un cronograma o diagrama de hitos
para identificar el inicio o finalización programada de los principales entregables u otros
eventos importantes.
Un proceso formal de gestión de cambio es componente del plan para la ejecución del
proyecto. Se hace uso de línea bases del alcance, cronograma y costos integradas, utilizadas
para comparación, a fin de gestionar, medir y controlar la ejecución del proyecto. Los equipos
de TPM no tienen que estar ubicados conjuntamente. Si bien la ubicación conjunta facilitaría
un poco la vida del gerente del proyecto, no es una necesidad. Las especificaciones detalladas
de estos proyectos los hacen adecuados para licitaciones competitivas bajo contratos de
precio fijo. Proyectos típicos de la industria de ingeniería
 MATRIZ WHAT-HOW
SOLUCIÓN
(¿Cómo implementar objetivos?)
Claro Poco Claro

¿Qué objetivos hay que lograr? Panorama

Emertxe Extreme
Poco claro
Proyectos
Proyectos Projectos
MPx (xPM)
Complejos
OBJETIVOS

Claro

Proyectos Proyectos
Tradicionales Ágiles
(TPM) (APM)

Fuente: Adaptado de CPM Competency Standards

V. 4.1 y Wysocki, R.2011

Gráfico 4: Matrix What-How

Los proyectos Ágiles - APM (tipo B) caen dentro del panorama de los proyectos complejos.
En esta cuadrícula es de destacar que los stakeholders están seguros de lo que hay que hacer,
pero no de cómo se va a realizar el proyecto. La organización dedica tiempo a definir ese
cómo. La fase de concepto puede ser relativamente corta y simple. Las fases de diseño e
implementación deben ser recursivas (Dombkins, 1997). El énfasis debe estar en la capacidad
de respuesta y la innovación con una relación cíclica entre diseño innovador y detallado.
Debido a que no se pueden detallar completamente antes de la implementación, la
planificación para proyectos de tipo APM es mucho más compleja que para los proyectos de
tipo TPM. Si un proyecto tipo APM se somete a licitación competitiva, debe basarse en un
contrato basado en el desempeño donde el QUE es un resultado específico y el COMO se
deja al licitador para que lo diseñe e implemente. Los proyectos de cambio de cultura
organizacional serán típicamente del tipo APM.

Los proyectos Extremos – xPM (tipo D) son los más complejos. Ni los objetivos ni los medios
para lograr esos objetivos son claros. La organización intenta hacer algo que no había hecho
antes y necesita tiempo para definir el QUE y el CÓMO. Los stakeholders no están seguros
de lo que se debe hacer y de CÓMO se va a hacer el proyecto. Estos proyectos caen dentro
del entorno de I+D. Igual énfasis en las fases de concepto, diseño e implementación; la
considerable superposición y su naturaleza recursiva. Se requiere innovación y flexibilidad
en todas las etapas. Dombkins (2007) propone adoptar un enfoque de sistemas para resolver
QUÉ y CÓMO usar simultáneamente un equipo integrado de diseño funcional y especialistas
operacionales (similar a los equipos scrum o ingeniería concurrente). El uso de proyectos
piloto y prototipos será común. En los proyectos de tipo xPM, habrá mucha negociación a lo
largo del proceso entre patrocinadores, partes interesadas, especialistas técnicos y operativos
(propietarios de productos).
En los proyectos Emertxe – MPx (tipo C) la empresa tiene la experiencia y el método que se
utilizará; necesita tiempo para definir el QUE. Los stakeholders no están seguros de lo que
se debe hacer, pero si del CÓMO se va a realizar el proyecto. La fase clave de este tipo de
proyectos es la conceptual. Cuyo foco debe estar en la innovación y la flexibilidad, pero
después de eso, las fases de diseño e implementación se parecen a un proyecto tipo TPM.
La planificación de la fase conceptual se trata como un proyecto complejo con asignación
para actividades recursivas y no lineales (similar a los proyectos tipo xPM. (Dumbkins,
1997). El diseño y la implementación se pueden planificar con un enfoque similar a los
proyectos de tipo TPM

En resumen, no todos los proyectos son iguales.

Conclusión

En este primer artículo de una serie de cinco, se han clasificado según: qué tan bien se definen
los objetivos del proyecto y qué tan bien están definidos los métodos/solución para lograr
esos objetivos. Esta clasificación para los proyectos está representada en la gráfica 3. Estos
son:
• Proyectos tipo A: Proyectos tradicionales – TPM
• Proyectos tipo B: Proyectos Ágiles
• Proyectos tipo D: Proyectos Extreme
• Proyectos tipo C: Proyectos Emertxe

Se espera que este artículo y los siguientes pueda ayudar a algunos a evaluar la complejidad
de los proyectos particulares utilizando algunos de los modelos que abordaremos
posteriormente, y contribuir a tomar buenas decisiones para asignar líderes competentes
acordes con el perfil de complejidad, seleccionar el enfoque del proyecto acorde con ese
perfil de complejidad y gestionar las dimensiones de complejidad presentes en el proyecto.
En resumen, no todos los proyectos son iguales. ¡Una talla no sirve para todos los proyectos!

REFERENCIAS

Arboleda, G. (2013). Proyectos Identificación, formulación, evaluación y gerencia 2a.

edición. Bogotá, D. C.: Alfaomega Colombiana S. A.
AXELOS. (2017). Managing Successful Projects with PRINCE2. United Kingdom: The
Stationery Office.
Dombkins, D. H. (1997). PROJAM: The Management of Complex Projects and Programs.
Hass, K. B. (2009). Managing complex projects: a new model . Leesburg Pike, Vienna,
VA. EE UU.: Management Conepts, Inc.
Institute, P. M. (2017). A Guide to the Project Management Body of Knowledge (PMBOK
Guide). Newtown Square, PA: Authot.
Instituto Colombiano de Normas Técnicas y Certificación - ICONTEC. (2013). GTC-ISO
21500 Directrices para la Dirección y Gestión de Proyectos. Bogotá, D.C.:
ICONTEC.
International Organization for Standardization. (2012). Guidance on Project Management
ISO 21500. Geneva: ISO.
International Project Management Association - IPMA. (2015). Individual Competence
Baseline for Project, Programme & Portfolio Management V. 4.0. Nijkerk, The
Netherlands: IPMA.
Project Management Institute. (2020). Ahead of the curve: forgoing a future-focused
culture. Pulse of the Profession 2020.
Wysocki, R. K. (2014). Effective Project Management: Traditional, Agile, Extreme.
Seventh Edition. Indianapolis, Indiana: John Wiley & Sons.