MPM - A1 - Mod1 - Direccion Estrategica

Módulo
Dirección Estratégica
Módulo
Dirección Estratégica
1. DIRECCIÓN ESTRATÉGICA DE PROYECTOS, LA EMPRESA Y SU ENTORNO...... 03
1.1. INTRODUCCIÓN.............................................................................................. 03
1.2. LA EMPRESA, DIRECCIÓN ESTRATÉGICA Y POLÍTICA DE EMPRESA ................. 04
1.2.1. LA GESTIÓN ESTRATÉGICA...................................................................... 06
1.2.2. EL MAPA ESTRATÉGICO .......................................................................... 08
1.3. LA GESTIÓN DE PROYECTOS Y LA EMPRESA................................................... 11
1.3.1. ORIGEN DE LA GESTIÓN DE PROYECTOS................................................. 13
1.3.2. ¿QUÉ ES UN PROYECTO?......................................................................... 15
1.3.3. DEFINICIÓN DE PROYECTO...................................................................... 19
1.3.4. PROYECTO, PROGRAMA, PORTAFOLIO.................................................... 21
1.3.5. EL EQUILIBRIO ENTRE EL TIEMPO, EL COSTE Y EL ALCANCE..................... 23
1.4. IMPLEMENTACIÓN DE LA ESTRATEGIA A TRAVÉS DE PROYECTOS .................. 24
1.4.1. ORGANIZACIONES REFERENTES EN LA GESTIÓN DE PROYECTOS............. 24
1.4.2. ESTÁNDARES DE GESTIÓN DE PROYECTOS.............................................. 27
1.5. CULTURA Y ESTILOS ORGANIZATIVOS. PROYECTOS: CAMBIO
ORGANIZATIVO ..................................................................................................... 31
1.5.1. INFLUENCIA DE LA ORGANIZACIÓN EN LA DIRECCIÓN DE PROYECTOS... 31
1.5.2. FACTORES AMBIENTALES DE LA EMPRESA............................................... 39
1.5.3. PARTES INTERESADAS EN EL PROYECTO.................................................. 40
1.6. RESUMEN........................................................................................................ 43
2. MARCO DE REFERENCIA PARA LA DIRECCIÓN DE PROYECTOS........................ 44
2.1. IMPORTANCIA DE LA GESTIÓN DE PROYECTOS ............................................. 44
2.2. METODOLOGÍAS DE DIRECCIÓN DE PROYECTOS............................................ 45
2.2.1. METODOLOGÍAS PREDICTIVAS DE GESTIÓN DE PROYECTOS .................. 49
2.2.2. PMBOK.................................................................................................... 50
2.2.3. PRINCE2.................................................................................................. 50
2.2.4. LAS TEMÁTICAS DE PRINCE2................................................................... 52
2.2.5. PMBOK VERSUS PRINCE2 ........................................................................ 54
2.2.6. POR QUÉ LAS METODOLOGÍAS ÁGILES DE GESTIÓN DE PROYECTOS...... 56
2.2.7. EL MANIFIESTO ÁGIL ............................................................................... 57
2.2.8. LOS DOCE PRINCIPIOS DEL MANIFIESTO ÁGIL ......................................... 58
2.2.9. METODOLOGÍAS ÁGILES......................................................................... 60
2.3. CICLO DE VIDA DEL PROYECTO...................................................................... 64
2.3.1. CICLO DE VIDA DEL PRODUCTO Y CICLO DE VIDA DEL PROYECTO......... 69
2.4. FASES DEL PROYECTO..................................................................................... 71
2.5. PROCESOS DE LA DIRECCIÓN DE PROYECTOS................................................ 73
2.5.1. GRUPO DE PROCESOS DE INICIO............................................................. 77
2.5.2. GRUPO DE PROCESOS DE PLANIFICACIÓN............................................... 78
2.5.3. GRUPO DE PROCESOS DE EJECUCIÓN..................................................... 79
2.5.4. GRUPO DE PROCESOS DE MONITOREO Y CONTROL................................ 80
2.5.5. GRUPO DE PROCESOS DE CIERRE............................................................ 81
2.6. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE PROYECTOS....................... 82
2.7. RESUMEN........................................................................................................ 87
BIBLIOGRAFÍA........................................................................................................... 88
Centro Europeo de Postgrado Módulo. Dirección Estratégica
1. Dirección estratégica de proyectos,

la empresa y su entorno
“Podemos definir la gestión de proyectos como el proceso de pla-
neación y manejo de tareas y recursos con el fin de cumplir con los
objetivos definidos para la implementación de un proyecto nuevo
en la empresa, y la comunicación permanente del progreso y avan-
ce de sus resultados (Vértice, 2008).”
1.1. Introducción
Así como a nivel personal vivimos rodeados de proyectos que debemos gestionar adecua-
damente, en todas las organizaciones confluyen multitud de proyectos de diversa índole y
complejidad. Desde proyectos como la implantación de un sistema de calidad conforme a
un estándar reconocido hasta proyectos realmente complejos, en los que la organización
invierte millones de euros, como la puesta en marcha de una nueva línea o área de fabri-
cación o el desarrollo de un software a medida.
Del mismo modo que nuestros proyectos personales son importantes porque afectan a
nuestras prioridades vitales, la adecuada gestión de los proyectos en el ámbito empresa-
rial es crítica para la organización porque, en muchos casos, estos proyectos están vincu-
lados a objetivos que son estratégicos:
• Para acceder a un determinado mercado internacional (objetivo) es necesario dis-

poner de una certificación de calidad en concreto (proyecto).
• Para cumplir los compromisos con los clientes (objetivo), la nueva línea de fabrica-
ción debe estar operativa (proyecto).
• Para culminar la absorción de otra compañía (objetivo), el nuevo software a medi-

da debe estar finalizado (proyecto).
03
1.2. La empresa, dirección estratégica y política de empresa

En la historia podemos encontrar ejemplos de proyectos realmente impresionantes por la
grandiosidad de su resultado, pero también por la complejidad que supuso su realización:
desde el Coliseo de Roma, el Taj Mahal en la India, la Gran Muralla china o las pirámi-
des de Egipto y México, hasta otros ejemplos más recientes como el Canal de Panamá,
el ferrocarril transiberiano de Rusia, el metro de Londres, el aeropuerto internacional de
Kansai en Japón, la Palma de Jumeirah en Dubai, o la Estación Espacial Internacional.
Los métodos con los que estos proyectos han sido diseñados, planificados, ejecutados y
controlados han sido diversos a lo largo de los siglos, aunque no ha sido hasta los últimos
50 años, desde la Segunda Guerra Mundial, que se han desarrollado los conceptos moder-
nos y sistemáticos de la Administración de Proyectos, así como los métodos, sistemas y
herramientas (Chamoun, 2002).
La utilización masiva de Internet en el ámbito personal y profesional a lo largo de las

últimas décadas ha contribuido a incrementar de forma exponencial la difusión de esta
gestión profesionalizada de los proyectos en todos los sectores. Sirva como ejemplo que
los miembros del Project Management Institute, PMI, han aumentado de 8.500 en 1990 a
más de 400.000 en el año 2013 a lo largo de 180 países (PMI, 2013).
Pero no son solo razones tecnológicas las que han contribuido a que la adecuada gestión
de proyectos cobre una especial relevancia en el escenario actual. Nos enfrentamos a un
entorno complejo y demandante, en el que las organizaciones deben abordar la gestión
de sus proyectos teniendo en cuenta los siguientes factores:
• Creciente complejidad de los sistemas organizativos, productivos y tecnológicos.
• Decrecientes recursos tanto económicos como de cualificación de personas.
• Multiculturalidad, convivencia entre diferentes nacionalidades, idiomas, culturas

y religiones.
• Múltiples subcontratistas colaborando, lo cual puede dificultar la adecuada coordi-

nación y comunicación entre ellos.
• Vidas operativas extendidas: la relación con el cliente se extiende durante toda la

vida útil del producto, más allá de su entrega.
04
• Creciente competencia industrial.
• Legislación cambiante y cada vez más exigente.
• Tecnologías en evolución.
• Costes crecientes.
• Continuos cambios en los requisitos, derivados de múltiples factores, entre ellos

el aumento de la exigencia por parte del cliente (cliente experto) y de la creciente
competencia.
Visualmente podemos resumirlo gráficamente en la siguiente figura:
Figura 1.1. El entorno actual

Fuente: Sols Rodríguez-Candela A, Fernández Fernández, I, Romero Yacobi, J. Gestión
integral de proyectos Unión de Editoriales Universitarias Españolas; 2013. p 22.
05
El reconocido gurú de la gestión Peter Drucker señala que la gestión existe por la ne-
cesidad de alcanzar los objetivos de la institución; la gestión debe comenzar con los re-
sultados pretendidos y debe organizar los recursos de la institución para alcanzar esos
resultados (Drucker, 2001).
En esta línea es necesaria una visión global para gestionar eficientemente los proyectos,
con la máxima garantía posible de que los objetivos de prestaciones técnicas serán alcan-
zados en plazo y dentro del presupuesto establecido (Rodríguez y otros, 2013).
Una adecuada metodología de dirección de proyectos puede servir de facilitador para

orientar los recursos de la organización hacia el cumplimiento de sus objetivos estratégi-
cos como empresa.
1.2.1. La gestión estratégica

Todas las empresas han tenido y tienen estrategias. La diferencia estriba en si estas cons-
tituyen el producto de ejercicios racionales y programados o si, por el contrario, está im-
plícita en la actuación de la empresa pero no obedece a un planteamiento formal (Brenes,
2004).
Este autor muestra la evolución de la historia empresarial en cuatro etapas claramente

diferenciadas:
• Cumplir el presupuesto: la primera fase podría estar constituida por la etapa ini-
cial del empresario moderno durante la revolución industrial y hasta la Segunda
Guerra Mundial, pues las actividades típicas de planificación o planeamiento (el
control operativo, el presupuesto anual y el enfoque) eran principalmente funcio-
nales.
• Planificar para el futuro: la segunda fase podría iniciarse con los movimientos de
posguerra representados por una planificación más eficaz para el crecimiento, el
análisis ambiental y los planes con cobertura de más de un período con asignación
estática de recursos.
06
• Pensar en términos abstractos: los años ochenta, la crisis petrolera y otros facto-
res podrían marcar el inicio de la tercera fase con una clara muestra de atención
y creciente respuesta a los mercados y a la competencia, complementado por un
análisis de la situación y una valoración competitiva como base para elegir las
alternativas estratégicas. Esta fase puede perfectamente considerarse la de mayor
impacto, pues marca la nueva era de los negocios donde el cliente, el entorno y la
competitividad han ocupado el primer lugar para los tomadores de decisiones.
• Crear el futuro: la cuarta fase no presenta grandes diferencias, sino más bien nue-
vos ingredientes importantes como la creatividad y la flexibilidad que apuntan
hacia el objetivo planteado: la creación del futuro. Esta es la fase actual, la fase de
mayor eficacia que la gestión de planificación o planificación formal empresarial
ha alcanzado.
Fase 1 Fase 2 Fase 3 Fase 4
Planeamiento Planeamiento basado Planeamiento con Administración

financiero básico en la producción orientación externa estratégica
Instrumentación de
todos los recursos
Creciente eficacia Creciente respuesta para crear ventajas
del planeamiento a los mercados y a la competitivas
competencia
Planeamiento más
eficaz para el creci- Marco de planea-
Análisis completo de la miento escogido
miento situación y valoración
Control operativo estratégicamente
competitiva
Análisis ambiental
Proceso de planea-
Presupuesto anual Evaluación de opciones miento creativo y
Planes plurianuales estratégicas flexible
Enfoque funcional
Asignación estática Asignación dinámica de Sistema y clima de
de recursos recursos valores de respaldo
Cumplir el Planificar para el Pensar en términos

Crear el futuro
presupuesto futuro abstractos
Figura 1.2. Evolución de la historia empresarial (objetivos)
Fuente: Brenes Bonilla L. Dirección Estratégica para Organizaciones
Inteligentes. Ágora; 2004. p 15
07
Crear el futuro implica gestionar de forma proactiva la estrategia de la organización, para

que esta llegue a alcanzar sus objetivos. El concepto de gestión estratégica permite la
realización de lo que se ha dado en llamar proyectos estratégicos. La gestión de proyectos
estratégicos inserta los conceptos de gestión estratégica en la organización, pero rom-
piendo la estructura tradicional de esta. A través del proyecto estratégico le damos un
principio y un fin a los procesos para que la realización de los objetivos corporativos ten-
ga sentido global. Si una organización genera un plan estratégico en el cual se establecen
grandes líneas de acción para la organización y desea llevarlo a la práctica, una forma de
hacerlo es estableciendo proyectos estratégicos y manejando dentro de ellos procesos
participativos y abiertos de gestión estratégica (Betancourt, 2002).
A modo de ejemplo, y por ilustrar la relación entre la gestión estratégica y los proyectos
estratégicos, podemos decir que la gestión estratégica se comporta como el cerebro, asu-
miendo la inteligencia del negocio, mientras que la gestión de proyectos se convierte en
las piernas y brazos que ejecutan. La gestión de proyectos se convierte, en este caso, en
el “modus operandi”. En abril de 2015, Apple realizó el lanzamiento mundial del reloj in-
teligente de pulsera Apple Watch conforme a su estrategia para diversificar su mercado.
Entre sus proyectos estratégicos se encuentra el desarrollo de este tipo de dispositivos
móviles con el objetivo de captar la mayor cuota posible de un mercado potencial estima-
do para 2019 de alrededor de 112 millones de artefactos de este tipo.
1.2.2. El mapa estratégico

Los mapas nos dan la facilidad de guiarnos de un punto a otro con una cierta garantía de
que podremos llegar a nuestro destino de la mejor forma posible. Los mapas, de forma
sencilla, nos indican todo aquello que necesitamos saber para poder tomar decisiones:
autopista, carretera nacional o local, rutas alternativas, puertos… Si el mapa es correcto y
tomamos las decisiones adecuadas, alcanzaremos nuestra meta.
Análogamente, un mapa estratégico debe proporcionar un modo simple, coherente y uni-

forme para describir la estrategia de una empresa con el fin de poder establecer objetivos
e indicadores y, lo que es más importante, poderlos gestionar. De este modo, el mapa es-
tratégico se convierte en el eslabón que faltaba entre la formulación de la estrategia y su
ejecución (Martínez y Milla, 2005).
Para que esto sea así, el mapa estratégico debe cumplir, según Kaplan y Norton (2004),
varios principios básicos:
• La estrategia supone el equilibrio de fuerzas contradictorias. La consecución

de rendimientos a largo plazo (necesario para asegurar un crecimiento sostenible
del valor para los accionistas) entra en conflicto con la obtención de buenos resul-
tados financieros a corto plazo.
08
• La correcta definición de la proposición de valor al cliente es crítica en el pro-

ceso estratégico. Si la satisfacción de los clientes es la fuente de creación de valor
sostenible, la correcta definición de los clientes objetivo y de la proposición de
valor para satisfacerlos es la dimensión más importante de la estrategia.
• El valor nace en los procesos internos. La perspectiva financiera y del cliente

son perspectivas “externas” que describen resultados respecto a lo que la empresa
espera lograr (aumento del valor de los accionistas vía crecimiento de ingresos o
mejora de la productividad, etc.).
Por el contrario, los objetivos relacionados con las perspectivas internas y de ca-
pacidades estratégicas se corresponden con el ámbito “interno” de la empresa, de-
biendo definir de qué forma la empresa pondrá en práctica su estrategia: gestión
de operaciones, gestión de clientes, innovación, procesos reguladores y sociales.
• La estrategia debe relacionarse con todos los procesos internos para ser inte-
gral. Las estrategias deben ser integrales en el sentido de incorporar, al menos, un
tema estratégico de cada uno de los cuatro grupos internos.
• El valor de los activos intangibles nace de su capacidad para ayudar a la im-

plantación de la estrategia. La cuarta perspectiva del mapa estratégico, la de ca-
pacidades estratégicas, describe los activos intangibles de la empresa y la función
que tienen en la estrategia. Los activos intangibles se pueden clasificar en tres
categorías: capital humano, capital de información y capital organizativo. Ninguno
de estos activos intangibles tiene un valor que se pueda medir por separado o de
forma independiente. El valor de estos activos intangibles nace de su capacidad
para ayudar a la empresa a poner en práctica su estrategia.
09
La representación visual del mapa estratégico propuesto por Kaplan y Norton, también
conocido como Cuadro de Mando Integral (CMI) o Balanced Scorecard, se muestra a
continuación:
Figura 1.3. El mapa estratégico de Kaplan y Norton
Fuente: Ventura J. Análisis estratégico de la empresa. Paraninfo; 2006. p 65
Disponer de un mapa estratégico no es en sí mismo una garantía de éxito. Es fundamen-

tal, del mismo modo que sucede con los mapas tradicionales en papel, que estén correcta-
mente realizados. Una decisión correcta sobre un mapa equivocado nos llevará a un lugar
que, seguro, no es el deseado.
Para elaborar el mapa estratégico según el planteamiento de Kaplan y Norton es conve-

niente tener en cuenta las siguientes consideraciones (Francés, 2006):
• Estrategia genérica y temas estratégicos: su elección constituye el punto crítico,

ya que marca las bases sobre las que se tomarán el resto de decisiones, constitu-
yendo por tanto los cimientos del mapa estratégico. Detroit Automobile Company,
fundada por Henry Ford, quebró al definir como estratégica la investigación y me-
jora de los prototipos de automóviles en lugar de intentar vender coches. Posterior-
mente, Henry Ford fundó con éxito Ford Motor Company.
10
• Perspectiva de accionistas: los accionistas esperan que se incremente el valor de

la inversión que han realizado y generar beneficio. Una empresa es, por definición,
una organización con ánimo de lucro, y como tal así lo esperan sus accionistas. En
las entidades públicas o sin ánimo de lucro, los accionistas o partes interesadas
también esperan que se cumplan los objetivos fundacionales; es el caso de hospi-
tales públicos, asociaciones, agrupaciones o colectivos.
• Perspectiva de clientes: la personalidad de cada empresa viene dada por su pro-

puesta de valor al cliente y a partir de ahí se establecen los objetivos estratégicos.
Esta impronta que añade la propuesta de valor al cliente se evidencia de forma
clara en la industria del automóvil, en la que cada fabricante tiene su propia seña
de identidad: seguridad, diseño, precio, eficiencia, prestigio, sostenibilidad…
• Perspectiva de procesos: deben explicitarse de forma clara los objetivos, indica-

dores e iniciativas para cada uno de los procesos, siempre de forma alineada con la
estrategia genérica de la organización.
• Perspectiva de aprendizaje y crecimiento: los recursos con los que cuenta la or-
ganización (personas, tecnología, cambio organizacional…) deben empujar y hacer
palanca en la dirección marcada por la estrategia.
Como veremos más adelante, la gestión de proyectos debe estar alineada y ser coherente
con la estrategia de la organización para que sirva como catalizador de la misma.
1.3. La gestión de proyectos y la empresa

