A1 - Mod1 - Unid2 - Marco de Referencia para La Dirección de Proyectos

Módulo
Dirección Estratégica
Unidad 02
Marco de referencia
para la dirección de
proyectos
Módulo
Dirección Estratégica
Unidad 02
Marco de referencia
para la dirección
de proyecto
2. MARCO DE REFERENCIA PARA LA DIRECCIÓN DE PROYECTOS........................ 04
2.1. IMPORTANCIA DE LA GESTIÓN DE PROYECTOS ............................................. 04
2.2. METODOLOGÍAS DE DIRECCIÓN DE PROYECTOS............................................ 05
2.2.1. METODOLOGÍAS PREDICTIVAS DE GESTIÓN DE PROYECTOS .................. 09
2.2.2. PMBOK.................................................................................................... 10
2.2.3. PRINCE2.................................................................................................. 10
2.2.4. LAS TEMÁTICAS DE PRINCE2................................................................... 12
2.2.5. PMBOK VERSUS PRINCE2 ........................................................................ 14
2.2.6. POR QUÉ LAS METODOLOGÍAS ÁGILES DE GESTIÓN DE PROYECTOS...... 16
2.2.7. EL MANIFIESTO ÁGIL ............................................................................... 17
2.2.8. LOS DOCE PRINCIPIOS DEL MANIFIESTO ÁGIL ......................................... 18
2.2.9. METODOLOGÍAS ÁGILES......................................................................... 20
2.3. CICLO DE VIDA DEL PROYECTO...................................................................... 24
2.3.1. CICLO DE VIDA DEL PRODUCTO Y CICLO DE VIDA DEL PROYECTO......... 29
2.4. FASES DEL PROYECTO..................................................................................... 31
2.5. PROCESOS DE LA DIRECCIÓN DE PROYECTOS................................................ 33
2.5.1. GRUPO DE PROCESOS DE INICIO............................................................. 37
2.5.2. GRUPO DE PROCESOS DE PLANIFICACIÓN............................................... 38
2.5.3. GRUPO DE PROCESOS DE EJECUCIÓN..................................................... 39
2.5.4. GRUPO DE PROCESOS DE MONITOREO Y CONTROL................................ 40
2.5.5. GRUPO DE PROCESOS DE CIERRE............................................................ 41
2.6. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE PROYECTOS....................... 42
2.7. RESUMEN........................................................................................................ 47
CEUPE Módulo. Dirección Estratégica CEUPE Módulo. Dirección Estratégica
Centro Europeo de Postgrado Unidad 02. Marco de referencia para la dirección de proyectos Centro Europeo de Postgrado Unidad 02. Marco de referencia para la dirección de proyectos
2. Marco de referencia para la

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-
dirección de proyectos
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-
“ La dirección y gestión de proyectos ha sido considerada eminen- tructurada consiguen finalizar sus proyectos con éxito 2,5 veces más que las que no si-
temente una disciplina de origen industrial (incluso militar, como guen una metodología. Aún así, el porcentaje global de los proyectos que finalizan con
la formulación de “estrategias”) y de las obras públicas, para pasar éxito ronda el 64 % durante los últimos años.
posteriormente al campo de los servicios y de los proyectos de con-
El PMI considera determinante para que se incremente este porcentaje de éxito la uti-
tenido y carácter social (Paris, 2011).”
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.
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- Figura 2.2. Porcentaje de proyectos finalizados con éxito 2012-2015
zaron con éxito, mientras que el 43 % lo hicieron con deficiencias (retraso, sobrecoste y/o Fuente: Project Management Institute. Pulse of the Profession: Capturing the
menos requisitos de los esperados).
Value of Project Management. Project Management Institute, Inc.; 2015. p. 8.
Proyectos 2004 2006 2008 2010 2012 Disponible en: http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/

thought-leadership/pulse/pulse-of-the-profession-2015.pdf
Finalizados con éxito 29% 35% 32% 37% 39%
2.2. Metodologías de dirección de proyectos
Fracasados 18% 19% 24% 21% 18%
Las metodologías de gestión de proyectos comenzaron a gestarse en los años 50 en el
Finalizados con ejército estadounidense para intentar reducir el volumen de proyectos que se descontro-
53% 46% 44% 42% 43%
deficiencias laban y ayudar a solventar problemas comunes que se habían identificado relativos a los
siguientes aspectos (Alnasser, 2010):
Figura 2.1. Porcentaje de resolución de proyectos años 2004 a 2012 según informe CHAOS • Exceso de carga de trabajo planificada o en proceso.
Fuente: CHAOS. CHAOS Manifesto 2013. Thing Big, act small. The Standish Group International; 2013. p. 1.
• Costes que superan el presupuesto inicial.
• Problemas en la calidad, valor o utilidad del resultado final.
04 05
La utilización de una metodología o sistematización de los procesos para la ejecución • Aporta herramientas para la gestión y el control del proyecto, informes de inciden-
de un proyecto reduce la aparición de problemas a lo largo de la vida del proyecto, por cias, informes de estado, desviaciones, control de cambios, etc.
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 • Asegura la satisfacción del cliente, ya que se focaliza en satisfacer sus requerimien-
metodología (figura A), existe un alto número de problemas que obliga a incrementar tos y expectativas.
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 • Aumenta la satisfacción del equipo de proyecto, ya que todos ellos colaboran ac-
y planificación del proyecto, lo que repercute en que se reduzca considerablemente el tivamente.
número de problemas, permitiendo aligerar el peso de los procesos a lo largo de la vida • Fomenta la disciplina de trabajo.
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.4. Beneficios de utilizar una metodología

