Marco de Referencia para La Dirección de Proyectos

Marco de referencia para la dirección de
proyectos © IMF Smart Education

Índice
Marco de referencia para la dirección de proyectos 3
I. INTRODUCCIÓN 3
II. OBJETIVOS 3
III. IMPORTANCIA DE LA GESTIÓN DE PROYECTOS 4
IV. METODOLOGÍAS DE DIRECCIÓN DE PROYECTOS 5
4.1. Metodologías predictivas de gestión de proyectos 8
4.2. PMBOK 9
4.3. PRINCE2 2017 10
4.4. Las temáticas de PRINCE2 11
4.5. PMBOK versus PRINCE2 12
4.6. Por qué las metodologías ágiles de gestión de proyectos 13
4.7. El Manifiesto Ágil 14
Manifiesto Ágil 14
4.8 Los 12 principios del Manifiesto Ágil 15
4.9. Metodologías ágiles 16
XP (programación extrema) 16
Código abierto 17
Scrum 17
V. CICLO DE VIDA DEL PROYECTO 20
5.1. Ciclo de vida del producto y ciclo de vida del proyecto 22
VI. FASES DEL PROYECTO 24
VII. PROCESOS DE LA DIRECCIÓN DE PROYECTOS 25
7.1. Grupo de procesos de inicio 27
7.2. Grupo de procesos de planificación 28
7.3. Grupo de procesos de ejecución 29
7.4. Grupo de procesos de monitoreo y control 30
La ejecución de este grupo de procesos también implica (PMI, 2017): 30
7.5. Grupo de procesos de cierre 30
VIII. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE PROYECTOS 31
IX. RESUMEN 34
X. LECTURAS 35
LECTURA 1 - PLANTILLAS PARA PROYECTOS 35
LECTURA 2 - “SCRUM”, EL MÉTODO DE TRABAJO QUE HARÁ QUE SU EMPRESA SEA MÁS EFICIENTE 36
LECTURA 3 - CICLOS DE VIDA PARA GESTIONAR UN PROYECTO SOFTWARE: CASCADA, ESPIRAL, ITERATIVO, INCREMEN…
36
LECTURA 4 - IMPLANTACIÓN DE METODOLOGÍAS ÁGILES: IDENTIFICANDO BARRERAS ORGANIZATIVAS 37
LECTURA 5 - AUMENTO DE LAS TASAS DE ÉXITO 37
Ejercicios 38
CASO PRÁCTICO 1 38
Recursos 39
Enlaces de Interés 39
Bibliografía 39
Glosario. 41
2/41
M arco de referencia para la dirección de proyectos
Marco de referencia para la dirección de

proyectos
I. INTRODUCCIÓN
El astrólogo romano Spurinna escribió varias cartas a Julio César advirtiéndole de peligros que veía en
su carrera. De hecho, parece ser que le envió una famosa carta avisando que tuviera especial cuidado con
"los Idus de Marzo" (15 de marzo). Aunque Julio César tenía profundos conocimientos acerca de los
astros y se le atribuye la autoría de un tratado de astronomía, no consideró que había motivos suficientes
para preocuparse. “Solo se debe temer al miedo”, afirmaba. El magnicidio de Julio César tuvo lugar el 15
de marzo. En esas fechas apareció un magnifico cometa sobre los cielos de Roma durante varios días,
señal que fue interpretada por los romanos como el alma de Julio César.
La astrología política acompañó a griegos y romanos durante siglos, con el convencimiento de que los
astros podían predecir el futuro y ayudarles a tomar decisiones. Tal vez si Julio César hubiera confiado en
las advertencias que le hicieron los astrólogos, el curso de la historia habría sido otro. O tal vez porque
sabía que no podía desafiar a su propio destino, no lo hizo.
2.000 años después, la astrología ha sido desterrada como herramienta de gestión y toma de decisiones
en los ámbitos políticos y de gestión empresarial a favor de otras sistemáticas basadas en el método
científico y en el círculo PDCA (planificar, hacer, verificar, actuar). Los mapas astrales y el estudio de las
constelaciones del Zodiaco utilizados por griegos y romanos para adivinar el futuro han dado paso a los
mapas estratégicos y a los estándares de gestión de proyectos como guías para predecir y evitar
infortunios en la ejecución de nuestros proyectos.
Julio César sabía lo que los astros le tenían preparado. No quiso o no pudo ir en contra de ese destino.
Una gestión sistematizada del proyecto puede predecir posibles infortunios asociados al mismo. A partir de
ahí ya será labor nuestra evitarlos o no.
II. OBJETIVOS
En esta unidad, los alumnos alcanzarán los siguientes objetivos:
Se conocerán las metodologías más relevantes de la dirección de proyectos haciendo