Todas las empresas y administraciones tienen que acometer proyectos, sin perjuicio de
que una gran parte de sus trabajos se refiera al desarrollo de actividades de naturaleza
continua. Todas las empresas emprenden con mayor o menor frecuencia proyectos de
las características mencionadas. Para algunas, el proyecto tendrá carácter de excepción
(sería, por ejemplo, el caso de una empresa que quiere lanzar un nuevo producto, o la que
quiere iniciar su actividad en Internet); para otras, trabajar con proyectos es algo inheren-
te a su propia actividad principal, como una empresa constructora (Vértice, 2008).
Pero la gestión de proyectos, según este autor, no es hoy algo reducido al ámbito de las
empresas constructoras, de ingeniería o de consultoría, sino un conjunto de métodos de
gestión que toda empresa debe emplear cuando se enfrenta a operaciones singulares si
no quiere verse abocada al fracaso.
Se pueden citar muchos ejemplos que responden a la noción de proyecto expuesta en

este punto, y que pueden ir desde el lanzamiento de un nuevo producto al mercado o la
introducción de Internet en la empresa hasta construir una obra pública; la lista sería in-
terminable, pero es suficiente comprobar estos hechos:
11
• Los proyectos son un tipo de actividad específica con la que toda empresa o admi-
nistración se ha de enfrentar con mayor o menor frecuencia.
• El proyecto tiene unas características especiales muy diferentes a las del resto de
las actividades continuas.
• Cada vez es más frecuente la necesidad de acometer proyectos al vivir en un mun-

do cambiante al que hay que adaptarse con rapidez y agilidad.
Del mismo modo que un negocio puede beneficiarse de un proyecto bien gestionado, es
posible que resulte gravemente perjudicado si el proyecto fracasa o sufre una ejecución
defectuosa. Roberts (2008) cita algunos proyectos que no cumplieron sus expectativas y
sobre los que podemos aprender mucho:
• Telescopio espacial Hubble. Lanzado de 1990, de este extraordinario proyecto de

la NASA se esperaba obtener imágenes del universo con un detalle jamás visto
hasta entonces. A pesar de superar tremendos retos tecnológicos, un instrumento
de medida mal calibrado que se utilizó durante el pulimentado del espejo principal
hizo que todas las imágenes saliesen borrosas. Como resultado, la agencia espacial
estadounidense sufrió una importante merma de su imagen pública, y tuvieron
que pasar tres años para que su buena reputación se restableciera después de ha-
ber hecho las reparaciones pertinentes.
• Proyecto de mejora del Departamento de Tráfico. El Departamento de Tráfico

del estado de Washington puso en marcha un proyecto de cinco años de duración,
con un coste de 42 millones de dólares, para informatizar los procesos de matri-
culación de vehículos y renovación de permisos. El presupuesto se desbordó, los
requisitos fueron modificados mientras el proyecto estaba en curso, e incluso si
este se hubiese completado, habría quedado obsoleto antes. A los siete años, y con
40 millones de dólares gastados, se canceló el proyecto.
• Parlamento escocés. Costó diez veces más de lo proyectado. Además, se puede

argüir que ese dinero hubiera estado mejor invertido en otro proyecto, más útil
para los ciudadanos.
12
• Túnel bajo el Canal de la Mancha. Constituye un magnífico logro tecnológico,

que, sin embargo, no fue capaz de generar el suficiente interés de los usuarios para
asegurar su futuro comercial. Cabe preguntarse si, aún reconociendo las numero-
sas dificultades técnicas que se superaron, el proyecto se llevó adelante porque
hacía falta o simplemente porque era factible.
• Aeropuerto Internacional de Kansai. Este ambicioso proyecto, terminado en 1994

sobre una isla artificial en la ciudad japonesa de Osaka, estuvo plagado de especu-
laciones sobre si los arquitectos habían contado o no con que la isla se hundiría por
su propio peso y si habían subestimado el grado en que lo haría. Seis años después
de inaugurarse, las autoridades tuvieron que invertir en medidas de protección
contra las inundaciones, que al ser parcialmente financiadas con una subida de
las tasas de aterrizaje provocaron una gran disminución del tráfico. De modo que,
a pesar de que el proyecto superó tremendos retos (incluido el que representó el
terremoto de Kobe), las autoridades tienen que afrontar una enorme deuda y, en las
mentes de muchos, Kansai será recordado como el aeropuerto que “se ha hundido”.
Todos los organismos que se hallaban detrás de las obras citadas tuvieron que enfrentar-
se a problemas de diversos tipos porque no supieron ver que la gestión de proyectos iba
a afectar a sus negocios.
1.3.1. Origen de la gestión de proyectos

Aunque como se ha señalado anteriormente si bien las técnicas de administración de
proyectos se utilizan desde hace varios siglos, el auge y desarrollo de herramientas espe-
cíficas comenzó a profundizarse a partir de 1960.
Lledó (2012) desarrolla a continuación, de forma simplificada, los criterios que a lo largo
de las últimas décadas se han considerado clave para considerar que un proyecto ha sido
un éxito:
En la década de 1960 el éxito de un proyecto se definía solo en función a su calidad. O sea,

un proyecto que cumpliera con los objetivos de calidad preestablecidos era considerado
como exitoso.
Luego, a partir de la década de 1980, se definía a un proyecto como exitoso, cuando, ade-
más de cumplir con la calidad, cumplía con los plazos y presupuesto según el plan del
proyecto.
13
Como si esto fuera poco, a partir de 1990 no alcanza con cumplir la calidad, plazos y
presupuesto para el éxito del proyecto, sino que además de estos objetivos mínimos es
necesario que el proyecto cumpla con la “satisfacción del cliente”. ¿De qué serviría un
proyecto de una calidad excepcional que se finalizó en el plazo previsto utilizando los
recursos preestablecidos si luego nadie compra los productos de ese emprendimiento?
A estas cuatro características de proyecto exitoso deberíamos agregar también la “soste-

nibilidad o cuidado”. O sea, no podríamos definir como exitoso un proyecto que cumplió
con parámetros técnicos de calidad, cronograma, presupuesto y satisfacción del cliente si
no fuimos capaces de preservar el medio ambiente o a los miembros del equipo durante
la ejecución del proyecto.
Otros autores, como es el caso de Chamoun (2002), señalan que, de acuerdo con un artí-
culo sobre la evolución de la administración de proyectos elaborado por Harold Kerzner,
pueden identificarse tres periodos en función de la necesidad del éxito en proyectos, así
como las habilidades requeridas por el director del proyecto:
Habilidades requeridas por el

Período Definición del éxito
director de proyecto
• En este período medimos el éxito prin-

cipalmente en términos técnicos
• Con base en estas expectativas, las
• En dicho período, y aún en casos ac- habilidades requeridas por el encarga-
tuales, al contratar el desarrollo de un do del proyecto serían más técnicas,
sistema electrónico o el diseño y cons- enfocadas a la experiencia y conoci-
Período mientos específicos sobre el tipo de
tradicional trucción de nuestra residencia, consi-
deramos que generalmente no cum- proyecto.
(1960-1985)
pliremos con el tiempo de entrega y el
presupuesto, y para considerar exitoso • El estilo de liderazgo es autoritario,
el proyecto será suficiente que funcione efectuado con la persona de más ex-
como esperamos y que la calidad sea lo periencia.
primordial, ya que utilizaremos el pro-
ducto del proyecto por un largo tiempo.
• El éxito se mide en función del apego

al tiempo, costo y desempeño de cali- • Las habilidades técnicas anteriores no
dad técnica. son suficientes, requerimos el manejo
Período de efectivo de equipos humanos para lo-
renacimiento • En dicho lapso, y aún en la actualidad, grar los nuevos requerimientos.
(1985-1993) no es suficiente que el proyecto cumpla
con los requerimientos técnicos si no se • El estilo de liderazgo es más parti-
termina en el tiempo establecido y den- cipativo que en el período tradicional.
tro del presupuesto.
14
Habilidades requeridas por el

Período Definición del éxito
director de proyecto
• Para lograr la aceptación por parte

del cliente, las habilidades requeridas
• Medimos el éxito en función del apego son conocimiento del negocio, adminis-
al tiempo, costo, desempeño y acepta- tración de riesgos e integración.
ción del cliente.
• No es suficiente el conocimiento, ex-
Período • Estamos conscientes de que, aunque periencia técnica y manejo de equipos
moderno entreguemos el proyecto dentro de pre- humanos, requerimos habilidades de
(1993- a la supuesto, a tiempo y con la calidad téc- liderazgo, comunicación, hacer que las
fecha) nica estipulada, si el cliente no queda cosas sucedan, negociación, y solución
satisfecho, no podemos considerar exi- de problemas, entre otras.
toso el proyecto.
• El estilo de liderazgo considera el fa-
cultamiento, el liderazgo situacional y
la integración de equipos, entre otras
técnicas.
Figura 1.4. Evolución de la Administración de Proyectos
Fuente: Chamoun, Yamal. Administración Profesional de Proyectos.
La Guía, McGraw-Hill Interamericana; 2002
1.3.2. ¿Qué es un proyecto?

Podemos definir la gestión de proyectos como el proceso de planeación y manejo de ta-
reas y recursos con el fin de cumplir con los objetivos definidos para la implementación
de un proyecto nuevo en la empresa, y la comunicación permanente del progreso y avan-
ce de sus resultados (Vértice, 2008).
La gestión de proyectos requiere por tanto la coordinación de tiempo + equipo + dinero +

tareas + personas, aunque como veremos más adelante, adicionalmente a los anteriores
también hay otros condicionantes en la ejecución del proyecto que hay que coordinar
adecuadamente: integración, calidad, comunicaciones, riesgos y compras.
Brown Boveri (Vértice, 2008) aporta una interesante definición de proyecto, identificándo-
lo como un trabajo no repetitivo que ha de planificarse y realizarse según unas especifica-
ciones técnicas determinadas y con unos objetivos, costes, inversiones y plazos prefijados.
También se define un proyecto como un trabajo de un volumen y complejidad considera-
bles que ha de realizarse con la participación de varios departamentos de la empresa y tal
vez con la colaboración de terceros.
15
La ejecución de un conjunto de actividades no constituye en sí misma un proyecto. Para

que este conjunto de actividades pueda ser considerado como tal, además debe:
• Implicar un cierto grado de complejidad: esta complejidad puede ser derivada

de su propia naturaleza (una obra de construcción) o de los condicionantes que le
rodean, por ejemplo la ubicación en la que se realiza, el entorno multicultural, o las
restricciones de plazos o costes. Es decir, es un proyecto porque existe un grado de
dificultad para gestionar adecuadamente los recursos asociados.
• Tener un carácter no repetitivo: cada proyecto es único, aunque pueda parecerse

a otros realizados anteriormente. Si construyésemos el mismo puente en cien luga-
res diferentes a lo largo del mundo, podríamos hablar de cien proyectos diferentes
porque existe una serie de condicionantes que influyen de forma determinante: el
terreno, la climatología, las personas, los proveedores o la cultura que hacen que el
éxito no esté garantizado por el mero de hecho de reproducir lo ejecutado en otro
proyecto.
• Afectar a varias personas: un proyecto no se realiza de forma individual, sino

que implica que varias personas interactúen en la ejecución del mismo de forma
coordinada.
Además de las anteriores, las características más relevantes que deben cumplirse para
que una serie de actividades puedan considerarse como un proyecto según Domingo
(2000) son:
• Persecución de uno o varios objetivos: las actividades aisladas no constituyen,

por sí solas, un proyecto. Para que exista un proyecto, debe existir una coordina-
ción de actos orientados a la consecución de uno o varios objetivos, integrados
entre sí y estructurados, tanto de índole técnica como económica. En general, el
objetivo de un proyecto es satisfacer un conjunto de requisitos técnicos, a un coste
dado, en las condiciones más eficientes.
• Actividades planificadas, ejecutadas y supervisadas: la coordinación de activi-

dades anteriormente mencionada es condición sine qua non para que a las mismas
se las pueda calificar de proyecto. Actividades aisladas, independientes, carentes
de interrelación entre ellas, no constituyen un proyecto. Un proyecto, por el contra-
rio, exige que exista vinculación entre las actividades, puesto que persiguen un ob-
jetivo común. Esa vinculación debe plasmarse en forma de planificación (técnica,
temporal y económica), cuya correcta ejecución supervisada es clave para el éxito
o el fracaso del proyecto.
16
• Disponibilidad limitada de recursos: el proceso proyectual implica la búsqueda

de la eficiencia en el uso de los recursos para obtener el resultado perseguido. Si
los recursos son ilimitados, desaparece el concepto de eficiencia, y con él la natu-
raleza proyectual de las actividades.
• Limitado en el tiempo: este propio marco temporal, que puede ser desde días
hasta décadas, lleva a que los proyectos tengan, además de un inicio establecido,
también un final que podrá ser determinado cuando se produzcan alguna de estas
situaciones:
• Se han cumplido los objetivos marcados.
• Los objetivos marcados no se han cumplido o no pueden cumplirse.
• La necesidad que dio origen al proyecto ya no existe, bien sea por razones políti-
cas, económicas, sociales, coyunturales, etc.
• El cliente, o algunas de las partes interesadas, bien sea patrocinador o líder, de-
sea terminar el proyecto.
Aunque el proyecto tenga una duración determinada en el tiempo, esto no implica

que deba suceder lo mismo con sus resultados, que pueden perdurar con carác-
ter indefinido, como veíamos en ejemplos mencionados anteriormente: Coliseo de
Roma, el Taj Mahal en la India, la Gran Muralla china, las pirámides de Egipto y
México, el Canal de Panamá, el ferrocarril transiberiano de Rusia, el metro de Lon-
dres o la Palma de Jumeirah en Dubai.
• Con resultado único: retomar un trabajo finalizado y repetir sus resultados no es

un proyecto. Un proyecto exige algo nuevo o único en su género, y no reproducir
resultados de otras actividades.
17
De forma esquematizada podemos identificar las características del proyecto como:
Características de un proyecto
Complejidad
No repititividad
Grupal
Objetivo claro
Coordinación de actividades
Limitación de recursos
Marco temporal
Resultado único
Figura 1.5. Características de un Proyecto
Fuente: elaboración propia
Todos estos conceptos son conceptualizados en la propia definición que el Project Mana-
gement Institute hace en la Guía para la Gestión de Proyectos del PMBOK (PMI, 2013) en
la que establece que el proyecto es un esfuerzo temporal que se lleva a cabo para crear un
producto, servicio o resultado único.
Por tanto, la consecución de un proyecto puede generar (PMI, 2013):
• Un producto, que puede ser un componente de otro elemento, una mejora de un

elemento o un elemento final en sí mismo.
• Un servicio o la capacidad de realizar un servicio (p.ej., una función de negocio que

brinda apoyo a la producción o distribución).
• Una mejora de las líneas de productos o servicios existentes (p.ej., un proyecto Seis
Sigma cuyo objetivo es reducir defectos).
• Un resultado, tal como una conclusión o un documento (p.ej., un proyecto de inves-

tigación que desarrolla conocimientos que se pueden emplear para determinar si
existe una tendencia o si un nuevo proceso beneficiará a la sociedad).
18
Los ejemplos de proyectos, incluyen entre otros:
• El desarrollo de un nuevo producto, servicio o resultado.
• La implementación de un cambio en la estructura, los procesos, el personal o el

estilo de una organización.
• El desarrollo o la adquisición de un sistema de información nuevo o modificado

(hardware o software).
• La realización de un trabajo de investigación cuyo resultado será adecuadamente

registrado.
• La construcción de un edificio, planta industrial o infraestructura.
• La implementación, mejora o potenciación de los procesos y procedimientos de

negocios existentes.
1.3.3. Definición de proyecto

Existen prácticamente tantas definiciones de proyecto como autores y obras al respecto en
la literatura (Domingo, 2005). Aunque en el punto anterior hemos visto las características
que debe tener un proyecto para ser considerado como tal, conviene hacer una breve re-
visión de algunas definiciones interesantes de qué es un proyecto (Cardoza y otros, 2011).
De acuerdo con la Norma Internacional ISO 10006 (2003), un proyecto es “un proceso
único que consiste en un conjunto de actividades coordinadas y controladas con fechas
de inicio y finalización, llevadas a cabo para lograr un objetivo conforme con requisitos
específicos y requerimientos específicos, incluyendo las limitaciones de tiempo, coste y
recursos”.
Guerra et al. (2002) definen un proyecto “como una transformación que realiza un deter-
minado grupo de individuos, en un plazo de tiempo definido, de una idea, que se establece
basándose en unos requisitos o necesidades, en una realidad, producto o servicio, dentro
de un contexto tecnológico determinado y utilizando recursos limitados y con carácter
temporal”.
De Cos (2007) indica que un proyecto es “la combinación de todos los recursos necesa-
rios, reunidos en una organización temporal, para la transformación de una idea en una
realidad”.
Kerzner (2006) señala que un proyecto es “cualquier serie de actividades y tareas que
tienen un objetivo específico para ser completado con ciertas especificaciones, tienen
unas fechas de inicio y fin definidas, tienen límites de financiación, consumen recursos
humanos y no humanos (dinero, gente y equipo) y son multifuncionales”.
19
Existen a nivel mundial diversas organizaciones referentes en dirección de proyectos

como veremos con detalle más adelante. Resulta interesante revisar cómo algunas de es-
tas organizaciones definen o interpretan el término proyecto y cómo cada una de ellas da
especial protagonismo a determinados matices relacionados con dicho término.
La IPMA (International Project Management Association, 2009), menciona que un pro-

yecto es “una operación limitada en tiempo y coste para materializar un conjunto de en-
tregables definidos (el alcance para cumplir los objetivos el proyecto) de acuerdo con
unos requisitos y estándares de calidad”.
La definición del PMI (Project Management Institute, 2008), aporta de forma adicional a
la anterior la matización de la singularidad que aporta el proyecto, identificándolo como
“un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado
único”.
La Asociación Japonesa para la Gestión de Proyectos, (Project Management Association

of Japan, P2M 2005), enfoca sin embargo la gestión del proyecto como un “compromiso
de creación de valor sobre la base de un procedimiento específico que se completa en
un plazo determinado o acordado, y bajo restricciones que incluyen los recursos y las
circunstancias externas”. Aparecen en esta definición algunos matices interesantes que
no hemos encontrado en las definiciones anteriores: el proyecto debe crear valor, lo que
nos obligará a centrarnos en los requerimientos y expectativas de las partes interesadas,
y habla también de restricciones. La gestión del proyecto nos obligará a decidir y a dar
más importancia a algunos aspectos, por ejemplo plazo, en detrimento de otros, como son
los costes.
Finalmente, PRINCE2 (Projects in Controlled Environments 2, 2009), especifica en rela-

ción con el proyecto que es “un entorno de gestión que se crea con el propósito de entre-
gar uno o más productos de negocio de acuerdo al caso de negocio especificado”. Puesto
que se trata, como bien señala, de un entorno de gestión, deberán aplicarse una serie de
herramientas y metodologías para su tratamiento de forma sistematizada.
20
Dato importante
Peter Drucker señala que la gestión existe por la necesidad de alcanzar los obje-
tivos de la institución; la gestión debe comenzar con los resultados pretendidos y
debe organizar los recursos de la institución para alcanzar esos resultados (Druc-
ker, 2001).
1.3.4. Proyecto, Programa, Portafolio