Figura 2.3. Evolución de un proyecto usando metodología y sin usarla
Fuente: Bucero Torres A. La dirección de proyectos: una nueva visión. 2ª ed. Díaz de Santos; 2013
Fuente: Charvart J. Project Management Methodologies: selecting, implementing, and supporting
methodogies and processes for projects. John Wiley & Sons Inc.; 2003. p. 6 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
Las metodologías de gestión de proyectos establecen los estándares de procesos y áreas la dirección de proyectos. Básicamente, podemos decir que la gestión de proyectos puede
de conocimiento, pero también proporcionan métricas para juzgar el rendimiento, un sis- ser predictiva (también conocida como clásica, tradicional o formal) o ágil.
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 La decisión final de cuál elegir dependerá de las características del proyecto y de las ca-
una vez que está implantada (Bucero, 2013). No es fácil implantar una metodología de di- racterísticas de la organización. Dichas características, así como las diferencias entre me-
rección de proyectos, según este autor, pero existen muchos beneficios en su utilización, todologías predictivas y ágiles, se resumen en la siguiente figura:
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.
06 07
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-
Figura 2.5. Diferencia entre metodologías ágiles y predictivas
ra. Esto solo es posible si se puede conocer al detalle el resultado que se quiere obtener y
se trabaja en un entorno estable.
Fuente: https://be-klan.com/2013/01/31/gestion-de-proyectos-agil-o-predictiva/
Ejemplos típicos de proyectos gestionados bajo metodologías predictivas podrían ser:
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 • Obras de construcción civil.
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á • Implantación de estándares de calidad.
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 • Ampliación de un área o línea de fabricación.
las metodologías ágiles asumen que las especificaciones del cliente irán cambiando a lo
Dos de las metodologías predictivas más ampliamente implantadas son:
largo de la vida del proyecto.
• PMBOK (Project Management Body of Knowledge), desarrollado por el Project
La diferencia conceptual entre ambas metodologías podemos ilustrarla con este sencillo
Management Institute, PMI.
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 • PRINCE2 (PRojects IN Controlled Environments 2), impulsado por la Oficina de
realizar las excursiones, en qué restaurantes va a comer y cuánto dinero se va a gastar. Comercio Gubernamental del Reino Unido.
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.
08 09
2.2.2. PMBOK 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,
El Project Management Institute (PMI) es una asociación sin ánimo de lucro fundada en Dinamarca, Canadá), sector privado (Sun Microsistems, DHL, Barclays, Vodafone, Shell,
1969 que lidera mundialmente el campo de la administración de proyectos. De hecho, los Unilever, Microsoft, HP, IBM, British Airways) y organizaciones internacionales (ONU y
miembros del Project Management Institute (PMI) han aumentado de 8.500 en 1990 a sus agencias, Banco Mundial, ILO -International Labour Organization-).
más de 400.000 en el año 2013 a lo largo de 180 países (PMI, 2013).
PRINCE2 se fundamenta en:
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 • Siete procesos que forman la gestión de proyectos.
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 • Siete principios que constituyen la base del método de gestión de proyectos.
tratarse de la primera publicación de este tipo, se convirtió en una base para la posterior
• Siete temáticas o áreas de conocimiento que apoyan determinadas áreas clave de
discusión y mejora de la definición de la “dirección de proyectos” como profesión. Una
la gestión de proyectos.
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 Estos principios, temáticas y fases se resumen en la siguiente tabla:
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).
Temáticas o Áreas
Principios Procesos o Fases
conocimiento
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 Justificación Modelo negocio o Puesta en marcha
comercial continua business case (preproyecto)
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 Aprender de la experiencia Organización Dirección del proyecto
utilidad contrastada. Las pautas que marca la guía son de carácter general y permiten su Roles y responsabi-
Calidad Inicio del proyecto
aplicación a una amplia generalidad de proyectos, independientemente de su tamaño, lidades definidos
alcance o naturaleza. Gestión por fases Planes Control de fase
A lo largo de esta unidad se irá profundizando en el contenido del PMBOK al tratarse del Gestión por excepción Riesgo
Gestión de la
entrega de productos
estándar de dirección de proyectos más ampliamente difundido internacionalmente.
Gestión de los
Orientación a productos Cambio
2.2.3. PRINCE2 límites de fase
Adaptación Progreso Cierre del proyecto

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. 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).
Según la Oficina de Comercio Gubernamental del Reino Unido (2009), PRINCE2 está
Éxito en la Gestión de Proyectos con PRINCE2, 5ª ed., TSO
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.
10 11
2.2.4. Las temáticas de PRINCE2

Temática Descripción Contesta a
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- Esta temática describe la manera en que la gestión del
proyecto evalúa y actúa sobre las cuestiones que tienen
nuamente. Cualquier project manager que preste atención rigurosamente a estas temáti- un posible impacto en cualquiera de los aspectos baseli-
¿Cuál es el
cas desempeñará el rol con seriedad profesional. Sin embargo, la solidez de PRINCE2 se Cambio ne del proyecto (sus planes y/o productos completados).
impacto?
Las cuestiones pueden ser problemas generales no anti-
basa en la manera en que las siete temáticas se integran a lo largo del flujo cronológico cipados, solicitudes de cambio o instancias en las que la
del proyecto, como se muestra en la siguiente figura: calidad ha fallado.
¿Dónde esta-
Esta temática aborda la viabilidad continua de sus planes. mos ahora?
Temática Descripción Contesta a 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
El proyecto se inicia con una idea que se considera que vamos?
salen según lo indicado en el plan. En última instancia,
tiene valor potencial para la organización en cuestión. Esta
la temática de progreso determina si el proyecto debería
temática aborda la manera en que la idea se desarrolla ¿Deberíamos
proceder y de qué manera.
Business case para convertirse en una proposición de inversión viable ¿Por qué? continuar?
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.
Figura 2.7. Las temáticas de PRINCE2
La organización patrocinadora del proyecto necesita asig- Fuente: Oficina de Comercio Gubernamental del Reino Unido. Éxito en la
nar el trabajo a gerentes capaces de asumir la responsa-
bilidad y la dirección del proyecto hasta su terminación. Gestión de Proyectos con PRINCE2. 5ª ed. TSO; 2009. p 19
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 Dato importante
de gestión del proyecto PRINCE2 que se requieren para
gestionar el proyecto con efectividad. El PMI considera determinante para que se incremente este porcentaje de éxito la
La idea inicial solo se comprenderá a grandes rasgos. Esta
utilización por parte de las organizaciones de metodologías de gestión de proyec-
temática explica la manera en que la idea inicial se desa- tos que identifiquen los conocimientos, procesos, habilidades, herramientas y técni-
Calidad
rrolla de modo que todos los participantes comprenden los
atributos de calidad de los productos a entregar, y luego
¿Qué? cas que tienen impacto en el éxito de un proyecto.
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.
12 13
2.2.5. PMBOK versus PRINCE2 Sin embargo, también podemos encontrar algunas diferencias que son resumidas en la
siguiente tabla:
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 PMBOK PRINCE2
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. Qué es Campo de conocimiento Metodología
Obtener el proyecto en
Objetivo Generar el valor esperado
La siguiente figura muestra una comparación entre las áreas de conocimiento de la Guía coste, tiempo y alcance
PMBOK y las temáticas de PRINCE2:
Genera una organización para
Directores de proyecto
llevar a cabo el proyecto
Orientación
Áreas conocimiento PMBOK Temáticas PRINCE2 Consecución del business
Finalización del proyecto
case (modelo de negocio)
Integración Progreso, cambios
Roles, responsabilidad
Se define con más detalle
Alcance, tiempo, coste Planes, business case y toma de decisiones
Calidad Calidad, organización Descripción de