especial énfasis en el PMBOK.
Se manejará el concepto de ciclo de vida del proyecto, el cual no coincide con el ciclo
de vida del producto.
Se abordarán las fases del proyecto.
Se analizará en qué momento del proyecto nos encontramos dentro de los cinco grupos
de procesos de la dirección de proyectos (inicio, planificación, ejecución, monitoreo y
control, y cierre).
Se analizarán las áreas de conocimiento de la dirección de proyectos.
3/41
III. 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 supone 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, el cual
analiza 50.000 proyectos, desde pequeños proyectos TIC a gigantescos proyectos de ingeniería. Según el
informe CHAOS 2015, solo un 29 % de estos proyectos finalizaron con éxito, mientras que el 52 % lo
hicieron con deficiencias (retraso, sobrecoste y/o menos requisitos de los esperados).
La Figura 2.1 muestra la evolución histórica de este estudio que comenzó en 1994.
Figura 2.1. Porcentaje de resolución de proyectos años 2004 a 2015 según informe CHAOS
Por último, en 2017, el PMI sacó su informe Pulse of the Profession. Aumento de las tasas de éxito. La
transformación del alto costo de un bajo desempeño, donde destaca que “por primera vez en cinco años,
una mayor cantidad de proyectos cumplen los objetivos e intención de negocio iniciales y se terminan
dentro del presupuesto. También ha habido una disminución significativa en la pérdida de dinero: las
organizaciones están desperdiciando un promedio de $97 millones por cada $1.000 millones invertidos
debido al deficiente desempeño en los proyectos, es decir, un 20 % de mejora respecto del año
anterior”.[1]
4/41
Noticias: [1]
[1] Project Management Institute.Pulse of the Profession. Aumento de las tasas de éxito. La transf
ormación del alto costo de un bajo desempeño. Project Management Institute.
Figura 2.2. Porcentaje de proyectos finalizados con éxito 2012-2015
IV. 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 descontrolaban 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.
5/41
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
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 sistema 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 direcció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 actividades a realizar,

asignando recursos asignados, identificando restricciones, etc.
Aporta herramientas para la gestión y el control del proyecto, informes de incidencias, informes de
estado, desviaciones, control de cambios, etc.
Asegura la satisfacción del cliente, ya que se focaliza en satisfacer sus requerimientos y expectativas.
6/41
Aumenta la satisfacción del equipo de proyecto, ya que todos ellos colaboran activamente.
Fomenta la disciplina de trabajo.
Figura 2.4. Beneficios de utilizar una metodología
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 características de la
organización. Dichas características, así como las diferencias entre metodologías predictivas y ágiles, se
resumen en la siguiente figura:
7/41
Figura 2.5. Diferencia entre metodologías ágiles y predictivas
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 potente 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.
4.1. Metodologías predictivas de gestión de proyectos

Las metodologías de gestión de proyectos conocidas como predictivas se conocen también con el
nombre de metodologías clásicas, tradicionales o formales.
Estas metodologías parten de las siguientes premisas (Alnasser, 2010):
8/41
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 esfuerzos 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 primera. 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 2017 (PRojects IN Controlled Environments 2), impulsado por la Oficina de
Comercio Gubernamental del Reino Unido.
4.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 500.000 en el año 2017 a lo largo
de 180 países (PMI, 2017).
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 publicació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).
9/41
La Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK) (2013) proporciona 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.
4.3. PRINCE2 2017

PRINCE (PRojects IN Controlled Environments) es una metodología de gestión de proyectos nacida en
el Reino Unido que pretende convertir proyectos que manejan una carga importante de variabilidad y de
incertidumbre en entornos controlados.
En mayo de 2017, AXELOS publicó una nueva versión de la guía de PRINCE2 2017 manteniendo su
estructura de procesos, principios y temáticas. Entre los principales cambios en la guía podemos citar:
“Adaptar PRINCE2 a las necesidades de las organizaciones y entornos de proyectos (concepto de

Project tailoring).
2
Apuntalar los principios que sustentan PRINCE2.
3
Aclarar el vínculo entre los temas y principios.
La reestructuración de la guía de “temas” para acomodar ejemplos específicos de sastrería (tailoring).
La aplicación práctica del método y la guía, con numerosos ejemplos, pistas y consejos.
Manteniendo su certificación a través de la membresía PRINCE2”.[2]
Anotación: [2]
[2] AXELOS Global Best Practice. PRINCE2 2017 Update, About the update.
10/41
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.
PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empresas 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
7 procesos que forman la gestión de proyectos.