En función del tamaño, complejidad, organización y tipos de proyectos podemos encon-
trarnos que estos se agrupan generando a su vez programas y portafolios. Básicamente,
podemos definir estos niveles de agrupación como:
• Portafolio: conjunto de proyectos, programas, subconjuntos de portafolios y ope-

raciones que se gestionan como un grupo para alcanzar determinados objetivos
estratégicos (PMI, 2013), aunque no tienen por qué tener relación entre sí. Se trata,
por tanto, de la planificación de proyectos al más alto nivel y con una directa rela-
ción con los objetivos estratégicos.
• Programas: agrupan un conjunto de proyectos relacionados entre sí. El programa

espacial Apolo de la NASA para llevar una misión tripulada a la luna estuvo cons-
tituido por posiblemente multitud de proyectos que se encargaron de desarrollar
todo lo necesario para llevar esta hazaña a cabo. Aunque cada uno de estos proyec-
tos fuese independiente: la construcción de la nave, el diseño del traje, las comu-
nicaciones, la selección y preparación de los astronautas… Todos estos proyectos
estaban relacionados entre sí con un único objetivo: conseguir que el 21 de julio de
1969 Neil Armstrong fuese el primer hombre en pisar la luna.
Continuando con este ejemplo, los programas de misiones tripuladas son uno más de los
que constituyen el portafolio o cartera de la NASA junto con otros programas tan dispares
como los programas no tripulados, los programas de investigación científica, los progra-
mas de desarrollo de nuevas tecnologías espaciales o la investigación aeronáutica. Todos
estos programas están alineados con los objetivos estratégicos de la NASA, aunque no
tiene por qué existir una vinculación directa entre unos y otros, a pesar de que puedan
compartir recursos materiales, humanos o económicos.
A modo de resumen simplificado, podemos encontrar en la siguiente tabla (Sols et al.,

2013) las principales características que identifican y diferencian la gestión de proyectos,
programas y portafolios o carteras:
21
ÁMBITO
PROYECTO PROGRAMA PORTAFOLIO O CARTERA
ASPECTO
Existe un objetivo y un al-

Todos los proyectos de la
cance bien definidos, que
cartera tienen un objetivo
Objetivo Existe un objetivo y un son la unión y la sinergia
que debe estar alineado con
y alcance alcance bien definidos. de los objetivos de los pro-
los de la empresa u organi-
yectos que integren el pro-
zación.
grama.
La cartera de proyectos de la
empresa u organización se
gestiona de manera dinámi-
La planificación a nivel La planificación a nivel ca, según se van contratando
de proyecto es siem- programa es de más alto unos proyectos y cerrando
pre detallada, identi- nivel. Se identifican los ob- otros, teniendo siempre en
ficándose las activida- jetivos generales de cada cuenta los recursos disponi-
Planificación
des necesarias y los uno de los proyectos in- bles en la empresa. Los dis-
recursos requeridos dividuales que integren el tintos proyectos gestionados
para alcanzar los obje- programa, así como el mo- pueden no tener vínculo de
tivos establecidos. mento de ejecutarlos. objetivos entre sí, pero lo
normal es que compartan re-
cursos (humanos, materiales
y/o económicos).
Los gestores o jefes de Los gestores o jefes de

proyecto tienen asig- programa coordinan y
Los responsables de la em-
nados recursos y los gestionan a los jefes o
presa u organización asig-
gestionan para alcan- gestores de los proyectos
Gestión y nan los gestores o jefes de
zar los objetivos del integrantes del programa.
seguimiento proyecto y realizan el segui-
proyecto. Les compete Hacen un seguimiento de
miento de alto nivel de los
llevar a cabo el segui- alto nivel del cumplimiento
proyectos de la cartera.
miento detallado de de los objetivos específicos
los proyectos de cada proyecto.
El proyecto conclu-
ye satisfactoriamente
siempre que se alcan- El éxito de la empresa u or-
cen sus objetivos den- ganización se cimenta en la
tro de los plazos y del renovación constante de su
El programa se considera
presupuesto estableci- cartera o portfolio de proyec-
un éxito si todos los pro-
Éxito do. Ciertas desviacio- tos, en el sentido más amplio
yectos que lo integran ter-
nes en prestaciones, (número de proyectos, de
minan satisfactoriamente.
plazo y/o presupuesto clientes finales, importe glo-
pueden ser, en deter- bal, etc.) y en su satisfactorio
minadas ocasiones, cumplimiento.
admisibles para el
cliente final.
Figura 1.6. Diferencias entre proyectos, programas y portfolios o carteras
Fuente: Sols Rodríguez-Candela A, Fernández Fernández, I, Romero Yacobi, J.
Gestión integral de proyectos. Unión de Editoriales Universitarias Españolas: 2013. p. 24
22
1.3.5. El equilibrio entre el tiempo, el coste y el alcance

Una de las características que identifican inequívocamente los proyectos es que estos
deben ejecutarse en un marco de limitación de recursos (Summers, 2006). En este senti-
do, las restricciones más habituales a las que nos enfrentamos están relacionadas con el
tiempo, el coste y el alcance, las cuales son definidas y/o consensuadas con el cliente, y
por tanto difíciles de modificar de forma aleatoria.
Para ilustrar este concepto pongamos como ejemplo el diseño y la implantación de una
aplicación informática. Si en la fase de ejecución de la misma queremos reducir el plazo
de entrega al cliente, porque así nos lo ha requerido, disponemos de dos opciones: la pri-
mera es modificar el alcance, eliminando alguna funcionalidad accesoria o que no sea crí-
tica; la segunda opción es aumentar los recursos si fuese posible trabajar ciertas fases en
paralelo (suponiendo, por supuesto, que se dispusiera de personas cualificadas para ello).
Este caso, muy probablemente, implicaría un aumento de los costes asociados al proyecto.
A lo largo del módulo 3 se profundizará más en las restricciones que afectan al proyecto y
que nos obligan a ser conscientes de que un cambio en alguna de estas tres dimensiones
críticas afecta inevitablemente al resto, por lo que deben ser gestionadas adecuadamente
para que no afecten a la viabilidad del propio proyecto.
Figura 1.7. La triple restricción en la gestión de proyectos
23
1.4. Implementación de la estrategia a través de proyectos

Pümpin y García Echevarría (1993) señalan que toda estrategia con éxito debe contener
siempre aspectos innovadores, ya que trata de mejorar las actividades de la empresa y
asegurar el futuro de las mismas. Los nuevos conocimientos que hemos deducido a través
de las estrategias exigen que se pongan en marcha nuevas medidas. Los dos instrumen-
tos más adecuados son los planes de proyecto y los planes de acción.
Los planes de proyectos pueden desarrollarse cuando se trate de funciones amplias, com-
plejas y difícilmente perceptibles, y estén estrechamente vinculados a riesgos importan-
tes. Si ese no es el caso, probablemente la utilización de un plan de acción sea más que
suficiente en la mayoría de los casos. De hecho, por regla general, los planes de acción y
los planes de proyectos se encuentran, según Pümpin y García Echevarría (1993) en una
relación de al menos 5:1, incluso pueden llegar a 10:1. Esto implica que el 80 % o 90 % de
las funciones que se derivan de las nuevas estrategias pueden desarrollarse a través de
planes de acción, aunque evidentemente este porcentaje puede variar en función de la
naturaleza y situación particular de la organización.
1.4.1. Organizaciones referentes en la gestión de proyectos

A lo largo de este tema hemos señalado que la gestión profesionalizada de la adminis-
tración de proyectos es relativamente reciente, fechándose en los últimos 50 años, en los
que se han desarrollado los conceptos modernos y sistemáticos de la administración de
proyectos, así como los métodos, sistemas y herramientas.
Es interesante, por tanto, mencionar, aunque sea brevemente, las organizaciones a nivel
internacional más relevantes en la gestión de proyectos (Cardoza y otros, 2011) y que po-
demos resumir en estas cuatro:
• IPMA: International Project Management Association.
• PMI: Project Management Institute.
• PRINCE2: Projects in Controlled Environments 2.
• PMAJ: Project Management Association of Japan.
24
IPMA (International Project Management Association)
IPMA es la institución de dirección de proyectos más antigua del mundo. Creada en 1965,
es una federación de asociaciones nacionales profesionales de dirección de proyectos.
En el año 2001 estaba constituida por 28 asociaciones nacionales, elevándose este nú-
mero hasta 54 asociaciones en el año 2011. En España, la asociación que la representa es
AEIPRO, Asociación Española de Dirección e Ingeniería de Proyectos, creada en 1992 e
incorporada a IPMA en 1996.
AEIPRO dispone de un programa de Certificación en Dirección de Proyectos validado

por IPMA y acreditado por ENAC. Esta asociación organiza el International Congress
on Engineering Projects desde 1994, evolución del Congreso Nacional de Ingeniería de
Proyectos (1984).
PMI (Project Management Institute)
El Project Management Institute (PMI) es la principal organización mundial dedicada a

la dirección de proyectos. Desde su fundación en 1969, ha crecido hasta convertirse en la
mayor organización sin ánimo de lucro que reúne a profesionales en todo el mundo. Su
sede central está en Pensilvania, EE. UU., y cuenta con más de 200 capítulos en más de
125 países del mundo (PMI, 2015). El PMI se organiza a nivel mundial en capítulos con
identidad propia en la región que tienen asignada, y son responsables de la actividad del
PMI en una región geográfica determinada.
Su objetivo principal es establecer los estándares de la dirección de proyectos, mediante

la organización de programas educativos, y administrar de forma global el proceso de cer-
tificación de los profesionales. Tanto sus estándares como su certificación profesional han
sido reconocidos por las principales entidades gubernamentales y privadas del mundo.
La Guía del PMBOK, elaborada por el PMI, contiene el estándar, reconocido a nivel glo-
bal, y es la guía para la profesión de la dirección de proyectos con mayor difusión y segui-
miento internacional.
25
PRINCE2 (Projects in Controlled Environments 2)
PRINCE es un método de dirección de proyectos desarrollado en 1989 por la Central

Computer and Telecommunications Agency (CCTA), ahora parte de la Oficina de Comer-
cio Gubernamental del Reino Unido. Previsto inicialmente como una norma del gobierno
para la gestión de proyectos de Tecnología de la Información (TI).
PRINCE2 nace a partir de PRINCE y es publicado en 1996 como un enfoque genérico, y es

de las mejores prácticas aplicables a la dirección de todo tipo de proyectos.
El APM Group es el acreditador oficial de PRINCE2 de la Oficina de Comercio Guberna-

mental del Reino Unido.
El método divide los proyectos en fases manejables, permitiendo el control eficiente de

los recursos y el control periódico de su evolución. PRINCE2 está “basado en los produc-
tos”, es decir, los planes del proyecto se centran en obtener resultados concretos, y no solo
en la planificación de las actividades que se llevan a cabo.
PMAJ (Project Management Association of Japan)
La Project Management Association of Japan (PMAJ) es la organización no lucrativa,

establecida en mayo del 2002, que se encarga de mantener y promover el P2M.
P2M es la versión japonesa del sistema de dirección de proyectos. Desarrollada por el Co-
mité de Desarrollo de la Dirección de Proyectos de la ENNA, Engineering Advancement
Association (Asociación de Promoción de la Ingeniería de Japón), con la financiación del
gobierno japonés a través del METI, Ministry of Economics, Trade, and Industry (Minis-
terio de Economía, Comercio e Industria).
26
1.4.2. Estándares de gestión de proyectos

Del mismo modo que acabamos de ver cómo existen diversas organizaciones internacio-
nales que promueven y difunden el conocimiento en materia de gestión de proyectos, nos
encontramos, así mismo, con que actualmente conviven varios estándares en esta mate-
ria. Según Zabaleta et al. (2012), los estándares más significativos en gestión de proyectos
se describen a continuación:
Figura 1.8. Principales estándares de gestión de proyectos
Fuente: Zabaleta Etxebarría N, Igartua López N, Errasti Lozares JI. Análisis de
la Relación Existente entre los Estándares de Gestión de Proyectos y los

Factores Críticos para su Éxito. 6th International Conference on Industrial
Engineering and Industrial Management. Vigo: XVI Congreso de Ingeniería
de Organización; 18-20 julio 2012 18-20. p. 945
27
• The PMBOK (Project Management Body of Knowledge): es el estándar desarro-

llado por el Project Management Institute. Esta organización es considerada líder
mundial en la profesión de la gestión de proyectos con cerca de medio millón de
miembros y certificados a lo largo de 195 países (PMI, 2015). Este modelo identifica
9 áreas de conocimiento, 42 procesos y cinco grupos de procesos.
• APM BoK (Association of Project Management Body of Knowledge): establecido

en Europa, identifica seis áreas de conocimiento y 42 puntos que las personas in-
volucradas en gestión de proyectos deberían conocer y tener experiencia en ellas.
• BS 6079 (British Standard Guide to Project Management): es un estándar inglés es-

tablecido en 1901. Identifica once áreas de conocimiento y 50 actividades de apoyo.
• IPMA Competence Baseline (ICB): desarrollado por el International Project Ma-

nagement Association (la organización vinculada a la gestión de proyectos más
antigua, fundada en 1965 en Suiza). Se divide en 46 competencias correspondien-
tes a la parte técnica, las competencias de comportamiento de las personas y las
competencias contextuales relacionadas con los proyectos, los programas y los
portfolios.
• ISO 10006: elaborado por el International Standard Organization. Dota de guías

para la calidad de los proyectos y no es considerado como estándar de gestión de
proyectos por algunos profesionales (Crawford 2004). Se compone de cuatro áreas
de conocimiento y 34 procesos.
• P2M (Project & Program Management for Enterprise Innovation): es un estándar

establecido por el Project Management Professionals Certification Centre (PMCC)
de Japón, hoy en día conocido como el Project Management Association of Japan
(PMAJ, 2005). Determina 11 marcos de conocimiento y 33 prácticas.
Existen más estándares en el entorno de la dirección de proyectos como el Prince2 (Reino

Unido), NCSPM (Australia), SAQA (Sudáfrica), DIN 69901 (Alemania), entre otros, pero
no se focalizan tanto en el proyecto, sino en la organización o en las personas que desa-
rrollan dicho proyecto.
En la siguiente tabla se resumen los seis principales estándares en dirección de proyectos,

así como las áreas de conocimiento de cada uno de ellos. Puesto que el más extendido ac-
tualmente es el PMBOK, promovido por el Project Management Institute (PMI), es el que
se utilizará como base fundamental para el desarrollo de los contenidos de este máster.
28
Principales Estándares Dirección de Proyectos
Organización Estándar Áreas de conocimiento
Integración
Alcance
Calendario
Costes
Project Management
PMBOK (9 áreas de
Calidad
conocimiento)
Institute, PMI
Personas
Comunicaciones
Riesgos
Compras
Estrategia
Control
Association of Project Técnicas

APM BoK(6 áreas de
conocimiento)
Management, APM Comercio
Organización
Personas
Planificación
Objetivos
Beneficios
Calendario
Recursos
BS 6079 (11 áreas de
British Standard, BS Costes
conocimiento)
Riesgos
Eventos
Contratación y proveedores
Calidad
Stakeholders y comunicación
Comp. técnicas
International Project IPMA Competence
Management Baseline (ICB) (3 Comp. contextuales
Association, IPMA competencias)
Comp. comportamiento
29
Principales Estándares Dirección de Proyectos
Organización Estándar Áreas de conocimiento
Responsabilidad
Recursos
International
ISO 10006
Standard
(4 áreas de conocimiento) Realización del producto
Organization, ISO
Medición, análisis
y mejora
Estrategia
Finanzas
Sistemas
Organización
P2M (Project & Program Objetivos

Project Management Management for Enterprise
Association of Innovation) Recursos
Japan, PMAJ (11 marcos de
conocimiento) Riesgos
Información
Relaciones
Valor
Comunicación
Figura 1.9. Áreas de conocimiento principales de estándares de gestión de proyectos
Fuente: Elaboración propia a partir de Zabaleta Etxebarría N, Igartua López N, Errasti Lozares JI.
Análisis de la Relación Existente entre los Estándares de Gestión de Proyectos y los Factores
Críticos para su Éxito. 6th International Conference on Industrial Engineering and
Industrial Management. Vigo: XVI Congreso de Ingeniería de Organización; 18-20 julio 2012 18-20. p. 948
Aunque se desarrollará con mayor profundidad en el módulo de calidad, se considera con-

veniente en este apartado citar, como referencia obligada, la norma ISO 21.500 surgida
como iniciativa británica en 2006 (BSI-British Standards Institution), con los ojos pues-
tos en los Juegos Olímpicos de Londres 2012. Las principales asociaciones mundiales de
dirección de proyectos estuvieron directamente involucradas dirigiendo el programa de
consenso hasta la aprobación definitiva de la norma en 2012, por lo que puede conside-
rarse como una guía generada a partir de las mejores prácticas y estándares mundiales
(AEIPRO, 2013).
30
1.5. Cultura y estilos organizativos. Proyectos: cambio organizativo
1.5.1. Influencia de la organización en la dirección de proyectos

La forma en la que las organizaciones se estructuran y organizan afecta no solo a su pro-
pio funcionamiento, sino también a la manera en la que los proyectos se van a desarrollar
en la misma, así como a la importancia relativa que estos adquieren en el conjunto de la
organización.
Los estándares existentes en materia de gestión de proyectos, entre ellos la Guía de PM-
BOK (PMI, 2013), dan importancia a la cultura y el estilo de una organización, puesto
que afectan a su forma de llevar a cabo los proyectos. Según este propio referencial, las
culturas y estilos son fenómenos de tipo grupal, conocidos como normas culturales, que
se desarrollan con el tiempo. Las normas incluyen enfoques establecidos para iniciar y
planificar proyectos, los medios considerados aceptables para realizar el trabajo y las au-
toridades reconocidas que toman o influyen en las decisiones.
La estructura de la organización condiciona el modo de dirigir los proyectos, cómo fluyen

las decisiones a lo largo de la estructura y cómo se asocian los recursos en función de las
necesidades del proyecto y de la organización.
Básicamente podemos describir tres tipos de estructuras organizativas:
• Funcionales.
• Por proyecto.
• Matriciales, que surgen como una combinación de las dos anteriores.
31
La siguiente tabla muestra las características clave de los principales tipos de estructuras
de una organización en relación con los proyectos:
Estructura de la
Organización Matricial
Orientada a
Funcional
Proyectos
Matricial Matricial Matricial
Débil Equilibrada Fuerte
Características
del Proyecto
Autoridad del
Poco o Moderada Alta a
Director del Baja Baja a Moderada
Ninguna a Alta Casi Total
Proyecto
Disponibilidad Poco o Moderada Alta

Baja Baja a Moderada
de Recursos Ninguna a Alta a Casi Total
Quién gestiona
Gerente Gerente Director Director
el presupuesto Mixta
Funcional Funcional del Proyecto del Proyecto
del proyecto
Rol del Director Tiempo Tiempo Tiempo Tiempo