Se incluye en profundidad Solo en la temática de calidad
técnicas/ herramientas
Riesgo Riesgo
En el triángulo Se considera un cuarto factor,
Comunicaciones Control Calidad tiempo-coste-alcance, además del tiempo, coste y alcance
forma parte del alcance y, por lo tanto, sacrificable
Recursos humanos Organización
Adquisiciones Se incluye No se incluye
Adquisiciones No incluido
Habilidades de gestión
Se incluye No se incluye
e interpersonales
Figura 2.8. Comparación áreas conocimiento PMBOK y áreas temáticas PRINCE2

Figura 2.9. Diferencias entre PMBOK y PRINCE2
Fuente: Verhage L. Management Methodology for Enterprise Systems Implentations.
Fuente: Elaboración propia
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.
14 15
2.2.6. Por qué las metodologías ágiles de gestión de proyectos 2.2.7. El Manifiesto Ágil
La dirección y gestión de proyectos ha sido considerada eminentemente una disciplina En marzo de 2001, 17 críticos de los modelos de producción basados en procesos, convo-
de origen industrial (incluso militar, como la formulación de “estrategias”) y de las obras cados por Kent Beck, que había publicado un par de años antes el libro en el que explicaba
públicas, para pasar posteriormente al campo de los servicios y de los proyectos de con- la nueva metodología Extreme Programming, se reunieron en Salt Lake City para discutir
tenido y carácter social (Paris, 2011). 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,
Este origen de la gestión de proyectos ha condicionado el enfoque de las metodologías que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte
que tradicionalmente se han utilizado, orientándose a proyectos en los que era posible un dependencia de planificaciones detalladas previas al desarrollo (Palacio, 2015).
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. 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
Pero no todos los proyectos son principalmente estáticos en su concepción y desarrollo. ágiles de gestión de proyectos.
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 Manifiesto Ágil
metodologías tradicionales de gestión de proyectos no sirven, por tanto, en este tipo de Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo
entornos o en aquellos en los que las metas, los objetivos y los métodos no están claros. y ayudando a otros a que lo hagan.
El entorno de trabajo de las empresas del conocimiento se parece muy poco al que originó Con este trabajo hemos llegado a valorar:
la gestión de proyectos predictiva. Ahora se necesitan estrategias para el lanzamiento de • A los individuos y su interacción, por encima de los procesos y las herramientas.
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). • El software que funciona, por encima de la documentación exhaustiva.
A diferencia de los proyectos predictivos o tradicionales, la gestión de proyectos ágil no • La colaboración con el cliente, por encima de la negociación contractual.
se basa en la anticipación, sino en la continua adaptación a las necesidades del cliente, • La respuesta al cambio, por encima del seguimiento de un plan.
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. Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
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.
16 17
2.2.8. Los doce principios del Manifiesto Ágil 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
El Manifiesto Ágil, tras los postulados de los cuatro valores descritos anteriormente en los la satisfacción del cliente, aportando valor al producto o servicio que se le presta. Este
que se fundamenta, establece doce principios (Dimes, 2015). En la siguiente tabla se han enfoque también es compartido por el Manifiesto Ágil. El tercer principio Lean (trabajar
relacionado los doce principios del Manifiesto Ágil con el valor en el que impacta, para en flujo), se consigue en la metodología ágil con las entregas frecuentes de software. As-
facilitar su comprensión: pectos como la mejora continua, quinto principio Lean, se recogen expresamente en el
manifiesto (Lledó, 2012).
Valores Principios
Lean otorga una especial importancia a las personas, su motivación y contribución a la
• Construcción de proyectos en torno a individuos motivados, dándo- mejora continua, así como a la búsqueda de soluciones sencillas. Estos dos aspectos tam-
les la oportunidad y el respaldo que necesitan y procurándoles confianza
para que realicen la tarea.
bién son recogidos en los principios ágiles.
• La forma más eficiente y efectiva de comunicar informa-ción de ida y Detrás del pensamiento ágil existen varias herramientas o técnicas específicas para ges-
A los individuos y su in-
teracción, por encima de
vuelta dentro de un equipo de desarrollo es mediante la conversación tionar proyectos, por ejemplo:
cara a cara.
los procesos y las herra-
mientas
• Las mejores arquitecturas, requisitos y diseños emergen de equipos • Adaptive Software Development (ASD).
que se autoorganizan.
• Crystal Clear.
• En intervalos regulares, el equipo reflexiona sobre la for-ma de ser
más efectivo y ajusta su conducta en consecuencia.
• Método de desarrollo de sistemas dinámicos (DSDM).
• El software que funciona es la principal medida del progreso.
• Extreme Programming.
• 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. • Feature Driven Development (FDD).
por encima de la docu-
mentación exhaustiva
• La simplicidad como arte de maximizar la cantidad de trabajo que se • Lean Development.
hace es esencial.
• Kanban.
• La atención continua a la excelencia técnica enaltece la agilidad
• Nuestra principal prioridad es satisfacer al cliente a través de la • Pragmatic Programming.