7 principios que constituyen la base del método de gestión de proyectos.
7 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:
Figura 2.6. P Principios, temáticas y procesos de PRINCE2
4.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 continuamente. Cualquier project
manager que preste atención rigurosamente a estas temáticas 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:
11/41
Figura 2.7. Las temáticas de PRINCE2
4.5. PMBOK versus PRINCE2

El PMBOK, está considerado una guía que recoge una serie de buenas prácticas ampliamente
reconocidas sobre la dirección de proyectos de las cuales el project manager o la organización deciden
cuáles son de aplicación a cada proyecto en particular.
PRINCE2 es un metodología y está más orientado al uso o a la acción. PRINCE2 prescribe cómo
planificar y ejecutar el proyecto; si no se siguen los pasos no es PRINCE2, de hecho lo denominan con el
acrónimo PINO (Prince In Name Only).
La siguiente figura muestra una comparación entre las áreas de conocimiento de la Guía PMBOK y las
temáticas de PRINCE2:
12/41
Figura 2.8. Comparación áreas conocimiento PMBOK y áreas temáticas PRINCE2
Ambas metodologías presentan algunas similitudes que, por ejemplo, permiten su aplicació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.
Sin embargo, también podemos encontrar algunas diferencias que son resumidas en la siguiente tabla:
Figura 2.9. Diferencias entre PMBOK y PRINCE2
4.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 contenido y carácter social (Paris, 2011).
13/41
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 proyectos 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 ejecución como una
respuesta rápida y flexibilidad para funcionar en entornos de negocio que cambian y evolucionan
rápidamente.
4.7. El Manifiesto Ágil

En marzo de 2001, 17 críticos de los modelos de producción basados en procesos, convocados 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 denominado 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.
14/41
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.
La última frase es clave, pues no se quiere decir que no se necesiten procesos ni herramientas, sino que
tener un buen equipo es más importante.
4.8 Los 12 principios del Manifiesto Ágil

El Manifiesto Ágil, tras los postulados de los cuatro valores descritos anteriormente en los que se
fundamenta, establece 12 principios (Dimes, 2015). En la siguiente tabla se han relacionado los 12
principios del Manifiesto Ágil con el valor en el que impacta, para facilitar su comprensión:
Figura 2.10. Los 12 principios del Manifiesto Ágil
Existen continuas similitudes entre las metodologías ágiles y la filosofía de mejora continua 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. Aspectos 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 también son recogidos en los
principios ágiles.
15/41
Detrás del pensamiento ágil existen varias guías o metodologías específicas para gestionar
proyectos, como 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.
Aunque estas metodologías surgieron y se desarrollaron a partir de entornos relacionados con el