Tiempo Completo
del Proyecto Parcial Parcial Completo Completo
Personal
Administrativo Tiempo Tiempo Tiempo Tiempo
Tiempo Parcial
de la Dirección Parcial Parcial Completo Completo
de Proyectos
Figura 1.10. Características clave de los principales tipos de estructuras de
una organización en relación con los proyectos
Fuente: Project Management Institute. Guía de los Fundamentos para la
Dirección de Proyectos (Guía del PMBOK). Project Management Institute, Inc; 2013. p. 223
32
Dato importante
IPMA es la institución de dirección de proyectos más antigua del mundo. Creada

en 1965, es una federación de asociaciones nacionales profesionales de dirección
de proyectos. En el año 2001 estaba constituida por 28 asociaciones nacionales,
elevándose este número hasta 54 asociaciones en el año 2011.
Estructura organizacional funcional
En una estructura funcional los departamentos o áreas se organizan en función de disci-

plinas o especialidades: contabilidad, informática, mantenimiento, producción, calidad,
marketing... Este tipo de estructura es muy habitual, ya que presenta interesantes ventajas
al disponer de personas muy especializadas que trabajan para el conjunto de la organi-
zación y se eliminan duplicidades. Sin embargo, como apuntan Gido y Clements (2012),
las organizaciones funcionales pueden provocar aislamiento porque cada componente
funcional se ocupa exclusivamente de su propio desempeño. No subraya el trabajo en
equipo, y el intercambio de ideas entre funciones es escaso. Desde el punto de vista del
impacto de este tipo de estructura en la gestión de proyectos, presenta el inconveniente
de que no se concentra la atención y la disponibilidad de los recursos en el proyecto, y las
decisiones serían de alcance limitado en lugar de buscar el interés del proyecto global. La
estructura jerárquica provoca que la comunicación, la solución de problemas y la toma de
decisiones sean lentas, ya que la autoridad del responsable funcional prevalece sobre la
autoridad del director de proyecto.
Gráficamente, la estructura funcional puede ser ilustrada como se muestra a continuación:
Figura 1.11. Organización funcional
Fuente: Project Management Institute,. Guía de los Fundamentos para la Dirección de

Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 22
33
Estructura organizacional por proyectos
A diferencia de la estructura funcional, en las estructuras por proyectos los equipos se

configuran con perfiles profesionales multidisciplinares que trabajan de forma exclusiva
para el director de proyecto. Este tipo de organización presenta ventajas importantes, ya
que no hay conflicto alguno con otros proyectos por prioridades ni recursos, porque todos
los recursos para el proyecto están totalmente dedicados a él. La organización por proyec-
to tiene una enorme capacidad de respuesta al cliente. Por ejemplo, si el cliente cambia el
alcance del trabajo, el gerente de proyectos tiene autoridad para reasignar los recursos de
modo que se ajusten de inmediato a los cambios (Gido y Clements, 2012).
Sin embargo, este tipo de estructura también presenta algunas limitaciones, ya que al
estar los recursos asignados por proyectos, resulta difícil poder compartirlos con otros
proyectos cuando por el motivo que fuese determinadas tareas tienen que adelantarse o
retrasarse. Este tipo de disfunción tiene asociado un cierto grado de ineficiencia, ya que si
una fase del proyecto se retrasa, supongamos por ejemplo la parte de diseño gráfico en un
proyecto informático, el diseñador estará esperando poder ejecutar su parte del proyecto,
suponiendo un coste para la empresa, mientras que si posteriormente hubiese que acele-
rar la ejecución de esta parte, podría suponer también un coste extra.
Otra limitación en este tipo de estructuras es la duplicidad y las ineficiencias en costos

en aquellas tareas que pudieran ser repetitivas y transversales en todos los proyectos. Por
ejemplo, en el caso de una empresa de construcción organizada por proyectos, la solicitud
de permisos y licencias, el acopio de materiales, etc.
La gestión del conocimiento es una de las mayores restricciones en este tipo de estructu-
ra. La vinculación de las personas se mantiene mientras existe el proyecto, con el riesgo
de que si este se termina y no puede asignarse posteriormente a otro, se perderán el
conocimiento y la experiencia adquiridos. Puesto que cada proyecto es completamente
independiente del resto, no hay garantías de que las lecciones aprendidas en un proyecto
puedan ser compartidas o extrapolables a otros proyectos.
34
Figura 1.12. Organización orientada a proyectos
Fuente: Project Management Institute. Guía de los Fundamentos para
la Dirección de Proyectos (Guía del PMBOK). Project Management
Institute, Inc.; 2013. p. 252
Estructura organizacional matricial
Partiendo de las ventajas e inconvenientes de la estructura funcional y la estructura orien-

tada a proyectos, la estructura matricial trata de aglutinar lo mejor de ambas, de tal forma
que se garanticen los recursos necesarios para que el proyecto pueda desarrollarse y que
al mismo tiempo esto no suponga ineficiencias o exceso de costes.
La estructura matricial presenta las siguientes ventajas (Gido y Clements, 2012):
• Permite asignar personas de forma exclusiva o temporal a uno o varios proyectos.
• El conocimiento experto permanece en la organización a disposición de todos los

proyectos.
• Se facilita la comunicación, ya que se dispone de dos canales: el gerente funcional

y el de proyectos.
• Se incrementa el enfoque en el cliente. El gerente de proyectos asegura la comu-

nicación con el cliente, mientras que las unidades funcionales se concentran en el
desarrollo de los proyectos.
35
Para clarificar todas estas particularidades de las tres estructuras mencionadas, la siguien-
te tabla resume las ventajas y desventajas de las estructuras organizacionales funcionales,
matriciales y por proyectos:
Estructura Ventajas Desventajas
• Aislamiento
• No hay actividades duplicadas
Estructura
• Respuesta lenta
funcional
• Excelencia funcional
• No se enfoca en el cliente
• Control de los recursos • Ineficiencia en costos

Estructura
por proyecto • Capacidad de respuesta • Bajo nivel de transferencia de
a los clientes conocimiento entre proyectos
• Utilización eficiente de
los recursos
• Expertise funcional a
disposición de todos los
proyectos • Dos líneas de dependencia
Estructura
matricial
• Mayor aprendizaje y • Necesario equilibrar el poder
transferencia de conocimiento
• Mejor comunicación
• Enfoque en el cliente
Figura 1.13. Ventajas y desventajas de las estructuras organizacionales

Fuente: Gido, J, Clements JP. Administración Exitosa de Proyectos. 5ª ed. Cengage Learning; 2012. p. 441
36
A pesar de las ventajas de la estructura matricial, esta también presenta un cierto riesgo
asociado al hecho de tener dos líneas de dependencia y a la relación de poder que puede
existir entre ambos. En función de la influencia que exista entre el gerente funcional y el
director de proyecto podremos hablar de organizaciones matriciales débiles, equilibradas
o fuertes:
• Matricial débil: se asemeja a una organización funcional. El rol del director del
proyecto es el de coordinador o facilitador.
Figura 1.14. Organización matricial débil
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de Proyectos
(Guía del PMBOK). Project Management Institute, Inc; 2013. p. 23
37
• Matricial fuerte: su estructura es similar a las organizaciones orientadas a proyec-

tos. El director de proyectos tiene autoridad dentro de la estructura de la organiza-
ción y dedicación completa para la ejecución de los proyecto
Figura 1.15. Organización matricial fuerte
(Guía del PMBOK). Project Management Institute, Inc; 2013. p. 24
• Matricial equilibrada: en este tipo de estructura existe la figura del director de pro-
yecto, aunque a diferencia del matricial fuerte, no le confiere autoridad plena sobre
el proyecto.
Figura 1.16. Organización matricial equilibrada
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección
de Proyectos (Guía del PMBOK). Project Management Institute, Inc; 2013. p. 24
38
1.5.2. Factores ambientales de la empresa

El éxito o fracaso de un proyecto depende de múltiples factores. El reto de la gestión
de proyectos es conseguir que se cumplan los objetivos del proyecto conforme al marco
de actuación establecido (tiempo, coste, alcance…). Sin embargo, existen condicionan-
tes cuyo control se escapa al equipo del proyecto y que influyen, restringen o dirigen el
proyecto. Estos condicionantes son conocidos como factores ambientales de la empresa.
Aunque, como acabamos de señalar, su control no es posible, deben ser identificados y
monitorizados a lo largo del proyecto, puesto que afectan o pueden afectar positivamente
o negativamente al resultado final del proyecto.
Los factores ambientales de la empresa varían ampliamente en cuanto a tipo o naturaleza,

e incluyen entre otros (PMI, 2013):
• La cultura, estructura y gobierno de la organización.
• La distribución geográfica de instalaciones y recursos.
• Los estándares de la industria o gubernamentales (p.ej., reglamentos del organis-

mo de control, códigos de conducta, estándares de producto, estándares de calidad
y estándares de fabricación).
• Las infraestructuras (p.ej., instalaciones existentes y bienes de capital).
• Los recursos humanos existentes (p.ej., habilidades, disciplinas y conocimientos

como los relacionados con el diseño, el desarrollo, las leyes, las contrataciones y
las compras).
• La gestión de personal (p.ej., pautas de selección y retención de personal, revisión

del desempeño de los empleados y registros de capacitación, política de incentivos
y horas extras, y registro de horas trabajadas).
• Los sistemas de autorización de trabajos de la compañía.
• Las condiciones del mercado.
• La tolerancia al riesgo por parte de los interesados.
• El clima político.
39
• Los canales de comunicación establecidos en la organización.
• Las bases de datos comerciales (p.ej., datos para estimación estandarizada de cos-
tos, información de estudios de los riesgos de la industria y bases de datos de
riesgos).
• El sistema de información para la dirección de proyectos (p.ej., herramientas auto-

máticas, tales como una herramienta de software para programación, un sistema
de gestión de configuraciones, un sistema de recopilación y distribución de la in-
formación o las interfaces web a otros sistemas automáticos en línea).
1.5.3. Partes interesadas en el proyecto

Hasta ahora hemos visto que los proyectos necesitan gestionarse adecuadamente, que
existen estándares o metodologías sistematizadas y que además necesitamos tener en
cuenta los factores que, escapándose a nuestro control, pueden influir positiva o negati-
vamente en el resultado final. Reflexionemos acerca de lo que Chamoun (2002) identifica
como el éxito de un proyecto:
“Cumplir los objetivos de tiempo, costo y calidad, a satisfacción del cliente y de los involu-
crados clave al mismo tiempo que desarrollamos relaciones a largo plazo con proveedores
y demás integrantes del equipo”.
En este punto incorporamos un nuevo elemento que son las personas: clientes, involucra-
dos clave, proveedores y miembros del equipo.
Conforme a la definición de Chamoun (2002) definiremos como involucrados a “organi-

zaciones y personas que serán afectadas o beneficiadas en el desarrollo del proyecto”. Los
involucrados clave se muestran en la siguiente figura, en la que el círculo engloba a todos
los involucrados, los dos rectángulos superiores a los miembros del equipos directivo y
los dos rectángulos inferiores al equipo ejecutor.
40
Figura 1.17. Partes interesadas en el proyecto
Fuente: Chamoun, Yamal. Administración Profesional de Proyectos. La
Guía. Mc Graw-Hill Interamericana; 2002. p. 30
Según esta concepción, como involucrados podemos considerar a todos los que parti-
cipan de forma activa en la consecución del proyecto (cliente, patrocinador, gerente/di-
rector del proyecto y miembros del equipo), pero no obviemos que existen otros agentes
latentes como los medios de comunicación, vecinos, o público en general que pueden
contribuir a acelerar, ralentizar o incluso llegar a parar el proyecto. Un ejemplo de esta
influencia ha sido la polémica decisión de la creación de un cementerio nuclear en Villar
de Cañas (Cuenca), que ha generado una plataforma contraria al proyecto, formada por
unas 50 asociaciones y representantes de municipios de la comarca, así como el enfrenta-
miento entre los Gobiernos autonómico y central. Identificar y gestionar adecuadamente
las expectativas de los involucrados es crucial para no enfrentarnos a situaciones como
la anteriormente descrita, que puede retrasar durante años la ejecución de un proyecto,
como de momento es el caso, o incluso llegar a paralizarlo de forma permanente con el
correspondiente perjuicio, en ambos casos, económico y social.
Tener claro cuáles son los roles de cada una de las partes interesadas en el proyecto y
gestionar adecuadamente sus expectativas es importante antes de su comienzo. De forma
esquematizada, puesto que se estudiará con más profundidad en otros módulos, se descri-
ben cada una de sus funciones (Chamoun, 2002):
41
Cliente Patrocinador
Es el contratante, propietario o desa- Es la persona a cargo de la dirección del pro-

rrollador del proyecto quien: yecto en la empresa quien:
• Autoriza. • Asegura la toma de decisiones a tiempo.
• Define el alcance. • Apoya la asignación de recursos.
• Establece alineamientos y criterios • Supera conflictos y barreras organizaciona-

de aceptación. les para una mejor realización del proyecto.
• Asigna y apoya al gerente/director del pro-

yecto.
• Provee la dirección estratégica al gerente/

director del proyecto.
Gerente/director del proyecto Miembros del equipo
• Es el encargado del proyecto quien: Son el gerente/director, los organizadores,

staff y los proveedores:
• Lidera al equipo del proyecto para al-
canzar los objetivos. • Elaboran el plan del proyecto.
• Asegura la comunicación efectiva en- • Ejecutan y controlan siguiendo el plan.

tre la Administración y otras organiza-
ciones. • Colaboran en la integración de los equipos
para lograr los objetivos del proyecto.
• Asegura que los problemas del pro-
yecto sean identificados y resueltos a
tiempo y adecuadamente.
Figura 1.18. Funciones de las partes interesadas en el proyecto
Fuente: Chamoun, Yamal (2002), Administración Profesional de Proyectos. La Guía, Mc Graw-Hill Interamericana
42
1.6. Resumen
Cada día convivimos con multitud de proyectos que se gestan alrededor de nuestra vida
cotidiana: prepararnos para participar en una maratón, organizar un aniversario de boda,
planificar una acampada con los amigos… Sabemos que son acontecimientos importan-
tes, únicos e irrepetibles que debemos planificar y coordinar adecuadamente para que
cumplan nuestros deseos y expectativas y las del resto de personas que también van a
estar involucradas en ellos.
Del mismo modo, los proyectos rodean la gestión de las organizaciones: el lanzamiento
de un nuevo producto, la migración a un nuevo software, las obras de ampliación del área
de fabricación... Estos proyectos no solo son importantes para las empresas, sino que en
muchos casos son críticos para alcanzar sus objetivos estratégicos.
Un proyecto puede ser definido de forma sencilla como un esfuerzo temporal que se lle-
va a cabo para crear un producto, servicio o resultado único. Los proyectos reúnen una
serie de características que los identifican y distinguen: complejidad, no repetitividad,
grupal, objetivo claro, coordinación de actividades, limitación de recursos, marco tempo-
ral y resultado único. Proyectos similares con un objetivo común pueden agruparse en
programas. El portafolio o cartera agrupa a un conjunto de proyectos y programas que se
gestionan para alcanzar determinados objetivos estratégicos.
Aunque los proyectos han existido a lo largo la historia, la gestión sistematizada de los
mismos se ha desarrollado con mayor intensidad en los últimos 50 años, existiendo diver-
sas organizaciones y estándares que pueden ser considerados como referentes en la di-
rección de proyectos: Project Management Institute, Association of Project Management,
British Standard, International Project Management Association, Project Management
Association of Japan, etc.
La gestión de los proyectos está influenciada por diversos condicionantes, denominados

factores ambientales, que siendo ajenos al propio proyecto contribuyen al éxito o fracaso
del mismo. Entre estos factores se encuentra la propia cultura, estilo y estructura de la
organización (funcional, matricial, por proyecto) y la forma en la que la organización se
relaciona con las partes involucradas en el proyecto (medios, público, cliente final, veci-
nos, equipo…).
43
2. Marco de referencia para la

dirección de proyectos
“ La dirección y gestión de proyectos ha sido considerada eminen-
temente una disciplina de origen industrial (incluso militar, como
la formulación de “estrategias”) y de las obras públicas, para pasar
posteriormente al campo de los servicios y de los proyectos de con-
tenido y carácter social (Paris, 2011).”
2.1. Importancia de la gestión de proyectos

En los últimos años, la gestión de proyectos ha sido reconocida como una rama de gestión
por derecho propio, con sus propios colegios profesionales y con un completo y creciente
abanico de procedimientos y técnicas (Lock, 2001).
Cada vez más las organizaciones parecen estar concienciadas sobre los beneficios que su-
pone una buena gestión de proyectos. Sin embargo, llevarla a cabo no es una tarea fácil. El
informe CHAOS, que elabora el Standish Group, es el informe más famoso sobre el éxito
y fracaso de los proyectos en el sector de las tecnologías de la información (TI). Según el
informe CHAOS 2013, como se muestra en la tabla, solo un 39 % de estos proyectos finali-
zaron con éxito, mientras que el 43 % lo hicieron con deficiencias (retraso, sobrecoste y/o
menos requisitos de los esperados).
Proyectos 2004 2006 2008 2010 2012
Finalizados con éxito 29% 35% 32% 37% 39%
Fracasados 18% 19% 24% 21% 18%
Finalizados con
53% 46% 44% 42% 43%
deficiencias
Figura 2.1. Porcentaje de resolución de proyectos años 2004 a 2012 según informe CHAOS
Fuente: CHAOS. CHAOS Manifesto 2013. Thing Big, act small. The Standish Group International; 2013. p. 1.
44
El estudio del Project Management Institute, PMI, publicado en 2015 bajo el título Pulso
de la profesión: Capturando el Valor de la Gestión de Proyectos, señala que las organiza-
ciones siguen perdiendo 109 millones de dólares por cada mil millones de dólares inver-
tidos en proyectos, debido al bajo desempeño de los mismos ocasionados por problemas
durante la ejecución, falta de agilidad o falta de coherencia con la estrategia. Así mismo,
este informe constata que las organizaciones que gestionan sus proyectos de forma es-
tructurada consiguen finalizar sus proyectos con éxito 2,5 veces más que las que no si-
guen una metodología. Aún así, el porcentaje global de los proyectos que finalizan con
éxito ronda el 64 % durante los últimos años.
El PMI considera determinante para que se incremente este porcentaje de éxito la uti-
lización por parte de las organizaciones de metodologías de gestión de proyectos que
identifiquen los conocimientos, procesos, habilidades, herramientas y técnicas que tienen
impacto en el éxito de un proyecto.
Figura 2.2. Porcentaje de proyectos finalizados con éxito 2012-2015
Fuente: Project Management Institute. Pulse of the Profession: Capturing the
Value of Project Management. Project Management Institute, Inc.; 2015. p. 8.
Disponible en: http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/

thought-leadership/pulse/pulse-of-the-profession-2015.pdf
2.2. Metodologías de dirección de proyectos