entrega temprana y continua de software de valor.
• Scrum.
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 • Etc.
• Los procesos ágiles promueven el desarrollo sostenido. Los patroci-
nadores, desarrolladores y usuarios deben mantener un ritmo constante Aunque estas metodologías surgieron y se desarrollaron a partir de entornos relaciona-
de forma indefinida.
dos con el desarrollo de software, cada vez más se utilizan en otros entornos de negocio
La respuesta al cambio, • Son bienvenidos los requisitos cambiantes, incluso si llegan tarde que cambian y evolucionan rápidamente.
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.
18 19
2.2.9. Metodologías ágiles La siguiente figura ilustra el proceso de la programación extrema (XP):
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- Figura 2.11. El ciclo de entrega en la Programación Extrema
ción del cliente en niveles “extremos”. Fuente: Fuente: Sommerville I, Alfonso Galipienso ML. Ingeniería del
software 7ª ed. Pearson Education; 2005. p. 364

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. 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.
En la programación extrema, todos los requerimientos se expresan como escenarios (lla-
mados historias de usuario) a través de las siguientes etapas: 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
• Las historias de usuarios, con los requerimientos del cliente, se dividen en una
de requisitos y en las pruebas de aceptación del sistema.
serie de tareas.
Código abierto
• Se planifican entregas del sistema pequeñas y frecuentes.
El código abierto es un estilo de software, no tanto un proceso. Sin embargo, hay una ma-
• Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes
nera definida de hacer las cosas en la comunidad de código abierto, y mucho de su acerca-
de escribir el código.
miento es tan aplicable a los proyectos de código cerrado como a los de código abierto. En
• La integración en el sistema se produce cuando todas las pruebas realizadas con el particular, su proceso se engrana a equipos físicamente distribuidos, lo que es importante
código nuevo se ejecutan satisfactoriamente. porque la mayoría de los procesos adaptables exigen equipos locales (Bucero, 2013).
• Con el fin de poder evaluar adecuadamente el sistema, existe un pequeño espacio Scrum
de tiempo entre las entregas.
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”.
20 21
Según el creador de Scrum, Sutherland (2015), es un cambio radical respecto a los anti- Las reglas de Scrum pueden resumirse en la siguiente figura:
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 Exposición de
prioridades.
Estimación del
esfuerzo para cada
otro tipo. Resolución de dudas. historia de usuario.
Presentación del
Revisión del avance.
Los conceptos en los que se basa Scrum son los siguientes (Lledó, 2014): Objetivo del Sprint Resolución de impedimento.
incremento, sugerencias,
anuncio próximo sprint.
Planificación del Sprint Scrum diario Revisión del sprint

• 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. Retrospectiva
• Los equipos de profesionales bien preparados y automotivados se desarrollan me-

jor y producen mejores resultados si trabajan en equipos autogestionados en el ROLES ARTEFACTOS EVENTOS
que cada uno toma responsabilidad sobre su trabajo y se compromete con la cali- PLANIFICACIÓN
PILA DEL
dad siguiendo sus propios procesos para lograrlo. PROPIETARIO PRODUCTO
DEL SPRINT
1.Jornada de trabajo
DEL PRODUCTO Relación de requisitos
Determina las (max.) El propietario del
del producto, no es
• La colaboración constante con el cliente y patrocinador tiene más posibilidades de prioridades. necesario excesivo
producto explica las priori-
dades. El equipo estima el
Una sóla persona detalle. El propietario
éxito que aquellos proyectos en los que estos interesados se involucran solo en el del producto es su
esfuerzo de los requisitos
prioritarios y se elabora la
principio del proyecto y luego al final para aprobar o no el producto o servicio fi- responsable y quien
decide.
pila del sprint. El equipo
define en una frase el
nal. Al tener una colaboración constante, los cambios de requerimientos se podrán EQUIPO DE
DESARROLLO objetivo del sprint.
PILA DEL SPRINT
detectar rápidamente e incorporar al proyecto en las iteraciones siguientes para Construye el
producto Requisitos com-
SPRINT
entregar al cliente un producto alineado a las necesidades de su negocio. prometidos por el
equipo para el sprint
Ciclo de desarrollo básico
en el marco estándar
con nivel de detalle
de scrum, de duración
SCRUM MASTER
Scrum se basa en un ciclo de vida iterativo incremental que persigue el objetivo de opti- Gestiona y facilita la
suficiente para su
ejecución.
recomendada inferior a un
mes y nunca mayor de 6
mizar la previsibilidad y controlar el riesgo. En Scrum, cada iteración se denomina sprint ejecución de las reglas
de Scrum
semanas.
INCREMENTO
y tiene una duración fija de dos a cuatro semanas. Durante este periodo se realizan los Parte del producto
SCRUM DIARIO
trabajos seleccionados y al finalizar cada sprint se obtiene como resultado un producto desarrollada en un
sprint, en condicio-
15 minutos máximo. Res-
ponsabilidad del equipo.
que provee alguna funcionalidad al cliente. INTERESADOS
Resto de implicados.
nes de ser usada
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é
Scrum es, por tanto, un marco de trabajo por el cual las personas pueden acometer pro- tada).
problemas. Se actualiza la
pila del sprint.
blemas complejos adaptativos a la vez que entregar productos del máximo valor posible
productiva y creativamente (Schwaber y Sutherland, 2013). Figura 2.12. Las reglas de Scrum
REVISIÓN DEL SPRINT
Informativa, máx. 4 horas,
presentación del incre-
Scrum puede ser considerada como una metodología ligera y fácil de entender, pero al Fuente: Palacio J. Gestión Proyectos Scrum Manager. mento, planteamiento de
sugerencias y anuncio del
mismo tiempo extremadamente difícil de llegar a dominar. Versión 2.5.1; 2015. p. 21. próximo sprint.
Disponible en: RETROSPECTIVA