desarrollo de software, cada vez más se utilizan en otros entornos de negocio que cambian y evolucionan
rápidamente.
4.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 conocidos y ampliamente utilizados para el desarrollo de software. El nombre fue acuñado por Ken
Beck, autor del primer libro sobre la materia (Extreme Programming Explained: Embrace Change; 1999),
debido a que el enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el desarrollo
iterativo, y con la participación del cliente en niveles “extremos”.
La primera aplicación de programación extrema se atribuye a Ken Beck en Chrysler Corporation en 1996
para desarrollar una aplicación de nóminas.
En la programación extrema, todos los requerimientos se expresan como escenarios (llamados 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.
16/41
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.
La siguiente figura ilustra el proceso de la programación extrema (XP):
Figura 2.11. El ciclo de entrega en la Programación Extrema
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 manera definida
de hacer las cosas en la comunidad de código abierto, y mucho de su acercamiento 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
17/41
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 consideradas como “pesadas”.
Según el creador de Scrum, Sutherland (2015), es un cambio radical respecto a los antiguos 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 mejor y
producen mejores resultados si trabajan en equipos autogestionados en el que cada uno toma
responsabilidad sobre su trabajo y se compromete con la calidad 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 final. 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 optimizar la
previsibilidad y controlar el riesgo. En Scrum, cada iteración se denomina sprint y tiene una duración fija de
2 a 4 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 problemas
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 especí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.
Las reglas de Scrum pueden resumirse en la siguiente figura:
18/41
Figura 2.12. Las reglas de Scrum
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 plantean 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.
19/41
V. 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 marcha. 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 sencillo 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.
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 fuertes problemas a las siguientes fases.
Los ciclos de vida del proyecto pueden ser:
20/41
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 complejas como un túnel, un aeropuerto o un software crítico.
En estos casos, los aspectos 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 requieren un importante esfuerzo de reajuste de todo
el proyecto (planificación, ejecución, control), por lo que no es aconsejable en entornos altamente
cambiantes.
Ciclos de vida adaptativos
También conocidos como métodos orientados al cambio 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 continuamente 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 claro de este tipo de ciclo de vida
podemos encontrarlo en los proyectos de investigació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 equipo 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.
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 intencionada una o más actividades del proyecto a medida que aumenta el entendimiento 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í sucesivamente. Esto permite al usuario final ir testando y
reportando feedback del producto semiterminado conforme avanza el proyecto (PMI, 2013).
21/41
Veamos a continuación algunas consideraciones en cuanto al ciclo de vida de los proyectos (PMI,
2013).
Figura 2.12.A: Coste de los cambios a lo largo del ciclo de vida 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.
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.
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 primeras 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.
Esta misma figura nos muestra que el coste de los cambios se incrementa considerablemente 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 antes 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 reforma. 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.
5.1. Ciclo de vida del producto y ciclo de vida del proyecto
22/41
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:
Figura 2.13. Ciclo de vida de los sistemas
Un mismo producto, en general, generará múltiples proyectos. Pongamos como ejemplo el desarrollo de
un modelo de Smartphone, donde hay un proyecto de diseño del terminal, luego proyectos para adecuar
las distintas fábricas o cadenas de montaje que lo produzcan, proyectos de ampliación de gama (como
hacerlo sumergible) y, finalmente, el proyecto de desmontaje de las líneas de producción cuando resulte
obsoleto.
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 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).
23/41
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 adquisición, desarrollo o fabricación de
un producto.
Figura 2.14. Ciclo de vida del producto y ciclo de vida del proyecto
VI. 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 perfectamente 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 claramente 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.
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 deberían dividirse en fases siguiendo criterios
análogos con el objetivo de facilitar la transferencia de información entre proyectos.
24/41
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.
La superposición de fases presenta alguna ventaja importante, como permitir una ejecució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 nuevo hospital. Al
mismo tiempo que se ejecuta la obra, se podrían ir comprando los equipos 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 encontrarnos 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 equipo electromédico.
VII. 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, 2017).
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.
Herramientas
Proceso
Entrada
Salida
Figura 2.15. Descripción de proceso
25/41
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 asegurar 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.
Los procesos de la dirección de proyectos pueden agruparse en cinco categorías conocidas como
grupos de procesos de la dirección de proyectos (PMI, 2017):
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á ejecutando.
Grupo de procesos de planificación
los procesos de planificación incluyen todos los procesos necesarios para definir el alcance del
proyecto, establecer los objetivos 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.) aplicaremos los 5 grupos de procesos: inicio, planificación, ejecución,
monitoreo y control, y cierre.
Por último, es interesante cómo en el PMBOK (2013) se abordaba el diagrama de flujo de procesos.
Como se puede ver a continuación este proporciona un resumen global 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 salidas 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.
26/41
Figura 3.21. Interacciones entre Procesos de la dirección de 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. 53
7.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.
Según el PMI, el proyecto comienza en el instante en que el patrocinador firma el acta de constitución
del proyecto, documento que resume el proyecto al incluir alcance, hitos principales, presupuesto,
interesados principales, criterios de éxito y riesgos. Este documento, a su vez, designa al director de
proyecto y define su autoridad. Generalmente hay mucho trabajo previo al comienzo de un proyecto, por
ejemplo, una negociación contractual con el cliente.
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.
27/41
Figura 2.16. Límites del Proyecto
En esta fase debe disponerse de información relacionada con el proyecto que se plasma en el acta de
constitución del proyecto, que no debe confundirse ni reemplazarse por el contrato 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.
7.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 navegación
necesitamos tener en cuenta una serie de consideraciones importantes relacionadas con los siguientes
aspectos:
Alcance.
Tiempo.
Costo.
Calidad.
Comunicaciones.
Recursos humanos.
28/41
Riesgos.
Adquisiciones.
Participación de los interesados.
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 documentació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.
7.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 especificaciones 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.
29/41
Durante la ejecución del proyecto, en función de los resultados obtenidos, se puede requerir 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 productividad 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).
7.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), coincidiendo 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, 2017):
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 problemas.
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.
7.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 previstos inicialmente, existen
otros objetivos adicionales en los procesos de cierre de sumo interés para el desempeño de futuros
proyectos:
30/41
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 originaron 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 ejecució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 transferencia de información en este sentido puede
ayudarnos a que las buenas prácticas 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 oportunidades comerciales.
VIII. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE

PROYECTOS
Además de los cinco grupos de procesos de la dirección de proyectos descritos anteriormente (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 elegido. A modo de
ejemplo, veamos los procesos y áreas de conocimiento del PMBOK y las fases y temáticas de PRINCE2:
31/41
Figura 2.17. Procesos / Areas conocimiento PMBOK y Fases / Temáticas PRINCE2
Continuando con el estándar del PMBOK (PMI, 2017), este identifica diez áreas de conocimiento 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 5 grupos de procesos de la dirección
de proyectos y las 10 áreas de conocimientos de la dirección de proyectos 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.
Esta tabla se ha completado con los puntos de la norma UNE-ISO 21500 Orientación sobre la gestión de
proyectos , que no se abordan expresamente como tal en la Guía del PMBOK. 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 trabajo que redactó la norma ISO 21500, publicada en su primera edición en 2012.
32/41
Figura 2.18. Correspondencia entre grupos de procesos y áreas de conocimiento de la

dirección de proyecto
33/41
IX. RESUMEN
El rol del project manager
34/41
La utilización de metodologías para la dirección de proyectos reduce la aparición de problemas

a lo largo de la vida del proyecto, por lo que la probabilidad de éxito se incrementa. 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 procesos,
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 PMBOK 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 perfectamente 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 difundido 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 5 categorías conocidas
c o mo grupos de procesos de la dirección de proyectos : inicio, planificación, ejecución,
monitorización y control, y cierre. Estos grupos de procesos pueden aplicarse a cada una de las
fases del proyecto y al proyecto en su conjunto. La Guía del PMBOK identifica también 10 á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, adquisiciones e interesados.
A lo largo de los próximos módulos se profundizará en cada una de estas áreas de

conocimiento, abordando los procesos asociados a cada una de ellas, así como sus entradas,
salidas y herramientas.
X. LECTURAS
LECTURA 1 - PLANTILLAS PARA PROYECTOS

A lo largo de este curso se van a desarrollar las diferentes áreas de conocimiento necesarias para poder
gestionar adecuadamente un proyecto. La utilización de plantillas puede servirnos como soporte durante las
diferentes actividades realizadas durante las fases del proyecto.
En esta lectura se presentan ejemplos de las plantillas más comúnmente utilizadas para la Dirección de
Proyectos.
35/41
Recursosenprojectmanagement.com. “Plantillas para proyectos”.
LECTURA 2 - “SCRUM”, EL MÉTODO DE TRABAJO QUE HARÁ

QUE SU EMPRESA SEA MÁS EFICIENTE
En un mundo que está cambiando constantemente, las empresas exigen nuevas formas de realizar los
proyectos que permitan obtener el máximo rendimiento a cada minuto de trabajo y que sean capaces de
producir resultados solventes sin dar muchas vueltas. Los resultados son importantes para dejar una buena
sensación no solo para el cliente, sino también en el usuario final.
Se da una circunstancia, que las empresas tecnológicas nacieron con otro modelo diferente, libre de
jerarquías y donde cada persona podía ser autónoma y creativa. Los ciclos de trabajo eran más cortos y
las tareas se organizaban teniendo en cuenta una fecha de entrega. Los propios grupos de trabajo decidían
el rumbo de su proyecto, cambiando las órdenes directas por una comunicación bilateral entre el cliente y
los miembros del equipo.
Sastre, Íñigo. “‘Scrum’, el método de trabajo que hará que su empresa sea más eficiente”.
Cadenaser.com. 27 de febrero de 2015.
Lectura imprescindible para responder correctamente la evaluación del módulo.
LECTURA 3 - CICLOS DE VIDA PARA GESTIONAR UN

PROYECTO SOFTWARE: CASCADA, ESPIRAL, ITERATIVO,
INCREMENTAL O ÁGIL
Es curioso ver como el concepto “ciclo de vida”, una de las piezas más fundamentales, y
transcendentales, de la gestión de un proyecto software produce tanta confusión.
En parte, tampoco es de extrañar, debido a que no existe una única terminología al respecto, existen
muchas definiciones, conceptos confusos, etc.
A lo largo de esta lectura se profundiza en los ciclos de vida para gestionar un proyecto software:
cascada, espiral, iterativo, incremental o ágil.
Garzás, Javier. “Ciclos de vida para gestionar un proyecto software: cascada, espiral, iterativo, i
ncremental o ágil”. Javiergarzas.com, 3 de julio de 2013.
36/41
Lectura imprescindible para responder correctamente la evaluación del módulo.
LECTURA 4 - IMPLANTACIÓN DE METODOLOGÍAS ÁGILES:

IDENTIFICANDO BARRERAS ORGANIZATIVAS
El éxito de la implantación de metodologías ágiles es función de la cultura de la organización. La lectura
recientemente presentada en la web de Wolf Project Management facilita un modelo para afrontar estos
cambios.
Ortiz Giner, Sergio. “Implantación de metodologías ágiles: identificando barreras organizativas”,

Wolf Project, s. f.
LECTURA 5 - AUMENTO DE LAS TASAS DE ÉXITO

Uno de los aspectos que los miembros de la profesión valoran de PMI es el Pulse of the Profession,
donde se indican las últimas tendencias en dirección de proyectos. El rigor y transparencia con que se
elaboran se muestra en el hecho de que por varios años se indicó un empeoramiento en el desempeño en
gestión de proyectos hasta este último informe.
Project Management Institute. Pulse of the Profession. Aumento de las tasas de éxito. La transf
ormación del alto costo de un bajo desempeño. Project Management Institute.
37/41
Ejercicios
CASO PRÁCTICO 1
25
Scrum se ha transformado en uno de los estándares más extendidos en las llamadas metodología ágiles.
De hecho, muchos, y aunque no es correcto, asimilan Scrum a ágil.
Las metodologías tradicionales de gestión de proyectos, cuyo origen es el sector industrial, pero ya
aplicadas desde hace décadas en el sector servicios, se han demostrado menos eficaces cuando la gestión
de un proyecto presenta –ya desde su misma concepción– un grado importante de incertidumbre en su
desarrollo que imposibilita su planificación inicial y su ejecución lineal.
Ante los proyectos que necesitan agilidad, no previsibles, sin experiencias anteriores o referentes, sin la
información adecuada conocida, y en la que el propio desarrollo del proyecto condiciona su continuidad
es, por tanto, importante todo lo planteado en la guía que se presenta a continuación.
En definitiva, el conocimiento de esta guía es muy interesante para que el alumno pueda familiarizarse
con esta metodología y añadirlo a su maletín de conocimientos.
Ken Schwaber y Jeff Sutherland. La guía de ScrumTM. La guía definitiva de Scrum: las reglas del
juego. Scrumguides.org., julio de 2016.
ACTIVIDAD INTERACTIVA: PROYECTOS ÁGILES
38/41
Recursos
Enlaces de Interés
http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf: CHAOS
MANIFESTO 2013 - Think Big, Act Small
http://cadenaser.com/ser/2015/02/26/ciencia/1424944497_395736.html: ‘Scrum’, el método de
trabajo que hará que su empresa sea más eficiente.
Bibliografía
A system approach to planning, scheduling and controlling.: Herzner H. Project
Management. A system approach to planning, scheduling and controlling. John Wiley & Sons;
2001.
Administración Profesional de Proyectos.: Chamoun Y. Administración Profesional de
Proyectos. La Guía. Mc Graw-Hill Interamericana; 2002.
Comparación de cuatro sistemas de certificación del ámbito de la dirección de
proyectos.: Cardoza Ramírez A, Guerrero Chanduví D, De los Ríos Carmenado I.
Comparación de cuatro sistemas de certificación del ámbito de la dirección de proyectos. XV
Congreso Internacional de Ingeniería de Proyectos; 2011. Disponible en:
http://oa.upm.es/12809/1/INVE_MEM_2011_107522.pdF
Conceptos básicos de Scrum: Desarrollo de software Agile y manejo de proyectos Agile.:
Dimes T. Conceptos básicos de Scrum: Desarrollo de software Agile y manejo de proyectos
Agile. Babelcube, Inc.; 2015.
Dirección y Gestión de Proyectos Norma UNE-ISO 21500:2013.: AENOR. Dirección y
Gestión de Proyectos Norma UNE-ISO 21500:2013. AENOR; 2103. Disponible en:
http://www.idi.es/docs/iso_21500._certificacion.pdf.
Dirección y Gestión de Proyectos. Un enfoque práctico.: Domingo Ajenjo A. Dirección y
Gestión de Proyectos. Un enfoque práctico. RA-MA Editorial; 2000.
El Compañero de Bolsillo de la Guía del PMBOK.: Wuttke T, Snijders P, Zandhuis A. El
Compañero de Bolsillo de la Guía del PMBOK. Van Haren Publishing; 2014.
Éxito en la Gestión de Proyectos con PRINCE2.: Oficina de Comercio Gubernamental del
Reino Unido. Éxito en la Gestión de Proyectos con PRINCE2. 5ª ed. TSO; 2009.
Extreme Programming Explained: Embarce Change.: Beck K. Extreme Programming
Explained: Embarce Change. 2ª ed. Addison-Wesley Pearson Education; 2004.
Fundamentos de la Gestión de Proyectos.: Lock D. Fundamentos de la Gestión de
Proyectos. AENOR; 2001.
Gestión Ágil de Proyectos: Lean Project Management.: Lledó P. Gestión Ágil de Proyectos:
Lean Project Management. Trafford Publishing; 2012.
Gestión de proyectos con mapas mentales.: Ocaña JA. Gestión de proyectos con mapas
mentales. Volumen I. ECU, Editorial Club Universitario; 2012.
39/41
Gestión integral de proyectos.: 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.
Gestión Lean y Ágil de proyectos.: Lledó P. Gestión Lean y Ágil de proyectos. Trafford
Publishing; 2014.
Gestión Proyectos Scrum Manager.: Palacio J. Gestión Proyectos Scrum Manager. Versión
2.5.1; 2015. Disponible en: http://scrummanager.net/files/gestion_proyectos_scrum_manager.pdf
Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK). : Project
Management Institute. Guía de los Fundamentos para la Dirección de Proyectos (Guía del
PMBOK). Project Management Institute, Inc.; 2017.
Ingeniería del software.: Sommerville I, Alfonso Galipienso MI. Ingeniería del software. 7ª ed.
Pearson Education; 2005.
Introducción a la Gestión de Proyectos.: Williams M. Introducción a la Gestión de Proyectos.
Ediciones Anaya Multimedia; 2008.
Introducción a la metodología de gestión de “proyectos ágiles”: un nuevo campo de
aplicación en las organizaciones deportivas.: 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. Disponible en:
http://www.fagde.org/archivos/Proyectos-%C3%A1giles.pdf
La dirección de proyectos: Una nueva visión.: Bucero Torres A. La dirección de proyectos:
Una nueva visión. 2ª ed. Díaz de Santos; 2013.
La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego: 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
Management Methodology for Enterprise Systems Implentations.: Verhage L. Management
Methodology for Enterprise Systems Implentations. Eburon; 2009.
Planificación preliminar del Proyecto.: Díaz Martín A. David y Goliat. Planificación
preliminar del Proyecto. RA-MA Editorial; 2008.
PRINCE2 o PMBoK: ¿Qué es mejor para gestionar mi proyecto?: LSBESBCN. PRINCE2
o PMBoK: ¿Qué es mejor para gestionar mi proyecto? 2010. Disponible en:
http://blog.masterinprojectmanagement.net/prince2-y-pmbok/
Project Management Methodologies: selecting, implementing, and supporting
methodologies and processes for projects.: Charvart J. Project Management Methodologies:
selecting, implementing, and supporting methodologies and processes for projects. John Wiley &
Sons Inc.; 2003.
Project Management.: Brojt D. Project Management. Ediciones Granica; 2005.
Project Management. Case studies.: Herzner H. Project Management. Case studies. John
Wiley & Sons; 2006.
Pulse of the Profession: Capturing the Value of Project Management.: Project Management
Institute. Pulse of the Profession: Capturing the Value of Project Management. Project
Management Institute, Inc.; 2015. Disponible en: http://www.pmi.org/~/media/PDF/learning/pulse-
of-the-profession-2015.ashx
Scrum: El nuevo y revolucionario modelo organizativo que cambiará tu vida.: Sutherland
J. Scrum: El nuevo y revolucionario modelo organizativo que cambiará tu vida. Grupo Planeta
Spain; 2015.
40/41
The AMA handbook of Project Management.: Dinsmore PC, Cabanis-Brewin J. The AMA
handbook of Project Management. 2nd ed. American Management Association; 2006.
Thing Big, act small.: CHAOS. CHAOS Manifesto 2013. Thing Big, act small. The Standish
Group International; 2013. Disponible en:
http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf
Glosario.
PMBOK: Guía de los Fundamentos para la Dirección de Proyectos. Es el estándar de facto