Las metodologías de gestión de proyectos comenzaron a gestarse en los años 50 en el
ejército estadounidense para intentar reducir el volumen de proyectos que se descontro-
laban y ayudar a solventar problemas comunes que se habían identificado relativos a los
siguientes aspectos (Alnasser, 2010):
• Exceso de carga de trabajo planificada o en proceso.
• Costes que superan el presupuesto inicial.
• Problemas en la calidad, valor o utilidad del resultado final.
45
La utilización de una metodología o sistematización de los procesos para la ejecución

de un proyecto reduce la aparición de problemas a lo largo de la vida del proyecto, por
lo que la probabilidad de éxito del mismo se incrementa (Charvart, 2003). La siguiente
figura pretende ilustrar esta comparación. En aquellos casos en los que no se aplica una
metodología (figura A), existe un alto número de problemas que obliga a incrementar
los procesos de corrección y control. Sin embargo, cuando se aplica una metodología de
gestión de proyectos (figura B), se pone un especial énfasis en la correcta preparación
y planificación del proyecto, lo que repercute en que se reduzca considerablemente el
número de problemas, permitiendo aligerar el peso de los procesos a lo largo de la vida
del proyecto. Recordemos que la existencia de problemas tendrá, de una u otra forma,
consecuencias para el proyecto: retrasos, encarecimiento de los costes, modificaciones
del alcance, retrabajos, pérdida de credibilidad ante el cliente, etc.
Figura 2.3. Evolución de un proyecto usando metodología y sin usarla
Fuente: Charvart J. Project Management Methodologies: selecting, implementing, and supporting
methodogies and processes for projects. John Wiley & Sons Inc.; 2003. p. 6
Las metodologías de gestión de proyectos establecen los estándares de procesos y áreas

de conocimiento, pero también proporcionan métricas para juzgar el rendimiento, un sis-
tema donde esos procesos puedan ser aplicados de forma consistente en la organización,
y un método global (el modelo de madurez) para evaluar la efectividad de la metodología
una vez que está implantada (Bucero, 2013). No es fácil implantar una metodología de di-
rección de proyectos, según este autor, pero existen muchos beneficios en su utilización,
como se muestra a continuación:
• Contribuye a definir mejor las expectativas del cliente, facilita herramientas y mé-
todos para identificar las partes interesadas en el proyecto.
• Favorece la creación de un buen plan de proyecto, definiendo el alcance y activida-

des a realizar, asignando recursos asignados, identificando restricciones, etc.
46
• Aporta herramientas para la gestión y el control del proyecto, informes de inciden-

cias, informes de estado, desviaciones, control de cambios, etc.
• Asegura la satisfacción del cliente, ya que se focaliza en satisfacer sus requerimien-

tos y expectativas.
• Aumenta la satisfacción del equipo de proyecto, ya que todos ellos colaboran ac-
tivamente.
• Fomenta la disciplina de trabajo.
Figura 2.4. Beneficios de utilizar una metodología
Fuente: Bucero Torres A. La dirección de proyectos: una nueva visión. 2ª ed. Díaz de Santos; 2013
En función de las características de la organización, tipo de proyecto, restricciones de

tiempo, coste, recursos disponibles, etc., podrán utilizarse diferentes metodologías para
la dirección de proyectos. Básicamente, podemos decir que la gestión de proyectos puede
ser predictiva (también conocida como clásica, tradicional o formal) o ágil.
La decisión final de cuál elegir dependerá de las características del proyecto y de las ca-
racterísticas de la organización. Dichas características, así como las diferencias entre me-
todologías predictivas y ágiles, se resumen en la siguiente figura:
47
Figura 2.5. Diferencia entre metodologías ágiles y predictivas
Fuente: https://be-klan.com/2013/01/31/gestion-de-proyectos-agil-o-predictiva/
Una de las características más importantes de las señaladas anteriormente es la prioridad

final para el proyecto. Mientras que la metodología predictiva le otorga más importancia
a los procesos, los métodos ágiles consideran que el valor o utilidad final del resultado
que se quiere obtener es lo más importante. Otra de las características más relevante está
relacionada con los requisitos del producto final. La metodología predictiva es más poten-
te en entornos estables en los que hay pocos cambios por parte del cliente, mientras que
las metodologías ágiles asumen que las especificaciones del cliente irán cambiando a lo
largo de la vida del proyecto.
La diferencia conceptual entre ambas metodologías podemos ilustrarla con este sencillo
ejemplo. La metodología predictiva equivale a la persona que va a realizar un viaje a un
país y sabe qué ciudades va a visitar, en qué hoteles se va a alojar, cuándo y cómo va a
realizar las excursiones, en qué restaurantes va a comer y cuánto dinero se va a gastar.
Es más, seguramente hasta tendrá pensado un plan alternativo por si fallara algo: una
excursión cancelada por mal tiempo o una reserva en el restaurante que no es posible
porque está completo. En este tipo de viaje es importante adaptarse al plan, y en el caso de
que falle algo, recuperar la normalidad lo antes posible. La metodología ágil equivale a la
persona que va a realizar un viaje a un país y sabe que empezará por la capital, pero deja
la decisión de qué otras ciudades visitará, cuándo y cómo va a realizar las excursiones, en
qué restaurantes va a comer, etc., para cuando llegue. Si hubiera cambios a lo largo del
viaje se adaptaría a ellos con el fin de conseguir su objetivo: conocer el país.
48
2.2.1. Metodologías predictivas de gestión de proyectos

Las metodologías de gestión de proyectos conocidas como predictivas se conocen tam-
bién con el nombre de metodologías clásicas, tradicionales o formales.
Estas metodologías parten de las siguientes premisas (Alnasser, 2010):
• Estabilidad del entorno: considera que todos los proyectos tienen características
y comportamientos regulares, guiados por un patrón, desarrollados en un entorno
estático y predecible.
• Carácter predictivo: se define al detalle el resultado que se quiere conseguir. Lo

importante son los procesos, no el valor final del producto, de forma que los es-
fuerzos se orientan a cumplir en términos de tiempo, costes y recursos, siendo sus
principales valores la planificación y el control.
Su lema es que la forma más eficiente de desarrollar un trabajo es hacerlo bien a la prime-
ra. Esto solo es posible si se puede conocer al detalle el resultado que se quiere obtener y
se trabaja en un entorno estable.
Ejemplos típicos de proyectos gestionados bajo metodologías predictivas podrían ser:
• Obras de construcción civil.
• Implantación de estándares de calidad.
• Ampliación de un área o línea de fabricación.
Dos de las metodologías predictivas más ampliamente implantadas son:
• PMBOK (Project Management Body of Knowledge), desarrollado por el Project

Management Institute, PMI.
• PRINCE2 (PRojects IN Controlled Environments 2), impulsado por la Oficina de

Comercio Gubernamental del Reino Unido.
49
2.2.2. PMBOK
El Project Management Institute (PMI) es una asociación sin ánimo de lucro fundada en
1969 que lidera mundialmente el campo de la administración de proyectos. De hecho, los
miembros del Project Management Institute (PMI) han aumentado de 8.500 en 1990 a
más de 400.000 en el año 2013 a lo largo de 180 países (PMI, 2013).
En 1981 la Junta Directiva del PMI aprobó un proyecto en el que uno de los objetivos era
la elaboración de un estándar de dirección de proyectos que describiera el contenido y la
estructura de los contenidos en esta materia. Este proyecto dio lugar en 1983 a la publi-
cación de los estándares de la dirección de proyectos que se tomaron como referencia. Al
tratarse de la primera publicación de este tipo, se convirtió en una base para la posterior
discusión y mejora de la definición de la “dirección de proyectos” como profesión. Una
extensión de dicho proyecto dio lugar en 1987 a la publicación de los Fundamentos para
la dirección de proyectos. Los avances posteriores y la retroalimentación continua basada
en la aplicación práctica de esos conocimientos dieron paso en 1996 a la llamada Guía de
los fundamentos para la dirección de proyectos (Guía del PMBOK) (Wuttke, 2014).
La Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK) (2013) pro-
porciona una serie de buenas prácticas para la ejecución de proyectos que, sin ánimo
de pretender ser de obligado cumplimiento, tratan de guiar la correcta ejecución de los
proyectos a través de la aplicación de una metodología sistemática y herramientas de
utilidad contrastada. Las pautas que marca la guía son de carácter general y permiten su
aplicación a una amplia generalidad de proyectos, independientemente de su tamaño,
alcance o naturaleza.
A lo largo de esta unidad se irá profundizando en el contenido del PMBOK al tratarse del
estándar de dirección de proyectos más ampliamente difundido internacionalmente.
2.2.3. PRINCE2
PRINCE (PRojects IN Controlled Environments) es una metodología de gestión de pro-
yectos nacida en el Reino Unido que pretende convertir proyectos que manejan una carga
importante de variabilidad y de incertidumbre en entornos controlados.
Según la Oficina de Comercio Gubernamental del Reino Unido (2009), PRINCE2 está
ampliamente extendido a escala mundial, en más de 150 países. Esta metodología permite
a quienes llevan proyectos de cualquier tamaño y en cualquier entorno entregar de modo
eficaz lo que el proyecto requiera, gestionando correctamente los costes, los calendarios,
la calidad, el alcance, los riesgos y los beneficios.
50
PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empre-

sas privadas y organizaciones, como son: Gobiernos (Reino Unido, Australia, Holanda,
Dinamarca, Canadá), sector privado (Sun Microsistems, DHL, Barclays, Vodafone, Shell,
Unilever, Microsoft, HP, IBM, British Airways) y organizaciones internacionales (ONU y
sus agencias, Banco Mundial, ILO -International Labour Organization-).
PRINCE2 se fundamenta en:
• Siete procesos que forman la gestión de proyectos.
• Siete principios que constituyen la base del método de gestión de proyectos.
• Siete temáticas o áreas de conocimiento que apoyan determinadas áreas clave de

la gestión de proyectos.
Estos principios, temáticas y fases se resumen en la siguiente tabla:
Temáticas o Áreas
Principios Procesos o Fases
conocimiento
Justificación Modelo negocio o Puesta en marcha

comercial continua business case (preproyecto)
Aprender de la experiencia Organización Dirección del proyecto
Roles y responsabi-
Calidad Inicio del proyecto
lidades definidos
Gestión por fases Planes Control de fase
Gestión de la
Gestión por excepción Riesgo
entrega de productos
Gestión de los
Orientación a productos Cambio
límites de fase
Adaptación Progreso Cierre del proyecto
Figura 2.6. P Principios, temáticas y procesos de PRINCE2
Fuente: elaboración propia a partir de Oficina de Comercio Gubernamental del Reino Unido (2009).
Éxito en la Gestión de Proyectos con PRINCE2, 5ª ed., TSO
51
2.2.4. Las temáticas de PRINCE2

Conforme a la Oficina de Comercio Gubernamental del Reino Unido (2009), las temáticas
de PRINCE2 describen aspectos de la gestión del proyecto que se deben abordar conti-
nuamente. Cualquier project manager que preste atención rigurosamente a estas temáti-
cas desempeñará el rol con seriedad profesional. Sin embargo, la solidez de PRINCE2 se
basa en la manera en que las siete temáticas se integran a lo largo del flujo cronológico
del proyecto, como se muestra en la siguiente figura:
Temática Descripción Contesta a
El proyecto se inicia con una idea que se considera que

tiene valor potencial para la organización en cuestión. Esta
temática aborda la manera en que la idea se desarrolla
Business case para convertirse en una proposición de inversión viable ¿Por qué?
para la organización y la manera en que la gestión del
proyecto mantiene la atención en los objetivos de la orga-
nización durante todo el proyecto.
La organización patrocinadora del proyecto necesita asig-

nar el trabajo a gerentes capaces de asumir la responsa-
bilidad y la dirección del proyecto hasta su terminación.
Los proyectos son interfuncionales y, por consiguiente, las
Organización estructuras jerárquicas normales de la organización no ¿Quién?
son necesariamente apropiadas. Esta temática describe
los roles y las responsabilidades en el equipo temporal
de gestión del proyecto PRINCE2 que se requieren para
gestionar el proyecto con efectividad.
La idea inicial solo se comprenderá a grandes rasgos. Esta

temática explica la manera en que la idea inicial se desa-
rrolla de modo que todos los participantes comprenden los
Calidad ¿Qué?
atributos de calidad de los productos a entregar, y luego
la manera en que la gestión del proyecto asegurará que
estas exigencias se entreguen posteriormente.
Los proyectos PRINCE2 proceden en base a una serie de ¿Cómo?

planes aprobados. Esta temática complementa la temá-
tica de la calidad al describir los pasos requeridos para
¿Cuánto?
desarrollar los planes y las técnicas de PRINCE2 que se
Planes
deberían aplicar. En PRINCE2, los planes se hacen corres-
¿Cuándo?
ponder a las necesidades del personal en los diversos ni-
veles de la organización. Son el foco de la comunicación y
del control durante todo el proyecto.
Típicamente, los proyectos conllevan más riesgo que la

actividad operacional estable. Esta temática aborda la
¿Qué pasa
Riesgo manera en que la gestión del proyecto gestiona las in-
si…?
certidumbres en sus planes y en el entorno de proyecto
más amplio.
52
Temática Descripción Contesta a
Esta temática describe la manera en que la gestión del

proyecto evalúa y actúa sobre las cuestiones que tienen
un posible impacto en cualquiera de los aspectos baseli-
¿Cuál es el
Cambio ne del proyecto (sus planes y/o productos completados).
impacto?
Las cuestiones pueden ser problemas generales no anti-
cipados, solicitudes de cambio o instancias en las que la
calidad ha fallado.
¿Dónde esta-
Esta temática aborda la viabilidad continua de sus planes. mos ahora?
La temática explica el proceso de toma de decisiones para
aprobar planes, el seguimiento del rendimiento real y el
¿Adónde
Progreso proceso de presentación de excepciones si los eventos no
vamos?
salen según lo indicado en el plan. En última instancia,
la temática de progreso determina si el proyecto debería
proceder y de qué manera. ¿Deberíamos
continuar?
Figura 2.7. Las temáticas de PRINCE2
Fuente: Oficina de Comercio Gubernamental del Reino Unido. Éxito en la
Gestión de Proyectos con PRINCE2. 5ª ed. TSO; 2009. p 19
Dato importante
El PMI considera determinante para que se incremente este porcentaje de éxito la

utilización por parte de las organizaciones de metodologías de gestión de proyec-
tos que identifiquen los conocimientos, procesos, habilidades, herramientas y técni-
cas que tienen impacto en el éxito de un proyecto.
53
2.2.5. PMBOK versus PRINCE2

A diferencia del PMBOK, que es considerado una guía que recoge una serie de buenas
prácticas ampliamente reconocidas sobre la dirección de proyectos y está focalizada en
identificar qué hay que hacer en cada fase del proyecto y cómo, PRINCE2 es un método y
está más orientado al uso o a la acción.
La siguiente figura muestra una comparación entre las áreas de conocimiento de la Guía
PMBOK y las temáticas de PRINCE2:
Áreas conocimiento PMBOK Temáticas PRINCE2
Integración Progreso, cambios
Alcance, tiempo, coste Planes, business case
Calidad Calidad, organización
Riesgo Riesgo
Comunicaciones Control
Recursos humanos Organización
Adquisiciones No incluido
Figura 2.8. Comparación áreas conocimiento PMBOK y áreas temáticas PRINCE2
Fuente: Verhage L. Management Methodology for Enterprise Systems Implentations.
Eburon; 2009. p. 65 (traducción propia)
Ambas metodologías presentan algunas similitudes que, por ejemplo, permiten su aplica-
ción a proyectos de cualquier tamaño y sector, que están basadas en buenas prácticas, que
proporcionan un vocabulario común en torno a la dirección de proyectos, y por último
que se basan en conseguir el producto o servicio objeto del proyecto y no en realizar las
tareas o actividades.
54
Sin embargo, también podemos encontrar algunas diferencias que son resumidas en la
siguiente tabla:
PMBOK PRINCE2
Qué es Campo de conocimiento Metodología
Obtener el proyecto en
Objetivo Generar el valor esperado
coste, tiempo y alcance
Genera una organización para

Directores de proyecto
llevar a cabo el proyecto
Orientación
Consecución del business
Finalización del proyecto
case (modelo de negocio)
Roles, responsabilidad
Se define con más detalle
y toma de decisiones
Descripción de
Se incluye en profundidad Solo en la temática de calidad
técnicas/ herramientas
En el triángulo Se considera un cuarto factor,

Calidad tiempo-coste-alcance, además del tiempo, coste y alcance
forma parte del alcance y, por lo tanto, sacrificable
Adquisiciones Se incluye No se incluye
Habilidades de gestión
Se incluye No se incluye
e interpersonales
Figura 2.9. Diferencias entre PMBOK y PRINCE2
Fuente: Elaboración propia
55
2.2.6. Por qué las metodologías ágiles de gestión de proyectos

La dirección y gestión de proyectos ha sido considerada eminentemente una disciplina
de origen industrial (incluso militar, como la formulación de “estrategias”) y de las obras
públicas, para pasar posteriormente al campo de los servicios y de los proyectos de con-
tenido y carácter social (Paris, 2011).
Este origen de la gestión de proyectos ha condicionado el enfoque de las metodologías

que tradicionalmente se han utilizado, orientándose a proyectos en los que era posible un
alto grado de planificación, en entornos con relativamente pocos cambios, y en los que es
posible ajustar con razonable exactitud el plazo, el costo y el alcance del proyecto.
Pero no todos los proyectos son principalmente estáticos en su concepción y desarrollo.

Es más, los cambios en los requerimientos del cliente o en los mercados, las evoluciones
tecnológicas y la complejidad técnica asociada al propio proyecto hacen que los proyec-
tos tengan un componente dinámico, impredecible, no programable inicialmente. Las
metodologías tradicionales de gestión de proyectos no sirven, por tanto, en este tipo de
entornos o en aquellos en los que las metas, los objetivos y los métodos no están claros.
El entorno de trabajo de las empresas del conocimiento se parece muy poco al que originó
la gestión de proyectos predictiva. Ahora se necesitan estrategias para el lanzamiento de
productos orientadas a la entrega temprana de resultados tangibles y a la respuesta ágil y
flexible, necesaria para trabajar en mercados de evolución rápida (Palacio, 2015).
A diferencia de los proyectos predictivos o tradicionales, la gestión de proyectos ágil no

se basa en la anticipación, sino en la continua adaptación a las necesidades del cliente,
la evolución del mercado y las innovaciones tecnológicas. Esto implica dejar de tener
“productos finales” o “entregables” a favor de productos en continua evolución y mejora.
En los proyectos ágiles no es tan importante la planificación y la previsibilidad en la eje-

cución como una respuesta rápida y flexibilidad para funcionar en entornos de negocio
que cambian y evolucionan rápidamente.
56
2.2.7. El Manifiesto Ágil

En marzo de 2001, 17 críticos de los modelos de producción basados en procesos, convo-
cados por Kent Beck, que había publicado un par de años antes el libro en el que explicaba
la nueva metodología Extreme Programming, se reunieron en Salt Lake City para discutir
sobre el desarrollo de software. En la reunión se acuñó el término “métodos ágiles” para
definir a aquellos que estaban surgiendo como alternativa a las metodologías formales,
que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte
dependencia de planificaciones detalladas previas al desarrollo (Palacio, 2015).
Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado deno-