El marco de trabajo Scrum consiste en los equipos Scrum, roles, eventos, artefactos y El equipo autoanaliza la
reglas asociadas. Cada componente, dentro del marco de trabajo, sirve a un propósito es- http://www.scrummanager.net/bok/index.php?title=Scrum:_
componentes_y_marco
forma de trabajo. Identifi-
cación de fortalezas y de-
pecífico y es esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan bilidades. Refuerzo de las
primeras, plan de mejora
los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos. de las segundas.
22 23
Scrum prescribe cuatro eventos formales, contenidos dentro del sprint, para la inspección • Personas involucradas.
y adaptación:
• Criterios de control y aprobación de cada una de las fases.
• 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 Todos los proyectos, por tanto, tienen un ciclo de vida (Chamoun, 2002). Se inician, se
identifican los sprints (mejoras) a desarrollar. 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-
• Scrum diario (Daily Scrum): permite revisar diariamente y de forma muy rápida, tes problemas a las siguientes fases.
apenas 15 minutos, la evolución del proyecto.
Los ciclos de vida del proyecto pueden ser:
• 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. • 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
• Retrospectiva del sprint (Sprint Retrospective): el equipo autoanaliza su forma de este ciclo de vida predictivo podemos encontrarlos en obras de construcción com-
trabajar identificando planes de mejora. 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
2.3. Ciclo de vida del proyecto antes posible para poder desarrollar adecuadamente la planificación del proyecto,
la cual requiere de un considerable esfuerzo. Aunque se asume que habrá cambios,
Los directores de proyecto o la organización pueden dividir los proyectos en fases para en este tipo de ciclo de vida las modificaciones en aspectos básicos del proyecto re-
proporcionar un mejor control con las relaciones apropiadas de las operaciones en mar- quieren un importante esfuerzo de reajuste de todo el proyecto (planificación, eje-
cha. Globalmente, estas fases se llaman ciclo de vida de proyecto. El ciclo de vida del cución, control), por lo que no es aconsejable en entornos altamente cambiantes.
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- • Ciclos de vida adaptativos. También conocidos como métodos orientados al cam-
cillo y descriptivo que sea posible (Bucero, 2013). 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-
Un ciclo de vida, por ejemplo, para un proyecto de desarrollo de software podría constar tinuamente conforme avanza el proyecto en función de los logros obtenidos y el
de las siguientes fases: 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-
• Fase 1: Análisis.
ción. Supongamos que el objetivo de nuestro proyecto es encontrar una cura para
• Fase 2: Diseño. 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
• Fase 3: Desarrollo e implantació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,
• Fase 4: Producción. 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-
• Fase 5: Garantía y Soporte. 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
Para cada una de estas fases que constituyen el ciclo de vida del proyecto deberá definirse:
fármaco y en la dosis hasta encontrar una combinación que minimice los efectos
• Actividades a realizar. secundarios y sea plenamente efectiva. Otro ejemplo típico de este ciclo de vida lo
encontramos en los proyectos tecnológicos.
• Entregables a generar en cada fase, en qué plazo y qué criterios de aceptación de
los mismos serán utilizados.
24 25
• 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.
Figura 2.13. Niveles típicos de costo y dotación de personal en
• Ejecución. una estructura genérica de ciclo de vida del proyecto
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de

• Cierre.
Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 39
Veamos a continuación algunas consideraciones en cuanto al ciclo de vida de los proyec-
tos (PMI, 2013). 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
El coste del proyecto y la dotación de recursos de personal se incrementan a lo largo de dotar recursos de personal desde el primer momento o hacer estudios previos en las pri-
las primeras fases del proyecto, inicio y organización, hasta llegar a su máximo en la fase meras fases que supongan un alto coste.
de ejecución del trabajo, como podemos ver reflejado en la siguiente figura:
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.
26 27
Esta misma figura nos muestra que el coste de los cambios se incrementa considerable- 2.3.1. Ciclo de vida del producto y ciclo de vida del proyecto
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 Es importante no confundir el ciclo de vida de un producto o sistema y el ciclo de vida del
todo en las primeras fases, y proceder a su validación por todas las partes implicadas an- proyecto. La siguiente figura ilustra el ciclo de vida de los sistemas y las distintas fases
tes de comenzar la siguiente. Imaginemos el proyecto de reforma de una vivienda: el coste que lo conforman:
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-
Identificación
ma. Identificar posibles cambios en las primeras fases es fundamental para que aspectos y definición de
como el alcance, el coste o el tiempo no repercutan de forma negativa en la evolución del Análisis de
la necesidad
mercado
proyecto.
Retirada
de servicio
Estudio de
viavilidad
Vida de
servicio
n
ificació
Espec isitos
u
de req
Producción
Diseño
Figura 2.14. Impacto de las variables en función del tiempo del proyecto Figura 2.15. Ciclo de vida de los sistemas
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de Proyectos (Guía del Fuente: Sols Rodríguez-Candela A, Fernández Fernández I, Romero Yacobi J. Gestión integral de proyectos.
PMBOK). Project Management Institute, Inc.; 2013. p. 40 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í
Dato importante mismos también puede considerarse que tienen un ciclo de vida, cuyas fases en líneas
A diferencia de los proyectos predictivos o tradicionales, la gestión de proyectos generales pueden definirse como sigue:
ágil no se basa en la anticipación, sino en la continua adaptación a las necesidades • Fase inicial: implica el lanzamiento del proyecto, la definición de su alcance y de
del cliente, la evolución del mercado y las innovaciones tecnológicas. Esto implica los objetivos a conseguir.
dejar de tener “productos finales” o “entregables” a favor de productos en continua
evolución y mejora. • 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.
28 29
Los proyectos están vinculados a alguna o a todas las fases del ciclo de vida de un siste- 2.4. Fases del proyecto
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 Para simplificar la gestión del proyecto, este puede dividirse en fases. Cada una de las
del sistema. Por este motivo, la vida de un proyecto es normalmente más corta que la vida fases contiene una secuencia lógica de actividades, con un comienzo y un final perfecta-
de un sistema. Hay proyectos que no están necesariamente vinculados a sistemas, sino mente definibles y un entregable claramente establecido. El número de fases y su alcance
que tienen como producto final un servicio. Para estos proyectos, se aplican las mismas viene determinado por la naturaleza del proyecto y el tamaño de la organización. En el
consideraciones mencionadas, pero con las adaptaciones necesarias (Sols y otros, 2013). 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
La siguiente figura muestra un ejemplo de la relación entre el ciclo de vida de un sistema una pequeña empresa, podría ser factible considerar todo el proyecto en una única fase.
o producto y el ciclo de vida de un proyecto para el caso típico de un proyecto de adquisi- Sin embargo, si se trata de la limpieza de un vertedero de una gran ciudad, sería claramen-
ción, desarrollo o fabricación de un producto. 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.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