en dirección de proyectos con más de 4,5 millones de copias vendidas. Su sexta edición se lanzó
en septiembre 2017.
Procedimiento: Es el método de ejecutar los procesos, lo que nos lleva a desarrollar con
mucho más detalle el cómo. Va fijando los pasos para ejecutar el proceso. Si nos salimos de los
pasos o fases marcados, ya no estaremos aplicando el procedimiento correspondiente.
Proceso: Según la norma ISO 9001, el concepto de proceso radica en un conjunto de

actividades interrelacionadas que convierten entradas en salidas, generalmente una salida es la
entrada de otro proceso.
Scrum: Es un marco de trabajo (framework) á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).
41/41

Marco de Referencia para La Dirección de Proyectos

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

Marco de Referencia para La Dirección de Proyectos

Cargado por

Copyright:

Formatos disponibles

Marco de referencia para la dirección de

proyectos © IMF Smart Education

Marco de referencia para la dirección de

Se conocerán las metodologías más relevantes de la dirección de proyectos haciendo

III. IMPORTANCIA DE LA GESTIÓN DE PROYECTOS

Figura 2.2. Porcentaje de proyectos finalizados con éxito 2012-2015

IV. METODOLOGÍAS DE DIRECCIÓN DE PROYECTOS

Exceso de carga de trabajo planificada o en proceso.