minado como “Manifiesto Ágil”, que son los valores sobre los que se asientan los métodos
ágiles de gestión de proyectos.
Manifiesto Ágil
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo

y ayudando a otros a que lo hagan.
Con este trabajo hemos llegado a valorar:
• A los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
57
2.2.8. Los doce principios del Manifiesto Ágil

El Manifiesto Ágil, tras los postulados de los cuatro valores descritos anteriormente en los
que se fundamenta, establece doce principios (Dimes, 2015). En la siguiente tabla se han
relacionado los doce principios del Manifiesto Ágil con el valor en el que impacta, para
facilitar su comprensión:
Valores Principios
• Construcción de proyectos en torno a individuos motivados, dándo-

les la oportunidad y el respaldo que necesitan y procurándoles confianza
para que realicen la tarea.
• La forma más eficiente y efectiva de comunicar informa-ción de ida y

A los individuos y su in- vuelta dentro de un equipo de desarrollo es mediante la conversación
teracción, por encima de cara a cara.
los procesos y las herra-
mientas
• Las mejores arquitecturas, requisitos y diseños emergen de equipos
que se autoorganizan.
• En intervalos regulares, el equipo reflexiona sobre la for-ma de ser

más efectivo y ajusta su conducta en consecuencia.
• El software que funciona es la principal medida del progreso.
• Entregar con frecuencia software que funcione, en periodos de un

par de semanas hasta un par de meses, con preferencia en los periodos
El software que funciona, breves.
por encima de la docu-
mentación exhaustiva
• La simplicidad como arte de maximizar la cantidad de trabajo que se
hace es esencial.
• La atención continua a la excelencia técnica enaltece la agilidad
• Nuestra principal prioridad es satisfacer al cliente a través de la

entrega temprana y continua de software de valor.
La colaboración con el • Las personas del negocio y los desarrolladores deben trabajar juntos
cliente, por encima de la de forma cotidiana a través del proyecto.
negociación contractual
• Los procesos ágiles promueven el desarrollo sostenido. Los patroci-
nadores, desarrolladores y usuarios deben mantener un ritmo constante
de forma indefinida.
La respuesta al cambio, • Son bienvenidos los requisitos cambiantes, incluso si llegan tarde
por encima del segui- al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja
miento de un plan competitiva para el cliente.
Figura 2.10. Los doce principios del Manifiesto Ágil
Fuente: Dimes T. Conceptos básicos de Scrum: desarrollo de software Agile
y manejo de proyectos Agile, Babelcube, Inc. 2015.
58
Existen continuas similitudes entre las metodologías ágiles y la filosofía de mejora con-
tinua Lean. El primer principio Lean enunciado por Womack y Jones hace referencia a
la satisfacción del cliente, aportando valor al producto o servicio que se le presta. Este
enfoque también es compartido por el Manifiesto Ágil. El tercer principio Lean (trabajar
en flujo), se consigue en la metodología ágil con las entregas frecuentes de software. As-
pectos como la mejora continua, quinto principio Lean, se recogen expresamente en el
manifiesto (Lledó, 2012).
Lean otorga una especial importancia a las personas, su motivación y contribución a la

mejora continua, así como a la búsqueda de soluciones sencillas. Estos dos aspectos tam-
bién son recogidos en los principios ágiles.
Detrás del pensamiento ágil existen varias herramientas o técnicas específicas para ges-
tionar proyectos, por ejemplo:
• Adaptive Software Development (ASD).
• Crystal Clear.
• Método de desarrollo de sistemas dinámicos (DSDM).
• Extreme Programming.
• Feature Driven Development (FDD).
• Lean Development.
• Kanban.
• Pragmatic Programming.
• Scrum.
• Etc.
Aunque estas metodologías surgieron y se desarrollaron a partir de entornos relaciona-

dos con el desarrollo de software, cada vez más se utilizan en otros entornos de negocio
que cambian y evolucionan rápidamente.
59
2.2.9. Metodologías ágiles

Varias metodologías encajan bajo el estandarte de ágil. Mientras todas ellas comparten
muchas características, también hay algunas diferencias significativas. A continuación, se
muestra una breve descripción de algunas de ellas:
XP (programación extrema)
Según Sommerville (2005), la programación extrema (XP) es posiblemente uno de los

métodos ágiles más conocido y ampliamente utilizado para el desarrollo de software. El
nombre fue acuñado por Ken Beck, autor del primer libro sobre la materia (Extreme Pro-
gramming Explained: Embarce Change; 1999), debido a que el enfoque fue desarrollado
utilizando buenas prácticas reconocidas, como el desarrollo iterativo, y con la participa-
ción del cliente en niveles “extremos”.
La primera aplicación de programación extrema se atribuye a Ken Beck en Chrysler Cor-

poration en 1996 para desarrollar una aplicación de nóminas.
En la programación extrema, todos los requerimientos se expresan como escenarios (lla-

mados historias de usuario) a través de las siguientes etapas:
• Las historias de usuarios, con los requerimientos del cliente, se dividen en una
serie de tareas.
• Se planifican entregas del sistema pequeñas y frecuentes.
• Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes
de escribir el código.
• La integración en el sistema se produce cuando todas las pruebas realizadas con el

código nuevo se ejecutan satisfactoriamente.
• Con el fin de poder evaluar adecuadamente el sistema, existe un pequeño espacio

de tiempo entre las entregas.
60
La siguiente figura ilustra el proceso de la programación extrema (XP):
Figura 2.11. El ciclo de entrega en la Programación Extrema
Fuente: Fuente: Sommerville I, Alfonso Galipienso ML. Ingeniería del
software 7ª ed. Pearson Education; 2005. p. 364
La programación extrema implica varios valores que se ajustan a los principios de los mé-
todos ágiles: simplicidad, comunicación, retroalimentación (feedback), coraje y respeto.
Una de las características de la programación extrema es que el cliente participa a tiempo

completo en el equipo de desarrollo, lo que permite una mayor agilidad en la definición
de requisitos y en las pruebas de aceptación del sistema.
Código abierto
El código abierto es un estilo de software, no tanto un proceso. Sin embargo, hay una ma-
nera definida de hacer las cosas en la comunidad de código abierto, y mucho de su acerca-
miento es tan aplicable a los proyectos de código cerrado como a los de código abierto. En
particular, su proceso se engrana a equipos físicamente distribuidos, lo que es importante
porque la mayoría de los procesos adaptables exigen equipos locales (Bucero, 2013).
Scrum
Scrum es un marco de trabajo ágil y estructurado que permite que equipos de desarrollo
de software, en colaboración con sus clientes, puedan desarrollar productos innovadores
y complejos en un ambiente de confianza y en base a unas pocas reglas simples (Lledó,
2014). Según este autor, este marco de trabajo plantea una simplificación respecto a las
metodologías tradicionales que prosperaron en los años noventa y que podrían ser consi-
deradas como “pesadas”.
61
Según el creador de Scrum, Sutherland (2015), es un cambio radical respecto a los anti-
guos modelos de gestión de proyectos de arriba abajo. Scrum, al contrario que aquellos
métodos, está en la línea de los sistemas evolutivos, adaptativos y que se autocorrigen.
Desde que se ideó, el marco de trabajo que ofrece el Scrum se ha hecho famoso y se ha
convertido en la forma habitual en que la industria tecnológica crea nuevo software y
nuevos productos, aunque sigue siendo relativamente desconocido en los negocios de
otro tipo.
Los conceptos en los que se basa Scrum son los siguientes (Lledó, 2014):
• En los proyectos experimentales, los métodos predictivos son menos efectivos que
los enfoques iterativo-incrementales que presentan al cliente resultados de forma
temprana, sobre los cuales él mismo puede hacer ajustes y correcciones.
• Los equipos de profesionales bien preparados y automotivados se desarrollan me-

jor y producen mejores resultados si trabajan en equipos autogestionados en el
que cada uno toma responsabilidad sobre su trabajo y se compromete con la cali-
dad siguiendo sus propios procesos para lograrlo.
• La colaboración constante con el cliente y patrocinador tiene más posibilidades de

éxito que aquellos proyectos en los que estos interesados se involucran solo en el
principio del proyecto y luego al final para aprobar o no el producto o servicio fi-
nal. Al tener una colaboración constante, los cambios de requerimientos se podrán
detectar rápidamente e incorporar al proyecto en las iteraciones siguientes para
entregar al cliente un producto alineado a las necesidades de su negocio.
Scrum se basa en un ciclo de vida iterativo incremental que persigue el objetivo de opti-
mizar la previsibilidad y controlar el riesgo. En Scrum, cada iteración se denomina sprint
y tiene una duración fija de dos a cuatro semanas. Durante este periodo se realizan los
trabajos seleccionados y al finalizar cada sprint se obtiene como resultado un producto
que provee alguna funcionalidad al cliente.
Scrum es, por tanto, un marco de trabajo por el cual las personas pueden acometer pro-
blemas complejos adaptativos a la vez que entregar productos del máximo valor posible
productiva y creativamente (Schwaber y Sutherland, 2013).
Scrum puede ser considerada como una metodología ligera y fácil de entender, pero al
mismo tiempo extremadamente difícil de llegar a dominar.
El marco de trabajo Scrum consiste en los equipos Scrum, roles, eventos, artefactos y
reglas asociadas. Cada componente, dentro del marco de trabajo, sirve a un propósito es-
pecífico y es esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan
los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos.
62
Las reglas de Scrum pueden resumirse en la siguiente figura:
Exposición de Estimación del

prioridades. esfuerzo para cada
Resolución de dudas. historia de usuario.
Presentación del
Revisión del avance. incremento, sugerencias,
Objetivo del Sprint Resolución de impedimento. anuncio próximo sprint.
Planificación del Sprint Scrum diario Revisión del sprint
Retrospectiva
ROLES ARTEFACTOS EVENTOS
PLANIFICACIÓN
PILA DEL
PROPIETARIO DEL SPRINT
PRODUCTO
DEL PRODUCTO 1.Jornada de trabajo
Relación de requisitos
Determina las (max.) El propietario del
del producto, no es
prioridades. producto explica las priori-
necesario excesivo
Una sóla persona dades. El equipo estima el
detalle. El propietario
esfuerzo de los requisitos
del producto es su
prioritarios y se elabora la
responsable y quien
pila del sprint. El equipo
decide.
EQUIPO DE define en una frase el
DESARROLLO objetivo del sprint.
Construye el PILA DEL SPRINT
producto Requisitos com-
SPRINT
prometidos por el
Ciclo de desarrollo básico
equipo para el sprint
en el marco estándar
con nivel de detalle
de scrum, de duración
SCRUM MASTER suficiente para su
recomendada inferior a un
Gestiona y facilita la ejecución.
mes y nunca mayor de 6
ejecución de las reglas
semanas.
de Scrum INCREMENTO
Parte del producto
SCRUM DIARIO
desarrollada en un
15 minutos máximo. Res-
sprint, en condicio-
INTERESADOS ponsabilidad del equipo.
nes de ser usada
Resto de implicados. Cada miembro expone: Lo
(pruebas, codificación
Asesoran y observan que hizo ayer. Lo que va a
limpia y documen-
hacer hoy, si tiene o prevé
tada).
problemas. Se actualiza la
pila del sprint.
REVISIÓN DEL SPRINT

Figura 2.12. Las reglas de Scrum Informativa, máx. 4 horas,
presentación del incre-
Fuente: Palacio J. Gestión Proyectos Scrum Manager. mento, planteamiento de
sugerencias y anuncio del
Versión 2.5.1; 2015. p. 21. próximo sprint.
Disponible en: RETROSPECTIVA

El equipo autoanaliza la
forma de trabajo. Identifi-
http://www.scrummanager.net/bok/index.php?title=Scrum:_
componentes_y_marco cación de fortalezas y de-
bilidades. Refuerzo de las
primeras, plan de mejora
de las segundas.
63
Scrum prescribe cuatro eventos formales, contenidos dentro del sprint, para la inspección
y adaptación:
• Reunión de planificación del sprint (Sprint Planning Meeting): el propietario del

producto explica las prioridades y el equipo estima los esfuerzos requeridos. Se
identifican los sprints (mejoras) a desarrollar.
• Scrum diario (Daily Scrum): permite revisar diariamente y de forma muy rápida,
apenas 15 minutos, la evolución del proyecto.
• Revisión del sprint (Sprint Review): se revisa el sprint (mejora) anterior, se plan-
tean sugerencias y se presenta el próximo sprint o mejora.
• Retrospectiva del sprint (Sprint Retrospective): el equipo autoanaliza su forma de

trabajar identificando planes de mejora.
2.3. Ciclo de vida del proyecto

Los directores de proyecto o la organización pueden dividir los proyectos en fases para
proporcionar un mejor control con las relaciones apropiadas de las operaciones en mar-
cha. Globalmente, estas fases se llaman ciclo de vida de proyecto. El ciclo de vida del
proyecto define las fases que conectan el comienzo con su fin. Una característica esencial
para el éxito de los proyectos en las organizaciones es definir un ciclo de vida lo más sen-
cillo y descriptivo que sea posible (Bucero, 2013).
Un ciclo de vida, por ejemplo, para un proyecto de desarrollo de software podría constar
de las siguientes fases:
• Fase 1: Análisis.
• Fase 2: Diseño.
• Fase 3: Desarrollo e implantación.
• Fase 4: Producción.
• Fase 5: Garantía y Soporte.
Para cada una de estas fases que constituyen el ciclo de vida del proyecto deberá definirse:
• Actividades a realizar.
• Entregables a generar en cada fase, en qué plazo y qué criterios de aceptación de

los mismos serán utilizados.
64
• Personas involucradas.
• Criterios de control y aprobación de cada una de las fases.
Todos los proyectos, por tanto, tienen un ciclo de vida (Chamoun, 2002). Se inician, se
desarrollan en varias etapas o fases y terminan. Las fases del proyecto pueden traslaparse,
subdividirse o reagruparse; sin embargo, ninguna puede ser eliminada sin acarrear fuer-
tes problemas a las siguientes fases.
Los ciclos de vida del proyecto pueden ser:
• Ciclos de vida predictivos. Este enfoque se realiza en proyectos en los que una
exhaustiva planificación es clave para asegurar el éxito del proyecto. Ejemplos de
este ciclo de vida predictivo podemos encontrarlos en obras de construcción com-
plejas como un túnel, un aeropuerto o un software crítico. En estos casos, los as-
pectos esenciales como el alcance, el costo y el tiempo tienen que ser acotados lo
antes posible para poder desarrollar adecuadamente la planificación del proyecto,
la cual requiere de un considerable esfuerzo. Aunque se asume que habrá cambios,
en este tipo de ciclo de vida las modificaciones en aspectos básicos del proyecto re-
quieren un importante esfuerzo de reajuste de todo el proyecto (planificación, eje-
cución, control), por lo que no es aconsejable en entornos altamente cambiantes.
• Ciclos de vida adaptativos. También conocidos como métodos orientados al cam-

bio o métodos ágiles. Aunque puede definirse el resultado final que se pretende
conseguir, se desconoce la hoja de ruta que hay que seguir. Esta será ajustada con-
tinuamente conforme avanza el proyecto en función de los logros obtenidos y el
feedback de los miembros del equipo, cliente y partes interesadas. Un ejemplo cla-
ro de este tipo de ciclo de vida podemos encontrarlo en los proyectos de investiga-
ción. Supongamos que el objetivo de nuestro proyecto es encontrar una cura para
el virus del Ébola. Primero tendremos que estudiar cómo se contagia, cómo afecta
al cuerpo humano, sus efectos y duración, cómo muta... Con toda esta información
se podrá definir la siguiente fase, que es identificar qué tipo de fármaco sería el
más conveniente (antibióticos, inmunosupresores, polifármacos, antineoplásicos,
antiinfecciosos, etc.). A continuación, se realizarán estudios clínicos para detectar
si es efectivo o no. La cantidad y duración de los estudios será definida por el equi-
po en función de múltiples parámetros, entre ellos la bibliografía disponible y la
urgencia. Seguramente se tendrán que llevar a cabo múltiples ajustes en el tipo de
fármaco y en la dosis hasta encontrar una combinación que minimice los efectos
secundarios y sea plenamente efectiva. Otro ejemplo típico de este ciclo de vida lo
encontramos en los proyectos tecnológicos.
65
• Ciclos de vida iterativos e incrementales. Son aquellos en los cuales, dentro de

las fases del proyecto (también llamadas iteraciones), se repiten de manera inten-
cionada una o más actividades del proyecto a medida que aumenta el entendi-
miento del producto por parte del equipo del proyecto.
• Un ejemplo podría ser un proyecto de una página web corporativa de una empresa
en la que se desarrolla la estructura de la página el primer mes, las tres primeras
secciones de la misma el segundo mes, el área de clientes el tercer mes, y así su-
cesivamente. Esto permite al usuario final ir testando y reportando feedback del
producto semiterminado conforme avanza el proyecto (PMI, 2013).
Independientemente del tamaño y complejidad de los proyectos, así como de su ciclo de

vida (predictivo, adaptativo o iterativo), todos los proyectos pueden estructurarse de la
siguiente manera:
• Inicio.
• Organización y preparación.
• Ejecución.
• Cierre.
Veamos a continuación algunas consideraciones en cuanto al ciclo de vida de los proyec-

tos (PMI, 2013).
El coste del proyecto y la dotación de recursos de personal se incrementan a lo largo de

las primeras fases del proyecto, inicio y organización, hasta llegar a su máximo en la fase
de ejecución del trabajo, como podemos ver reflejado en la siguiente figura:
66
Figura 2.13. Niveles típicos de costo y dotación de personal en
una estructura genérica de ciclo de vida del proyecto
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de
Aunque esta curva es típica para la mayoría de los proyectos, puede haber casos en los
que tenga una configuración racialmente diferente, por ejemplo, porque sea necesario
dotar recursos de personal desde el primer momento o hacer estudios previos en las pri-
meras fases que supongan un alto coste.
La incertidumbre y los riesgos asociados al proyecto disminuyen a lo largo de la vida del

proyecto, como puede verse en la figura, según se va dando forma al proyecto a través de
los entregables y la toma de decisiones por parte del equipo.
67
Esta misma figura nos muestra que el coste de los cambios se incrementa considerable-
mente conforme evoluciona el proyecto, especialmente en los ciclos de vida predictivos.
Por ello es importante definir con la mayor precisión posible los requerimientos, sobre
todo en las primeras fases, y proceder a su validación por todas las partes implicadas an-
tes de comenzar la siguiente. Imaginemos el proyecto de reforma de una vivienda: el coste
de cambiar el suelo no es el mismo cuando el cliente ya está instalado en su vivienda,
antes de su entrega, antes de comprar el material o durante la fase de diseño de la refor-
ma. Identificar posibles cambios en las primeras fases es fundamental para que aspectos
como el alcance, el coste o el tiempo no repercutan de forma negativa en la evolución del
proyecto.
Figura 2.14. Impacto de las variables en función del tiempo del proyecto
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de Proyectos (Guía del
PMBOK). Project Management Institute, Inc.; 2013. p. 40
Dato importante
A diferencia de los proyectos predictivos o tradicionales, la gestión de proyectos