Figura 2.17. Ejemplo de proyecto de tres fases
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. 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.
30 31
Habitualmente las fases del proyecto se completan secuencialmente, de tal forma que una Dato importante
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 Los proyectos están vinculados a alguna o a todas las fases del ciclo de vida de un
continuación, se muestra un ejemplo de proyecto con fases superpuestas: 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.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. Figura 2.19. Descripción de proceso
Otro ejemplo de proyecto con fases superpuestas podría ser la construcción de un nue- Fuente: elaboración propia
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 Los procesos del proyecto son ejecutados por el equipo del proyecto con la participación
en paralelo permite acortar el plazo final del proyecto. Sin embargo, si estas fases no se activa de las partes interesadas y pueden ser de dos tipos:
sincronizan adecuadamente y no se traslada la información necesaria, podríamos encon- • Procesos de la dirección de proyectos: estos procesos están orientados a asegu-
trarnos con un equipo electromédico que no puede instalarse porque carece de toma de rar que el proyecto se ejecuta adecuadamente a lo largo de su ciclo de vida.
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- • Procesos orientados al producto: estos procesos están orientados a producir el
po electromédico. producto servicio objeto del proyecto.
32 33
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
Figura 2.20. Los grupos de procesos interactúan en una fase o proyecto
fuese necesario.
Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de
• Grupo de procesos de cierre: se consideran procesos de cierre los necesarios para Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 51
finalizar formalmente un proyecto o una fase del proyecto.
El diagrama de flujo de procesos mostrado a continuación proporciona un resumen glo-
Aunque la terminología resulte parecida, recordemos que los grupos de procesos no son bal del flujo básico y de las interacciones entre los grupos de procesos y los interesados
lo mismo que las fases del ciclo de vida del proyecto. Los grupos de procesos pueden concretos. Los procesos de la dirección de proyectos están vinculados por entradas y sali-
ejecutarse, y de hecho habitualmente se hace así, en cada una de las fases del proyecto. das específicas, de modo que el resultado de un proceso se convierte en la entrada de otro
Si retomamos el ejemplo de la construcción de un nuevo hospital, para cada una de las proceso, aunque no necesariamente en el mismo grupo de procesos.
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:
34 35
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
Figura 2.21. Interacciones entre Procesos de la dirección de Proyectos
36 37
En esta fase debe disponerse de información relacionada con el proyecto que se plasma Como resultado del grupo de procesos de planificación obtendremos:
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): • Alcance total del proyecto.
• La razón de ser del proyecto. • Definición de los objetivos.
• Lo que se debe entregar y cómo se tiene que hacer. • Línea de acción.
• Quién va a ocuparse de qué cosas. 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
• Los tiempos en que se entregarán las distintas partes del proyecto. 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
2.5.2. Grupo de procesos de planificación 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
El grupo de procesos de planificación actúa como un plan de vuelo o navegación contra proyecto.
el cual compararemos el avance para evaluar periódicamente el desempeño del proyecto
(Chamoun, 2002). 2.5.3. Grupo de procesos de ejecución
Siguiendo con esta analogía, para poder establecer correctamente el plan de vuelo o na- El grupo de procesos de ejecución coordina, integra y gestiona todos los recursos
vegación necesitamos tener en cuenta una serie de consideraciones importantes relacio- (Ocaña, 2012):
nadas con los siguientes aspectos:
• ¿Para qué? Para lograr los objetivos del proyecto.
• Alcance.
• ¿Cómo? Llevando a cabo el plan del proyecto.
• Tiempo.
• Mientras se responde a cambios y se mitigan los riesgos.
• Costo.
Este grupo de procesos está compuesto por aquellos procesos realizados para completar
• Calidad. el trabajo definido en el plan para la dirección del proyecto, a fin de cumplir con las espe-
cificaciones del mismo.
• Comunicaciones.
Este grupo de procesos implica:
• Recursos humanos.
• Coordinar personas y recursos.
• Riesgos.
• Gestionar las expectativas de los interesados.
• Adquisiciones.
• Integrar y realizar las actividades del proyecto conforme al plan para la dirección.
• Participación de los interesados.
38 39
Durante la ejecución del proyecto, en función de los resultados obtenidos, se puede reque- 2.5.5. Grupo de procesos de cierre
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- Una vez finalizado el proyecto o una fase del proyecto, parece evidente la necesidad de
tividad de los recursos, así como riesgos no previstos. Tales variaciones pueden afectar analizar los resultados y recapitular el curso de los hechos, para hacerse una idea clara
al plan para la dirección del proyecto o a los documentos del proyecto y pueden requerir de los objetivos cumplidos, de los que no se han alcanzado y de la utilidad futura en otras
un análisis detallado y el desarrollo de respuestas de dirección de proyectos adecuadas. fases o proyectos del trabajo realizado (Domingo Ajenjo, 2000).
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 Además del objetivo fundamental de analizar económicamente el resultado de la fase o
del mismo y, posiblemente, requerir el establecimiento de nuevas líneas base. Gran parte proyecto y conocer si ha sido beneficioso o no para la organización en los términos pre-
del presupuesto del proyecto se utilizará en la realización de los procesos del grupo de vistos inicialmente, existen otros objetivos adicionales en los procesos de cierre de sumo
procesos de ejecución (Guía del PMBOK, 2013). interés para el desempeño de futuros proyectos:
• Identificar y analizar las razones de las desviaciones entre la previsión inicial y la