La utilización de una metodología o sistematización de los procesos para la ejecución de un proyecto

Figura 2.3. Evolución de un proyecto usando metodología y sin usarla

Las metodologías de gestión de proyectos establecen los estándares de procesos y áreas de

Favorece la creación de un buen plan de proyecto, definiendo el alcance y actividades a realizar,

Fomenta la disciplina de trabajo.

Figura 2.4. Beneficios de utilizar una metodología

En función de las características de la organización, tipo de proyecto, restricciones de tiempo, coste,

Figura 2.5. Diferencia entre metodologías ágiles y predictivas

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

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

Estabilidad del entorno

Ejemplos típicos de proyectos gestionados bajo metodologías predictivas podrían ser

Obras de construcción civil.

Dos de las metodologías predictivas más ampliamente implantadas son

PMBOK (Project Management Body of Knowledge), desarrollado por el Project

4.3. PRINCE2 2017

“Adaptar PRINCE2 a las necesidades de las organizaciones y entornos de proyectos (concepto de

La reestructuración de la guía de “temas” para acomodar ejemplos específicos de sastrería (tailoring).

Manteniendo su certificación a través de la membresía PRINCE2”.[2]

7 procesos que forman la gestión de proyectos.

Estos principios, temáticas y fases se resumen en la siguiente tabla:

Figura 2.6. P Principios, temáticas y procesos de PRINCE2

4.4. Las temáticas de PRINCE2

Figura 2.7. Las temáticas de PRINCE2

4.5. PMBOK versus PRINCE2

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

Figura 2.9. Diferencias entre PMBOK y PRINCE2

4.6. Por qué las metodologías ágiles de gestión de proyectos

Este origen de la gestión de proyectos ha condicionado el enfoque de las metodologías que

A diferencia de los proyectos predictivos o tradicionales, la gestión de proyectos ágil no se basa en la

4.7. El Manifiesto Ágil

Con este trabajo hemos llegado a valorar:

A los individuos y su interacción, por encima de los procesos y las herramientas.

La colaboración con el cliente, por encima de la negociación contractual.

4.8 Los 12 principios del Manifiesto Ágil

Figura 2.10. Los 12 principios del Manifiesto Ágil

Adaptive Software Development (ASD).

Aunque estas metodologías surgieron y se desarrollaron a partir de entornos relacionados con el

4.9. Metodologías ágiles

Se planifican entregas del sistema pequeñas y frecuentes.

La siguiente figura ilustra el proceso de la programación extrema (XP):

Figura 2.11. El ciclo de entrega en la Programación Extrema

Las reglas de Scrum pueden resumirse en la siguiente figura:

Figura 2.12. Las reglas de Scrum

Reunión de planificación del sprint (Sprint Planning Meeting)

Scrum diario (Daily Scrum)

Revisión del sprint (Sprint Review)

Retrospectiva del sprint (Sprint Retrospective)

el equipo autoanaliza su forma de trabajar identificando planes de mejora.

V. CICLO DE VIDA DEL PROYECTO

Los ciclos de vida del proyecto pueden ser:

Ciclos de vida predictivos

Ciclos de vida adaptativos

A continuación, se realizarán estudios clínicos para detectar si es efectivo o no. La cantidad y

Ciclos de vida iterativos e incrementales