ágil no se basa en la anticipación, sino en la continua adaptación a las necesidades
del cliente, la evolución del mercado y las innovaciones tecnológicas. Esto implica
dejar de tener “productos finales” o “entregables” a favor de productos en continua
evolución y mejora.
68
2.3.1. Ciclo de vida del producto y ciclo de vida del proyecto

Es importante no confundir el ciclo de vida de un producto o sistema y el ciclo de vida del
proyecto. La siguiente figura ilustra el ciclo de vida de los sistemas y las distintas fases
que lo conforman:
Identificación
y definición de
Análisis de
la necesidad
mercado
Retirada
de servicio
Estudio de
viavilidad
Vida de
servicio
n
ificació
Espec isitos
u
de req
Producción
Diseño
Figura 2.15. Ciclo de vida de los sistemas
Fuente: Sols Rodríguez-Candela A, Fernández Fernández I, Romero Yacobi J. Gestión integral de proyectos.
Unión de Editoriales Universitarias Españolas; 2013. p. 40
Del mismo modo que un producto o sistema tiene su ciclo de vida, los proyectos en sí
mismos también puede considerarse que tienen un ciclo de vida, cuyas fases en líneas
generales pueden definirse como sigue:
• Fase inicial: implica el lanzamiento del proyecto, la definición de su alcance y de

los objetivos a conseguir.
• Fase intermedia: en esta fase se ejecutan los procesos de planificación, ejecución, y

seguimiento y control; es decir, los procesos principales del proyecto.
• Fase final: supone el cierre del proyecto, analizándose los resultados finales obteni-
dos y las lecciones aprendidas.
69
Los proyectos están vinculados a alguna o a todas las fases del ciclo de vida de un siste-
ma. Puede haber proyectos de adquisición, proyectos de desarrollo, proyectos de mejora o
actualización, proyectos de enajenación, etc., que cubren una o más fases del ciclo de vida
del sistema. Por este motivo, la vida de un proyecto es normalmente más corta que la vida
de un sistema. Hay proyectos que no están necesariamente vinculados a sistemas, sino
que tienen como producto final un servicio. Para estos proyectos, se aplican las mismas
consideraciones mencionadas, pero con las adaptaciones necesarias (Sols y otros, 2013).
La siguiente figura muestra un ejemplo de la relación entre el ciclo de vida de un sistema

o producto y el ciclo de vida de un proyecto para el caso típico de un proyecto de adquisi-
ción, desarrollo o fabricación de un producto.
Figura 2.16. Ciclo de vida del producto y ciclo de vida del proyecto
Fuente: Sols Rodríguez-Candela A, Fernández Fernández I. Romero Yacobi J. Gestión
integral de proyectos. Unión de Editoriales Universitarias Españolas; 2013. p. 44
70
2.4. Fases del proyecto