2.5.4. Grupo de procesos de monitoreo y control
ejecución final.
De nada sirve un plan si no se sigue. Pero incluso ejecutando el plan tal y como se dise-
• Implantar acciones correctivas o preventivas que eviten que las causas que origi-
ñó, es necesario controlar que efectivamente se está haciendo así y que no hay errores o
naron estas desviaciones puedan volver a repetirse.
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 • Corregir, para futuras fases o proyectos, las actuaciones inadecuadas que dieron
inicialmente establecidos y que no se han modificado por circunstancias intrínsecas al lugar a las desviaciones.
proyecto o externas al mismo.
• Recopilar las lecciones aprendidas y el conocimiento experto derivado de la eje-
Este enfoque nos recuerda al propio ciclo de mejora continua o ciclo PDCA: planificar, cución de la fase o del proyecto. Este conocimiento hace referencia al resultado
hacer, comprobar, actuar. Los grupos de procesos de monitoreo y control permiten revisar técnico del proyecto y a la forma en la que el proyecto se ha desarrollado. La trans-
el correcto avance del proyecto en intervalos regulares de tiempo (cada x meses), coin- ferencia de información en este sentido puede ayudarnos a que las buenas prác-
cidiendo con la finalización de una fase, en situaciones anormales o excepcionales, o en ticas se extiendan a futuras fases o proyectos y a que no se vuelvan a cometer los
momentos considerados clave. mismos errores.
La ejecución de este grupo de procesos también implica (PMI, 2013): • 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
• Comparar la ejecución de las actividades del proyecto con el plan para la dirección
hacernos reflexionar si disponemos de recursos para poder afrontar el diseño o
del proyecto y con la línea base para la medición del desempeño del proyecto.
el mantenimiento de la misma. Si esto fuera posible, daría lugar a nuevas oportu-
• Recomendar acciones correctivas o preventivas para anticiparse a posibles proble- nidades comerciales.
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.
40 41
2.6. Áreas de conocimiento de la dirección de proyectos

Áreas conocimiento PMBOK Temáticas PRINCE2
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 Gestión de la integración del proyecto Modelo de negocio o business case
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 Gestión del alcance del proyecto Organización
desempeño del proyecto.
Gestión del tiempo del proyecto Calidad
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- Gestión de los costes del proyecto Planes
gido. A modo de ejemplo, veamos los procesos y áreas de conocimiento del PMBOK y las
fases y temáticas de PRINCE2: Gestión de la calidad del proyecto Riesgo
Gestión de los recursos humanos del proyecto Cambio

Procesos PMBOK Fases PRINCE2
Gestión de las comunicaciones del proyecto Progreso
Inicio Puesta en marcha (preproyecto)
Planificación Dirección del proyecto Gestión de los riesgos del proyecto
Ejecución Inicio del proyecto Gestión de las adquisiciones del proyecto
Monitorización y control Control de fase Gestión de los interesados del proyecto
Cierre Gestión de la entrega de productos

Figura 2.23. Procesos / Áreas conocimiento PMBOK y Fases / Temáticas PRINCE2
Gestión de los límites de fase Fuente: Elaboración propia
Cierre del proyecto 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.
42 43
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- Grupos de Procesos de la Dirección de Proyectos
BOK. Es destacable el alto grado de alienación entre ambas normas, aunque no se trata
Áreas de Grupo de
en absoluto de una casualidad, teniendo en cuenta que el Project Management Institute conocimiento/
Grupo de Grupo de Grupo de
procesos de
Grupo de
procesos procesos de procesos de procesos
(PMI), autor de la Guía del PMBOK, asumió la secretaria del ISO/PC 236, grupo de traba- temas en los que
de inicio planificación ejecución
monitoreo
de cierre
se desarrollan y control
jo que redactó la norma ISO 21500, publicada en su primera edición en 2012.
• Planificar
la gestión de
los costos
Grupos de Procesos de la Dirección de Proyectos
3.- Gestión
• Controlar
de los costes • Estimar
Áreas de Grupo de los costos
Grupo de Grupo de Grupo de Grupo de del proyecto los costos
conocimiento/ procesos de
temas en los que monitoreo • Determinar
de inicio planificación ejecución de cierre
se desarrollan y control el presupuesto
• Monitorear • Cerrar
y controlar proyecto • Realizar
4.- Gestión • Planificar
el trabajo del o fase el asegura- • Controlar
• Desarrollar • Desarrollar • Dirigir y de la calidad la gestión de
8.- Gestión de proyecto miento de la calidad
el acta de el plan para gestionar el del proyecto la calidad
la integración • Recopilar calidad
constitución la Dirección trabajo del
del proyecto • Realizar las leccio-
del proyecto del Proyecto proyecto
el control nes apren- • Planificar
integrado didas (ISO la gestión de • Adquirir el
de cambios 21.500)* • Controlar
los recursos equipo del
los recur-
humanos proyecto
• Planificar sos (ISO
• Establecer
la gestión 5.- Gestión de 21.500)**
el equipo • Estimar los • Desarrollar
del alcance los recursos
de proyec- recursos (ISO el equipo del
humanos del • Gestionar
to (ISO 21.500)** proyecto
• Validar el proyecto el equipo
• Recopilar 21.500)**
3.- Gestión alcance del pro-
requisitos • Definir la or- • Dirigir el
del alcance yecto (ISO
del proyecto ganización del equipo del
• Controlar 21.500)**
• Definir el proyecto (ISO proyecto
el alcance
alcance 21.500)**
• Crear la • Gestionar • Controlar

EDT/WBS las comu- las comu-
nicaciones nicaciones
• Planificar la 7.- Gestión de las • Planificar la
gestión del comunicaciones gestión de las
• Distribuir • Gestionar
cronograma del proyecto comunicaciones
la informa- las comunica-
ción (ISO ciones (ISO
• Definir las 21.500)* 21.500)*
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
44 45
2.7. Resumen
Grupos de Procesos de la Dirección de Proyectos
La utilización de metodologías para la dirección de proyectos reduce la aparición de pro-
Áreas de Grupo de
conocimiento/
Grupo de Grupo de Grupo de
procesos de
Grupo de blemas a lo largo de la vida del proyecto, por lo que la probabilidad de éxito se incremen-
temas en los que
de inicio planificación ejecución
monitoreo
de cierre ta. En función de las características de la organización, tipo de proyecto, restricciones de
se desarrollan y control
tiempo, coste, recursos disponibles, etc., podrán utilizarse diferentes metodologías para
• Planificar la dirección de proyectos. Básicamente, se puede decir que la gestión de proyectos puede
la gestión de
los riesgos
ser predictiva (también conocida como clásica, tradicional o formal) o ágil.
• Identificar La principal característica de los proyectos predictivos es que están enfocados a los pro-
los riesgos
cesos, pueden ser planificados con detalle y hay pocos cambios por parte del cliente. Las
• Realizar el metodologías de gestión de proyectos predictivas más ampliamente difundidas son PM-
4.- Gestión análisis cualita- • Tratar los
de los riesgos tivo de riesgos riesgos (ISO
• Controlar BOK y PRINCE2.
los riesgos
del proyecto 21.500)*
• Realizar Los proyectos ágiles se centran, sin embargo, en el valor o utilidad final del resultado y
el análisis
cuantitativo se desarrollan en entornos cambiantes que hacen que tengan un componente dinámico,
de riesgos impredecible, no programable inicialmente. Dentro de las metodologías ágiles podemos
• Planificar la citar como ejemplos: programación extrema (Xp), código abierto y Scrum.
respuesta a
los riesgos
Para simplificar la gestión del proyecto, este puede dividirse en fases. Cada una de las
• Efectuar fases contiene una secuencia lógica de actividades con un comienzo y un final perfecta-
las adqui-
siciones
mente definibles y un entregable claramente establecido. Las fases del proyecto pueden
6.- Gestión de • Planificar la • Controlar • Cerrar
las adquisiciones gestión de las las adqui- las adqui-
desarrollarse secuencialmente o superpuestas, permitiendo acortar el cronograma del
• Seleccionar
del proyecto adquisiciones
los provee-
siciones siciones proyecto, aunque esto supone un aumento de los riesgos.
dores (ISO
21.500)* 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
1.- Gestión de • Identi- • Planificar la
• Gestionar • Controlar este máster. Esta guía identifica los procesos de la dirección de proyectos y los agrupa en
la participa- la participa-
los interesados ficar a los gestión de los
ción de los ción de los cinco categorías conocidas como grupos de procesos de la dirección de proyectos: inicio,
del proyecto interesados interesados
interesados interesados 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
Figura 2.24. Correspondencia entre grupos de procesos y áreas de conocimiento de la dirección de proyectos explícitas que requieren conocimientos específicos para dirigir un proyecto: integración,
Fuente: Elaboración propia a partir de: Project Management Institute. Guía de los Fundamentos para la
alcance, tiempo, costos, calidad, recursos humanos, comunicaciones, riesgos, adquisicio-
nes e interesados.
Dirección de Proyectos (Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 61, y de la norma ISO 21.500
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.
46 47
CEUPE
Centro Europeo de Postgrado
Web
www.ceupe.com
E-mail
info@ceupe.com

A1 - Mod1 - Unid2 - Marco de Referencia para La Dirección de Proyectos

Cargado por

Información del documento

Descripción original:

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

A1 - Mod1 - Unid2 - Marco de Referencia para La Dirección de Proyectos

Cargado por

Copyright:

Formatos disponibles

Módulo

2. Marco de referencia para la

Proyectos 2004 2006 2008 2010 2012 Disponible en: http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/

• Problemas en la calidad, valor o utilidad del resultado final.

Figura 2.4. Beneficios de utilizar una metodología

• Favorece la creación de un buen plan de proyecto, definiendo el alcance y activida-

2.2.1. Metodologías predictivas de gestión de proyectos

Estas metodologías parten de las siguientes premisas (Alnasser, 2010):

• Carácter predictivo: se define al detalle el resultado que se quiere conseguir. Lo

Adaptación Progreso Cierre del proyecto

2.2.4. Las temáticas de PRINCE2

Los proyectos PRINCE2 proceden en base a una serie de ¿Cómo?

Típicamente, los proyectos conllevan más riesgo que la

Calidad Calidad, organización Descripción de

Figura 2.8. Comparación áreas conocimiento PMBOK y áreas temáticas PRINCE2

En los proyectos ágiles no es tan importante la planificación y la previsibilidad en la eje-

• Nuestra principal prioridad es satisfacer al cliente a través de la • Pragmatic Programming.

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.

Según Sommerville (2005), la programación extrema (XP) es posiblemente uno de los

software 7ª ed. Pearson Education; 2005. p. 364

Planificación del Sprint Scrum diario Revisión del sprint

• Los equipos de profesionales bien preparados y automotivados se desarrollan me-

Disponible en: RETROSPECTIVA

• Ciclos de vida iterativos e incrementales. Son aquellos en los cuales, dentro de

Independientemente del tamaño y complejidad de los proyectos, así como de su ciclo de

• Ejecución. una estructura genérica de ciclo de vida del proyecto

Fuente: Project Management Institute. Guía de los Fundamentos para la Dirección de

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

(Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 43

2.5. Procesos de la dirección de proyectos

Podemos definir un proceso como un conjunto actividades, acciones o tareas relacionadas

(Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 43

Los procesos de la dirección de proyectos pueden agruparse en cinco categorías conoci-

• Grupo de procesos de inicio: se consideran procesos de inicio los necesarios para

• Grupo de procesos de planificación: los procesos de planificación incluyen todos

• Grupo de procesos de monitoreo y control: los procesos de monitoreo y control

2.5.1. Grupo de procesos de inicio

En los procesos de inicio deben explicitarse claramente:

• 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

Figura 2.21. Interacciones entre Procesos de la dirección de Proyectos

(Guía del PMBOK). Project Management Institute, Inc.; 2013. p. 53

• La razón de ser del proyecto. • Definición de los objetivos.

• Lo que se debe entregar y cómo se tiene que hacer. • Línea de acción.

• Identificar y analizar las razones de las desviaciones entre la previsión inicial y la

• Controlar los cambios, garantizando que todos ellos estén aprobados.

• Proporcionar información al equipo del proyecto y demás partes interesadas sobre

• Identificar áreas que precisan una mayor atención.

• Actualizar la documentación del proyecto fruto de la revisión.

2.6. Áreas de conocimiento de la dirección de proyectos

Gestión de los recursos humanos del proyecto Cambio

Planificación Dirección del proyecto Gestión de los riesgos del proyecto

Ejecución Inicio del proyecto Gestión de las adquisiciones del proyecto

Monitorización y control Control de fase Gestión de los interesados del proyecto

Cierre Gestión de la entrega de productos

Estas diez áreas de conocimiento se utilizan en la mayoría de los proyectos durante la