Para simplificar la gestión del proyecto, este puede dividirse en fases. Cada una de las
fases contiene una secuencia lógica de actividades, con un comienzo y un final perfecta-
mente definibles y un entregable claramente establecido. El número de fases y su alcance
viene determinado por la naturaleza del proyecto y el tamaño de la organización. En el
ejemplo mostrado en la figura se aborda el proyecto de limpieza de un lugar con desechos
peligrosos. Si el alcance es pequeño, pongamos que consista en la limpieza del patio de
una pequeña empresa, podría ser factible considerar todo el proyecto en una única fase.
Sin embargo, si se trata de la limpieza de un vertedero de una gran ciudad, sería claramen-
te recomendable establecer fases que nos ayuden a gestionar de una forma más adecuada
el proyecto. En este caso, las fases que podrían ser establecidas son:
• Desmantelamiento de la instalación.
• Eliminación/limpieza de desechos.
• Paisajismo.
Figura 2.17. Ejemplo de proyecto de tres fases
(Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 43
Cada una de estas fases actúa como un mini-proyecto por lo que es probable que la mayor
parte o todos los procesos (inicio, planificación, ejecución, monitoreo y control y cierre)
sean ejecutados de alguna manera en cada fase.
Los criterios para el establecimiento de las fases del proyecto pueden ser definidos por
el equipo del proyecto o definirse de forma estandarizada para todos los proyectos de la
organización. En cualquier caso, proyectos similares dentro de la misma organización de-
berían dividirse en fases siguiendo criterios análogos con el objetivo de facilitar la trans-
ferencia de información entre proyectos.
71
Habitualmente las fases del proyecto se completan secuencialmente, de tal forma que una
fase solo se inicia cuando ha finalizado la fase anterior. Otra posibilidad es que las fases
se desarrollen en paralelo o superpuestas, iniciándose antes de que finalice la anterior. A
continuación, se muestra un ejemplo de proyecto con fases superpuestas:
Figura 2.18. Ejemplo de proyecto con fases superpuestas
La superposición de fases presenta alguna ventaja importante, como permitir una ejecu-
ción más rápida del proceso, pero al mismo tiempo tiene desventajas al requerir recursos
adicionales para permitir que el trabajo se realice en paralelo y supone un riesgo si se
avanza en algunas fases sin tener toda la información necesaria.
Otro ejemplo de proyecto con fases superpuestas podría ser la construcción de un nue-
vo hospital. Al mismo tiempo que se ejecuta la obra, se podrían ir comprando los equi-
pos electromédicos necesarios y configurar la historia clínica informatizada. Este avance
en paralelo permite acortar el plazo final del proyecto. Sin embargo, si estas fases no se
sincronizan adecuadamente y no se traslada la información necesaria, podríamos encon-
trarnos con un equipo electromédico que no puede instalarse porque carece de toma de
datos, electricidad, agua, gases, protección radiológica, etc., o con una historia clínica que
no es capaz de capturar automáticamente la información que genera un sofisticado equi-
po electromédico.
72
Dato importante
Los proyectos están vinculados a alguna o a todas las fases del ciclo de vida de un
sistema. Puede haber proyectos de adquisición, proyectos de desarrollo, proyectos
de mejora o actualización, proyectos de enajenación, etc., que cubren una o más
fases del ciclo de vida del sistema. Por este motivo, la vida de un proyecto es normal-
mente más corta que la vida de un sistema.
2.5. Procesos de la dirección de proyectos

La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas
y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Esta
aplicación de conocimientos requiere la gestión eficaz de los procesos de dirección de
proyectos (PMI, 2013).
Podemos definir un proceso como un conjunto actividades, acciones o tareas relacionadas

entre sí que se realizan para crear un producto o servicio. Cada proceso tiene asociado
unas entradas, salidas y herramientas.
Figura 2.19. Descripción de proceso
Los procesos del proyecto son ejecutados por el equipo del proyecto con la participación
activa de las partes interesadas y pueden ser de dos tipos:
• Procesos de la dirección de proyectos: estos procesos están orientados a asegu-

rar que el proyecto se ejecuta adecuadamente a lo largo de su ciclo de vida.
• Procesos orientados al producto: estos procesos están orientados a producir el

producto servicio objeto del proyecto.
73
Los procesos de la dirección de proyectos pueden agruparse en cinco categorías conoci-

das como grupos de procesos de la dirección de proyectos (PMI, 2013):
• Grupo de procesos de inicio: se consideran procesos de inicio los necesarios para

definir un nuevo proyecto o una nueva fase de un proyecto que ya se está ejecu-
tando.
• Grupo de procesos de planificación: los procesos de planificación incluyen todos

los procesos necesarios para definir el alcance del proyecto, establecer los objeti-
vos y trazar el plan de acción del proyecto.
• Grupo de procesos de ejecución: reúne los procesos que hay que llevar a cabo
para completar el trabajo planificado.
• Grupo de procesos de monitoreo y control: los procesos de monitoreo y control

permiten revisar la ejecución del proyecto y gestionar los cambios en caso de que
fuese necesario.
• Grupo de procesos de cierre: se consideran procesos de cierre los necesarios para

finalizar formalmente un proyecto o una fase del proyecto.
Aunque la terminología resulte parecida, recordemos que los grupos de procesos no son
lo mismo que las fases del ciclo de vida del proyecto. Los grupos de procesos pueden
ejecutarse, y de hecho habitualmente se hace así, en cada una de las fases del proyecto.
Si retomamos el ejemplo de la construcción de un nuevo hospital, para cada una de las
fases del mismo (obra, compra de equipamiento, aplicaciones informáticas, etc.) aplica-
remos los cinco grupos de procesos: inicio, planificación, ejecución, monitoreo y control,
y cierre. La siguiente figura ilustra cómo los grupos de procesos interactúan en una fase
o proyecto:
74
Figura 2.20. Los grupos de procesos interactúan en una fase o proyecto
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de
El diagrama de flujo de procesos mostrado a continuación proporciona un resumen glo-

bal del flujo básico y de las interacciones entre los grupos de procesos y los interesados
concretos. Los procesos de la dirección de proyectos están vinculados por entradas y sali-
das específicas, de modo que el resultado de un proceso se convierte en la entrada de otro
proceso, aunque no necesariamente en el mismo grupo de procesos.
75
Figura 2.21. Interacciones entre Procesos de la dirección de Proyectos
76
2.5.1. Grupo de procesos de inicio

El propósito de la fase de inicio es configurar el proyecto para su correcta consecución.
A menudo se argumenta que es la fase más importante del ciclo de vida de un proyecto,
ya que si no se realiza el resultado puede ser catastrófico. Después de todo, el comienzo
de un proyecto es el mismo instante en que el cliente firma el contrato (bien formal, bien
informal) que explica lo que se va a llevar a cabo, una descripción sencilla de cómo se va
a realizar y cuándo se dará por bueno el trabajo (Williams, 2008).
En los procesos de inicio deben explicitarse claramente:
• Alcance inicial.
• Recursos financieros (una primera aproximación).
• Partes interesadas en el proyecto (internas y externos).
• Director del proyecto.
Figura 2.22. Límites del Proyecto
Fuente: Project Management Institute. Guía de los Fundamentos para la
Dirección de Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 54
77
En esta fase debe disponerse de información relacionada con el proyecto que se plasma
en el documento inicial del proyecto, que no debe confundirse ni reemplazarse por el con-
trato legal. Este documento inicial del proyecto debe incluir (Williams, 2008):
• La razón de ser del proyecto.
• Lo que se debe entregar y cómo se tiene que hacer.
• Quién va a ocuparse de qué cosas.
• Los tiempos en que se entregarán las distintas partes del proyecto.
2.5.2. Grupo de procesos de planificación

El grupo de procesos de planificación actúa como un plan de vuelo o navegación contra
el cual compararemos el avance para evaluar periódicamente el desempeño del proyecto
(Chamoun, 2002).
Siguiendo con esta analogía, para poder establecer correctamente el plan de vuelo o na-
vegación necesitamos tener en cuenta una serie de consideraciones importantes relacio-
nadas con los siguientes aspectos:
• Alcance.
• Tiempo.
• Costo.
• Calidad.
• Comunicaciones.
• Recursos humanos.
• Riesgos.
• Adquisiciones.
• Participación de los interesados.
78
Como resultado del grupo de procesos de planificación obtendremos:
• Alcance total del proyecto.
• Definición de los objetivos.
• Línea de acción.
Toda esta información se plasmará en el plan para la dirección del proyecto y su docu-
mentación derivada. Este plan es posible que exija varias revisiones o iteraciones, hasta
que todas las partes interesadas estén conformes con el mismo. Pero recordemos que, aun
así, la planificación no es estática y que puede incluir modificaciones a medida que el
proyecto evolucione y se disponga de más información, o que precise de la incorporación
de cambios por requerimiento del cliente o como resultado de la propia ejecución del
proyecto.
2.5.3. Grupo de procesos de ejecución

El grupo de procesos de ejecución coordina, integra y gestiona todos los recursos
(Ocaña, 2012):
• ¿Para qué? Para lograr los objetivos del proyecto.
• ¿Cómo? Llevando a cabo el plan del proyecto.
• Mientras se responde a cambios y se mitigan los riesgos.
Este grupo de procesos está compuesto por aquellos procesos realizados para completar
el trabajo definido en el plan para la dirección del proyecto, a fin de cumplir con las espe-
cificaciones del mismo.
Este grupo de procesos implica:
• Coordinar personas y recursos.
• Gestionar las expectativas de los interesados.
• Integrar y realizar las actividades del proyecto conforme al plan para la dirección.
79
Durante la ejecución del proyecto, en función de los resultados obtenidos, se puede reque-
rir una actualización de la planificación y una revisión de la línea base. Esto puede incluir
cambios en la duración prevista de las actividades, cambios en la disponibilidad y produc-
tividad de los recursos, así como riesgos no previstos. Tales variaciones pueden afectar
al plan para la dirección del proyecto o a los documentos del proyecto y pueden requerir
un análisis detallado y el desarrollo de respuestas de dirección de proyectos adecuadas.
Los resultados del análisis pueden dar lugar a solicitudes de cambio que, en caso de ser
aprobadas, podrían modificar el plan para la dirección del proyecto u otros documentos
del mismo y, posiblemente, requerir el establecimiento de nuevas líneas base. Gran parte
del presupuesto del proyecto se utilizará en la realización de los procesos del grupo de
procesos de ejecución (Guía del PMBOK, 2013).
2.5.4. Grupo de procesos de monitoreo y control

De nada sirve un plan si no se sigue. Pero incluso ejecutando el plan tal y como se dise-
ñó, es necesario controlar que efectivamente se está haciendo así y que no hay errores o
defectos que hubieran podido pasar inadvertidos, que toda la documentación se recoge
y está disponible según lo acordado, que los requerimientos del cliente siguen siendo los
inicialmente establecidos y que no se han modificado por circunstancias intrínsecas al
proyecto o externas al mismo.
Este enfoque nos recuerda al propio ciclo de mejora continua o ciclo PDCA: planificar,
hacer, comprobar, actuar. Los grupos de procesos de monitoreo y control permiten revisar
el correcto avance del proyecto en intervalos regulares de tiempo (cada x meses), coin-
cidiendo con la finalización de una fase, en situaciones anormales o excepcionales, o en
momentos considerados clave.
La ejecución de este grupo de procesos también implica (PMI, 2013):
• Comparar la ejecución de las actividades del proyecto con el plan para la dirección
del proyecto y con la línea base para la medición del desempeño del proyecto.
• Recomendar acciones correctivas o preventivas para anticiparse a posibles proble-

mas.
• Controlar los cambios, garantizando que todos ellos estén aprobados.
• Proporcionar información al equipo del proyecto y demás partes interesadas sobre

la evolución del proyecto.
• Identificar áreas que precisan una mayor atención.
• Actualizar la documentación del proyecto fruto de la revisión.
80
2.5.5. Grupo de procesos de cierre

Una vez finalizado el proyecto o una fase del proyecto, parece evidente la necesidad de
analizar los resultados y recapitular el curso de los hechos, para hacerse una idea clara
de los objetivos cumplidos, de los que no se han alcanzado y de la utilidad futura en otras
fases o proyectos del trabajo realizado (Domingo Ajenjo, 2000).
Además del objetivo fundamental de analizar económicamente el resultado de la fase o

proyecto y conocer si ha sido beneficioso o no para la organización en los términos pre-
vistos inicialmente, existen otros objetivos adicionales en los procesos de cierre de sumo
interés para el desempeño de futuros proyectos:
• Identificar y analizar las razones de las desviaciones entre la previsión inicial y la

ejecución final.
• Implantar acciones correctivas o preventivas que eviten que las causas que origi-
naron estas desviaciones puedan volver a repetirse.
• Corregir, para futuras fases o proyectos, las actuaciones inadecuadas que dieron
lugar a las desviaciones.
• Recopilar las lecciones aprendidas y el conocimiento experto derivado de la eje-

cución de la fase o del proyecto. Este conocimiento hace referencia al resultado
técnico del proyecto y a la forma en la que el proyecto se ha desarrollado. La trans-
ferencia de información en este sentido puede ayudarnos a que las buenas prác-
ticas se extiendan a futuras fases o proyectos y a que no se vuelvan a cometer los
mismos errores.
• Identificar nuevos nichos de negocio surgidos de la ejecución del proyecto. El

resultado de la ejecución de un proyecto de fabricación de una máquina puede
hacernos reflexionar si disponemos de recursos para poder afrontar el diseño o
el mantenimiento de la misma. Si esto fuera posible, daría lugar a nuevas oportu-
nidades comerciales.
81
2.6. Áreas de conocimiento de la dirección de proyectos

Además de los cinco grupos de procesos de la dirección de proyectos descritos ante-
riormente (inicio, planificación, ejecución, monitorización y control, y cierre), existen una
serie de áreas de conocimiento que deben utilizarse en la gestión de los proyectos para
garantizar que se abordan adecuadamente todos los aspectos que pueden influir en el
desempeño del proyecto.
Antes de seguir profundizando, recordemos que tanto los grupos de procesos/fases, como
las áreas/temáticas pueden variar en función del estándar de dirección de proyectos ele-
gido. A modo de ejemplo, veamos los procesos y áreas de conocimiento del PMBOK y las
fases y temáticas de PRINCE2:
Procesos PMBOK Fases PRINCE2
Inicio Puesta en marcha (preproyecto)
Planificación Dirección del proyecto
Ejecución Inicio del proyecto
Monitorización y control Control de fase
Cierre Gestión de la entrega de productos
Gestión de los límites de fase
Cierre del proyecto
82
Áreas conocimiento PMBOK Temáticas PRINCE2
Gestión de la integración del proyecto Modelo de negocio o business case
Gestión del alcance del proyecto Organización
Gestión del tiempo del proyecto Calidad
Gestión de los costes del proyecto Planes
Gestión de la calidad del proyecto Riesgo
Gestión de los recursos humanos del proyecto Cambio
Gestión de las comunicaciones del proyecto Progreso
Gestión de los riesgos del proyecto
Gestión de las adquisiciones del proyecto
Gestión de los interesados del proyecto
Figura 2.23. Procesos / Áreas conocimiento PMBOK y Fases / Temáticas PRINCE2
Fuente: Elaboración propia
Continuando con el estándar del PMBOK (PMI, 2013), este identifica diez áreas de co-
nocimiento de dirección de proyectos, áreas explícitas que requieren de conocimientos
específicos para dirigir un proyecto y que se utilizarán en mayor o menor intensidad en
función del proyecto específico que estemos abordando.
Estas diez áreas de conocimiento se utilizan en la mayoría de los proyectos durante la

mayor parte del tiempo. Combinando los grupos de procesos y las áreas de conocimiento
resulta una matriz de 47 procesos de la dirección de proyectos, reconocidos como buenas
prácticas y aplicables a la mayoría de los proyectos.
A continuación, se muestra una tabla de correspondencia entre los cinco grupos de proce-
sos de la dirección de proyectos y las diez áreas de conocimientos de la dirección de pro-
yectos del PMBOK. Para facilitar el estudio de cada una de estas áreas de conocimiento,
se detalla el módulo de este máster en el que se desarrolla con más profundidad.
83
Esta tabla se ha completado con los puntos de la norma UNE-ISO 21500 Orientación so-
bre la gestión de proyectos, que no se abordan expresamente como tal en la Guía del PM-
BOK. Es destacable el alto grado de alienación entre ambas normas, aunque no se trata
en absoluto de una casualidad, teniendo en cuenta que el Project Management Institute
(PMI), autor de la Guía del PMBOK, asumió la secretaria del ISO/PC 236, grupo de traba-
jo que redactó la norma ISO 21500, publicada en su primera edición en 2012.
Grupos de Procesos de la Dirección de Proyectos
Áreas de Grupo de
Grupo de Grupo de Grupo de Grupo de
conocimiento/ procesos de
procesos procesos de procesos de procesos
temas en los que monitoreo
de inicio planificación ejecución de cierre
se desarrollan y control
• Monitorear • Cerrar
y controlar proyecto
el trabajo del o fase
• Desarrollar • Desarrollar • Dirigir y
8.- Gestión de proyecto
el acta de el plan para gestionar el
la integración • Recopilar
constitución la Dirección trabajo del
del proyecto • Realizar las leccio-
del proyecto del Proyecto proyecto
el control nes apren-
integrado didas (ISO
de cambios 21.500)*
• Planificar
la gestión
del alcance
• Validar el
• Recopilar
3.- Gestión alcance
requisitos
del alcance
del proyecto • Controlar
• Definir el
el alcance
alcance
• Crear la
EDT/WBS
• Planificar la
gestión del
cronograma
• Definir las
actividades
• Secuenciar
las actividades
3.- Gestión
• Controlar el
del tiempo
• Estimar los cronograma
del proyecto
recursos de las
actividades
• Estimar la
duración de las
actividades
• Desarrollar el
cronograma
84
Áreas de Grupo de
• Planificar
la gestión de
los costos
3.- Gestión
• Controlar
de los costes • Estimar
los costos
del proyecto los costos
• Determinar
el presupuesto
• Realizar
4.- Gestión • Planificar
el asegura- • Controlar
de la calidad la gestión de
miento de la calidad
del proyecto la calidad
calidad
• Planificar
la gestión de • Adquirir el
• Controlar
los recursos equipo del
los recur-
humanos proyecto
sos (ISO
• Establecer
5.- Gestión de 21.500)**
el equipo • Estimar los • Desarrollar
los recursos
de proyec- recursos (ISO el equipo del
humanos del • Gestionar
to (ISO 21.500)** proyecto
proyecto el equipo
21.500)**
del pro-
• Definir la or- • Dirigir el
yecto (ISO
ganización del equipo del
21.500)**
proyecto (ISO proyecto
21.500)**
• Gestionar • Controlar
las comu- las comu-
nicaciones nicaciones
7.- Gestión de las • Planificar la
comunicaciones gestión de las
• Distribuir • Gestionar
del proyecto comunicaciones
la informa- las comunica-
ción (ISO ciones (ISO
21.500)* 21.500)*
85
Áreas de Grupo de
• Planificar
la gestión de
los riesgos
• Identificar
los riesgos
• Realizar el
4.- Gestión análisis cualita- • Tratar los
• Controlar
de los riesgos tivo de riesgos riesgos (ISO
los riesgos
del proyecto 21.500)*
• Realizar
el análisis
cuantitativo
de riesgos
• Planificar la
respuesta a
los riesgos
• Efectuar
las adqui-
siciones
6.- Gestión de • Planificar la • Controlar • Cerrar
las adquisiciones gestión de las las adqui- las adqui-
• Seleccionar
del proyecto adquisiciones siciones siciones
los provee-
dores (ISO
21.500)*
• Gestionar • Controlar
1.- Gestión de • Identi- • Planificar la
la participa- la participa-
los interesados ficar a los gestión de los
ción de los ción de los
del proyecto interesados interesados
interesados interesados
Figura 2.24. Correspondencia entre grupos de procesos y áreas de conocimiento de la dirección de proyectos
Fuente: Elaboración propia a partir de: Project Management Institute. Guía de los Fundamentos para la
Dirección de Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 61, y de la norma ISO 21.500
86
2.7. Resumen
La utilización de metodologías para la dirección de proyectos reduce la aparición de pro-
blemas a lo largo de la vida del proyecto, por lo que la probabilidad de éxito se incremen-
ta. En función de las características de la organización, tipo de proyecto, restricciones de
tiempo, coste, recursos disponibles, etc., podrán utilizarse diferentes metodologías para
la dirección de proyectos. Básicamente, se puede decir que la gestión de proyectos puede
ser predictiva (también conocida como clásica, tradicional o formal) o ágil.
La principal característica de los proyectos predictivos es que están enfocados a los pro-
cesos, pueden ser planificados con detalle y hay pocos cambios por parte del cliente. Las
metodologías de gestión de proyectos predictivas más ampliamente difundidas son PM-
BOK y PRINCE2.
Los proyectos ágiles se centran, sin embargo, en el valor o utilidad final del resultado y
se desarrollan en entornos cambiantes que hacen que tengan un componente dinámico,
impredecible, no programable inicialmente. Dentro de las metodologías ágiles podemos
citar como ejemplos: programación extrema (Xp), código abierto y Scrum.
Para simplificar la gestión del proyecto, este puede dividirse en fases. Cada una de las
fases contiene una secuencia lógica de actividades con un comienzo y un final perfecta-
mente definibles y un entregable claramente establecido. Las fases del proyecto pueden
desarrollarse secuencialmente o superpuestas, permitiendo acortar el cronograma del
proyecto, aunque esto supone un aumento de los riesgos.
La Guía del PMBOK es el referencial en gestión de proyectos más ampliamente difun-

dido y utilizado a nivel internacional, por lo que será utilizado como hilo conductor de
este máster. Esta guía identifica los procesos de la dirección de proyectos y los agrupa en
cinco categorías conocidas como grupos de procesos de la dirección de proyectos: inicio,
planificación, ejecución, monitorización y control y cierre. Estos grupos de procesos pue-
den aplicarse a cada una de las fases del proyecto y al proyecto en su conjunto. La Guía del
PMBOK identifica también diez áreas de conocimiento de dirección de proyectos, áreas
explícitas que requieren conocimientos específicos para dirigir un proyecto: integración,
alcance, tiempo, costos, calidad, recursos humanos, comunicaciones, riesgos, adquisicio-
nes e interesados.
A lo largo de los próximos módulos se profundizará en cada una de estas áreas de cono-
cimiento, abordando los procesos asociados a cada una de ellas, así como sus entradas,
salidas y herramientas.
87
Bibliografía
Publicaciones
• BETANCOURT TANG JR. Gestión Estratégica: Navegando hacia el Cuarto Para-

digma. 3ª ed. Porlamar; 2002.
• BRENES BONILLA L. Dirección Estratégica para Organizaciones Inteligentes.

Ágora; 2004.
• CHAMOUN, YAMAL. Administración Profesional de Proyectos. La Guía. McGraw-

Hill Interamericana; 2002.
• DOMINGO AJENJO A. Dirección y Gestión de Proyectos. Un enfoque práctico,

RA-MA Editorial; 2000.
• DRUCKER PF. The Essential Drucker: In One Volume the Best of Sixty Years of
Peter Drucker’s Essential Writings on Management. HarperBusiness; 2001.
• FRANCÉS A. Estrategia y planes para la empresa: con el cuadro de mando inte-

gral. Pearson Prentice Hall; 2006.
• GIDO J, CLEMENTS JP. Administración exitosa de proyectos. 5ª ed. Cengage

Learning; 2012.
• LLEDÓ P. Gestion Agil de Proyectos: Lean Project Management. Trafford Publis-

hing; 2012.
• LOCK D. Fundamentos de la Gestión de Proyectos. AENOR; 2001.
• MARTÍNEZ PEDROS D, MILLA GUTIÉRREZ A. La elaboración del plan estratégi-

co a través del Cuadro de Mando Integral. Díaz de Santos; 2005.
• NORTON RS, KAPLAN DP. STRATEGY MAPS: Converting Intangible Assets into
Tangible Outcomes. Harvard Business Review Press; 2004.
• PROJECT MANAGEMENT INSTITUTE. Guía de los Fundamentos para la Direc-

ción de Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013.
88
• PUBLICACIONES VÉRTICE. Gestión de proyectos. Editorial Vértice; 2008.
• PÜMPIN C, GARCÍA ECHEVARRÍA S. Estrategia empresarial: cómo implementar

la estrategia en la empresa. Ediciones Díaz de Santos; 1993.
• ROBERTS P. GUÍA DE GESTIÓN DE PROYECTOS: Obtener beneficios perdura-

bles a través de cambios efectivos. Gestión 2000; 2008.
• SOLS RODRÍGUEZ-CANDELA A, FERNÁNDEZ FERNÁNDEZ I, ROMERO YA-

COBI J. Gestión integral de proyectos. Unión de Editoriales Universitarias Espa-
ñolas; 2013.
• SUMMERS DC. Administración de la calidad. Pearson Education; 2006.
• VENTURA J. Análisis estratégico de la empresa. Paraninfo; 2006.
• WILLIAMS M. Introducción a la Gestión de Proyectos. Ediciones Anaya Multime-

dia; 2008.
• BECK K. Extreme Programming Explained: Embarce Change. 2ª ed. Addison-Wes-

ley Pearson Education; 2004.
• BROJT D. Project Management. Ediciones Granica; 2005.
• BUCERO TORRES A. La dirección de proyectos: Una nueva visión. 2ª ed. Díaz de

Santos; 2013.
• CHAMOUN Y. Administración Profesional de Proyectos. La Guía. McGraw-Hill

Interamericana; 2002.
• CHARVART J. Project Management Methodologies: selecting, implementing, and

supporting methodologies and processes for projects. John Wiley & Sons Inc.;
2003.
• DÍAZ MARTÍN A. David y Goliat. Planificación preliminar del Proyecto. RA-MA

Editorial; 2008.
• DIMES T. Conceptos básicos de Scrum: Desarrollo de software Agile y manejo de

proyectos Agile. Babelcube, Inc.; 2015.
• DINSMORE PC, CABANIS-BREWIN J. The AMA handbook of Project Manage-

ment. 2nd ed. American Management Association; 2006.
• DOMINGO AJENJO A. Dirección y Gestión de Proyectos. Un enfoque práctico.

RA-MA Editorial; 2000.
89
• HERZNER H. Project Management. A system approach to planning, scheduling

and controlling. John Wiley & Sons; 2001.
• HERZNER H. Project Management. Case studies. John Wiley & Sons; 2006.
• LOCK D. Fundamentos de la Gestión de Proyectos. AENOR; 2001.
• WILLIAMS M. Introducción a la gestión de proyectos. Ediciones Anaya Multime-

dia; 2008.
• LLEDÓ P. Gestión Ágil de Proyectos: Lean Project Management. Trafford Publis-

hing; 2012.
• LLEDÓ P. Gestión Lean y Ágil de proyectos. Trafford Publishing; 2014.
• OCAÑA JA. Gestión de proyectos con mapas mentales. Vol. I. ECU, Editorial Club
Universitario; 2012.
• Oficina de Comercio Gubernamental del Reino Unido. Éxito en la Gestión de Pro-

yectos con PRINCE2. 5ª ed. TSO; 2009.
• PROJECT MANAGEMENT INSTITUTE. Guía de los Fundamentos para la Direc-

ción de Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013.
• SOLS RODRÍGUEZ-CANDELA A, FERNÁNDEZ FERNÁNDEZ I, ROMERO YA-

COBI J. Gestión integral de proyectos. Unión de Editoriales Universitarias Espa-
ñolas; 2013.
• SOMMERVILLE I, ALFONSO GALIPIENSO MI. Ingeniería del software. 7ª ed.

Pearson Education; 2005.
• SUTHERLAND J. SCRUM: El nuevo y revolucionario modelo organizativo que

cambiará tu vida. Grupo Planeta Spain; 2015.
• VERHAGE L. Management Methodology for Enterprise Systems Implentations.

Eburon; 2009.
• WUTTKE T, SNIJDERS P, ZANDHUIS A. El Compañero de Bolsillo de la Guía del

PMBOK. Van Haren Publishing; 2014.
• PARÍS ROCHE F. Introducción a la metodología de gestión de “proyectos ágiles”:

un nuevo campo de aplicación en las organizaciones deportivas. Comunicación
Libre para el Congreso de FAGDE 2011.
• PALACIO J. Gestión Proyectos Scrum Manager. Versión 2.5.1; 2015.
90
Legislación y normativa
• AENOR. Dirección y Gestión de Proyectos Norma UNE-ISO 21500:2013. AENOR;

2103.
Enlaces de interés
• ASOCIACIÓN ESPAÑOLA DE DIRECCIÓN E INGENIERÍA DE PROYECTOS

AEIPRO. Mitos y Realidades acerca de la norma ISO 21.500. AEIPRO; 2013. Dis-
ponible en:
http://aeipro.com/files/noticias/2013/Mitos_y_Realidades_acerca_de_la_norma_
ISO_21500.pdf
• CARDOZA RAMÍREZ A, GUERRERO CHANDUVÍ D, DE LOS RÍOS CARMENA-

DO I. Comparación de cuatro sistemas de certificación del ámbito de la Dirección
de Proyectos. Huesca: XV Congreso Internacional de Ingeniería de Proyectos; 6-8
julio 2011. Disponible en:
http://oa.upm.es/12809/1/INVE_MEM_2011_107522.pdf
• ZABALETA ETXEBARRIA N, IGARTUA LOPEZ N, ERRASTI LOZARES JI. Aná-

lisis de la Relación Existente entre los Estándares de Gestión de Proyectos y los
Factores Críticos para su Éxito. 6th International Conference on Industrial Engi-
neering and Industrial Management. Vigo: XVI Congreso de Ingeniería de Orga-
nización; 18-20 julio 2012. Disponible en:
http://adingor.es/congresos/web/uploads/cio/cio2012/SP_02_Gestion_de_
Operaciones_y_Produccion/943-950.pdf
• CHAOS. CHAOS Manifesto 2013. Thing Big, act small. The Standish Group Inter-
national; 2013.
http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.
pdf
• LSBESBCN. PRINCE2 o PMBoK: ¿Qué es mejor para gestionar mi proyecto? 2010.

Disponible en:
http://blog.masterinprojectmanagement.net/prince2-y-pmbok
91
• PROJECT MANAGEMENT INSTITUTE. Pulse of the Profession: Capturing the

Value of Project Management. Project Management Institute, Inc.; 2015. Disponi-
ble en:
http://www.pmi.org/~/media/PDF/learning/pulse-of-the-profession-2015.ashx
• SUTHERLAND J, SCHWABER K. La Guía de Scrum. La Guía Definitiva de Scrum:

Las Reglas del Juego; 2013. Disponible en:
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf
92
CEUPE
Centro Europeo de Postgrado
Web
www.ceupe.com
E-mail
info@ceupe.com

MPM - A1 - Mod1 - Direccion Estrategica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MPM - A1 - Mod1 - Direccion Estrategica

Cargado por

Copyright:

Formatos disponibles

Módulo

1. Dirección estratégica de proyectos,

• Para acceder a un determinado mercado internacional (objetivo) es necesario dis-

• Para culminar la absorción de otra compañía (objetivo), el nuevo software a medi-

1.2. La empresa, dirección estratégica y política de empresa

La utilización masiva de Internet en el ámbito personal y profesional a lo largo de las

• Creciente complejidad de los sistemas organizativos, productivos y tecnológicos.

• Decrecientes recursos tanto económicos como de cualificación de personas.

• Multiculturalidad, convivencia entre diferentes nacionalidades, idiomas, culturas

• Múltiples subcontratistas colaborando, lo cual puede dificultar la adecuada coordi-

• Vidas operativas extendidas: la relación con el cliente se extiende durante toda la

• Creciente competencia industrial.

• Legislación cambiante y cada vez más exigente.

• Continuos cambios en los requisitos, derivados de múltiples factores, entre ellos

Visualmente podemos resumirlo gráficamente en la siguiente figura:

Figura 1.1. El entorno actual

integral de proyectos Unión de Editoriales Universitarias Españolas; 2013. p 22.

Una adecuada metodología de dirección de proyectos puede servir de facilitador para

1.2.1. La gestión estratégica

Este autor muestra la evolución de la historia empresarial en cuatro etapas claramente

Fase 1 Fase 2 Fase 3 Fase 4

Planeamiento Planeamiento basado Planeamiento con Administración

Cumplir el Planificar para el Pensar en términos

Figura 1.2. Evolución de la historia empresarial (objetivos)

Fuente: Brenes Bonilla L. Dirección Estratégica para Organizaciones

Inteligentes. Ágora; 2004. p 15

Crear el futuro implica gestionar de forma proactiva la estrategia de la organización, para

1.2.2. El mapa estratégico

Análogamente, un mapa estratégico debe proporcionar un modo simple, coherente y uni-

• La estrategia supone el equilibrio de fuerzas contradictorias. La consecución

• La correcta definición de la proposición de valor al cliente es crítica en el pro-

• El valor nace en los procesos internos. La perspectiva financiera y del cliente

• El valor de los activos intangibles nace de su capacidad para ayudar a la im-

Figura 1.3. El mapa estratégico de Kaplan y Norton

Fuente: Ventura J. Análisis estratégico de la empresa. Paraninfo; 2006. p 65

Disponer de un mapa estratégico no es en sí mismo una garantía de éxito. Es fundamen-

Para elaborar el mapa estratégico según el planteamiento de Kaplan y Norton es conve-

• Estrategia genérica y temas estratégicos: su elección constituye el punto crítico,

• Perspectiva de accionistas: los accionistas esperan que se incremente el valor de

• Perspectiva de clientes: la personalidad de cada empresa viene dada por su pro-

• Perspectiva de procesos: deben explicitarse de forma clara los objetivos, indica-

1.3. La gestión de proyectos y la empresa

Se pueden citar muchos ejemplos que responden a la noción de proyecto expuesta en

• Cada vez es más frecuente la necesidad de acometer proyectos al vivir en un mun-

• Telescopio espacial Hubble. Lanzado de 1990, de este extraordinario proyecto de

• Proyecto de mejora del Departamento de Tráfico. El Departamento de Tráfico

• Parlamento escocés. Costó diez veces más de lo proyectado. Además, se puede

• Túnel bajo el Canal de la Mancha. Constituye un magnífico logro tecnológico,

• Aeropuerto Internacional de Kansai. Este ambicioso proyecto, terminado en 1994

1.3.1. Origen de la gestión de proyectos

En la década de 1960 el éxito de un proyecto se definía solo en función a su calidad. O sea,

A estas cuatro características de proyecto exitoso deberíamos agregar también la “soste-

Habilidades requeridas por el

• En este período medimos el éxito prin-

• El éxito se mide en función del apego

Habilidades requeridas por el

• Para lograr la aceptación por parte

Figura 1.4. Evolución de la Administración de Proyectos

Fuente: Chamoun, Yamal. Administración Profesional de Proyectos.

La Guía, McGraw-Hill Interamericana; 2002

1.3.2. ¿Qué es un proyecto?

La gestión de proyectos requiere por tanto la coordinación de tiempo + equipo + dinero +

La ejecución de un conjunto de actividades no constituye en sí misma un proyecto. Para