14MMAN JJRuiz

MÁSTER UNIVERSITARIO EN PROJECT MANAGEMENT
Módulo X. Metodologías tradicionales e innovadoras. Gestión de proyectos sectoriales
METODOLOGÍAS
TRADICIONALES E
INNOVADORAS. GESTIÓN DE
PROYECTOS SECTORIALES
José Javier Ruíz Cobo

Este material es de uso exclusivo para los
alumnos de la VIU. No está permitida la
reproducción total o parcial de su contenido ni
su tratamiento por cualquier método por
aquellas personas que no acrediten su relación
con la VIU, sin autorización expresa de la
misma.
Edita
Universidad Internacional de Valencia
Máster Universitario en
Project Management
Metodologías tradicionales e innovadoras. Gestión de proyectos
sectoriales
Módulo X. Metodologías tradicionales e innovadoras. Gestión de
proyectos sectoriales
5CTS

viu Máster Universitario en Project Management
.es Módulo X. Metodologías tradicionales e innovadoras. Gestión de proyectos sectoriales
Índice
TEMA 1. METODOLOGÍAS DE GESTIÓN DE PROYECTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Metodologías, métodos, normas y procedimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Metodologías de Gestión Tradicionales y Ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3. Línea de tiempo de las metodologías de la gestión de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4. La normativa internacional: ISO 21500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
TEMA 2. MARCO DE PROCESOS: PRINCE2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2. Organización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3. Modelo de los 7 procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4. Procesos de PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1. El Proceso de Puesta en Marcha del Proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.2. El Proceso de Dirección del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.3. El proceso de inicio de un proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.4. El proceso de control de fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.5. El proceso de gestión de la entrega de productos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.6. El proceso de gestión de los límites de etapa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.7. El proceso de cierre del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.5. Comparativa PRINCE 2 vs. PMBOK® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
TEMA 3. METODOLOGÍAS AGILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1. Manifiesto por el desarrollo Agile de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2. Principios de Agile: el rol del líder de proyecto en Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3. Algunas técnicas y herramientas de Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.1. SCRUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.3. Lean. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.4. Extreme Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4. Declaración de Interdependencia (DOI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
TEMA 4. SCRUM: EJEMPLO DE MARCO DE AGILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1. Historia de Scrum. Teoría de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5
Metodologías tradicionales e innovadoras. Gestión de proyectos sectoriales viu
5ECTS .es
4.2. Equipos de Scrum. Eventos de Scrum. Artefactos de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1. Equipos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.2. Eventos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.3. Artefactos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3. Relación de Scrum con Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1. Lean y la industria automotriz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.2. Lean y la industria del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
TEMA 5. LA GESTIÓN DE PROYECTOS EN DIFERENTES INDUSTRIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1. La gestión de proyectos en la industria de la construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2. La gestión de proyectos en la industria del software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
TEMA 6. DETERMINACIÓN DE LA MEJOR METODOLOGÍA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1. Enfoques, metodologías y procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2. Enfoques de management. Complejidad relativa y absoluta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3. Project tracking y Project steering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.1. Project tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.2. Project Steering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
GLOSARIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ENLACES DE INTERÉS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
BIBLIOGRAFÍA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Referencias bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Bibliografía recomendada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6
7
5ECTS .es
Leyenda
Glosario
Términos cuya definición correspondiente está en el apartado “Glosario”.
Enlace de interés
Dirección de página web.
8
Tema 1.
Metodologías de gestión de proyectos
1.1. Metodologías, métodos, normas y procedimientos

La gestión de proyectos se ha convertido en un elemento esencial para la ejecución exitosa de
proyectos, independientemente del sector industrial o del tamaño del proyecto, ya que permite
mejorar la probabilidad de alcanzar los objetivos del proyecto. Algunas de las ventajas que proporciona
una correcta gestión de proyectos son:
•• Clarifica las metas y objetivos del proyecto.
•• Los procesos de trabajo son más eficientes y efectivos.
•• Permite mayor flexibilidad y adaptación de las lecciones aprendidas de proyecto a proyecto.
•• Mayor precisión en la planificación, identificación, gestión de riesgos, desafíos y complejidades.
•• Asegura un mayor grado de estandarización.
•• Roles claros e identificación de las responsabilidades, con lo que se mejora la comunicación.
9
5ECTS .es
•• Optimiza la calidad de los productos y entregables.
Una Metodología de Gestión de Proyectos puede ser explicada a través de múltiples definiciones:
podría ser la aplicación de conocimiento, habilidades, herramientas y técnicas para cumplir o superar
los requisitos del proyecto; una hoja de ruta para llevarte de donde estás a donde quieres estar; un
conjunto integral de mejores prácticas, herramientas y técnicas que son dinámicas, flexibles, adaptables
y personalizables a diferentes proyectos, dentro de un ambiente específico; y así, podríamos seguir ad
infinitum dando diferentes visiones y definiciones.
En general, una metodología identifica enfoques específicos para la gestión de cada aspecto del
proyecto, en forma de procedimientos generales, específicos del sector, y normas y reglamentos
que establecen los estándares para garantizar la calidad y el control. En un sentido más amplio, una
metodología incluye una amplia gama de áreas de conocimiento y un conjunto de herramientas y
técnicas para apoyar y gestionar cada aspecto del proyecto.
Las metodologías de proyectos deben funcionar eficazmente para toda la gama de proyectos llevados
a cabo dentro de una organización específica, incluso cuando las características del proyecto (tamaño
del equipo, criticidad del proyecto, naturaleza o alcance) sean muy diferentes y heterogéneas.
Por lo tanto, cada metodología debe proporcionar al equipo del proyecto un conjunto de procesos que
pueden escalarse o sustituirse según sea necesario, proyecto por proyecto, para ayudar a la gestión
de los proyectos a lo largo de todo su ciclo de vida: los equipos de proyecto podrán comprender
claramente su ámbito de trabajo, lo que cada uno de ellos debe lograr, cómo su trabajo se ajusta y
contribuye al proyecto en su conjunto, y proporcionar las herramientas y técnicas para ayudarles a
hacer el proyecto exitoso.
Los componentes de la metodología cubrirán:
i. Los procesos de gestión de proyectos tales como iniciar, planificar, ejecutar y monitorear el
progreso del proyecto.
ii. La selección de herramientas y técnicas para comunicar la entrega a la satisfacción de todos

los interesados.
iii. Un conjunto consolidado e integrado de mejores prácticas y valores apropiados de gestión de

proyectos.
iv. Una lista de referencias de terminología y lenguaje como denominador común en el entorno
del proyecto.
A continuación, vamos a mostrar una forma de categorización de las metodologías de gestión de

proyectos valiéndonos de múltiples niveles, partiendo de un ámbito muy general, que vamos a ir
particularizando hasta llegar a una metodología de alcance muy individualizado:
10
L5-M.
Específica
ad-hoc
L4- Metod.
específica para un
proyecto
L3- Metodología específica
para una organización
L2- Metodología específica
de un sector industrial
L1- Best practices, standards & guidelines
Figura 1. Representación de la categorización de las Metodologías de Gestión de Proyectos por niveles. Fuente: elaboración
propia.
L1 - Mejores prácticas, estándares y pautas
Este es el grupo al que nos referimos habitualmente cuando utilizamos el término metodologías. Sin
embargo, varios autores prominentes respaldan la opinión de que no se trata de metodologías, sino
que se consideran enciclopedias de mejores prácticas.
Estas mejores prácticas son fuentes de información extremadamente valiosas para el desarrollo
de nuevos Gestores de Proyecto, particularmente porque comúnmente apoyan los programa
de muchos cursos de capacitación en gestión de proyectos, como pueden ser la Guía PMBOK® o
PRINCE2. Sin embargo, por su naturaleza multisectorial y aplicables a cualquier tamaño de proyecto,
las metodologías L1 son las más complejas de desarrollar.
L2 - Metodología específica de un sector
El siguiente nivel son las metodologías específicas de un sector. Diferentes industrias requieren
distintas variaciones y particularización en el conocimiento de gestión de proyectos, así como en las
regulaciones y enfoques sectoriales específicos para ejecutar proyectos. Las metodologías sectoriales
se construyen extrayendo los elementos apropiados de las metodologías de Nivel 1, agregando
los componentes requeridos por las reglas específicas del sector, las reglamentaciones, las mejores
prácticas y asignándolas al flujo natural de trabajo dentro del sector.
La necesidad de especificidad surge debido a las diferencias en la naturaleza del trabajo, el flujo
de trabajo, el entorno, los conjuntos de habilidades de las personas involucradas y el riesgo y las
prioridades de cada sector. Como consecuencia, por ejemplo, se han desarrollado metodologías
específicas orientadas al sector de desarrollo de software, como pueden ser Agile, SCRUM, etc. de
uso muy común en la actualidad.
11
5ECTS .es
L3 - Metodología personalizada y específica de una organización
En L3, la metodología específica del sector está adaptada para cumplir con la estrategia, la estructura,
la naturaleza de los proyectos y las necesidades de una organización específica.
Por ejemplo, Microsoft ha diseñado, implementado y operado con éxito su metodología conocida
como Microsoft Solution Framework (MSF). De manera similar, IBM tiene su propia metodología
orientada en la implementación y la entrega de proyectos llamados Rational Unified Process (RUP).
Ericsson introdujo una metodología propia para manejar proyectos de desarrollo de productos
conocida como PROPS. Las metodologías específicas de la organización también han sido adoptadas
por instituciones académicas. Por ejemplo, la metodología de la Universidad de Cornell también ha
sido adoptada de la Universidad de Princeton.
El grado de influencia que una organización específica tiene en las metodologías L1 y L2 varía
considerablemente. Sin embargo, el hecho de que una empresa (particularmente empresas más
pequeñas) no pueda extraer los enfoques desarrollados en L1 y L2 dará como resultado que sus
propias metodologías pierdan enfoques valiosos y dediquen costes de desarrollo reinventando la
rueda. Un paso importante en la implementación de una metodología L3 dentro de una empresa
es integrar los procesos del proyecto con los sistemas empresariales de la organización. Sin este
elemento vital, la organización encontrará dificultades considerables para acceder a la información
y tendrá que duplicar constantemente la gestión. Estos dos factores se citan comúnmente como una
causa de resistencia a la adopción de nuevas metodologías.
L4 - Metodología específica de un proyecto
Este nivel enfatiza que una metodología debe ser escalable para hacer frente a las diversas naturalezas
y tamaños de proyecto dentro de una organización. No es práctico desarrollar una metodología
completamente nueva para cada nuevo proyecto dentro de la misma organización. Sin embargo, si se
garantiza que las sucursales se apoyen en metodologías de orden superior (L3, L2 y L1) comunes, el
tiempo de desarrollo y el aprendizaje organizacional se mantienen lo más bajo posible. Por lo tanto,
la clave es desarrollar una metodología específica para la organización y el tipo de proyecto, pero que
también sea dinámica, flexible y adaptable, facilitando la adaptación a un proyecto determinado.
L5 - Metodología individualizada
En el grado más alto de especificidad en el diseño de la metodología: L5 se clasifica específicamente

para proyectos individualizados (desarrollados por una persona), que deben tener una relativa
simplicidad. Cada miembro del equipo debe estar adecuadamente formado en los procesos,
estructuras, herramientas y técnicas de gestión de proyectos si desea contribuir o liderar los proyectos
con éxito. En tal caso, el diseño de la metodología L5 se facilita extrayendo los componentes más
importantes y relevantes de L4 que son aptos para su uso en un entorno de proyecto individualizado.
12
1.2. Metodologías de Gestión Tradicionales y Ágiles

Una vez hemos revisado una clasificación muy general de cómo organizar las metodologías, vamos a
centrar el análisis en aquellas que se han identificado como más generales y de uso más común entre
los perfiles de gestor de proyectos (nivel 1 y 2).
Para empezar, catalogaremos estas metodologías en dos grandes categorías: metodologías

tradicionales y metodologías ágiles. La aparición de estas nuevas metodologías de tipo Agile viene
originada por la necesidad de optimización en la gestión de proyectos en los sectores de desarrollo
de software, si bien en la actualidad se está extendiendo su uso en nuevos sectores de aplicación.
Metodología Waterfall (tradicional)
Se considera como el modelo de ciclo de vida más básico, con un enfoque lineal y secuencial. En este
modelo, el proyecto se divide en diferentes fases, y cada fase requiere la necesidad de completarse
antes de pasar a la siguiente. El progreso se compara con una cascada, donde una vez que el agua
traspasa el borde del acantilado y comienza a fluir hacia abajo nunca puede regresar para llegar de
nuevo a la cima de la colina: el progreso nunca puede revertirse, es decir, no podemos retroceder de
una fase a la anterior.
En un proceso de cascada, normalmente las entradas de una fase son el resultado de las fases
anteriores. Los miembros del equipo no pueden cambiar los resultados que el proyecto ya ha
certificado anteriormente. Sin embargo, los requisitos están sujetos a cambios, por lo que existe la
necesidad de un mecanismo que garantice que las modificaciones de alcance se realicen de forma
controlada sin afectar al producto y su progreso.
Esta metodología debe utilizarse:
i. Cuando hay una imagen clara del producto final.
ii. Cuando los requisitos están bien definidos y entendidos, y no están sujetos a cambios.
iii. Cuando el interés está sobre todo en el producto final, y no tanto en el tiempo de desarrollo
del proyecto.
El modelo de cascada funciona bastante bien cuando el alcance del proyecto está muy acotado y las
posibles modificaciones que puedan solicitarse están muy delimitadas. También se adapta bien a los
proyectos en los que los cambios en el alcance se pueden introducir de forma controlada.
Sin embargo, el modelo de cascada falla cuando se demanda un cambio de alcance muy importante,
o existen muchas incertidumbres para acotar completamente dicho alcance. Por ejemplo, en
el mercado de software para PC las tecnologías de hardware y las necesidades de los clientes
cambian muy rápidamente. En tales situaciones, capturar las especificaciones de un proyecto desde
el principio es difícil. En consecuencia, el desarrollo no puede ocurrir de forma lineal. Cualquier
cambio en cualquier parte del producto, por ejemplo, debido a los comentarios de los clientes o la
evolución en determinadas tecnologías de hardware o software, o incluso simplemente para agregar
13
5ECTS .es
una característica que acaba de presentar un competidor, puede provocar que parte del hardware
utilizado ya no sea compatible, y el proyecto no se pueda completar.
Metodología Agile
El desarrollo ágil es en sí mismo un término muy amplio que incluye un conjunto de metodologías
ágiles: Scrum, XP, Crystal, FDD, DSDM, etc.
Las metodologías ágiles se han diseñado específicamente teniendo en cuenta la adaptabilidad a los
requisitos cambiantes. Una metodología ágil es una combinación de modelos de procesos iterativos
e incrementales, que tienen en cuenta la flexibilidad y la entrega oportuna del producto (software).
Los modelos ágiles consideran que cada proceso de desarrollo es diferente, y que los métodos ya
establecidos deben personalizarse para adaptarse mejor a los requisitos del proyecto.
Agile proporciona métodos para evaluar el desarrollo y los riesgos, y también la dirección a lo largo del
ciclo de vida del proyecto. El producto se desarrolla en una serie de rondas conocidas como iteraciones.
Cada iteración suele durar de 2 a 3 semanas e implica que varios equipos trabajen simultáneamente
en diversas áreas, como la recopilación de requisitos, la planificación, el diseño, la codificación y las
pruebas. Cada iteración garantiza una mejora en las características del producto desde la iteración
anterior, y el producto de iteración final involucra todas las características demandadas por el cliente.
Agile trabaja en los siguientes enfoques:
1. Individuos e interacciones: la autoorganización y la motivación son tan importantes como las

interacciones. También es muy importante la composición y organización de los grupos de
trabajo.
2. Software de trabajo: agile requiere la necesidad de desarrollar un prototipo funcional al inicio

de la vida del producto, y este prototipo suele ser la mejor manera de comunicarse con los
interesados que no disponen de conocimiento técnico para interpretar cómo funciona el
producto.
3. Participación del cliente: dado que agile no requiere todos los requisitos al comienzo del
software, es indispensable la interacción del cliente durante todo el desarrollo.
4. Adaptabilidad rápida: Agile debe ser capaz de adaptarse rápidamente a los requisitos
cambiantes y siempre que sea necesario para el desarrollo adecuado y oportuno del software.
Esta técnica de inspeccionar y adaptar disminuye significativamente los costos de desarrollo.
Los equipos pueden comenzar a desarrollar su versión al mismo tiempo que se mantiene el
proceso de recopilación de requisitos, lo que reduce el impacto de la "parálisis del análisis"
en el progreso. El ciclo de trabajo de un equipo está limitado a 2 semanas debido a que es
necesario que las partes interesadas dispongan de frecuentes oportunidades para revisar las
versiones.
Agile permite a las empresas mejorar constantemente sus productos y planificar sus lanzamientos
para una mejor aceptación y un mayor éxito. Por lo tanto, agile se asegura de que el esfuerzo realizado
no se desperdicie y que la relevancia del portfolio de productos no disminuya.
14
Un equipo adaptable agile tendrá dificultades para describir cuánto progreso se observará en la
próxima iteración y, probablemente, a qué riesgos se podrían enfrentar; pero podría ser capaz de
decir cuáles son las funcionalidades que se agregarán al producto. Cuanto más lejos está el plazo, más
vaga es la idea del resultado final.
Cada equipo agile dispone de un representante del cliente, que es elegido por las partes interesadas
para operar en su nombre y estar disponible para responder las preguntas que los desarrolladores
le planteen. Al final de cada iteración, las partes interesadas y el representante del cliente evalúan el
progreso y vuelven a evaluar las prioridades con el fin de optimizar el retorno de la inversión (ROI), y
para una mejor alineación con las necesidades del cliente y los objetivos de la empresa.
1.3. Línea de tiempo de las metodologías de la gestión de proyectos

A continuación, vamos a ver cómo ha ido creciendo y evolucionando en el tiempo las diferentes
técnicas y metodologías de gestión de proyectos, desde las épocas más remotas, de las cuales han
llegado a nosotros los resultados de importantes proyectos arquitectónicos, hasta las metodologías
más actuales.
15
5ECTS .es
Estructura de
Administración
Departamento de Teoría de las Total de Costos
Defensa de E.E.U.U. restricciones Guía PMBOK®
Desarrollo del
resuelve aplicar WBS 4ª edición
Diagrama de Gantt Scrum como estilo
Fundación de PM PRINCE2® 2009:
de IPMA Guía PMBOK® Refresh
Fundación PRINCE Certificación
del PMI® Ágil del PMI®
1910 1920 1930 1940 1950 1960 1970 1980 1990 2000 2010 2020
Primer informe Guía
del CAOS PMBOK®
Se forma la AACE PROMPTII 5ª edición
Proyecto
Hoover Dam Se inventa CPM El Mítico PRINCE2® Posible
Se inventa PERT Hombre-Mes; publicación
Ensayos ISO 21500
Se inventa CCPM
PMBOK® se convierte
estándar ANSI
Figura 2. Cronograma histórico. Fuente: Haughey, D. (2017).
16
Primer Periodo: hasta 1958
Hay muchos ejemplos en la historia de proyectos desafiantes que se completaron con éxito, a pesar
de todas las complejidades e incertidumbres que podrían haber convertido cada proyecto en un
fracaso. Muchos de estos proyectos necesitaron una fuerza de trabajo enorme, abarcaron un amplio
alcance, muchos años de trabajo, planificación avanzada y ejecución precisa.
A lo largo de la historia, arquitectos e ingenieros realizaron obras impresionantes que han llegado
hasta nosotros, como la Pirámide de Giza, la Gran Muralla China, el Coliseo o, incluso, el complejo
neolítico de Stonehenge, por nombrar algunos. Esos arquitectos e ingenieros estaban cumpliendo,
además de sus roles principales de ingenieros y arquitectos, el rol de director de proyecto.
Para que estos proyectos pudieran tener éxito, estos personajes se convirtieron en administradores de
proyectos, tuvieron que pensar cuidadosamente en todos los procesos, desde las fases de iniciación
y planificación, pasando por la de ejecución, seguimiento, hasta el cierre. Para cada uno de estos
proyectos, alguien tuvo que administrar cientos de miles de trabajadores durante muchos años, y
asegurar que hubiera suficientes suministros para sostener el proyecto.
Lamentablemente, a pesar de todos estos logros monumentales, muy poca documentación de sus
métodos y técnicas han sobrevivido al paso de los años. No fue sino hasta la década de 1950 que las
organizaciones comenzaron a aplicar herramientas y técnicas sistemáticas para proyectos complejos.
No queda claro cuándo comenzó lo que entendemos en nuestros días como ‘Gestión de Proyectos’.
Algunos autores dan su paternidad a Henri Foyal y Henry Gantt:
•• Henri Fayol (1841-1925) fue un ingeniero francés, que gestionó la mayor fábrica de
transformación de acero de Francia inmediatamente antes de la 1ª guerra mundial.
A través de la observación, Fayol identificó cinco funciones de gestión, que él creía que eran
universales y de uso diario por los gerentes de las empresas: planificar, organizar, mandar,
coordinar y controlar. Fayol también formuló 14 principios que dan orientación a los gerentes
sobre cómo ejecutar esas cinco funciones gerenciales de manera efectiva.
El trabajo de Fayol fue criticado en su momento por muchos que consideraban que su teoría
no transmitía las verdaderas complejidades a las que se enfrentan los gerentes en su trabajo
diario. Sin embargo, el trabajo de Fayol hizo contribuciones significativas a la gerencia. A pesar
de las deficiencias que su teoría presentaba, las cinco funciones aún ofrecen una visión general
estructurada de las tareas que son importantes para la administración, y proporcionan una
visión general inicial de las principales funciones que los gerentes experimentan a diario.
•• Henry Gantt (1861-1919) fue un ingeniero estadounidense y más tarde consultor de gestión.
Sin embargo, su nombre ha llegado a nosotros por ser el autor del desarrollo del diagrama de
Gantt. Los diagramas de Gantt son importantes en la historia de la gestión moderna de
proyectos porque reconocen los beneficios de dividir grandes proyectos en tareas manejables
más pequeñas. También explican el hecho de que algunas tareas pueden depender unas de
17
5ECTS .es
las otras. Los diagramas de Gantt todavía se usan hoy en día y se consideran una herramienta
vital en la gestión de un proyecto.
Otros autores sitúan el comienzo de la edad moderna de gestión de proyectos en 1958 con el desarrollo
de las técnicas CPM/PERT, que se gestionaron prácticamente en paralelo:
•• En 1958, la marina de los EE. UU. dirigió el proyecto Polaris, los primeros misiles balísticos de
lanzamiento submarino (SLBM) que transportaban armas nucleares. Durante la gestión de
este proyecto, a la armada de los EE.UU. se le atribuye el desarrollo de una de las más utilizadas
actualmente: Técnica de Revisión de Evaluación de Programas (PERT). Debido a la alta
complejidad e incertidumbre asociadas con la programación del proyecto, PERT fue muy
adecuado para visualizar los diferentes escenarios de programación del proyecto.
•• El Método de ruta crítica (CPM) se inventó casi simultáneamente con PERT. La creación vino
como resultado de E.I DuPont de Nemours Company, mientras desarrollaba un importante
proyecto de construcción de una importante planta química. El CPM surgió porque la empresa
necesitaba estimar con precisión el coste y tiempo del proyecto. Originalmente, el método
que desarrollaron se conocía como Planificación de proyectos y Programación (PPS), que
posteriormente fue evolucionando hasta llegar al actual CPM.
Si bien, en 1956 se constituye la American Association of Cost Enginers (actualmente AACE

International) formada por los primeros profesionales de la administración de proyectos y de las
especialidades asociadas a la planificación, calendarización y estimación de costos.
Segundo Periodo: desde 1958 hasta 1979
Este periodo coincide con un tiempo donde hubo considerables avances tecnológicos, incluyendo el
despunte de la industria de la computación, ordenadores y metodológicos.
Un desarrollo muy importante en este periodo fue el mandato del uso del enfoque por medio de
Work Breakdown Structure (WBS) para cualquier proyecto.
En el lado profesional, el proceso de institucionalización de la gestión de proyectos comenzó con la

creación de la primera asociación de gestión del mundo, conocida como la Asociación Internacional
de Gestión de Proyectos (IPMA). Desde su desarrollo en 1965 IPMA ha crecido sustancialmente y
ahora es primer promotor internacional de gestión de proyectos en Europa, Asia y los países árabes.
Cuatro años más tarde fue fundado Project Management Institute (PMI), que está principalmente
basado en los EE. UU., y es el editor de The Project Management Body of Knowlegement (PMBOK®).
El libro es una recopilación de procesos y áreas de conocimiento generalmente aceptadas como las
mejores prácticas dentro de la disciplina de gestión de proyectos.
La aparición de facilidades de computación con la aparición de los primeros ordenadores permitió

generalizar y simplificar el uso de las técnicas de gestión ya desarrolladas.
En 1975 se publica la conocida como Ley de Brooks: “agregar recursos humanos a un proyecto de
software retrasado hace que se retrase más”, que viene incluida en el libro “The Mythical Man-Month:
18
Essays on Software Engineering”, de Fred Brooks, publicado a partir de sus experiencias mientras era
responsable del departamento de desarrollo de 0S/360 en IBM.
Tercer Periodo: desde 1980 hasta 1994
La mayor potencia computacional de los ordenadores permitió durante este periodo el desarrollo
de software capaz de manejar y organizar complejas estructuras de información requeridas para la
gestión de proyectos muy complejos.
En los años ochenta, los programas de gestión de proyectos se basaban principalmente en el modelo
PROMPT II, que luego se refinó en el modelo Projects In Controlled Environments (PRINCE).
Otro desarrollo significativo durante ese tiempo fue la Teoría de las Restricciones (TOC), una filosofía
de gestión introducida por Eliyahu M. Goldratt en su conocida novela "The Goal". La filosofía tiene
como objetivo ayudar a las organizaciones a alcanzar sus objetivos de forma continua, utilizando la
premisa de que la tasa de logro de consecución en un sistema orientado a objetivos está limitado por
al menos una restricción.
En 1986 se desarrolla Scrum, un modelo ágil de desarrollo de software que lo fomenta a través de
múltiples equipos pequeños. Su enfoque se basa en una estrategia de desarrollo de productos flexible
y holística, en la que trabaja un equipo de desarrollo como una unidad para alcanzar un objetivo
común en oposición a un enfoque tradicional y secuencial.
En 1987, PMBOK® fue publicado por PMI, el libro se basó principalmente en un libro blanco publicado
en 1983 llamado el "Informe final del Comité de Ética, Normas y Acreditación". La guía fue un intento
de documentar y estandarizar las prácticas y administración de proyectos. Con el paso de los años la
guía PMBOK®® se ha convertido en el estándar mundial para la industria.
En 1994, el Standish Group recogió información sobre fracasos de proyectos en la industria de TI,
consolidada y resumida en el informe CHAOS, con el objetivo de hacer a la industria más exitosa,
mostrando las formas de cómo mejorar los índices de éxito e incrementar el valor de las inversiones
en TI. Este informe se publica con información actualizada cada dos años.
No debemos dejar de recordar que durante este periodo se ejecutan proyectos tan importantes como
la construcción del Túnel bajo el Canal de la Mancha, el programa de vuelos con la Lanzadera Espacial
de la NASA o la celebración de los Juegos Olímpicos de Calgary, donde en todos ellos se gestionaron
equipos con diferentes culturas y/o lenguas, diferentes procesos burocráticos e, incluso, diferentes
sistemas de medición.
Cuarto Periodo: desde 1994 hasta la actualidad
1996 PRINCE se actualizó a PRINCE2, y poco después en 1997 se introdujo un método llamado
gestión de proyectos con cadena crítica (CCPM), un método de planificación y gestión de
proyectos desarrollado por Eliyahu M. Goldratt, y se deriva de TOC: una red de proyecto de Cadena
Crítica mantendrá los recursos con cargas niveladas, pero necesitarán de ellos para ser flexibles en
sus tiempos de inicio y cambiar rápidamente entre tareas y cadenas de tareas para mantener todo el
proyecto dentro del calendario previsto.
19
5ECTS .es
En 1998, tanto el ANSI como el IEEE reconocieron PMBOK® como estándar.
En 2001, se escribe The Agile Manifesto: el manifesto se basa en un conjunto de valores centrales que
tienen como objetivo permitir que los equipos de desarrollo de software funcionen bien como un
equipo.
En 2008, PMI lanza la 4° edición del PMBOK®, y en 2009 se revisa a fondo PRINCE2 por la Oficina de
Comercio del Gobierno de Reino Unido.
En 2011, aparece la nueva credencial del PMI® Agile Certified Practitioner, donde PMI demostró que
no está cerrado a las metodologías ágiles; y en 2012 aparece la certificación PRINCE2® Professional.
En 2012 y 2018, PMI vuelve a lanzar actualizaciones de PMBOK®; y en 2012 se publica la Norma ISO
21500 sobre Project Management
Con la globalización siempre vienen desafíos más grandes y la necesidad de aumentar la velocidad
de salida al mercado de nuevos productos y servicios, lo que hace que la gestión de proyectos deba
adecuarse a los nuevos paradigmas.
Sin duda, nuevas técnicas y mejores prácticas surgirán a medida que empujamos los límites de lo que
es posible.
1.4. La normativa internacional: ISO 21500

ISO 21500 es una norma sobre la gestión de proyectos que puede ser utilizada por cualquier
tipo de organización, ya sea pública, privada o comunitaria; y para cualquier tipo de proyecto,
independientemente de su complejidad, tamaño y duración.
ISO 21500 proporciona una descripción de alto nivel de los conceptos y procesos que se consideran
buenas prácticas en la gestión de un proyecto.
La aparición de esta norma llegó como consecuencia de la necesidad de uniformizar las diferentes
normas de gestión de proyectos particulares que cada país estaba desarrollando en paralelo, así como
iniciativas de diferentes organizaciones (Global Project Management Forum, Global Working Groups,
Operational Level Coordination Initiative (OLCI), o Global Alliance for Project Performance Standards). La
iniciativa de uniformización fue lanzada en 2006 por la British Standard Institue, miembro de la ISO, y
participaron más de 30 países en su desarrollo.
El resultado fue la publicación de ISO 21500 el 1 de septiembre de 2012.
Adicionalmente, cada país ha ido adaptando la norma a sus directrices particulares, publicando
normas adaptadas. Por ejemplo, para el ámbito iberoaméricano, se publicó en Marzo de 2013 la norma
UNE-ISO 21500:2013. Directrices para la Dirección y Gestión de Proyectos, traducida del original en inglés
por el Spanish Translation Task Force, con participación de representantes de Argentina, Chile, España,
Costa Rica y Méjico.
En definitiva, se ha creado un documento consensuado que:
20
•• Toma los aspectos destacables y comunes de otras normas relacionadas, que se tomaron
como puntos de partida para su elaboración.
•• La gestión de los proyectos se realiza a través de procesos, un conjunto de actividades

mutuamente relacionadas y que interactúan entre sí, y que transforman los elementos de
entrada en resultados.
•• Los procesos se aplican durante diferentes fases del proyecto o durante todo el mismo.
La norma va dirigida a todos los niveles de decisión y coordinación de una organización:
•• Desde el comité ejecutivo y los patrocinadores de proyectos, para ofrecer apoyo y orientación
a sus directores y equipos de proyecto.
•• Directores y equipos de proyecto, que tendrán una base común para poder comparar sus
normas y prácticas de proyectos con las de otros.
•• Redactores de normas, como base para el desarrollo de normas sobre gestión de proyectos,
de modo que sean consistentes unas con otras.
Organization
Organizational Strategy
Opportunities
Benefits
Project Environment
Project Governance
Business Case
Project Organization
Project
Operations
Project Management Processes
Deliverables Product Processes
Support Processes
Figura 3. Interrelación entre roles y responsabilidades en ISO 21500.Fuente: Zandhuis, A. Stellingwerf, R. (2013).
21
5ECTS .es
Otras características reseñables de la norma son:
•• Es universal, con ámbito global y para cualquier tipo de proyecto o sector de aplicación.
•• Es integradora, intenta aglutinar las buenas prácticas de diferentes normas ya existentes.
•• Es sencilla, de forma que se facilita su interpretación y aplicación.
•• Es flexible, para que pueda desarrollarse su ámbito universal y tenga cabida en cualquier
organización.
Además, define QUÉ debe considerarse para gestionar eficientemente los proyectos, en contraposición
de otras normas que te indican el CÓMO. Esto es así para facilitar que cada organización desarrolle sus
propias metodologías de trabajo, dado que no incluye herramientas ni técnicas.
Conceptos de la Dirección y Gestión de Proyectos
La norma indica una serie de términos y definiciones (16) de aplicación. Dentro de la propia norma,
también se define:
•• Proyecto: conjunto único de procesos que consta de actividades coordinadas y controladas,

con fechas de inicio y fin, que se lleva a cabo para lograr los objetivos del proyecto.
•• Programa: grupo de proyectos relacionados o cualquier otra actividad alineados con metas
estratégicas.
•• Cartera de Proyectos: conjunto de proyectos, programas y otro tipo de trabajos que se agrupan
para facilitar la gestión eficaz de dicho trabajo de modo que se cumplan las metas estratégicas.
Se describen una serie de conceptos clave que son aplicables a la mayoría de los proyectos:
•• Relación entre la estrategia de la organización y los proyectos.
•• El entorno del proyecto (factores internos y externos a la organización, gestión de cartera y de

programa de proyectos).
•• La gobernanza del proyecto.
•• La distinción entre operaciones y proyectos.
•• La identificación de las partes interesadas y la organización del proyecto.
•• Las competencias del personal del proyecto.
•• El ciclo de vida y las restricciones del proyecto.
Como podéis ver, existe mucha semejanza en lo indicado por esta norma con lo que hemos podido
aprender del PMBOK® a lo largo del curso. Este acercamiento entre ambas metodologías se va a
presentar más claramente en la descripción de procesos y materias.
22
Se identifican los procesos de dirección y gestión (39) y se ofrece una clasificación o agrupación de los
mismos desde dos puntos de vista diferentes:
•• Grupo de procesos:
–– Inicio
–– Planificación
–– Implementación
–– Control
–– Cierre
Project Management Process Groups

ISO 21500 PMBoK® Guide
Initiating Initiating
Planning Planning
Implementing Executing
Controlling Monitoring and Controlling
Closing Closing
Tabla 1. Grupos de Procesos en ISO 21500. Fuente: Gasik, S. (2015).
La secuencia lógica de actividad entre los diferentes procesos se puede observar en la siguiente
figura, junto a los principales documentos del proyecto:
23
5ECTS .es
Acta de constitución Planes de

de proyecto proyecto Acciones correctivas
Proyecto nuevo Informes de avance
Casos de Cambios aprobados

Cambios
negocio
aprobados
Control Informes de
Contacto Informes de avance cierre de proyecto
Planes de
proyecto Informes de finalización o fase de proyecto
Registro de del proyecto
Enunciado Acta de constitución
de trabajo de proyecto riesgos
Registro de partes
interesadas
Inicio Planificación Cierre
Cambios
Planes de proyecto aprobados
Informes Cambios requeridos
de progreso Registro de problemas
Documentación Datos de progreso
de fase previa
Implementación
Registro de problemas
Fase nueva Lecciones aprendidas Lecciones aprendidas
de proyectos previos
Leyenda
Lecciones
Información Clave del Proyecto aprendidas
Etiquetas sobre las flechas Información que pasa entre grupos de procesos
Línea punteada Entradas y salidas representativas
Línea continua Interacciones entre grupos de proceso
Figura 4. Secuencia de actividad y documentos en ISO 21500. Fuente: Ginevri, W. Barbero, M.C. (2013).
24
•• Grupo de materias:
–– Integración
–– Parte interesada
–– Alcance
–– Recurso
–– Tiempo
–– Costo
–– Riesgo
–– Calidad
–– Adquisición
–– Comunicación
ISO 21500 PMBoK® Guide

Subjects Knowledge Areas
Integration Integration
Stakeholder Stakeholder
Scope Scope
Resource Human Resources
Time Time
Cost Cost
Risk Risk
Quality Quality
Procurement Procurement
Communication Communication
Tabla2. Comparativa ISO 21500 vs PMBOK. Fuente: Gasik, S. (2015).
25
5ECTS .es
Ambas agrupaciones procesos / materias están relacionadas entre sí:
Process groups
Subject groups
Initiating Planning Implementing Controlling Closing
4.3.7 Close
project
4.3.5 Control
phase or
4.3.2 Develop 4.3.3 Develop 4.3.4 Direct project work
Integration project
project charter project plans project work 4.3.6 Control
4.3.8 Collect
changes
lessons
learned
4.3.9 Identify 4.3.10 Manage
Stakeholder
stakeholders stakeholders
4.3.11 Define
scope
4.3.12 Create
4.3.14 Control
Scope work breakdown
scope
structure
4.3.13 Define
activities
4.3.16 Estimate
4.3.19 Control
resources
4.3.15 Establish 4.3.18 Develop resources
Resource 4.3.17 Define
project team project team 4.3.20 Manage
project
project team
organization
4.3.21 Sequence
activities
4.3.22 Estimate 4.3.24 Control
Time
activity durations schedule
4.3.23 Develop
schedule
4.3.25 Estimate
cost 4.3.27 Control
Cost
4.3.26 Develop costs
budget
4.3.28 Identify
risks 4.3.31 control
Risk 4.3.30 Treat risks
4.3.29 Assess risks
risks
4.3.33 Perform
4.3.32 Plan 4.3.34 Perform
Quality quality
quality quality control
assurance
4.3.35 Plan 4.3.36 Select 4.3.37 Administer
Procurement
procurements suppliers procurements
4.3.38 Plan 4.3.39 Distribute 4.3.40 Manage
Communication
communications information communications
Tabla 3. Relación entre Procesos y Materias en ISO 21500. Fuente: Gasik, S. (2015).
26
Los procesos establecidos por la norma se encuentran descritos en términos de propósito, descripción,
entradas y salidas principales. Por ejemplo, para el proceso “Gestionar el equipo de Proyecto” la
descripción es como sigue:
Gestionar el equipo de proyecto
La finalidad de Gestionar el equipo de proyecto es optimizar el desempeño del equipo, generar

retroalimentación, resolver problemas, promover la comunicación y coordinar los cambios para
lograr el éxito en el proyecto.
Como resultado de la gestión del equipo de proyecto, los recursos requeridos pueden revisarse. Se
debería elevar los problemas y proporcionar datos de entrada para permitir evaluar el desempeño del
personal de la organización y las lecciones aprendidas del proyecto.
Las entradas y salidas principales se enumeran en la siguiente tabla:
Gestionar el equipo de proyecto: entradas y salidas principales

Entradas principales Salidas principales
•• Planes de proyecto
•• Rendimiento del personal
•• Organigrama de proyecto
•• Evaluaciones del personal
•• Descripciones de las funciones de
•• Solicitudes de cambio
cada miembro
•• Acciones correctivas
•• Datos de progreso
Figura 5. Gestionar el Equipo de Proyecto en ISO 21500. Fuente: AENOR (2013).
A continuación, vamos a mostrar brevemente cómo se alinean los diferentes procesos entre ISO 21500
y la Guía PMBOK®. Cabe destacar, como se ha indicado anteriormente, que ISO 21500 no proporciona
una descripción de herramientas y técnicas, al contrario que PMBOK®, lo que hace que ISO 21500 sea
considerablemente más ligera y sencilla.
Proceso de Integración
ISO 21500 PMBOK Guide

4.3.2 Develop Project Charter 4.1 Develop Project Charter
4.3.3 Develop Project Plans 4.2 Develop Project Management Plan
4.3.4 Direct Project Work 4.3 Direct and Manage Project Work
4.3.5 Control Project Work 4.4 Monitor and Control Project Work
4.3.6 Control Changes 4.5 Perform Integrated Change Control
4.3.7 Close Project Phase or Project 4.6 Close Project or Phase
4.3.8 Collect Lessons Learned
Tabla 4. Proceso de Integración vs PMBOK. Fuente: elaboración propia.
Al agregar 4.3.8 Reunir lecciones aprendidas, enfocado en la gestión del conocimiento del proyecto,
ISO 21500 ha realizado un movimiento en la dirección correcta, ya que cada vez es más aceptado que
27
5ECTS .es
el conocimiento es el recurso más importante del proyecto y, por lo tanto, merece ser tratado como
una materia separada en la disciplina de gestión de proyectos.
ISO 21500 requiere el desarrollo de tres tipos de planes:
•• El plan del proyecto describe las líneas de base del proyecto: lo que debe lograr el proyecto en
temas separados como alcance, tiempo, costo y cualquier otro.
•• El plan de gestión del proyecto describe los procesos de gestión del proyecto.
•• El tercer tipo de planes son planes subsidiarios: cualquier parte de los procesos de gestión del
proyecto pueden colocarse en un documento separado.
En la Guía PMBOK® hay un plan de gestión de proyectos que consolida e integra todos los planes
necesarios de un proyecto.
Proceso de Parte Interesada

4.3.9 Identify Stakeholders 13.1 Identify Stakeholders
13.2 Plan Stakeholders Mahagement
4.3.10 Manage Stakeholders 13.3 Manage Stakeholder Engagement
13.4 Control Stakeholder Engagement
Tabla 5. Proceso de Parte Interesada vs PMBOK. Fuente: elaboración propia.
La Guía PMBOK® tiene dos procesos más en la gestión de partes interesadas: Planificar la gestión de
partes interesadas y Controlar la gestión de las partes interesadas.
Proceso de Alcance

5.1 Plan Scope Management
4.3.11 Define Scope 5.2 Collect Requirements
4.3.12 Create Work Breakdown Structure 5.3 Define Scope
4.3.13 Define Activities 5.4 Create WBS
6.2 Define Activities (taken from Time
Management Knowledge Area)
4.3.14 Control Scope 5.5 Validate Scope
5.6 Control Scope
Tabla 6. Proceso de Alcance vs PMBOK. Fuente: elaboración propia.
ISO 21500 no requiere un proceso separado para planificar la gestión del alcance. El proceso ISO 21500
Definir alcance incluye requisitos de recopilación: al menos los requisitos del proyecto son uno de los
principales resultados del proceso. No existe un proceso como Validar Alcance en ISO 21500. Ningún
proceso ISO 21500 produce resultados como entregas aceptadas, que es el resultado más importante
28
del proceso Validar el alcance. Hay que hacer notar que se está trasladando el proceso de Definir
actividades desde el área de conocimiento de gestión del tiempo al tema del alcance en ISO 21500.
Proceso de Recurso

9.1 Plan Human Resource Management
4.3.15 Establish Project Team 9.2 Acquire Project Team
4.3.16 Estimate Resources
4.3.17 Define Project Organization 6.4 Estimate Activity Resources (taken from Time
Management Knowledge Area)
4.3.18 Develop Project Team 9.3 Develop Project Team
4.3.19 Control Resources
4.3.20 Manage Project Team 9.4 Manage Project Team
Tabla 7. Proceso de Recurso vs PMBOK. Fuente: elaboración propia.
El tema de recursos en ISO 21500 cubre todo tipo de recursos: humanos, equipos, materiales, etc. Esto
es más que en el área de conocimiento de administración de recursos humanos de la guía PMBOK®.
ISO 21500 no requiere un proceso separado para la planificación de recursos. El proceso de definición
de la organización del proyecto en ISO 21500 se realiza después de establecer el equipo del proyecto.
El proceso de establecer un equipo de proyecto funciona en una estructura "plana": solo se necesitan
características de roles individuales para obtener recursos humanos. Las relaciones entre ellos se
definen más adelante, en Definir organización del proyecto. Este es un enfoque diferente en la Guía
PMBoK®, donde primero se deben definir los roles y la organización del proyecto en Planificar la
Gestión de Recursos Humanos y luego contratar a personas capacitadas.
El proceso de estimación de recursos se ha trasladado al tema de los recursos.
No hay un proceso separado para controlar recursos en la Guía PMBoK®. El objetivo del proceso de
recursos de control ISO 21500 es garantizar que los recursos necesarios estén disponibles para el
proyecto.
Proceso de Tiempo

6.1 Plan Schedule Management
Moved to Scope subject 6.2 Define Activities
4.3.21 Sequence Activities 6.3 Sequence Activities
Moved to Scope subject 6.4 Estimate Activity Resources
4.3.22 Estiamate Activity Durations 6.5 Estiamate Activity Durations
4.3.23 Develop Schedule 6.6 Develop Schedule
4.3.24 Control Schedule 6.7 Control Schedule
Tabla 8. Proceso de Tiempo vs PMBOK. Fuente: elaboración propia.
29
5ECTS .es
ISO 21500 no requiere un proceso separado para planificar la gestión del cronograma. Se han movido
dos procesos desde el Área de conocimiento de gestión del tiempo a otros temas. Los otros procesos
parecen ser estables.
Proceso de Costo

7.1 Plan Cost Management
4.3.25 Estimate Costs 7.2 Estimate Costs
4.3.26 Develop Budget 7.3 Determine Budget
4.3.27 Control Costs 7.4 Control Costs
Tabla 9. Proceso de Costo vs PMBOK. Fuente: elaboración propia.
ISO 21500 no requiere un proceso separado para planificar la administración de costos. El resto de
procesos ISO 21500 siguen estrictamente los de la Guía PMBOK®.
Proceso de Riesgo

11.1 Plan Risk Management
4.3.28 Identify Risks 11.2 Identify Risks
11.3 Perform Qualitative Risk Analysis
4.3.29 Assess Risks
11.4 Perform Quantitative Risk Analysis
4.3.30 Treat Risks 11.5 Plan Risk Responsive
4.3.31 Control Risks 11.6 Monitor and Control Risks
Tabla 10. Proceso de Riesgo vs PMBOK. Fuente: elaboración propia.
No existe una planificación de la gestión de riesgos en ISO 21500. Dos procesos analíticos de la Guía
PMBoK® se han fusionado en un proceso de evaluación de riesgos de ISO 21500, pero no está claro si
la gestión de riesgos cuantitativa es requerida por ISO 21500.
Proceso de Calidad

4.3.32 Plan Quality 8.1 Plan Quality Management
4.3.33 Perform Quality Assurance 8.2 Perform Quality Assurance
4.3.34 Perform Quality Control 8.3 Quality Control
Tabla 11. Proceso de Calidad vs PMBOK. Fuente: elaboración propia.
No existe una diferencia sustancial entre la guía PMBoK® y los procesos ISO 21500 en materia de
calidad.
30
Proceso de Adquisición

4.3.35 Plan Procurement 12.1 Plan Procurement Management
4.3.36 Select Suppliers 12.2 Conduct Procurements
12.3 Control Procurements
4.3.37 Administer Contracts
12.4 Close Procurements
Tabla12. Proceso de Adquisición vs PMBOK. Fuente: elaboración propia.
No existe un proceso separado de cierre de contratos en ISO 21500: el cierre de contratos forma parte
del proceso de administración de contratos.
Proceso de Comunicación

4.3.38 Plan Communications 10.1 Plan Communications Management
4.3.39 Distribute Information 10.2 Manage Communications
4.3.40 Manage Communications 10.3 Control Communications
Tabla 13. Proceso de Comunicación vs PMBOK. Fuente: elaboración propia.
Los procesos ISO 21500 coinciden con los de la Guía PMBOK®. Ambos estándares usan diferentes
estilos de nombre. Gestión de las Comunicaciones de PMBOK® tiene las mismas funciones que Distribuir
información de ISO 21500, mientras que el objetivo de ISO 21500 Gestión de las Comunicaciones es
controlar y mejorar las comunicaciones de proyectos, este es el objetivo del proceso de Control de
Comunicaciones de PMBOK®.
31
5ECTS .es
32
Tema 2.
Marco de procesos: PRINCE2
2.1. Introducción
PRINCE2 es una metodología de procesos no propietaria (a diferencia de PMBoK), y uno de los
métodos más aceptados para la gestión de proyectos en el mundo. Esto se debe principalmente al
hecho de que PRINCE2 es genérico: se puede aplicar a cualquier proyecto, independientemente de
su escala, tipo, organización, geografía o cultura.
Dado que PRINCE2 es genérico y está basado en principios probados, las organizaciones que adoptan
este método como estándar pueden mejorar sustancialmente su capacidad organizativa y madurez a
través de múltiples áreas de actividad empresarial.
PRINCE2 es un marco integrado de procesos y temas que abordan la planificación, delegación,

monitoreo y control de un proyecto.
33
5ECTS .es
2.2. Organización del proyecto

La universalidad de PRINCE2 se debe principalmente a cómo esta metodología estructura las diferentes
responsabilidades del proyecto, y cómo es capaz de identificar y enumerar los procesos de aquellas
que se realizan para realizar gestión de proyecto mientras que aquellas de tipo trabajo de especialistas,
que son muy particulares a cada proyecto y/o sector de actividad, quedan fuera de su ámbito.
Qué no cubre PRINCE2
Existen tres amplias categorías de temas que están deliberadamente consideradas fuera del alcance
de PRINCE2:
•• Aspectos especializados: la fortaleza de PRINCE2 está en su amplia aplicabilidad, es

completamente genérico. En consecuencia, cualquier actividad específica de una determinada
industria o de un sector específico queda excluida de su ámbito. Este tipo de actividades son
identificadas como especialista, y deben ser identificados e incluidos dentro del alcance y
planificación del proyecto.
•• Técnicas detalladas: hay muchas técnicas de planificación y control que pueden ser utilizadas
como apoyo para el desarrollo de los temas PRINCE2. Algunos ejemplos pueden ser el análisis
de ruta crítica (en planificación) o el análisis del valor ganado (durante el control del progreso).
En esta metodología solo se describen las técnicas que tienen una aproximación PRINCE2.
•• Capacidad de liderazgo: liderazgo, habilidades motivacionales y otras habilidades

interpersonales son inmensamente importantes en la gestión de proyectos, pero es difícil su
codificación en un método. PRINCE2 no aborda este aspecto de la gestión del proyecto
directamente. Existen muchos programas de entrenamiento de liderazgo y habilidades
interpersonales que cumplen con este requisito.
Qué beneficios aporta PRINCE2
•• PRINCE2 ofrece un conjunto de buenas prácticas y gobierno, establecido y probado para a

gestión de proyectos
•• Se puede aplicar a cualquier tipo de proyecto, y puede implementarse fácilmente integrado

con especialistas y modelos de sector específicos de industria (modelos de ingeniería o ciclos
de vida de desarrollo específicos)
•• PRINCE2 es ampliamente reconocido y aceptado, y por lo tanto proporciona un vocabulario

común para todos los participantes del proyecto, lo que facilita una comunicación efectiva.
•• PRINCE2 proporciona el reconocimiento explícito de las responsabilidades del proyecto, para

que los participantes comprendan su particular rol dentro del proyecto y las necesidades de
los demás. Permite crear una estructura de definición de responsabilidad, delegación,
autoridad y comunicación.
34
•• El enfoque sobre el producto aclara (para todas las partes) qué entregables ofrecerá el
proyecto, cuándo, por qué, por quién y para quién.
•• Los planes PRINCE2 están diseñados cuidadosamente para satisfacer las necesidades de los
diferentes niveles dentro del equipo de gestión, mejorando la comunicación y control.
•• Se basa en un marco de “gestión por excepción”, lo que permite un consumo de tiempo para
tareas de gestión muy eficiente y reducido.
•• PRINCE2 asegura que los participantes se centren en la viabilidad del proyecto con foco en el
Business Case, más allá de completar las tareas que tienen individualmente asignadas.
•• Define una estructura completa pero económica de reporte.
•• Asegura que las partes interesadas (incluidos patrocinadores y proveedores de recursos) están
debidamente representados en la planificación y la toma de decisiones.
•• La adopción de PRINCE2 promueve el aprendizaje y mejora continua en las organizaciones.
La metodología PRINCE2 aborda la gestión de un proyecto integrando cuatro elementos

fundamentales:
a. Los principios
Son las obligaciones rectoras y buenas prácticas que determinan si el proyecto es genuinamente
administrado usando PRINCE2. Existen siete principios, y si no se aplican absolutamente
todos, no se considera la gestión del proyecto como PRINCE2. Los principios son:
1. Justificación Comercial continua del Proyecto: la razón para comenzar un proyecto debe
tener sentido desde un punto de vista comercial, es decir: claramente debe haber un
retorno de la inversión, y esta justificación se debe mantener durante toda la vida del
proyecto.
2. Aprender de la Experiencia: los equipos de proyectos deben aprender de proyectos

previos, así que deben tomar la iniciativa de descubrir lecciones aprendidas anteriormente,
y tenerlas en cuenta durante la vida del proyecto.
3. Roles y Responsabilidades definidas: las personas involucradas necesitan saber qué hacer
y qué esperar de los demás, y tener en cuenta los intereses de las partes interesadas, tanto
del negocio como de los usuarios y proveedores.
4. Gestión del Proyecto por fases: un proyecto se planifica, supervisa y controla por fases
secuenciales. Estas fases de gestión están separadas por puntos de decisión (también
llamados “puntos de control”) a cargo de la Junta de Proyecto.
5. Gestión por Excepción: se emplea en cada nivel de la Organización del Proyecto para
administrar el nivel inferior. En PRINCE2 las cuestiones importantes se conocen como
Excepciones. Una Excepción es una cuestión que se encuentra fuera de la tolerancia
35
5ECTS .es
convenida: el nivel inferior solo debe notificar al nivel superior si existen cuestiones que
se encuentren fuera de su tolerancia. Se establecen 6 tipos de tolerancias: tiempo, costo,
calidad, alcance, riesgo y beneficios.
6. Enfoque hacia la entrega de Productos: un proyecto PRINCE2 centra su atención en

la definición y la entrega de productos, en particular en sus exigencias de calidad.
Una descripción de producto correcta proporciona claridad, ya que define el uso del
producto, su composición, origen, dimensión, métodos y criterios de calidad. Además
permite determinar con mayor facilidad los requerimientos de recursos, dependencias y
actividades.
7. Adaptación al cambio del entorno del proyecto: un proyecto PRINCE2 debe adaptarse al
tamaño, entorno, complejidad, importancia, capacidad y riesgos del proyecto.
b. Las temáticas
Estas describen aspectos de la gestión del proyecto que deben abordarse de forma continua
y en paralelo a lo largo del proyecto. Las siete temáticas explican el tratamiento específico
requerido por PRINCE2 para diferentes disciplinas de la gestión de proyectos, y por qué son
necesarios:
1. Business case: su objetivo es establecer un mecanismo para juzgar si el proyecto es (y se

mantiene) deseable, viable, alcanzable y vale la pena continuar con la inversión.
2. Organización: su propósito es ayudar a definir y establecer la estructura de obligaciones

y responsabilidades en el proyecto; en otras palabras, identificar el “quién” del proyecto.
3. Calidad: su propósito es definir e implementar un sistema para crear y verificar que los
productos son aptos para su uso.
4. Planes: su objetivo es proporcionar un marco de referencia para diseñar, desarrollar y

mantener los planes del proyecto.
5. Cambio: ayuda a identificar, evaluar y controlar cualquier potencial cambio en los productos
que se hayan aprobado y considerado como baseline. Proporciona un enfoque común
para el control de cambios y cuestiones.
6. Riesgo: se basa en la identificación, evaluación y control de la incertidumbre, así como

mejorar la capacidad del proyecto para resultar exitoso.
7. Progreso: se basa en la verificación y control del punto actual en que nos encontramos en
el proyecto en comparación a lo planificado.
c. Los procesos
Describen una progresión paso a paso a través del ciclo de vida del proyecto, desde el comienzo
hasta su cierre. Cada proceso proporciona listas de verificación de actividades recomendadas,
productos, responsabilidades y documentos del proceso. Los 7 procesos de PRINCE2 son:
36
1. El Proceso de Puesta en Marcha del Proyecto
2. El Proceso de Inicio del Proyecto
3. El Proceso de Dirección del Proyecto
4. El Proceso de Control de Fase del Proyecto
5. El Proceso de Gestión de la Entrega de Productos
6. El Proceso de Gestión de los Límites de Fase
7. El Proceso de Cierre del Proyecto
d. Adaptación de PRINCE2 al entorno del proyecto
Es necesario abordar la necesidad de adaptar PRINCE2 al contexto específico del proyecto.

PRINCE2 no es una solución de '”talla única”, es un marco flexible que se puede adaptar
fácilmente a cualquier tipo o tamaño de proyecto.
Estos elementos pueden representarse gráficamente mediante el siguiente esquema (del libro):
Bussines case
Progress Organization
PRINCE2 processes
Change Quality
Risk Plans
PRINCE2 themes
PRINCE2 principles
Figura 6. Organización de PRINCE2. Fuente: AXELOS (2009).
2.3. Modelo de los 7 procesos

El modelo de procesos de PRINCE2 se puede representar de muy diversas formas. Una de ellas puede
ser la siguiente:
37
5ECTS .es
Corporate of
programme
Project Corporate advice
mandate and decisions
Project Project Board

Initiation authorization request for Closure
Direction
notification notification advice notification
Directing a Project
Stage
Authority to Exception Plan Authorization Project Premature
initiate a project request Board close
Starting up a Project
Exception Plan
approved advice
Request to aprove
Request Exception Plan
to initiate Request to Request to approve Closure
a project deliver a project next Stage Plan recommendation
Management
Exception
Initiating a Managing a Stage raised Closing a
Project Boundary Request for Project
advice
Stage boundary Project end
approaching approaching
Controlling a Stage
Authority to deliver a Work Package
Authority to deliver a Work Package
Delivery
Managing Product Delivery
Figura 7. Modelo de los 7 procesos de PRINCE2. Fuente: AXELOS (2009).
38
Antes de comenzar a analizar los procesos de PRINCE2, hay que reseñar que los procesos están
ubicados dentro de 4 niveles de gestión (que pueden verse indicados en el lateral izquierdo de la
figura):
Nivel 1: Gestión Corporativa o de Programa
El nivel superior es el Nivel Corporativo o de "Gestión de Programas". Puede observarse en el diagrama

que el único elemento definido en este nivel es el mandato del proyecto.
Nivel 2: Dirección
El nivel de Dirección es donde se ubica la Junta del Proyecto. Interactúa normalmente con el Nivel de
Gestión y proporciona al nivel superior una serie de notificaciones: hay tres tipos de notificaciones
que vienen mostradas en el diagrama del modelo de proceso.
Nivel 3: Gestión
El siguiente nivel es de Gestión, donde se ubica el Gerente de Proyecto. Contiene la mayoría de las
actividades y procesos. En el diagrama se puede ver cómo la mayoría de las actividades de gestión
son realizadas por el Project Manager.
Nivel 4: Entrega
El nivel inferior, Entrega, es donde se crean los productos del proyecto. Todos los productos creados
por encima del nivel de Entrega se crean solo para administrar el proyecto y son conocidos como
productos de gestión.
2.4. Procesos de PRINCE2

A continuación, se resumen los objetivos y actividades que forman cada uno de los 7 procesos que
estructuran PRINCE2:
2.4.1. El Proceso de Puesta en Marcha del Proyecto
El propósito es garantizar que los requisitos previos para iniciar el proyecto están preparados
para responder a la siguiente pregunta: ¿tenemos un proyecto viable y que merezca la pena su
desarrollo? Ninguna actividad debe ser acometida hasta que se disponga de toda la información
necesaria para tomar decisiones racionales sobre la puesta en marcha del proyecto, si las funciones
y responsabilidades clave cuentan con recursos, están asignados y se dispone de planificación base
detallada.
El propósito de este proceso es tanto sobre la prevención de proyectos mal concebidos antes de ser
iniciados como de la aprobación del inicio de proyectos viables.
Las actividades que se desarrollan en este proceso se muestran a continuación:
39
5ECTS .es
Corporate or Directing
Project mandate programme a
management Project
Appoint the Executive

and the
Project Manager
Design and appoint

Capture previous lessons
the project
management team
Prepare the Select the project

outline approach and
Business assemble the Project
Case Brief
Plan the initiation Request to

stage initiate a
Starting up a Project project
Figura 8. El Proceso de Puesta en Marcha del Proyecto de PRINCE2. Fuente: AXELOS (2009).
2.4.2. El Proceso de Dirección del Proyecto
El objetivo del proceso es permitir que la junta sea responsable del éxito del proyecto al tomar
decisiones clave y ejercer el control general, mientras delega el día a día de la gestión al gerente del
proyecto.
El propósito final de este proceso es que exista autoridad para iniciar el proyecto y entregar los
productos del proyecto, que la dirección y el control de la gestión sean proporcionados a lo largo de
la vida del proyecto y siga siendo viable, proporcionar un interfaz hacia la gestión corporativa o de
programa y disponer de autoridad para cerrar el proyecto.
En la siguiente figura se pueden observar las diferentes actividades que se desarrollan en este proceso:
40
Project Project Board Corporate

Initiation Closure
authorization request advice and
notification notification
notification for advice decisions
Authorize
initiation
Authorize
the project
Authorize a Stage or Authorize

Exception Plan Give ad hoc direction project
closure
Project New issue

Stage Request to Manager
approve Project
authorization request for
Request to Authority Request to Exception Plan Board
advice Premature
initiate a to initiate deliver a advice
Exception Exception close
project a project project Request to Excepcion and
Plan approved Plan
approve next raised decisions
request
Stage Plan Closure
Starting up Initiating recommendation
a Project a Project
Managing a
Stage Boundary Closing a Project
Controlling a Stage
Figura 9. El Proceso de Dirección del Proyecto de PRINCE2. Fuente: AXELOS (2009).
41
5ECTS .es
2.4.3. El proceso de inicio de un proyecto
El propósito del proceso es establecer las bases sólidas para el desarrollo posterior del proyecto,
permitiendo a la organización entender el trabajo que se necesita realizar para desarrollar los
entregables antes de comprometer un gasto significativo.
El objetivo del proceso es asegurarse de que haya una comprensión común de:
•• Las razones para acometer el proyecto, los beneficios esperados y los riesgos asociados.
•• El alcance de lo que se debe realizar y el detalle de los productos a ser entregados.
•• Cómo y cuándo serán entregados los productos del proyecto y a qué costo.
•• Quién debe participar en la toma de decisiones dentro del proyecto.
•• Cómo se logrará la calidad requerida.
•• Cómo se establecerán y controlarán las líneas de base.
•• Cómo se identificarán, evaluarán y controlarán los riesgos, problemas y cambios.
•• Cómo se monitorizará y controlará el progreso.
•• Quién necesita información, en qué formato, y en qué momento
42
Directing a Project
Authority to
initiate project
Preparate the Risk Prepare the Quality Prepare the

Management Management Configuration
Strategy Strategy Management Strategy
Prepare the
Communication
Management Strategy
Set up the Create the

project controls Project Plan
Refine the
Business Case
Assemble the Project Request

Initiation to deliver
Initiating a Project Documentation a project
Stage boundary Managing a Stage Boundary

approaching
Figura 10. Proceso de Inicio de un Proyecto de PRINCE2. Fuente: AXELOS (2009).
43
5ECTS .es
2.4.4. El proceso de control de fases del proyecto
El propósito del proceso es asignar el trabajo a realizar, monitorizar dicho trabajo, tratar los problemas,
informar del progreso a la Junta del Proyecto y tomar medidas correctivas para garantizar que la etapa
permanece dentro de la tolerancia.
El objetivo de este proceso es asegurar los siguientes puntos:
•• La atención se debe centrar en la entrega de los productos de la etapa. Cualquier movimiento

fuera de la dirección y de los productos acordados al comienzo del proceso es monitorizada
para evitar cambios descontrolados y pérdida de enfoque.
•• Los riesgos y problemas se mantienen siempre bajo control.
•• El Business Case se mantiene en continua revisión.
•• Se entregan los productos acordados para la etapa dentro de los estándares de calidad
establecidos, del costo, esfuerzo y tiempo acordado.
•• El equipo de gestión del proyecto está enfocado en la entrega dentro de las tolerancias
establecidas.
44
Directing a Project
Excepcion Plan Excepcion Request Project

approved raised for advice Board advice
Stage
authorization
Managing a Closing a
Stage Boundary Project
Stage boundary Project end

approaching approaching
Controlling
a Stage Escalate
Report
issues and
highlights
risks
Take corrective Review the stage

action status
Capture and New
examine issues issue
and risks
Authorize Authorize Receive completed

Work Packages Work Packages Work Packages
Authority to deliver Completed Work

Work Package Package
Figura 11. Proceso de Control de Fases del Proyecto de PRINCE2. Fuente: AXELOS (2009).
45
5ECTS .es
2.4.5. El proceso de gestión de la entrega de productos
El propósito del proceso es controlar el enlace entre el gestor de proyecto y los managers de los
equipos, disponiendo requerimientos formales para aceptar, ejecutar y entregar el trabajo de proyecto.
El rol de los Gerentes del Equipo es coordinar un área de trabajo, que entregará uno o más de los
productos del proyecto. Este área puede ser interna o externa a la organización del cliente.
El objetivo es asegurar que:
•• El trabajo sobre los productos asignados al equipo está autorizado y acordado.
•• Los gerentes de equipo, los miembros del equipo y los proveedores tienen clarificado qué se
va a producir, con qué esfuerzo y coste, y cuáles son las escalas de tiempo esperadas.
•• Los productos planificados se entregan conforme a los requerimientos y dentro de las

tolerancias establecidas.
•• Se proporciona información de progreso precisa para el gerente del proyecto a una frecuencia
acordada que permite asegurar que las expectativas sean correctamente gestionadas.
Controlling a Stage
Authority to deliver Completed

a Work Package Work Package
Accept a Execute a Deliver a

Work Package Work Package Work Package
Figura 12. Proceso de Gestión de la Entrega de Productos de PRINCE2. Fuente: AXELOS (2009).
2.4.6. El proceso de gestión de los límites de etapa
El propósito es permitir que la Junta del Proyecto disponga de suficiente información suministrada
por el Project Manager, de forma que pueda revisar el éxito de la etapa que se esté desarrollando,
aprobar el Plan de la siguiente etapa, revisar el Plan de Proyecto actualizado y confirmar que se
mantiene la justificación comercial, así como que los riesgos sean aceptables. Por lo tanto, el proceso
debe ejecutarse cerca del final de cada etapa de gestión.
46
El objetivo del proceso es:
•• Asegurar a la Junta del Proyecto que todos los productos que se indican en el Plan de la Etapa
para la etapa que se está desarrollando han sido completados y validados.
•• Preparar el Plan de Etapa para la siguiente etapa.
•• Revisar y, si es necesario, actualizar la Documentación de Iniciación del Proyecto (en particular,

el Business Case, el Plan de Proyecto, la estructura del equipo de gestión del proyecto y la
descripción de roles)
•• Proporcionar la información necesaria hacia la Junta Directiva para evaluar la viabilidad

continua del proyecto.
•• Registrar cualquier información o lección que pueda ayudar en etapas posteriores de este
proyecto y/u otros proyectos.
•• Solicitar autorización para comenzar la siguiente etapa.
Directing a Project
Request to approve
Exception Plan
Request to approve Exception Plan

next Stage Plan request
Update the Produce an

Report stage end
Business Case Exception Plan
Update the
Project Plan
Plan de next
stage
Stage boundary
approaching
Controlling a
Initiating a Project
stage
Figura 13. Proceso de Gestión de los Límites de Etapa de PRINCE2. Fuente: AXELOS (2009).
47
5ECTS .es
2.4.7. El proceso de cierre del proyecto
El propósito del proceso es proporcionar un punto fijo en el que la aceptación del producto del
proyecto está confirmada, y reconocer que los objetivos establecidos en el inicio del proyecto han
sido conseguidos o que el proyecto no tiene nada más que aportar.
El objetivo del proceso es:
•• Verificar la aceptación del usuario de los productos del proyecto.
•• Asegurar que los equipos de operación sean capaces de soportar los productos cuando el
proyecto se disuelva.
•• Revisar el rendimiento del proyecto frente a sus líneas de base.
•• Evaluar cualquier beneficio que haya sido conseguido, actualizar el pronósticos de los
beneficios que queden por conseguir y planificar una revisión de aquellos beneficios no
pendientes.
•• Asegurar que la provisión se haya hecho para abordar todos los problemas y riesgos abiertos,
con recomendaciones de acciones de seguimiento.
Directing
a Project
Premature
close
Controlling a Project end Prepare planned Prepare planned

Stage approaching closure closure
Hand over
products
Closing a Evaluate the

Project project
Recommend Closure
project closure recommendation
Figura 14. Proceso de Cierre del Proyecto de PRINCE2. Fuente: AXELOS (2009).
48
2.5. Comparativa PRINCE 2 vs. PMBOK®

PMBOK es desarrollado por PMI y define los conceptos relacionados con la gestión de proyectos,
contiene un estándar reconocido a nivel mundial y actúa como guía para la profesión de gestión de
proyectos.
Por otro lado, PRINCE2 es desarrollado por la Oficina de Comercio Gubernamental del Reino Unido
(OGC). Es un método estructurado de gestión de proyectos basado en la experiencia obtenida de
miles de proyectos.
En las siguientes tablas vamos a hacer más explícitas estas diferencias:
PRINCE2 PMBOK
Definición Metodología PM estructurada Estándar y guía
Práctico, enfocado en áreas
Práctico vs. integral Integral
críticas
Temáticas y Áreas de
7 Temáticas 10 áreas de Conocimiento
Conocimiento
5 Grupos de Proceso y 47
Procesos y Actividades 7 Procesos y 35 actividades
actividades
Principios 7 Principios
Sólo se explican las técnicas Cubre las técnicas de cada
Técnicas
específicas de PRINCE2 proceso
Capacidades Interpersonales No cubiertas Cubiertas
Focalización Caso de Negocio y los Productos Requerimientos de Cliente
Solo se hace referencia al
Rol de la Junta de Proyecto Supervisión rol del Patrocinador y sus
responsabilidades
Activos Organizacionales y Fuertemente integrados con los
Parcialmente cubiertos
Factores Ambientales procesos
Principio de Gestión Gestión por excepciones
Tabla 14. Comparación PRINCE2 vs PMBOK. Fuente: elaboración propia.
Como se ha observado, existen diferencias significativas entre ambas metodologías, lo que hace que
cada una sea más idónea para su aplicación en función de los objetivos marcados y el ambiente
donde se desarrolla el proyecto. En la siguiente tabla realizamos una comparativa de las principales
diferencias:
49
5ECTS .es
PRINCE2 PMBOK
Acercamiento práctico 3 -
Enfoque integral - 3
Actividades de la Junta del
3 -
Proyecto
Gestión por excepción 3 -
Dirección de Procuración - 3
Enfoque en el producto 3
Enfoque de los requisitos del
- 3
cliente
Técnicas detalladas - 3
Habilidades interpersonales - 3
Tabla 15. Sectores de aplicación PRINCE2 vs PMBOK. Fuente: elaboración propia.
50
Tema 3.
Metodologías Agile
Agile es una forma de gestionar proyectos. Virtualmente se puede usar para cualquier tipo de proyecto,
si bien su origen estuvo orientado hacia el desarrollo de software. Agile fue y es un intento de hacer
que el proceso de desarrollo de software mejore y sea más eficaz, tiene una creciente popularidad.
Esta metodología le da un gran valor a las personas, es colaborativo y proporciona gran capacidad de
responder al cambio.
Agile divide proyectos de gran envergadura en trozos pequeños y manejables denominados

iteraciones. Al final de cada iteración (que generalmente se realiza sobre un intervalo de tiempo
consistente) siempre se entrega valor al cliente, aunque sea pequeño. El producto producido durante
cada iteración debe ser poder ser puesto en el mundo para obtener retroalimentación de los usuarios
o partes interesadas.
A diferencia de la gestión de proyectos Waterfall, que está estrictamente secuenciada (no comienzas
el diseño hasta que la toma de requerimientos está completada, y no comienzas el desarrollo hasta
que se firmen los diseños), Agile dispone a diseñadores, desarrolladores y responsables de negocio
trabajando conjunta y simultáneamente.
51
5ECTS .es
3.1. Manifiesto por el desarrollo Agile de software

En febrero de 2001, un grupo de desarrolladores interesados en metodologías avanzadas de desarrollo
ligero consiguieron converger sus puntos de vista y como resultado nació Agile. Los desarrolladores
que crearon Agile comprendieron la importancia de crear un modelo en el que cada iteración en el
ciclo de desarrollo "aprendía" de la anterior iteración. El resultado fue una metodología que era más
flexible, eficiente y orientada al equipo que cualquiera de los anteriores modelos utilizados hasta ese
momento.
Enlace 1
Manifesto for Agile Software Development
Ubicación donde se muestra el manifiesto original que describe las bases sobre las que se
ideó la filosofía de desarrollo de proyectos de software mediante metodología Agile
http://www.agilemanifesto.org
Todos los métodos ágiles se apoyan en el Manifiesto Agile y en sus 12 principios básicos. La adherencia
a la guía proporcionada por el manifiesto y los principios desarrolla un equipo agile, y no tanto un
proceso o herramienta de gestión.
El Manifiesto por el Desarrollo Ágil de Software (Beck et al., 2001), que se puede encontrar en el
enlace anterior, indica:
Estamos descubriendo mejores formas de desarrollar software tanto para nuestra propia experiencia
como para ayudar a terceros. A través de este trabajo hemos aprendido a valorar:
•• Individuos e interacciones sobre procesos y herramientas.
•• Software funcionando sobre documentación extensiva.
•• Colaboración con el cliente sobre negociación contractual.
•• Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
3.2. Principios de Agile: el rol del líder de proyecto en Agile

Las personas que escribieron el Manifiesto Ágil desarrollaron posteriormente 12 principios que
informan y refuerzan el manifiesto. Estos fortalecen aún más los valores ágiles en el desarrollo de
software.
El Manifiesto Ágil sigue estos principios:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de

software con valor.
52
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos
Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre cada dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el
apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre

sus miembros es la conversación cara a cara.
7. El software operativo es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y

usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para, a continuación,
ajustar y perfeccionar su comportamiento en consecuencia.
En un proyecto ágil disciplinado, cualquier persona puede estar en uno o más roles, y también
puede cambiar su rol a lo largo del tiempo de proyecto. Los roles no son ni están destinados a ser
posiciones. Los equipos que practican esta metodología se adaptan a los estilos que mejor encajan a
sus necesidades, lo que puede provocar que la forma de ejecución difiera de un proyecto a otro.
Agile deja de lado los roles especializados y considera que todos los miembros del equipo son iguales:
todos trabajan para entregar un producto, independientemente de su trabajo. Con la excepción de
los interesados (stakeholders), el resto de integrantes están efectivamente en el papel de miembro
del equipo.
Un stakeholder es alguien que está financieramente impactado por el resultado del proyecto, y su rol
es claramente diferente al de un usuario final.
El propietario del producto product owner es el miembro del equipo que habla como la voz del cliente.
Esta persona representa las necesidades y deseos de la comunidad de los diferentes stakeholders hacia
el equipo ágil. Su labor es aclarar cualquier detalle con respecto a la solución y también es responsable
de mantener una lista priorizada de elementos de trabajo que el equipo debe implementar para
entregar la solución.
53
5ECTS .es
El team leader guía al equipo realizando las actividades de gestión, descargando de estas a los
miembros de equipo. Actúa para garantizar que el equipo disponga de las condiciones necesarias
para conseguir el éxito conjunto. Esta figura también actúa como coach, que ayuda a mantener al
equipo enfocado en la entrega de trabajo y el cumplimiento de los objetivos de cada iteración, así
como en los compromisos hacia el product owner. El líder del equipo facilita la comunicación, faculta
al equipo para auto-optimizar sus procesos, asegura que el equipo tiene los recursos que necesita y
gestiona la resolución de los problemas de la manera más oportuna.
Aunque un líder de equipo experimentado pueda aportar habilidades a un equipo de nueva

creación, esta persona no puede ser un verdadero coach sin realizar mentorización. Por tanto, para
la constitución de un nuevo equipo agile, será necesario disponer de un coach durante, al menos,
algunas iteraciones.
3.3. Algunas técnicas y herramientas de Agile

Agile es un término general que se utiliza para englobar una gran variedad de metodologías y técnicas,
que comparten los principios y valores descritos anteriormente. Cada una de estas técnicas tiene sus
propias áreas de uso y características distintivas. A continuación, vamos a enumerar algunas de ellas:
3.3.1. SCRUM
Scrum es la metodología ágil dominante. En el ámbito del desarrollo de software, el 42% de las
organizaciones utilizan esta metodología exclusivamente, mientras otro 54% de las empresas lo
combinan con otras técnicas. Descrito por primera vez en 1986 por Hirotaka Takeuchi e Ikujiro Nonaka,
este enfoque se basa en las interacciones sistemáticas entre los tres roles principales: Scrum Master,
Product Owner y Team Members.
Una unidad básica de trabajo en scrum es el sprint, un corto ciclo de desarrollo que se necesita para
producir un incremento entregable del producto. Un sprint generalmente tiene entre 1 y 4 semanas
de duración: iteraciones más largas carecerían de predictibilidad y flexibilidad, que son los beneficios
fundamentales de scrum. Si bien la duración de un sprint no está estandarizada, sí se debe considerar
que todos los sprints dentro de un proyecto deben tener una longitud fija, lo que permite que sea más
fácil planear y controlar el progreso.
Scrum se basa en tres herramientas principales para gestionar los requerimientos y controlar el
progreso: Product backlog, Sprint backlog, Sprint burndown chart. El proceso se formaliza a través de
una serie de reuniones recurrentes: Daily Scrum (Standup), Sprint Planning, Review and Retrospective
meetings.
3.3.2. Kanban
Otro de los marcos de gestión de proyectos más comunes es Kanban. Se dice que se usa en un 43%
de organizaciones ágiles, tiene su origen en un sistema visual de tarjetas utilizado en las cadenas de
fabricación de Toyota como método de control de producción. Kanban es un enfoque muy simple
pero potente para el desarrollo de productos de software.
54
Policy Policy Policy Policy

Business case Selection at Smail, well- Risk assessed
showing value, Replenishment understood, per Continuous
cost of delay, size meeting testable, Deplyment
estimate and chaired by agreed with PD policy (see...)
design outline Product Director & Team
Figura 15. Panel Kanban. Fuente: Wikimedia (2017).
55
5ECTS .es
Kanban prioriza el trabajo en progreso (WIP) limitando su alcance para que coincida efectivamente con
la capacidad del equipo. Tan pronto como se completa una tarea, el equipo puede tomar el siguiente
elemento del pipeline. Por tanto, el proceso de desarrollo ofrece más flexibilidad en la planificación,
una respuesta más rápida, objetivos claros y transparencia.
A diferencia de Scrum, Kanban requiere iteraciones fijas y que no se definan procedimientos estándar
dentro del proceso. El desarrollo del proyecto se controla con la visualización del flujo de trabajo
a través de un Kanban board, generalmente representado por notas adhesivas y pizarras blancas, o
herramientas en línea tipo Trello.
3.3.3.Lean
Lean es el tercer enfoque ágil más utilizado, adoptado por el 21% de las organizaciones. Teniendo los
mismos orígenes que Kanban, el enfoque comenzó como una técnica aplicada a la fabricación física
de piezas. Fue desarrollado por Toyota como un nuevo enfoque de gestión destinado a fabricar los
vehículos pedidos por los clientes de la forma más rápida y eficiente, con el objetivo de conseguir los
tiempos de entrega de los vehículos lo más cortos posible.
La aplicación de principios Lean al desarrollo de software fue introducido inicialmente por Mary y Tom
Poppendieck. Incluye los 7 principios básicos de Lean:
•• Eliminar residuos
•• Amplificar el aprendizaje y la creación de conocimiento
•• Decidir lo más tarde posible
•• Entregar lo más rápido posible
•• Empoderar al equipo
•• Construir con integridad y calidad
•• Visión global del conjunto
Básicamente, estos fundamentos describen perfectamente la filosofía Lean: su objetivo es ofrecer más
valor a través de menos esfuerzo, inversión y tiempo. En términos de un proyecto, el término waste
se refiere a cualquier cosa que no agregue valor al proyecto, y por lo tanto debe ser eliminado. En
ingeniería de software esto puede ser tiempo de inactividad, características innecesarias o defectos.
El desarrollo de software Lean es una metodología iterativa e incremental. Por lo tanto, como en
cualquier otro enfoque ágil, las primeras versiones del producto se entregan en las primeras etapas
del proceso de desarrollo. El progreso adicional depende en gran medida en los comentarios del
propietario del producto.
56
Lo que diferencia el enfoque Lean es que el equipo no está restringido a usar ningún proceso formal,
tales como reuniones recurrentes o una priorización de tareas. Sin embargo, sus principios son a
menudo combinados con otras técnicas ágiles: el 21% de los equipos combinan Scrum con Lean.
3.3.4.Extreme Programming
Si bien las metodologías mencionadas anteriormente se enfocan principalmente en el proceso de

gestión de proyectos y sus aspectos formales, hay una gran cantidad de prácticas ágiles que son
meramente técnicas. Extreme Programming (XP) combina lo más esencial de Agile con una serie de
herramientas que permite a los equipos ágiles optimizar los procesos de ingeniería.
La Programación Extrema es un conjunto de ciertas prácticas, aplicadas a la ingeniería de software,

para mejorar su calidad y capacidad de adaptación a los requisitos cambiantes. Kent Beck, uno de los
signatarios iniciales del Manifiesto Ágil, fue el primero en documentar estas prácticas.
Las prácticas de XP más comúnmente usadas son:
•• Desarrollo basado en pruebas (TDD)
•• Refactorización
•• Integración continua
•• Programación en pareja (Pair Programming)
El desarrollo basado en pruebas usa test unitarios automatizados para impulsar el proceso de diseño
del software. A diferencia del ciclo de desarrollo regular, donde las pruebas se escriben después del
código, TDD tiene un enfoque de prueba primero, lo que hace que las pruebas unitarias se escriban
antes que el código en sí.
Además de ser utilizado dentro del ciclo TDD, la refactorización de código es una práctica común en
desarrollo de software ágil. Básicamente, es un proceso de mejora constante del código a través de
su simplificación y aclaración. El proceso es únicamente técnico y no implica ningún cambio en el
comportamiento del software. Mientras se desarrolla código con cada iteración, los equipos ágiles
usan la refactorización como una forma de eliminar desorden de código y duplicaciones, lo que
ayuda a disponer el código fácil de mantener y extender.
La integración continua (CI) es otra práctica que utilizan los equipos ágiles, confían para administrar el
código compartido y pruebas de software. Herramientas como CruiseControl o Jenkins son utilizadas
para verificar la calidad del software y automatizar su implementación. Además, CI ayuda a mantener
el código compartido eliminando los problemas de integración. Por lo tanto, la línea principal del
producto es robusta y limpia, y puede ser rápidamente desplegada según sea necesario.
La programación de pares o "emparejamiento" se considera una práctica ágil muy controvertida.

Esta técnica implica dos ingenieros trabajando juntos. Mientras que uno de ellos está realmente
escribiendo el código, el otro está activamente involucrado como observador, haciendo sugerencias
57
5ECTS .es
y navegando por el proceso. Con esta práctica se espera que el equipo de dos sea más eficiente,
creando un mejor diseño de software y cometiendo menos errores.
3.4. Declaración de Interdependencia (DOI)

El título "Declaración de Interdependencia" tiene múltiples significados. Significa que los miembros
del equipo del proyecto son parte de un todo interdependiente y no un grupo de personas no
conectadas entre sí. Significa que los equipos de proyecto, sus clientes y sus partes interesadas
también son interdependientes. Los equipos de proyectos que no reconocen esta interdependencia
rara vez tendrán éxito.
La declaración expone 6 valores:
1. Incrementamos el retorno de la inversión (ROI) centrándonos en un flujo continuo de valor.
Habla de dar valor al cliente de forma más continua posible: mejor realizar iteraciones de
2 semanas que de 3, mejor dar aportaciones diarias que cada 2 semanas, ofrecer lo que se
necesita de la forma más rápida posible desde el momento que se necesita.
2. Entregamos resultados fiables haciendo participes a los clientes en interacciones frecuentes y

compartiendo la propiedad.
El cliente debe formar parte activa del resultado, cuando más partícipe es en la definición de
producto y en su revisión, mejor adaptado estará el producto a sus necesidades.
3. Esperamos lo inesperado y lo gestionamos mediante iteraciones, anticipación y adaptación.
El mundo es caótico por naturaleza, lo que obliga a que los procedimientos de trabajo deben
ser flexibles y con ciclos cortos para poder seguir dando valor en estas condiciones.
4. Damos rienda suelta a la creatividad y la innovación reconociendo que los individuos son la fuente
última de valor, creando un entorno en el que puedan diferenciarse.
Los desarrolladores son los que crean, si se cargan de stress en un entorno de trabajo restringido
se obtendrán resultados mediocres, si se dejan que disfruten con lo que hacen y se les dan los
medios oportunos, crearán grandezas.
5. Disparamos el rendimiento mediante la responsabilidad común sobre los resultados y sobre la

propia efectividad del equipo.
No hay equipo más eficiente que aquel que está motivado y se le dan las herramientas para
que ellos mismos hagan su trabajo más rápido y con mejor calidad.
58
6. Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas específicas

para cada situación.
Existen muchas metodologías, pero no hay una sola que funcione para todos los entornos.
Hay que probar, medir y adaptar hasta encontrar el sistema que mejor funcione (mientras
funcione).
Estos valores también forman un conjunto interdependiente, si bien cada uno es importante
independientemente de los demás, los seis forman un sistema de valores que proporciona una visión
moderna de la gestión de proyectos, particularmente los complejos e inciertos. Las seis afirmaciones:
valor, incertidumbre, clientes, individuos, equipos y contexto (específico de la situación) definen un todo
inseparable. Por ejemplo: es difícil ofrecer valor sin un cliente que valora algo. Es difícil tener equipos
viables sin reconocer las contribuciones individuales. Es difícil manejar la incertidumbre sin aplicar
estrategias específicas de la situación.
59
5ECTS .es
60
Tema 4.
SCRUM: ejemplo de marco de Agile
4.1. Historia de Scrum. Teoría de Scrum

Jeff Sutherland y Ken Schwaber concibieron el proceso de Scrum a principios de los 90. Codificaron
Scrum en 1995 para presentarlo en la conferencia OOPSLA en Austin, Texas (EE. UU.) donde se publicó
el documento "SCRUM Software Development Process".
Ken y Jeff heredaron el nombre Scrum del innovador artículo de 1986 The New New Product
Development Game de Takeuchi y Nonaka, dos reconocidos pensadores. Con el término 'Scrum',
Nonaka y Takeuchi se refirieron al juego de rugby para enfatizar la importancia de los equipos
y algunas analogías entre un deporte de equipo como el rugby y tener éxito en las dinámicas de
desarrollo de nuevos productos. La investigación descrita en su artículo mostró que se logra un
desempeño sobresaliente en el desarrollo de productos nuevos y complejos cuando los equipos,
como unidades de personas pequeñas y autoorganizadas, se alimentan con objetivos, no con tareas.
Los mejores equipos son aquellos a los que se les da una dirección dentro de la cual tienen espacio
para idear sus propias tácticas sobre cómo dirigirse mejor hacia su objetivo conjunto. Los equipos
requieren autonomía para alcanzar la excelencia.
61
5ECTS .es
El marco de Scrum para desarrollo de software implementa los principios descritos en este documento
para desarrollar y mantener productos de software complejos.
Mientras estaba en el proceso de desarrollo y uso de las primeras versiones de Scrum, Ken le pidió
al profesor Babatunde A. Ogunnaike Tunde, un famoso ingeniero de investigación de control de
procesos, que observara los procesos de desarrollo de software. Tunde investigó varias metodologías
comerciales de desarrollo de software para concluir que la cascada y el proceso predictivo no encajan
bien en el trabajo de desarrollo de software. Confirmó el enfoque empírico de Scrum como el proceso
preferido.
El empirismo se usa para trabajos complejos en los que se desconoce más de lo que se conoce y las
predicciones tienen poco valor dado un alto índice de cambio e incertidumbre.
Scrum fue probado y refinado por primera vez en Individual, Inc., Fidelity Investments e IDX (ahora GE
Medical).
En febrero de 2001, Jeff y Ken se encontraban entre los 17 líderes de desarrollo de software que
crearon el Manifiesto para el desarrollo de software ágil.
En 2001, muy inspirado en Kent Beck, Ken Schwaber fue coautor del primer libro sobre Scrum con
Mike Beedle, Desarrollo de software ágil con Scrum.
En 2002, Ken Schwaber fundó la Alianza Scrum con Mike Cohn y Esther Derby, con Ken presidiendo
la organización. En los años siguientes, se crearon y lanzaron los exitosos programas Certified
ScrumMaster y sus derivados.
En 2006, Jeff Sutherland creó su propia compañía, Scrum.inc, mientras continuaba ofreciendo y
enseñando los cursos certificados de Scrum.
Ken dejó la Scrum Alliance en el otoño de 2009 y fundó Scrum.org para mejorar aún más la calidad y
eficacia de Scrum, principalmente a través de la serie Professional Scrum.
Con la primera publicación de la Guía de Scrum en 2010, y sus actualizaciones incrementales en 2011,
2013 y 2016, Jeff y Ken establecieron el cuerpo de conocimiento mundialmente reconocido de Scrum.
Desde su primera publicación en 1995 hasta ahora, Scrum ha sido adoptado por una gran cantidad de
empresas de desarrollo de software en todo el mundo. Hoy se reconoce como el marco más aplicado
para el desarrollo de software ágil. Se han publicado más de 1000 libros en Scrum.
Sin embargo, el método también se ha aplicado con éxito en otros dominios, por ejemplo, fabricación,
comercialización, operaciones y educación.
Con su trabajo continuo en sus respectivas compañías, Ken Schwaber y Jeff Sutherland siguen
estableciendo implacablemente la visión del éxito con Scrum.su
62
Teoría de Scrum
Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el
conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum
emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.
Tres pilares soportan toda la implementación del control de procesos empírico: transparencia,
inspección y adaptación.
•• Transparencia
Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables
del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar
común, de tal modo que los observadores compartan un entendimiento colectivo de lo que
se están viendo.
•• Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el

progreso hacia un objetivo para detectar variaciones indeseadas. Su inspección no debe ser
tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas
cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo.
•• Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites

aceptables y que el producto resultante será inaceptable, el proceso o el material que está
siendo procesado deben ajustarse. Dicho ajuste debe realizarse cuanto antes para minimizar
desviaciones mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y
adaptación:
–– Planificación del Sprint (Sprint Planning)
–– Scrum Diario (Daily Scrum)
–– Revisión del Sprint (Sprint Review)
–– Retrospectiva del Sprint (Sprint Retrospective)
4.2. Equipos de Scrum. Eventos de Scrum. Artefactos de Scrum

4.2.1. Equipos de Scrum
El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo

(Development Team) y un Scrum Master. Los Equipos Scrum son autoorganizados y multifuncionales.
63
5ECTS .es
Los equipos autoorganizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por
personas externas al equipo. Los equipos multifuncionales tienen todas las competencias necesarias
para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo
de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad. El
equipo de Scrum ha demostrado ser cada vez más efectivo para todos los usos anteriores y cualquier
trabajo complejo.
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las
oportunidades de obtener retroalimentación. Las entregas incrementales de producto “Terminado”
aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.
El Dueño de Producto (Product Owner)
El Dueño de Producto es el responsable de maximizar el valor del producto resultante del trabajo
del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar ampliamente entre distintas
organizaciones, Equipos Scrum e individuos.
El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product
Backlog).
El Equipo de Desarrollo (Development Team)
El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento
de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint.
Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de
Desarrollo participan en la creación del Incremento.
La organización es la encargada de estructurar y empoderar a los Equipos de Desarrollo para que

organicen y gestionen su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del
Equipo de Desarrollo.
El Scrum Master
El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Los
Scrum Masters hacen esto ayudando a todos a entender la teoría, prácticas, reglas y valores de Scrum.
El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas
externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles
no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por
el Equipo Scrum.
4.2.2. Eventos de Scrum
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de
reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo
que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no
puede acortarse o alargarse. Los demás eventos pueden terminar siempre que se alcance el objetivo
64
del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio
en el proceso.
Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de
Scrum constituye una oportunidad formal para la inspección y adaptación de algún aspecto. Estos
eventos se diseñaron específicamente para habilitar los pilares vitales de transparencia e inspección.
La falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye
una oportunidad perdida de inspección y adaptación.
El Sprint
El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos durante el

cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable. Es más
conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo. Cada
nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior.
Los Sprints contienen y consisten en:
•• La Planificación del Sprint (Sprint Planning):
El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea
mediante el trabajo colaborativo del Equipo Scrum completo.
La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un

mes. Para Sprints más cortos el evento es usualmente más corto. El Scrum Master se asegura
de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master
enseña al Equipo Scrum a mantenerse dentro del bloque de tiempo.
La Planificación de Sprint responde a las siguientes preguntas:
–– ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
–– ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
Durante la planificación del Sprint también se define el Objetivo del Sprint (Sprint Goal), que
es una meta establecida para el Sprint que puede lograrse mediante la implementación de
la Lista de Producto. Proporciona una guía al Equipo de Desarrollo acerca de por qué está
construyendo el incremento.
•• Los Scrums Diarios (Daily Scrums):
El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de
Desarrollo. El Scrum Diario se lleva a cabo cada día del sprint. En él, el Equipo de Desarrollo
planea el trabajo para las siguientes 24 horas. Esto optimiza la colaboración y el desempeño
del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una
proyección del trabajo del Sprint a realizar a continuación. El Scrum Diario se realiza a la misma
hora y en el mismo lugar todos los días para reducir la complejidad.
65
5ECTS .es
El Equipo de Desarrollo usa el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint
y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en
la Lista de Pendientes del Sprint. El Scrum Diario optimiza las posibilidades de que el Equipo de
Desarrollo cumpla el Objetivo del Sprint. Cada día, el Equipo de Desarrollo debería entender
cómo intenta trabajar en conjunto, como un equipo autoorganizado para lograr el Objetivo
del Sprint y crear el Incremento esperado hacia el final del Sprint.
•• La Revisión del Sprint (Sprint Review):
Al final del Sprint se lleva a cabo una Revisión para inspeccionar el Incremento y adaptar la Lista
de Producto si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum y los interesados
colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio
a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes
cosas que podrían hacerse para optimizar el valor.
Se trata de una reunión informal, no una reunión de seguimiento, y la presentación del

Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la
colaboración. Se trata de una reunión de, a lo sumo, cuatro horas para Sprints de un mes. Para
Sprints más cortos, el evento usualmente más corto. El Scrum Master se asegura de que el
evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a
todos a mantener el evento dentro del bloque de tiempo fijado.
•• La Retrospectiva del Sprint (Sprint Retrospective):
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí

mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y antes de la siguiente

Planificación de Sprint. Se trata de una reunión de, a lo sumo, tres horas para Sprints de un
mes. Para Sprints más cortos el evento es usualmente más corto. El Scrum Master se asegura
de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
El Scrum Master se asegura de que la reunión sea positiva y productiva. El Scrum Master enseña
a todos a mantener el evento dentro del bloque de tiempo fijado. El Scrum Master participa en
la reunión como un miembro del equipo ya que la responsabilidad del proceso Scrum recae
sobre él.
4.2.3. Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar
transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum
están diseñados específicamente para maximizar la transparencia de la información clave, necesaria
para asegurar que todos tengan el mismo entendimiento del artefacto.
66
Lista de Producto (Product Backlog)
La Lista de Producto es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es
la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto
(Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad
y ordenación.
Una Lista de Producto nunca está completa. El desarrollo más temprano de la misma solo refleja los
requisitos conocidos y mejor entendidos al principio. La Lista de Producto evoluciona a medida que el
producto y el entorno en el que se usará también lo hacen. La Lista de Producto es dinámica; cambia
constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Si
un producto existe, su Lista de Producto también existe.
La Lista de Producto enumera todas las características, funcionalidades, requisitos, mejoras y

correcciones que constituyen cambios a realizarse sobre el producto para entregas futuras. A medida
que un producto es utilizado, se incrementa su valor y el mercado proporciona retroalimentación, la
Lista de Producto se convierte en una lista más larga y exhaustiva.
Lista de Pendientes del Sprint (Sprint Backlog)
La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de Producto seleccionados

para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del
Sprint. La Lista de Pendientes del Sprint es una predicción hecha por el Equipo de Desarrollo acerca
de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa
funcionalidad en un Incremento “Terminado”.
La Lista de Pendientes del Sprint es un plan con un nivel de detalle suficiente como para que los
cambios en el progreso se puedan entender en el Scrum Diario. El Equipo de Desarrollo modifica la
Lista de Pendientes del Sprint durante el Sprint y esta Lista de Pendientes del Sprint emerge a lo largo
del Sprint.
Incremento
El Incremento es la suma de todos los elementos de la Lista de Producto completados durante un

Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo
Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que
cumple la Definición de “Terminado” del Equipo Scrum. Un incremento es un cuerpo de trabajo
inspeccionable y terminado que respalda el empirismo al final del Sprint. El incremento es un paso
hacia una visión o meta. El incremento debe estar en condiciones de utilizarse sin importar si el Dueño
de Producto decide liberarlo o no.
4.3. Relación de Scrum con Lean

Lean Thinking proporciona un marco de trabajo para optimizar aún más la interacción de los roles,
los artefactos y los eventos de Scrum. Los equipos Scrum seleccionan un subconjunto del trabajo
pendiente del producto para entregar cada Sprint, y se centran en la entrega de un incremento con
67
5ECTS .es
calidad y funcionalidad adecuadas. El patrón de pensamiento Lean puede ayudar a agilizar el flujo de
trabajo en todo el Sprint y a reducir los desperdicios de la secuencia de valor global.
Scrum y Lean se esfuerzan por mantener un alto nivel de calidad, que es necesario para el éxito del
trabajo global que se realiza. Para ver en acción los principios compartidos por el Lean Software
Development y por Scrum, basta con que analice los roles, artefactos y eventos de Scrum a través de
la lente de Lean Thinking.
El uso de Lean Thinking para considerar y resolver problemas expuestos por Scrum, a menudo genera
grandes beneficios y es una buena manera de sustentar una cultura Kaizen. Los equipos Scrum
siguen aprendiendo a aplicar Lean a Scrum, pero muchos procedimientos están ganando popularidad
porque han demostrado conseguir equipos Scrum más eficaces.
En el trabajo del conocimiento se utilizan muchos procedimientos y técnicas comunes que se ajustan
directamente a los principios de la metodología Lean. Algunas de estas técnicas se exploran a
continuación, prestando mayor atención a cómo pueden llevarse a cabo en un equipo Scrum.
•• Eliminar desechos
Quizás el ejercicio más básico de los procedimientos Lean es la eliminación de los desechos. La
metodología Lean considera que un desecho es aquello que no es en absoluto necesario para
generar el resultado deseado. Parte de los residuos no se pueden evitar e incluso son necesarios.
Si bien son necesarios algunos residuos, la mayor parte se pueden reducir, optimizar o incluso
quitar. Ciertos residuos en el flujo de valor del desarrollo de software, como tardar demasiado
en proteger el código, se reconocen y eliminan fácilmente. Otro desecho encontrado en los
equipos de desarrollo de software, como crear documentos grandes de requisitos antes de
que el desarrollo pueda iniciarse, se considera una referencia cultural y requiere un esfuerzo
significativo y tiempo para cambiar desde los fundamentos.
•• Limitar el trabajo en curso
Adecuar el volumen de trabajo en curso al dimensionamiento de los equipos de trabajo
•• Reducir los tiempos de espera
Se invierte mucho tiempo en esperar a que pasen cosas en el desarrollo de software. Este tipo
de residuos se encuentra fácilmente en la mayoría de los equipos de desarrollo. Peor que las
ineficiencias de esperar a los equipos Scrum es el tiempo que los clientes y las empresas pasan
esperando a que se integre, empaquete y envíe el software. Este problema aumenta con el
tamaño de la organización de desarrollo. Cuantos más desarrolladores o equipos se agreguen
a un proyecto, el costo de integrar su trabajo en mejoras individuales de un producto aumenta.
•• Compromiso de aplazamiento
El compromiso de aplazamiento es uno de los principios iniciales de Lean expresado como

valor de Lean Software Development. Este principio a menudo se describe como “esperar
hasta el último momento responsable” para tomar una decisión. Tomar una decisión que nos
68
compromete prematuramente a una línea de acción tiene poco o ningún valor, por lo que la
reflexión continúa. ¿Por qué no esperar hasta que la decisión deba tomarse, de forma que se
conozca la mayor cantidad de información posible sobre el problema? Esto limita el riesgo
de tomar la decisión incorrecta y da tiempo para que surjan incluso más opciones o rutas de
acción.
•• Visualizar el flujo de trabajo
El primer paso del método Kanban requiere la visualización de flujo de trabajo real utilizado
por un equipo. Esto hace realidad el principio “ver el todo” de Lean y requiere que se vea el
flujo de trabajo, no una versión idealizada prescrita por un documento de proceso de negocio
o algún otro modelo existente. Una visión útil representa lo que realmente ocurre. Una vez
haya visualización, se podrá llevar un seguimiento del trabajo con ella. Se recomienda el uso
de formatos de visualización lo más simples posibles:
Figura 16. Esquema Básico de Visualización Panel Kanban. Fuente: Microsoft (2017).
•• Compilar integridad en el proceso de creación
Los modelos de diseño de software, técnicas de desarrollo de pruebas en primer lugar, la

refactorización y la programación entre iguales buscan aumentar la calidad del software en el
momento de su creación. El uso de técnicas que aumentan la calidad en las fases más tempranas
del proceso de creación garantiza que los equipos no se basan en una comprobación de
calidad tras la finalización de la tarea para "probar la calidad más tarde”.
4.3.1.Lean y la industria automotriz
En la visión tradicional de la fabricación, el objetivo clave era aprovechar al máximo la capacidad

de las líneas de producción para que hubiera más productos producidos por menos trabajadores
y máquinas. Esto se hacía manteniendo grandes colas de inventario esperando en los centros de
trabajo. Los trabajadores y las máquinas nunca necesitaban esperar parte del material, o una pieza en
particular, y, como resultado, la utilización de la capacidad fue alta y los costos de producción bajos.
Sin embargo, también se obtenía como resultado en este tipo de entorno de fabricación en el que
los productos pasaban la mayor parte de su tiempo esperando a que el proceso siguiente estuviera
69
5ECTS .es
disponible, lo que provocaba un resultado que es inaceptable en la competencia actual basada en el

tiempo.
Hoy en día no es suficiente que las empresas sean productoras de alta calidad y bajo costo, sino que
además deben ser las primeras en desarrollar y entregar los productos y servicios al cliente. Por lo
tanto, para competir en este nuevo entorno, el ciclo desde que se realiza la orden hasta que se produce
la entrega debe reducirse drásticamente.
El principal desafío de un control de producción es mantener un flujo de producción sin problemas

frente a una variada combinación de productos. Además, para evitar desperdicio, esto debe lograrse
sin grandes inventarios. Taiichi Ohno describió el sistema desarrollado en Toyota para abordar este
desafío descansando en dos pilares:
1. Justo a tiempo (Just-in-time JIT), o produciendo solo lo que se necesita.
2. Autonomación, o automatización con un toque humano.
El modelo de Ohno es que cada estación de trabajo adquiriera los materiales requeridos de estaciones
de trabajo ascendentes según sea necesario, o justo a tiempo.
El pensamiento Lean se enfoca en el flujo de valor agregado y la eficiencia del sistema en general. Las
partes que se asientan en inventario se consideran desechos, y el objetivo es mantener el producto en
movimiento a través de la línea de montaje y agregar valor en cada paso. La atención se centra en el
sistema general y las operaciones de sincronización para que estén alineadas y produzcan a un ritmo
constante.
La fabricación ajustada es una metodología de fabricación que acorta el tiempo entre el pedido del
cliente y la creación / envío del producto al eliminar las fuentes de desechos, donde los desechos
son cualquier cosa que no contribuye a transformar una parte a las necesidades del cliente. La
fabricación ajustada elimina algunos residuos de la actividad de valor agregado, reduciéndolos como
en el enfoque de producción en masa, pero lo más importante es que reduce las actividades puras no
agregadas, que tiene el mayor impacto en el tiempo de entrega.
La fabricación ajustada está respaldada por cinco principios básicos:
1. Identifique lo que crea valor desde la perspectiva de sus clientes.
2. Especifique cada paso en sus procesos (el mapeo Value-stream es una excelente herramienta
para esto).
3. Haga que esos procesos fluyan.
4. Producir solo lo que los clientes soliciten.
5. Esforzarse por la perfección mediante la eliminación continua de residuos.
Recortar desperdicios en los procesos de producción es una de las maneras más efectivas de aumentar
la rentabilidad. Para eliminar el desperdicio, es importante entender exactamente qué es desperdicio
70
y dónde existe. Una vez identificado el desecho, es necesario desarrollar una estrategia para cada tipo
de residuo para reducir o eliminar su efecto, mejorando así el rendimiento general de su organización.
Los siete desechos incluyen:
1. Superproducción
2. Espera
3. Transporte
4. Procesamiento inapropiado (sobre procesamiento)
5. Inventario innecesario
6. Movimiento innecesario / excesivo
7. Defectos
Como has podido comprobar, el foco en la productividad y la eficiencia se centra en la mejora de los
procesos de producción, a todos los niveles, desde los procesos de gestión de personas y equipos de
trabajo, procesos de gestión, hasta el detalle de las cadenas de producción.
4.3.2. Lean y la industria del Software
La aplicación de la metodología Lean, que se desarrolló en un ámbito de industria manufacturera, en

un sector tan diferente como el del desarrollo de software puede parecer un reto de partida, al igual
que aplicar las teorías de reducción de los 7 desechos para aumentar la productividad de los procesos.
Si bien algunos de los residuos pueden parecer obvios en un entorno de desarrollo, para otros puede
que se tenga que cambiar la forma en la que se miran las cosas para ver realmente el desperdicio.
Vamos a intentar aclarar cómo estos residuos de fabricación se traducen en una fábrica de software:
•• Transporte
El transporte es probablemente el desperdicio más difícil de descubrir en un entorno de

desarrollo de software. Cuando se piensa en un departamento de TI, el producto final es algo
virtual. Es una pieza de software que reside en algún servidor. ¿Cómo se transportará esto?
En lugar de pensar en un transporte físico, se debe pensar en cómo las tareas pasan de un
desarrollador a otro, del diseñador al desarrollador, del analista al diseñador, etc. Un ejemplo
práctico de desperdicio de transporte es cuando un desarrollador ha terminado una tarea y
hace una entrega a un probador. Supongamos que el probador acaba de terminar otra tarea
y que la tarea se puede recoger inmediatamente. El examinador primero tiene que mirar la
tarea para comprender qué se supone que debe hacer o corregir. Luego tiene que iniciar la
aplicación y llegar al paso correcto en la aplicación para probar lo que se ha programado.
71
5ECTS .es
Esto es lo que se denomina tiempo de configuración y, en este caso, se genera mediante la

transferencia al siguiente paso. Por supuesto, hay muchas otras situaciones en las que el tiempo
de configuración entra en juego, pero este es solo un ejemplo para demostrar un punto.
Otro ejemplo claro en el que el transporte es un desperdicio es el hecho de que cuando se

entrega una determinada tarea, por lo general no es tratada inmediatamente por la siguiente
persona en la cadena de proceso. Entonces, de alguna manera, el transporte también introduce
un tiempo de espera adicional que analizaremos en detalle más adelante.
•• Inventario
El inventario es otra forma de desperdicio en una fábrica de software que puede no parecer
obvio cuando se piensa por primera vez. ¡Es un software! No se apila software en algún lugar
de un almacén donde puede generar exceso de stock, etc. De hecho, se hace exactamente eso,
con la única diferencia de que se llama retraso. Cuantos más artículos tenga en espera para ser
abordados, más stock o inventario se está construyendo.
Ahora, la acumulación no es el único tipo de inventario que se tiene en un entorno de desarrollo

de software. Comenzar una tarea y no terminarla de inmediato por la razón que sea (los otros
6 residuos pueden ser motivos para que esto suceda) también da como resultado la creación
de más inventario.
•• Movimiento
El movimiento, junto con el transporte, es el desperdicio más difícil de descubrir al principio.

El movimiento tiene que ver con el movimiento físico: personas u objetos que se mueven. Y
cuando se están moviendo, no están contribuyendo en absoluto al tiempo de Valor Agregado.
Uno de los problemas de movimiento que quizás no se considere en absoluto es el movimiento

que el usuario final debe realizar para trabajar con su software. Es posible que tengan que
realizar numerosas pulsaciones de teclas o movimientos del mouse para completar una tarea.
Adicionalmente, es sorprendente la distancia que los miembros de un equipo están caminando

todos los días.
Ahora, ¿cómo se elimina el desperdicio de movimiento tanto como sea posible? Por ejemplo,
poner a las personas que trabajan en el mismo proyecto en la misma sala funciona de manera
más efectiva que cuando están separados por una pared, piso o, a veces, incluso por otro edificio.
¿Por qué es así? Una razón es simplemente que la comunicación es un factor importante en
la optimización del rendimiento, y con líneas de comunicación más cortas (literalmente) la
comunicación es más natural, más directa y más instantánea. Lo que lleva automáticamente al
siguiente desperdicio: la espera.
72
•• Espera
El tiempo sin valor agregado se puede describir mejor como el tiempo que pasa en una tarea
para la cual el cliente no está dispuesto a pagar. Buenos ejemplos son correcciones de errores,
pasos de control de calidad (por ejemplo, pruebas), etc.
Algunos de estos NVA se deben eliminar todos juntos, pero algunos de ellos se pueden
clasificar como tiempo de valor agregado comercial (BVA), lo que significa que es tiempo que
el cliente no está dispuesto a pagar, pero es necesario para mantener el sistema funcionando
a un cierto nivel de calidad. Los ejemplos en el desarrollo de software son la creación de notas
de la versión, el mantenimiento del sistema de administración de tareas, la implementación
de cambios en toda la empresa para crear un mejor servicio, etc.
•• Sobreproducción
La sobreproducción es un desperdicio típico dentro de un entorno de desarrollo de software.

El primer nivel de sobreproducción es el desplazamiento del alcance. El avance de alcance
ocurre cuando un proyecto se inicia con un conjunto definido de características cuando
se comienza a desarrollar, pero después de un tiempo también se deben implementar
características adicionales o las características cambian. Esto dará como resultado un trabajo
adicional que no estaba previsto al inicio, lo que a su vez conduce a un mayor tiempo de
proceso (PLT) y ciclos de entrega más largos.
El segundo nivel de sobreproducción se puede conocer aplicando el principio de Pareto. Si

aplicamos este principio, podemos decir que el 80% de su audiencia objetivo solo usará el
20% de las funciones. Probablemente dediques mucho tiempo a desarrollar funciones que
casi nunca se usarán. ¿Eso significa que no debes desarrollarlos en absoluto? ¡Definitivamente
no! Pueden resultar en tener una ventaja sobre la competencia, atrayendo a más clientes, lo
que es algo bueno.
•• Exceso de procesamiento
Cada departamento de desarrollo de software tiene algún tipo de proceso que describe y
guía la forma en que se manejan las tareas, las solicitudes de funciones o las correcciones
de errores. Tener esta documentación disponible y comprendida por el equipo es una
necesidad para mantener el flujo de trabajo en movimiento. Sin embargo, con todas las
buenas intenciones de dividir el proceso en muchos pasos diferentes definidos para mayor
claridad y responsabilidades estrictamente definidas, se corre el riesgo de sobreprocesar todo
el proceso de desarrollo.
Se debe definir un flujo de proceso, pero demasiados subprocesos o pasos dentro de su

proceso solo lo harán más complejo. El aumento de la complejidad causa confusión y, a
veces, frustración entre las personas que deben seguir el proceso. Esto agrega desperdicio
al proceso porque la gente pasa tiempo en cosas como averiguar el próximo paso, ponerse
nervioso porque un colega tiene que manejar una cierta subtarea y no está disponible en este
momento, etc.
73
5ECTS .es
Otra cosa que sucede cuando tiene un flujo de proceso muy complejo es que tendrá tareas
o responsabilidades superpuestas. A veces, 2 personas emprenderán la misma acción en
diferentes pasos del proceso. La mejor forma de determinar las responsabilidades superpuestas
es usar un Value Stream Map (VSM). Al elaborar este VSM, dibuja los diferentes pasos del
proceso y agrega las responsabilidades de cada individuo para cada uno de estos pasos. Al
hacer esto, es imperativo que se cree un mapa con todo el equipo. Esa es la única forma en
que puede estar seguro de que está dibujando el proceso real y no de lo que cree que es el
proceso. Pensar que el proceso es exactamente como se piensa que es uno de los errores más
comunes al crear VSM.
•• Defectos
Los defectos son probablemente los más fáciles de reconocer como desperdicio. Defecto es
un concepto que es bien conocido en el negocio de desarrollo de software y muy fácil de
explicar. Se produce un defecto cuando el producto de software, parche o solicitud de función
no funciona como debería. El término "como debería ser" también se define como comprar al
cliente. Si el cliente no está satisfecho con la solución que está ofreciendo, tiene un defecto.
Un defecto no es necesariamente un error. Si el cliente ordena o compra un producto y no

cumple completamente con sus expectativas, usted tiene un defecto. Si se está hablando
de un error crítico real, definitivamente debería ser reparado. Pero no todos los defectos se
pueden arreglar. A veces se encuentra con limitaciones que no le permiten satisfacer al cliente
al 100%. En otros casos, no es económico o incluso financieramente viable satisfacer todas las
necesidades del cliente, y debe tomar algunas decisiones difíciles sobre qué implementar y
qué se descarta. El costo de satisfacer esa necesidad específica sería mayor que el retorno de
la inversión. Y, por supuesto, si tiene varios clientes, no se puede satisfacer a todos y cada uno
de ellos en la misma medida.
74
Tema 5.
La gestión de proyectos en diferentes industrias
Al buscar en la Guía PMBOK® no encontrará ninguna referencia a ninguna industria específica. De

hecho, la guía es independiente de la industria. En el sentido más amplio, es una caja de herramientas
para los gerentes de proyecto. Ser agnóstica a cualquier industria tiene algunos inconvenientes, pero
también una plétora de ventajas, especialmente en términos de aplicabilidad en la mayoría de las
empresas en la mayoría de las industrias en todo el mundo.
Siempre se ha indicado que su aplicación a las industrias de desarrollo de software es una excepción
porque es donde comenzó el movimiento ágil y la agilidad es primordial. PMI ha abordado el tema
ágil con una credencial relacionada, PMI Agile Certified Practitioner®. Por supuesto, una vez que nos
movemos más allá de los problemas de agilidad, incluso permaneciendo dentro de las unidades de
negocio relacionadas con TI, encontramos otros problemas que están inevitablemente relacionados,
pero comparativamente orientados al negocio, que se beneficiarán de la Guía completa del PMBOK.
Por lo tanto, la caja de herramientas de la Guía es aplicable a todas las empresas.
Pero las industrias aplican los fundamentos del proyecto de manera diferente. Aunque la Guía de
PMBOK es la misma para todas las industrias, todavía existen diferencias en cómo se aplican las mismas
técnicas en varios sectores. La tecnología de la información es un ejemplo citado con frecuencia,
un hecho también confirmado por la multitud de certificados de gestión de proyectos dirigidos
75
5ECTS .es
a los profesionales en el sector de la tecnología de la información. Como otro ejemplo, incluso la

terminología puede variar de una industria a otra. En las industrias financiera y de seguros, por ejemplo,
"riesgo" se refiere principalmente al riesgo financiero, y se aplican técnicas altamente especializadas
que, sin duda, podrían estar relacionadas con los conceptos de riesgo genéricos propuestos en la
Guía del PMBOK. En la industria de los dispositivos médicos se observa una desviación menor donde
(aunque se pueden aplicar enfoques más genéricos) la disciplina de riesgo es mucho más importante
para garantizar que un dispositivo como un marcapasos sea confiable.
Extensiones sectoriales a la guía PMBOK
Entonces, si bien la Guía de PMBOK es aplicable a todas las organizaciones en todas las industrias,
es posible una mayor adaptación. Hace años, PMI reconoció la naturaleza única de las industrias de
construcción al publicar una extensión oficial de la Guía PMBOK para ella.
Hoy hay tres extensiones oficiales de la Guía PMBOK disponibles en PMI.org. Tenga en cuenta la versión
de la Guía PMBOK para la que se escribe cada uno:
•• La Extensión de Software de la Guía PMBOK Quinta edición
Este estándar, desarrollado por PMI juntamente con IEEE Computer Society, proporciona
orientación sobre la gestión de proyectos de desarrollo de software y cierra la brecha entre el
enfoque predictivo tradicional descrito en la Guía PMBOK y los enfoques iterativos, como el
desarrollo ágil, más comúnmente utilizado en proyectos de software.
•• La extensión de la construcción a la Guía del PMBOK Tercera edición
Una buena parte de la Guía PMBOK es relevante para proyectos de construcción. Sin embargo,
los conceptos y la práctica de gestión de proyectos se han ampliado dentro de la industria de
la construcción mundial. Los cambios son lo suficientemente diferentes de otras industrias
para justificar la existencia de una extensión propia.
5.1. La gestión de proyectos en la industria de la construcción

La gestión de un proyecto en el ámbito de la industria de la construcción tiene ciertas peculiaridades
que hay que tener en cuenta para poder realizar una correcta adaptación de la metodología de gestión
de proyectos seleccionada y su correcta aplicación al proyecto en particular.
El objetivo de cualquier proyecto de construcción es terminar las obras dentro del plazo programado,
dentro del presupuesto asignado y dentro de la calidad especificada. Lograr la calidad especificada es
crucial para evitar demoras y los costos adicionales que se atribuirían a la repetición del trabajo y al
desperdicio de materiales.
Durante la construcción, el objetivo del PM es completar las obligaciones contractuales al mismo

tiempo que facilita el progreso y la finalización de las obras. Esto puede requerir la transmisión de
conocimiento al contratista y la orientación sobre cómo proceder y completar los trabajos.
76
Los contratos de construcción comprenden una serie de documentaciones que establecen el alcance
de las obras, sus requisitos asociados, y describen la naturaleza, los términos y condiciones del
acuerdo, incluidos los costos del contratista. Una vez que se acuerdan y el contrato se ejecuta, se
convierten en legalmente exigibles. Por lo tanto, es esencial invertir suficiente tiempo antes de la
etapa de ejecución del contrato para garantizar que las partes contratantes tengan claro qué implica
el contrato, el alcance y las condiciones correspondientes. Entender completamente esto puede
reducir la probabilidad de disputas o desacuerdos posteriores y fomentar la confianza, la apertura,
la cooperación, el apoyo mutuo, el compromiso con los resultados previstos, la comprensión de
las necesidades y circunstancias de la otra parte, la comunicación y el intercambio de información
durante el período contractual.
Una vez que se ejecuta el contrato, es esencial administrarlo y supervisar el desempeño, ya que esto
garantizará que se cumplan todas las condiciones y las obligaciones contractuales.
¿Por qué los proyectos de construcción son tan diferentes?
1. Los proyectos de construcción suelen ser poco o nada estandarizados, por lo que es difícil
disponer de sinergias de proyectos anteriores.
2. Los proyectos de construcción generalmente ocurren en zonas en el exterior, lo que introduce

variables que hay que tener en cuenta en la gestión del riesgo, gestión de la comunicación,
etc.
3. Tienen una naturaleza especial en términos de contratos, ya que el período del contrato suele
estar medido en años debido al tamaño del proyecto, y con esto, existen riesgos inherentes
únicos en términos de cambios tecnológicos, financiamiento / inflación, clima político, etc.
4. Complejidad de las obras, con muchas disciplinas diferentes, como arquitectura, civil, MEP,
con las siguientes características:
–– Los equipos no suelen haber trabajado conjuntamente antes.
–– La supervisión es muy compleja, con muchas disciplinas diferentes
–– Suele utilizar mano de obra no cualificada.
–– Pueden desarrollarse en diferentes regiones, lo que hace que convivan diferentes

normativas nacionales, lo que añade mayor complejidad al proyecto.
5. Las partes involucradas generalmente muestran conflictos de intereses mutuos:
i. El propietario necesita el proyecto entregado a un costo mínimo, la más alta calidad y

menos tiempo.
ii. El contratista se centra en maximizar las ganancias y, en general, no se preocupa por la

calidad.
77
5ECTS .es
iii. Los consultores tienen diferentes intereses dependiendo de los acuerdos, por ejemplo, si
las tarifas se basan en % de costos, entonces intentarán maximizar los ingresos.
Entonces, ¿cómo puede esto controlarse? La complejidad inherente requiere una comprensión
profunda; la supervisión debe ser independiente y verificada por terceros; el Project manager debe
considerar los diferentes grupos de procesos: iniciar, planificar, ejecutar y cerrar; se debe usar el propio
proceso de construcción adecuado a su naturaleza.
Sin embargo, la industria de la construcción se enfrenta a una variedad de desafíos. En muchos

países, su productividad es una de las más bajas; la imagen pública de la industria está empañada
particularmente en relación con la nueva economía; en muchos países industrializados, la industria
tiene una escasez casi constante de profesionales experimentados y trabajadores calificados, y su
entrada no está garantizada; el grado de utilización de alta tecnología no es comparable con el de
otras ramas de la industria, como la nueva economía y la fabricación; y la competencia de gestión de
proyectos se da por sentada.
Estos desafíos imponen a la industria la búsqueda de salidas para el futuro en busca de:
•• Más valor de administración de proyectos y construcción por dólar invertido
•• Imagen de industria muy mejorada.
•• La gestión de proyectos como guía para integrar tecnología, sabiduría, inteligencia y

experiencia, para diseñar el futuro de entornos construidos o, más ampliamente, la sociedad.
PMI ha publicado una extensión a la Guía PMBOK enfocada al ámbito de la industria de la Construcción.
¿En qué consisten los cambios frente a la Guía PMBOK?
•• Se mantienen los 5 grupos de procesos.
•• Se agregan 4 áreas de conocimiento adicionales a las actuales, formadas por 13 procesos:
–– Gestión de la Seguridad (3 procesos)
Trata de definir políticas, objetivos y responsabilidades para procurar que en la ejecución

de los proyectos se eviten accidentes que puedan causar daños a las personas y los bienes.
Incluye seguridad e higiene para garantizar la salud de los involucrados.
Los organización implementa el sistema de gestión de la seguridad a través de políticas,

procesos y procedimientos.
–– Gestión Ambiental (3 procesos)
Trata de definir políticas, objetivos y responsabilidades para procurar que en la ejecución

de los proyectos se evite o minimice el impacto ambiental.
Enfatiza la importancia de optimizar el uso de los recursos naturales.
78
Promueve el respeto a las regulaciones en materia ambiental en el entorno de nuestro

proyecto.
–– Gestión Financiera (3 procesos)
Se trata de definir los procesos para adquirir y gestionar recursos financieros para el
proyecto. A diferencia de la gestión de costos, el énfasis es en la gestión de ingresos y el
monitoreo del flujo de caja. En proyectos de construcción típicamente, los ingresos son
periódicos (estimaciones) pero los gastos son constantes, es importante manejar estas
diferencias.
–– Gestión de Reclamaciones (4 procesos)
Se trata de definir los procesos para prevenir reclamaciones que afecten al proyecto,
además de mitigar aquellas que se susciten y resolverlas lo antes posible. Va un paso más
delante de la prevención de riesgos, ya que se consideran inevitables.
•• Se añaden 4 nuevos procesos a las áreas de conocimiento existentes:
–– Definición de Peso de Actividades: proceso de Gestión del Tiempo, realiza evaluación de

características y atributos de las actividades para medir su contribución al progreso del
proyecto.
–– Desarrollo de Curvas de Progreso: proceso de Gestión del Tiempo, realiza representación

gráfica del progreso del proyecto, en referencia al sistema de gestión del valor ganado.
–– Monitoreo del Progreso: proceso de Gestión del Tiempo, realiza Monitoreo detallado del
sistema de gestión del valor ganado.
–– Cierre del Equipo de Proyecto: proceso de Gestión de Recursos donde se realiza el cierre y
disolución de un equipo de construcción. Este cierre es de mayor importancia que en
otros proyectos ya que típicamente pertenecen a organizaciones orientadas a proyecto.
•• Se incluyen algunas formas de organización específicas para la construcción.
•• Se agregan algunas herramientas y técnicas.
5.2. La gestión de proyectos en la industria del software

La naturaleza única del software hace que los elementos de los 47 procesos dentro de los 5 Grupos
de Procesos de la Guía del PMBOK se superpongan, intercalen e iteren de formas muy diferentes, lo
que provoca modificaciones en la forma en la que se utilizan para gestionar proyectos de software.
Para la gestión de proyectos de software es necesario tener en cuenta, además de las restricciones
que nos indica la Guía PMBOK, otros factores tecnológicos que afectan tanto al proyecto en sí, como
al propio producto de software:
79
5ECTS .es
•• Estado de la tecnología de hardware y software.
•• Plataformas de hardware, plataformas de software, sistemas operativos y protocolos de

comunicación.
•• Integridad, limitaciones y protocolos de la arquitectura de TI.
•• Herramientas de desarrollo de software.
•• Arquitectura de software.
•• Requerimientos de compatibilidad hacia adelante y hacia atrás.
•• Reutilización de componentes de software de una biblioteca.
•• Uso de componentes de software de fuente abierta versus de fuente cerrada.
Otros factores que pueden poner restricciones a los proyectos de software incluyen, entre otros,
requisitos de seguridad del sistema, cumplimiento de seguridad, confiabilidad, disponibilidad,
escalabilidad, rendimiento, capacidad de prueba, seguridad de la información, localización,
mantenimiento, soporte, regulaciones, políticas de clientes, soporte de infraestructura, disponibilidad
y habilidades de los miembros del equipo, entorno y métodos de desarrollo de software, madurez y
capacidad organizacional.
La naturaleza intangible del software crea desafíos al medir el estado actual del producto, lo que a su
vez complica el monitoreo y el control de un proyecto de software. Los enfoques tradicionales, como
las estructuras de desglose del trabajo, las redes de programación y los informes de valor ganado están
diseñados para ajustarse a las necesidades de los proyectos de software. Estas técnicas tradicionales
se complementan con técnicas tales como el desarrollo iterativo y/o incremental con demostraciones
frecuentes de software parcialmente completado. La naturaleza maleable del software tiene
connotaciones positivas y negativas para la gestión de proyectos de software. En el lado positivo,
la maleabilidad del software hace posible algunas veces (pero no siempre) responder rápidamente
a las necesidades cambiantes de los usuarios y otros factores ambientales, en comparación con
el cambio de los elementos del hardware de la computadora u otros artefactos físicos. En el lado
negativo, interrumpir el trabajo continuo para responder a los cambios solicitados puede sobrepasar
las limitaciones presupuestarias y de programación. Cada proyecto de software es un esfuerzo único
porque la replicación (es decir, la copia) del software existente es un proceso directo, a diferencia de
la replicación de los artefactos físicos de fabricación y proyectos de construcción. Cada proyecto de
software es, por lo tanto, una empresa que produce un producto único.
La planificación precisa y la estimación del costo y el cronograma es difícil para todo tipo de proyectos,
pero es particularmente difícil para los proyectos de software porque: (1) el software se desarrolla y
modifica por las actividades laborales cognitivas de los desarrolladores, (2) la productividad entre los
desarrolladores varían ampliamente (tanto en cantidad como en calidad de trabajo), (3) los requisitos
sobre los cuales se basan las estimaciones están a menudo mal definidos, y (4) la evolución continua
de la tecnología puede hacer que los datos históricos sean inexactos para los nuevos proyectos.
80
Por estas razones, los métodos actuales de desarrollo de software tienden a enfocarse en desarrollar
un conjunto creciente de incrementos de producto para que las compensaciones entre horario,
presupuesto, recursos, funcionalidad y atributos de calidad puedan ajustarse continuamente.
La productividad en proyectos de software incluye tanto cantidad como calidad de trabajo. La

cantidad de software escrito, es decir, la cantidad de líneas de código no es una buena medida de la
productividad del programador, un programador que escribe un programa pequeño y eficiente es
más productivo para contribuir a un resultado exitoso que un programador que escribe un programa
grande e ineficiente. De manera similar, un programador que se apresura en una tarea, pero comete
muchos errores que requerirá una revisión correctiva, es menos productivo que un programador que
avanza más lentamente, pero produce un programa que tiene menos defectos.
Con la llegada de la interconectividad generalizada, la seguridad del software se ha convertido en una

consideración importante al crear o modificar un producto de software. Al igual que otros atributos
de calidad, los atributos de seguridad deben diseñarse, construirse, verificarse y validarse. Al igual
que otros atributos de calidad, la seguridad del software no puede "probarse".
El rol del Project Manager
Como se establece en la Sección 1.7 de la Guía de PMBOK, el rol de un gerente de proyecto es distinto
al de un gerente funcional o un gerente de operaciones.
Sin embargo, el trabajo de proyecto de software puede organizarse por componente de producto
(por ejemplo, interfaz de usuario, base de datos, computación y software de comunicación,
funcionalmente por componente de proceso (por ejemplo, análisis, diseño, construcción, prueba e
instalación/procesos de capacitación) o por subsistema (por ejemplo, tiempo, radar, visualización
del tráfico aéreo). El equipo del proyecto puede organizarse de manera funcional, por ejemplo, y el
gerente del proyecto de software puede ser el administrador de las unidades funcionales del proyecto
durante la planificación y ejecución de ese proyecto.
Un gran proyecto de software puede tratarse como un programa de software que se descompone en
múltiples proyectos, cada uno con un gerente de proyecto cuyos productos de trabajo se fusionan en
un flujo de productos.
Además de las características de los gerentes de proyecto enumerados en la Guía PMBOK

(conocimiento, rendimiento, y personal) los gerentes de proyectos de software brindan liderazgo en:
•• Iniciar, planificar y desarrollar estimaciones y planes, tanto inicialmente como de manera

continua conforme el entorno cambia.
•• Monitorear y controlar los hitos del cronograma, los gastos del presupuesto, la estabilidad de
los requisitos, el rendimiento del statf, la utilización de los recursos y los factores de riesgo
identificados utilizando un proceso de control de versiones sistemático.
•• Liderar y dirigir definiendo la visión del proyecto, manteniéndolo a medida que cambian los
requisitos y otras limitaciones, proporcionando liderazgo práctico a los líderes de equipo,
81
5ECTS .es
desarrolladores de software y personal de apoyo que participan en un trabajo de equipo

innovador.
•• Mantener el cumplimiento de las políticas de la organización y los requisitos contractuales.
•• Gestionar el riesgo identificando, analizando, priorizando y respondiendo a los factores de

riesgo de manera continua.
•• Facilitar, entrenar, monitorear, inspirar y trabajar con los trabajadores del conocimiento de
ingeniería de software para obtener los resultados deseados.
•• Comunicarse con las partes interesadas para cerrar la "brecha tecnológica" mediante el uso de
términos y conceptos que sean familiares para las partes interesadas.
En un proyecto pequeño (por ejemplo, menos de diez personas), el gerente de proyecto puede tener
funciones adicionales, como líder de equipo y/o diseñador de software, arquitecto de software,
analista de negocios u otras funciones de contribución. Alternativamente, el administrador de un
pequeño proyecto de software puede administrar simultáneamente uno o más proyectos pequeños.
Sin embargo, se debe tener cuidado de no sobrecargar al gerente de un proyecto pequeño con otros
deberes.
El Cuerpo de Conocimiento de la Gestión de Proyectos
Debido a que el software es un producto intangible, existen muchas posibilidades para los ciclos
de vida de los proyectos de software y muchos enfoques diferentes para aplicar las técnicas de
administración de proyectos de software a esos ciclos de vida. La Sección 2.4.2 de la Extensión de
Software describe la continuidad de los ciclos de vida de un proyecto de software, que puede variar
de altamente predictivo a altamente adaptativo.
El principio de "la mayoría de los proyectos, la mayoría de las veces" se modifica para acomodar las
variaciones dentro del continuo de los ciclos de vida para el desarrollo de software; los gerentes de
proyectos de software adaptan los métodos, herramientas y técnicas para la gestión de proyectos a
los aspectos particulares de los diversos ciclos de vida de los proyectos de software.
No se espera que los gerentes de proyectos de software tengan el conocimiento profundo y las
habilidades de los miembros de su equipo, pero deben comprender sus problemas y las preocupaciones,
así como estar familiarizados con la terminología utilizada por el equipo. Los gerentes de proyectos
de software también deben comprender diferentes enfoques para administrar proyectos de software
dentro del continuo de los ciclos de vida del proyecto de software.
Los gerentes de proyectos de software pueden tener antecedentes técnicos, pero no siempre en
software. Esos gerentes de proyecto que no tienen habilidades sólidas de software pueden necesitar
trabajar estrechamente con un líder técnico en sus proyectos de software.
Dos aspectos importantes para los gerentes de proyectos de software son las habilidades interpersonales
y la gestión de la calidad del software. La Sección 1.7.1 de la Extensión de Software enumera las
habilidades interpersonales que son particularmente importantes para los administradores de
82
proyectos de software. Las consideraciones de calidad se introducen en la Sección 1.9 de la Extensión

de Software, y se presentan en detalle en la Sección 8 de la extensión.
Los ciclos de vida de los Proyectos y los métodos Agile
Los gerentes de proyectos de software son responsables de seleccionar los métodos de desarrollo
para sus proyectos y deben conocer los diferentes métodos de desarrollo de software, así como los
pros y contras relativos de esos métodos.
Los métodos ágiles para desarrollar software se han generalizado lo suficiente como para merecer
la discusión en esta Extensión de Software de la Guía PMBOK. Sin embargo, esta extensión no
proporciona definiciones de "ágil" y "métodos ágiles" porque esos términos son normalmente
utilizados con diferentes significados.
En cambio, los elementos de agilidad encontrados en varios ciclos de vida del proyecto de software
adaptativo se tratan de la siguiente manera:
•• Los equipos de colaboración se describen en la Sección 2.3.2.
•• Los ciclos de vida adaptables se describen en la Sección 2.4.
•• Otros aspectos de la agilidad para proyectos de software que usan ciclos de vida adaptativos
se describen en las secciones correspondientes de la Extensión de Software.
Cabe señalar que los métodos ágiles no son ciclos de vida del proyecto, son métodos de desarrollo
que pueden integrarse en los ciclos de vida del proyecto de software adaptativo. Los aspectos de
agilidad se presentan en la Sección 2.4.2.4 de la Extensión de Software, pero las especificaciones de
varios métodos ágiles en lo que se refiere a la práctica de ingeniería de software no se presentan en
la extensión.
83
5ECTS .es
84
Tema 6.
Determinación de la mejor metodología
6.1. Enfoques, metodologías y procedimientos

La elección de la metodología más adecuada para la gestión de un proyecto es una de las primeras
decisiones que tendrá que tomar un Project manager. La metodología que escoja tendrá un impacto
profundo y continuo en la forma en que él y su equipo trabajen.
Cada una de las metodologías de gestión de proyectos tienen sus propios pros y sus contras para
diferentes tipos de proyectos. Algunas están orientados a la velocidad de ejecución, otras a la
exhaustividad, unas orientadas al desarrollo de software, otras al sector de la construcción, etc.
La metodología que se elija dependerá del equipo de proyecto, del tipo de proyecto, e, incluso, del
alcance.
Por ejemplo, una metodología de Waterfall funciona mejor para los siguientes tipos de proyectos:
•• Proyectos cortos y sencillos
•• Proyectos con requisitos claros y fijos
85
5ECTS .es
•• Proyectos con recursos cambiantes que dependen de una documentación detallada
La flexibilidad del enfoque ágil permite adaptarlo a diferentes tipos de proyectos. Dicho esto, esta
metodología funciona mejor para:
•• Cuando no tienes un final fijo en mente pero tienes una idea general de un producto.
•• Cuando el proyecto necesita adaptarse a cambios rápidos.
•• Si la colaboración y la comunicación son sus puntos fuertes (y la planificación no lo es).
Un enfoque híbrido es el más adecuado para proyectos que tienen requisitos intermedios en
comparación con Agile y Waterfall, es decir, que requieren tanto estructura como flexibilidad. En la
mayoría de los casos, se trataría de proyectos de tamaño medio con una complejidad moderadamente
alta pero con presupuestos fijos. Es probable que se disponga de una idea del producto final,
pero también se está abierto a la experimentación. Se necesitaría de una estrecha colaboración,
especialmente después de la etapa de planificación.
El enfoque Scrum es el mejor para equipos de proyecto altamente experimentados, disciplinados

y motivados que pueden establecer sus propias prioridades y entender claramente los requisitos
del proyecto. Funciona para proyectos grandes, pero falla si el equipo del proyecto es muy grande.
En definitiva, se utiliza Scrum si se está desarrollando software complejo y se dispone de un equipo
experimentado.
El método del camino crítico es el más adecuado para proyectos con partes interdependientes.
Si se necesita que las tareas se completen simultáneamente o que una tarea finalice antes de que
otra pueda comenzar, se deberá utilizar esta metodología. CPM encuentra muchas aplicaciones en
actividades complejas pero repetitivas como proyectos industriales. Es menos adecuado para un área
dinámica como la gestión de proyectos creativos.
La Gestión de Proyectos por Cadena Crítica funciona mejor en ambientes donde los recursos se
dedican a un solo proyecto. Si se dispone de un equipo dedicado a un proyecto, funciona muy bien.
Si el equipo está dividido en varios proyectos, se tendrán problemas con la planificación de recursos.
El enfoque centrado en los recursos de CCPM también es ideal para equipos de proyecto con recursos
limitados.
La Gestión Integrada de Proyectos (GIP), a veces también llamada "Ejecución Integrada de Proyectos",
es una metodología común de gestión de proyectos en las industrias creativas. Esta metodología hace
hincapié en el intercambio y la estandarización de los procesos en toda la organización. Las grandes
agencias con equipos y procesos diversos son las que más se benefician de la Gestión Integrada de
Proyectos. Funciona mejor para proyectos creativos complejos en los que se necesitan recursos de
varios equipos y departamentos para interactuar entre sí.
PRiSM (Integración de Proyectos Métodos Sostenibles) es una metodología de gestión de

proyectos desarrollada por Green Project Management (GPM) Global. Como insinúa su nombre, el
enfoque PRiSM se enfoca en tomar en cuenta y minimizar los impactos ambientales adversos del
proyecto. Se diferencia de las metodologías tradicionales en que se extiende más allá del final del
86
proyecto. En cambio, tiene en cuenta todo el ciclo de vida del proyecto después de la entrega para
maximizar la sostenibilidad. PRiSM es principalmente adecuado para grandes y complejos proyectos
inmobiliarios e industriales donde la sostenibilidad es una preocupación clave.
PRINCE2 es la más adecuada para proyectos grandes y complejos con requisitos fijos, principalmente
en el entorno europeo y asiático, y en organizaciones gubernamentales.
Como se puede comprobar, la elección entre unas metodologías y otras no es asunto trivial. Para
intentar realizar la mejor elección, es posible sistematizar el proceso de selección a través del análisis
de varias características del proyecto:
1. Evaluar el proyecto
A la hora de elegir una metodología de gestión de proyectos es útil empezar por el final. Se
necesita saber exactamente cómo debe ser el resultado final y qué se necesita para lograrlo.
Es importante concentrarse en reunir los requisitos iniciales. Si los requisitos sugieren que
se necesita un equipo grande y diverso, escoja una metodología que apoye la flexibilidad.
Del mismo modo, si se tiene una idea clara del resultado final, elija una metodología más
estructurada como Waterfall. Si el resultado final es difuso, elija una metodología iterativa
como Agile.
Algunas otras cosas a considerar cuando se evalúa el proyecto son:
–– Presupuesto del proyecto
–– Cronología
–– Tamaño y complejidad
–– Expectativas de las partes interesadas
–– Tipo de proyecto e industria
2. Evalúe al equipo de trabajo
La metodología de gestión de proyectos es esencialmente un plan para el proyecto. Le dice

al equipo qué crear y cuándo crearlo. Para que esto suceda, sin embargo, el equipo debe ser
capaz de leer el plano en sí mismo. En otras palabras, si su equipo no está familiarizado con la
metodología de gestión de proyectos elegida, tendrá dificultades para obtener resultados: se
tendrá que dedicar tiempo a aprender la metodología (a la que algunos de los miembros de
su equipo podrían resistirse), lo que provocaría retrasos.
También se debe considerar la composición del equipo. Identificar sus fortalezas y debilidades.
Si el equipo prospera en la colaboración, puede elegir un enfoque menos estructurado
como Agile. Si el equipo está altamente motivado y disciplinado, un enfoque SCRUM puede
funcionar bien. Si usted tiene recursos limitados, escoja un enfoque eficiente como CCPM.
87
5ECTS .es
Aquí hay algunas cosas a considerar cuando evalúe al equipo:
–– Experiencia de equipo
–– Entrenamiento
–– Capacidad de auto-organización
–– Preparación del equipo
–– Localización de equipos (remotos, in situ, etc.)
Esencialmente, escoja una metodología que se ajuste a su equipo, en lugar de forzar a su

equipo a ajustarse a la metodología.
3. Evalúe su organización
La forma en que la empresa está organizada, su cultura y sus antecedentes tendrán un gran
impacto en su elección de la metodología de gestión de proyectos. Algunas metodologías solo
funcionan con grandes organizaciones con jerarquías establecidas. Otros son más adecuados
para trajes más pequeños y delgados. Por ejemplo, si los registros anteriores de proyectos
previos muestran que todos los proyectos ágiles han sido retrasados y mal recibidos, es una
buena idea evitar esta metodología en el futuro.
Algunas cosas que se debe considerar al evaluar su organización son:
–– Registros anteriores y experiencia con diferentes metodologías
–– Cultura
–– Jerarquía de la organización
–– Nivel de flexibilidad
–– Nivel de madurez de la organización
–– Tamaño de la organización
–– Recursos disponibles, incluyendo recursos externos tales como trabajadores

independientes y contratistas.
–– El sector de actividad
4. Evalúe a sus grupos de interés
Al elegir una metodología de MP, tenga en cuenta el grado de participación de las partes
interesadas: algunas metodologías exigen que las partes interesadas participen regularmente
en cada etapa del proyecto. Con Agile, por ejemplo, usted necesita que las partes interesadas
estén disponibles regularmente para recibir retroalimentación. Si las partes interesadas están
88
ocupadas, escoja una metodología que requiera una menor participación de las partes
interesadas.
Requisitos de las partes interesadas: ¿cómo trabajan las partes interesadas?, ¿qué requieren
del director de proyecto? Si se sabe que las partes interesadas cambian frecuentemente el
alcance del proyecto, escoja una metodología más flexible. Del mismo modo, si los grupos de
interés requieren actualizaciones diarias, escoja una metodología que pueda acomodar esta
demanda.
Dada la importancia de las partes interesadas en el éxito del proyecto, tener en cuenta sus
requisitos hará que las partes interesadas sean más felices y los proyectos más exitosos.
5. Evalúe las herramientas de gestión
Las herramientas de gestión de proyectos rara vez son agnósticas a la metodología. Por lo
general, están diseñadas para funcionar bien con una metodología específica. Por lo tanto, las
herramientas de software a las que se tiene acceso y experiencia pueden afectar a la elección.
Para hacer esto es necesario:
–– Hacer una lista de todas las herramientas de software que se utilizan habitualmente.
–– Enumerar sus limitaciones y capacidades.
–– Comparar sus capacidades con los requisitos de una metodología específica de gestión de
proyectos.
Lo ideal es que la metodología que se elija funcione con su conjunto de herramientas ya

existente. Si se tiene que comprar nuevas herramientas, no solo se tendrá que gastar más,
sino que también se perderá tiempo crítico en la reconversión y formación del equipo.
Esta evaluación en profundidad ayudará a elegir una metodología que se ajuste perfectamente
a los objetivos, a las capacidades del equipo y a los requisitos de las partes interesadas.
6.2. Enfoques de management. Complejidad relativa y absoluta

Cuando se habla de un proyecto complejo seguramente nos viene a la mente la imagen de
un proyecto que supone la elaboración de un producto compuesto de muchos elementos
interrelacionados, elaboración que requiere de un riguroso proceso constructivo. Tradicionalmente
es así como se ha visto la complejidad, y nuestra mejor herramienta para gestionarla ha sido la de
partir al elefante en pedacitos con el fin de contar con unidades más gestionables. Actualmente, en
un entorno más complejo y globalizado, la gestión de la complejidad requiere no solamente de un
análisis de la cantidad de trabajo a realizar sino de una reevaluación de la dificultad en todas sus
dimensiones, es decir, de la consideración de las complejidades en lo que se refiere a los tiempos, los
costos, las comunicaciones, la calidad, los recursos humanos, los riesgos y las adquisiciones. Dicho
de otro modo, de lo que se trata es de analizar la complejidad como un todo integrado de manera
que, a partir de un mayor conocimiento del proyecto, controlarla mejor y simplificarla mediante la
89
5ECTS .es
aplicación de técnicas avanzadas de gestión de proyectos. La simplificación de la complejidad se logra

principalmente mediante la creación de una sistemática de planificación y control del proyecto con
niveles de responsabilidad por área de trabajo y toma de decisiones efectiva.
Cada proyecto tiene su propia complejidad, difícilmente un proyecto es complejo en todas las
áreas de conocimiento. En ocasiones es posible ponderar cada área de conocimiento sobre la base
de su importancia en el marco del proyecto analizado. El conocimiento de los simplificadores de la
complejidad por área de conocimiento refuerza aún más la necesidad de planificar mejor para llevar
al proyecto a niveles de gestión controlada. La implementación de un sistema de medición de la
complejidad no solo permite identificar las áreas en que trabajar para simplificarla, sino que permite
también elegir al personal más idóneo para liderar el proyecto, de manera de asegurar una línea de
carrera para el personal de la organización.
El modelo de evaluación y simplificación se aplica a cualquier proyecto de cualquier industria y

puede ser enfatizado diferencialmente en el área de mayor relevancia para su proyecto. Cuanto más
complejo sea el proyecto, mayores serán las capacidades requeridas, y mayor deberá ser nuestra
apertura al manejo de la integración de la diversidad (de disciplinas, recursos, etc.) que está bajo
nuestra responsabilidad.
Todo lo anterior se pueden considerar mecanismos de simplificación de complejidad referidos a

metodologías de gestión de complejidad absoluta.
Existen alternativas de gestión, que realizan el planteamiento de análisis a partir de puntos de partida
más difusos: la gestión relativa se encarga de establecer una metodología que permite establecer la
forma en la que nos enfrentamos a situaciones en las que:
•• El objetivo no está perfectamente definido, porque no es posible o porque no sabemos hasta

dónde podemos llegar.
•• No hay una metodología o una forma conocida e inequívoca de hacer las cosas, es decir,
existen múltiples posibilidades.
•• En el caso de que se vayan a producir situaciones sobre las que no se tiene el control absoluto,
y que condicionan las alternativas a lo largo del proceso.
En resumen, cuando no está claro hasta dónde podemos o queremos llegar, la forma de hacerlo, o no
tenemos el control absoluto sobre el camino que se recorrerá.
Existen mecanismos y condicionantes que permiten gestionar de forma adecuada estas situaciones.
La gestión relativa establece las pautas para entender cómo se enfrentan a estas situaciones los
mejores gestores, y de esa forma mejorar la capacidad de afrontarlas. La gestión relativa trata de la
organización, del proceso como algo relativo, que depende del gestor y del entorno y descarta la
planificación como herramienta principal. No solo consiste en conseguir resultados predeterminados.
También busca provocar consecuencias. Y admite que se pueden establecer múltiples líneas de
actuación, que no necesitan estar coordinadas ni conectadas.
90
La gestión relativa avanza mediante un proceso continuo que evalúa lo que tratamos de alcanzar,
lo que hacemos para alcanzarlo y cómo lo hacemos, e introduce como elemento principal al gestor,
asume que es precisamente él quien provoca esa relatividad.
6.3. Project tracking y Project steering

Para finalizar, vamos a revisar dos términos muy importantes y usuales en la gestión de proyectos.
6.3.1. Project tracking
Este término hace referencia al mantenimiento continuo de la toma del pulso al proyecto durante
todo su ciclo de vida, midiendo el desempeño contra las estimaciones y realizando los ajustes que
sean necesarios.
Las metodologías populares actuales, como agile, promueven el Project tracking, específicamente
con respecto al alcance y la velocidad. Pero todos los miembros del equipo, en entornos ágiles y de
otro tipo, deben asegurarse de que están siguiendo las métricas correctas, que pueden incluir:
•• Tamaño acumulativo producido: puede incluir líneas de código fuente, historias ágiles,
características del producto, etc.
•• Esfuerzo mensual: el número de meses de la persona u horas de la persona pasadas.
•• Personal: el número de equivalentes a tiempo completo del tiempo de facturación del

proyecto.
•• Defectos: cuántos errores se descubren.
Los datos pueden ser recolectados semanal o mensualmente, dependiendo del cronograma del
proyecto, y, para obtener la mayor información posible, deben ser comparados con los estimados
originales del proyecto. Luego, los equipos deben tratar de averiguar por qué se están produciendo
desviaciones de las estimaciones. ¿Existe un desequilibrio entre la dirección y los promotores, lo que
conduce a una falta de personal cualificado necesario para completar el proyecto? ¿Ha introducido
el equipo nuevas herramientas, métodos o miembros del equipo? Puede llevar tiempo aumentar la
producción si se ha introducido alguna de estas variables.
6.3.2. Project Steering
Los Comités Directivos de los Proyectos (Project Steering) son reconocidos como elementos
estructurales importantes en la implementación de estos.
En particular, los comités directivos ejercen muchas influencias positivas en el éxito de los proyectos.
Al implicar a la alta dirección en las decisiones relativas a los proyectos, constituyen un componente
estructural para compensar una posible escasa autoridad de los gestores de proyectos. Además, los
comités pueden apoyar la coordinación entre las diferentes áreas funcionales de una organización.
91
5ECTS .es
Los comités de dirección también desempeñan un papel decisivo en la aplicación y el mantenimiento

de las normas, estructuras y políticas de gestión de proyectos.
Además de sus efectos positivos, los comités también pueden tener efectos negativos en la ejecución
de los proyectos al retrasar decisiones importantes de ejecución e instigar conflictos organizativos.
Estas influencias podrían derivarse de la discusión general centrada en la disfuncionalidad de los
consejos de administración.
Los miembros del Comité son responsables de las siguientes áreas:
Proporcionar Liderazgo y Dirección Transfronteriza
•• Supervisar los asuntos comerciales y estratégicos, y asesorar al equipo del proyecto sobre
aquellos asuntos que puedan presentar un riesgo para el proyecto o tener un impacto en la
lógica o el éxito del proyecto.
•• Resolver cuestiones fuera de la autoridad o el control de la gestión del proyecto, tales como el
establecimiento de prioridades, la toma de decisiones y los compromisos de recursos que
trascienden los límites de la organización y requieren el acuerdo de las partes interesadas de
alto nivel.
•• Asegurar la provisión de los recursos necesarios para la planificación y ejecución del proyecto.
•• Proporcionar apoyo de gestión, dirección y asesoramiento a la gestión del proyecto sobre la

base de la presentación de informes del proyecto al Comité.
•• Apoyar activa y abiertamente el proyecto y actuar como defensor de sus resultados.
•• Informar sobre el proyecto y su avance a la alta dirección y a los órganos de gobierno

pertinentes de la universidad.
Proporcionar gobernanza en la gestión de proyectos
•• Aprobar el estudio de viabilidad, el enfoque del proyecto y la metodología de gestión del

proyecto.
•• Establecer las facultades de delegación y los límites para la gestión del proyecto, en cuanto a
costo, tiempo, recursos, calidad y alcance.
•• Definir el perfil de riesgo aceptable y los umbrales de riesgo para el programa, basándose en
la estrategia de gestión de riesgos de UTAS y revisar los riesgos del proyecto.
•• Supervisar la gestión de los grupos de interés y los programas de gestión del cambio.
•• Supervisar el programa de garantía de calidad del proyecto.
•• Revisar y aprobar o rechazar planes de proyecto.
92
•• Resolver los asuntos de costo del proyecto, tiempo, riesgo, recursos, calidad y alcance
escalados al comité.
•• Supervisar el progreso del proyecto en relación con el estudio de viabilidad, los planes de
proyecto y las delegaciones aprobados.
•• Aprobar el cierre del proyecto.
Maximizar los beneficios del proyecto
•• Establecer cómo se definirán y medirán los beneficios.
•• Revisar y aprobar o rechazar la gestión del cambio y los planes de realización de beneficios.
•• Monitorear el progreso contra los planes aprobados.
•• Supervisar la alineación de los productos del proyecto para apoyar los resultados y beneficios
acordados.
•• Monitorear y facilitar la implementación del nuevo modelo operativo.
•• Supervisar la realización de los beneficios e informar a la alta dirección y a los órganos de

gobierno.
Roles
•• Entender las implicaciones estratégicas y los resultados del proyecto.
•• Apreciar el impacto del proyecto en las principales partes interesadas.
•• Proporcionar a las personas directamente implicadas en los proyectos orientación sobre

cuestiones empresariales.
•• Abordar cualquier asunto que tenga implicaciones importantes para el proyecto.
•• Asumir la responsabilidad de la estrategia del proyecto y de la realización global de los

beneficios del proyecto.
•• Delegar de autoridad para aprobar los cambios en el ámbito de aplicación tal como se han
definido.
93
5ECTS .es
94
Glosario
Agile
Describe un enfoque para el desarrollo de software bajo el cual los requerimientos y soluciones
evolucionan a través del esfuerzo colaborativo de equipos auto-organizados y multifuncionales y
sus clientes/usuarios finales. Aboga por la planificación adaptativa, el desarrollo evolutivo, la entrega
temprana y la mejora continua, alienta la respuesta rápida y flexible al cambio
CCPM
La gestión de proyectos por cadena crítica (CCPM por sus siglas en inglés) está basada en métodos y
algoritmos derivados de su Teoría de Restricciones. Si los recursos de un proyecto estuviesen siempre
disponibles en cantidades ilimitadas, entonces la cadena crítica de un proyecto sería igual a su ruta
crítica. En entornos de multiproyectos, o sea cuando simultáneamente se ejecutan o deben ejecutarse
varios proyectos, siempre existirán limitaciones en la disponibilidad sincronizada de los recursos, por
lo que la Cadena Crítica es siempre más efectiva que la tradicional ruta crítica.
CPM
Método de la ruta crítica o del camino crítico es un algoritmo utilizado para el cálculo de tiempos y
plazos en la planificación de proyectos. En administración y gestión de proyectos, una ruta crítica es
la secuencia de los elementos terminales de la red de proyectos con la mayor duración entre ellos,
determinando el tiempo más corto en el que es posible completar el proyecto. La duración de la ruta
crítica determina la duración del proyecto entero. Cualquier retraso en un elemento de la ruta crítica
afecta a la fecha de término planeada del proyecto, se dice que no hay holgura en la ruta crítica.
Extreme Programming
La programación extrema o eXtreme Programming es una metodología de desarrollo de la ingeniería
de software. Es el más destacado de los procesos ágiles de desarrollo de software. Los defensores de
la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e
incluso deseable del desarrollo de proyectos. Los valores de la programación extrema son: simplicidad,
comunicación, retroalimentación (feedback), coraje y respeto.
95
5ECTS .es
Guía PMBOK®
Identifica el subconjunto de fundamentos de gestión de proyectos que es "generalmente reconocido"
como una "buena práctica". Con "generalmente reconocido" se trata de referir a los conocimientos y
prácticas aplicables a la mayoría de los proyectos, la mayor parte del tiempo en la que hay un consenso
sobre su utilidad e importancia. Mientras que "buena práctica" implica que hay un acuerdo general
para la aplicación de los conocimientos, habilidades, herramientas y técnicas que pueden aumentar
las posibilidades de éxito a lo largo de muchos proyectos.
ISO 21500
Es una norma internacional desarrollada por la Organización Internacional de Normalización (ISO)
a partir de 2007 y publicada en 2012. Su objetivo era proporcionar orientación genérica, explicar
los principios básicos y lo que constituye una buena práctica en la gestión de proyectos. La norma
ISO 21500 fue desarrollada para ofrecer orientación sobre los conceptos y procesos de gestión de
proyectos con el objetivo de implementar procesos y mejores prácticas para mejorar el rendimiento
de la gestión de proyectos.
Kaizen
Es un proceso de mejora continua basado en acciones concretas, simples y poco onerosas, implica a
todos los trabajadores de una empresa, desde los directivos hasta los trabajadores de base.
Kanban
Es un sistema de información que controla de modo armónico la fabricación de los productos
necesarios en la cantidad y tiempo necesarios en cada uno de los procesos que tienen lugar tanto en el
interior de la fábrica, como entre distintas empresas. También se denomina “sistema de tarjetas”, pues
en su implementación más sencilla utiliza tarjetas que se pegan en los contenedores de materiales y se
despegan cuando estos contenedores son utilizados para asegurar la reposición de dichos materiales.
Las tarjetas actúan de testigo del proceso de producción.
Lean
Lean manufacturing es un modelo de gestión enfocado a la creación de flujo para poder entregar el
máximo valor para los clientes, utilizando para ello los mínimos recursos necesarios, es decir, ajustados.
Eliminando el despilfarro se mejora la calidad y se reducen el tiempo de producción y el coste.
Lean Thinking
Es una metodología de negocios que tiene como objetivo proporcionar una nueva forma de pensar
acerca de cómo organizar las actividades humanas para entregar más beneficios a la sociedad y valor
a los individuos, mientras se elimina el desperdicio. El objetivo del pensamiento lean es crear una
empresa que sostenga el crecimiento alineando la satisfacción del cliente con la satisfacción del
empleado, y que ofrezca productos o servicios innovadores de manera rentable a la vez que minimiza
los sobrecostes innecesarios para los clientes, los proveedores y el medio ambiente.
96
PERT
Las Técnicas de Revisión y Evaluación de Programas (o Proyectos), comúnmente referidas con la
abreviatura PERT (del inglés, Program Evaluation and Review Techniques), son técnicas estadística y
modelos para la administración y gestión de proyectos, inventado en 1957 por la Oficina de Proyectos
Especiales de la Marina de Guerra del Departamento de Defensa de EE.UU. PERT es básicamente un
método para analizar las tareas involucradas en completar un proyecto dado, especialmente el tiempo
para completar cada tarea e identificar el tiempo mínimo necesario para concluir el proyecto total.
PRINCE2
Propone una metodología de gestión de proyectos que cubre, mediante lo que se conoce como
Temáticas, la Calidad, el Cambio, la estructura de roles del proyecto (organización), los planes (cuánto,
cómo, cuándo), el Riesgo y el Progreso del proyecto, justificado por un Business Case (o estudio de
viabilidad) que debe ser revisado durante el ciclo de vida del proyecto y justificar en todo momento
el proyecto como consecución de los beneficios esperados.
SCRUM
Es un framework ágil para la gestión del trabajo con énfasis en el desarrollo de software. Está diseñado
para equipos de tres a nueve desarrolladores que dividen su trabajo en acciones que pueden
completarse dentro de iteraciones de tiempo, llamadas sprints (30 días o menos, más comúnmente
dos semanas), y hacer un seguimiento del progreso y volver a planificar en reuniones de 15 minutos,
llamadas scrums diarios.
TOC
La teoría de las limitaciones o teoría de restricciones fue creada por Eliyahu M. Goldratt, un doctor
en Física israelí. La libertad de elección implica responsabilidad. La esencia de la teoría de las
restricciones se basa en cinco puntos correlativos de aplicación: 1) Identificar las restricciones del
sistema. 2) Decidir cómo explotarlos. 3) Subordinar todo a la decisión anterior. 4) Superar la restricción
del sistema (elevar su capacidad). 5) Si en los pasos anteriores se ha roto una restricción, regresar al
paso (1) pero no permitir la inercia.
Waterfall
Es un enfoque de diseño secuencial relativamente lineal para ciertas áreas del diseño de ingeniería.
En el desarrollo de software tiende a estar entre los enfoques menos iterativos y flexibles, ya que
el progreso fluye en una sola dirección ("hacia abajo" como una cascada) a través de las fases de
concepción, iniciación, análisis, diseño, construcción, pruebas, despliegue y mantenimiento.
97
5ECTS .es
WBS
Una estructura de descomposición del trabajo (EDT), también conocida por su nombre en inglés
Work Breakdown Structure o WBS, es una herramienta que consiste en la descomposición jerárquica,
orientada al entregable del trabajo a ser ejecutado por el equipo de proyecto, para cumplir con
los objetivos de este y crear los entregables requeridos, donde cada nivel descendente de la EDT
representa una definición con un detalle incrementado del trabajo del proyecto.
WIP
El trabajo en curso (WIP) son los productos parcialmente terminados de una empresa a la espera de
su terminación y su eventual venta, o el valor de estos artículos. El término se utiliza en la gestión de
la producción y la cadena de suministro. La gestión óptima de la producción tiene como objetivo
minimizar el trabajo en curso. El trabajo en curso requiere espacio de almacenamiento, representa
capital ligado no disponible para la inversión y conlleva un riesgo inherente de vencimiento anticipado
de la vida útil de los productos.
98
Enlaces de interés
Norma ISO 21500
Ubicación de la norma ISO 21500 en el sitio de International Organization for Standardization (ISO),
que es el organismo responsable de la creación, actualización y publicación de la norma.
https://www.iso.org/standard/50003.html
PRINCE2
Ubicación de la metodología PRINCE2 en el sitio de AXELOS, que es el organismo responsable de la

creación, actualización y publicación de la metodología.
https://www.axelos.com/best-practice-solutions/prince2
Manifiesto Agile
Ubicación donde se muestra el manifiesto original que describe las bases sobre las que se ideó la
filosofía de desarrollo de proyectos de software mediante metodología Agile. Se puede encontrar
dicho manifiesto en multitud de idiomas.
http://www.agilemanifesto.org
SCRUM Guide
Ubicación donde se puede descargar la Guía Scrum. En este sitio es posible encontrar diferentes
recursos sobre SCRUM, así como la posibilidad de unirse a diferentes comunidades de discusión y
optar por diferentes certificaciones
https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
Lean
Sitio donde se puede encontrar una explicación sobre el concepto Lean, sus principios, así como
diferentes recursos y materiales para profundizar en dicho concepto
https://www.lean.org/WhatsLean/
99
5ECTS .es
100
Bibliografía
Referencias bibliográficas
Declaración de Interdependencia. (n.d.) Recuperado el (01/07/2018) de http://pmdoi.org/
Gasik, S. (2015). Comparison of ISO 21500 and PMBOK® Guide. Adaptado de http://www.sybena.pl/
dokumenty/ISO-21500-and-PMBoK-Guide.pdf
Managing Successful Projects with PRINCE2® 2009 Edition. (2009). (Primera edición). AXELOS.
Manifesto for Agile Software Development. (n.d.) Recuperado el (01/07/2018) de http://www.

agilemanifesto.org
Zandhuis, A. Stellingwerf, R. (2013). Interrelación entre roles y responsabilidades en ISO 21500.

[Figura] Adaptado de ISO21500: Guidance on project management – A Pocket Guide. (Primera Edición).
Van Haren Publishing
Bibliografía recomendada
A Guide to the Project Management Body of Knowledge. Sixth Edition (PMBOK Guide). (2018). Project
Management Institute.
Agile & Waterfall Methodologies – A Side-By-Side Comparison. (n.d.) Recuperado el (01/07/2018) de

http://www.base36.com/2012/12/agile-waterfallmethodologies-a-side-by-side-comparison/
Bolles, D. (2002). Building project management centers of excellence. AMACOM
Chin, C.M.M., Spowage, A.C., (2010) Defining & Classifying Project Management Methodologies. PM
World Today, Vol.(7)
Chin, C.M.M. & Spowage, A.C., (2012) Project Management Methodologies: A Comparative Analysis.
Journal for the Advancement of Performance Information and Value Vol. (4)
Cornell, U. (2008) Cornell Project Management Methodology. Recuperado el (01/07/2018) de http://

projectmanagement.cornell.edu/.
Gasik, S. (2015), Comparison of ISO 21500 and PMBOK® Guide. Recuperado de http://www.sybena.pl/
dokumenty/ISO-21500-and-PMBoK-Guide.pdf
Haughey, D. (n.d.) Breve historida sobre la administración de proyectos. Recuperado el (01/07/2018) de

http://www.liderdeproyecto.com/manual/breve_historia_sobre_la_administracion_de_proyectos.
html
101
5ECTS .es
Managing Successful Projects with PRINCE2® 2017 Edition. (Primera edición). (2017). AXELOS
Milosevic, D. P. Patanakul. (2005). Standardized project management may increase development project
success. (pp. 181-192) International Journal of Project Management
Monjurul H. (2013). Agile software development methodologies and how to apply them. Recuperado de
https://www.codeproject.com/Articles/604417/Agil
Principles of the Kanban Method. (2010). Recuperado de https://web.archive.org/

web/20140114161522/http://www.djaa.com/principles-kanban-method
Seymour, T. Hussein, S. (2014). The History Of Project Management. International. Journal of

Management & Information Systems. Vol.(18). 233.
What is Lean?. (n.d.) Recuperado el (01/07/2018) de https://www.lean.org/WhatsLean/
What is Scrum?. (n.d.) Recuperado el (01/07/2018) de https://www.scrumalliance.org/
Wideman, M. (2006). Project management methodologies. Recuperado el (01/07/2018) de http://www.

maxwideman.com/issacons/iac1013a/index.htm.
Zandhuis, A., Stellingwerf, R. (2013). ISO21500: Guidance on project management – A Pocket Guide
(Primera Edición). Van Haren Publishing
102
Agradecimientos
Autor
Departamento de Recursos para el Aprendizaje
D.ª Carmina Gabarda López
D.ª Cristina Ruiz Jiménez
D.ª Sara Segovia Martínez
Reservados todos los derechos VIU - 2018©.

14MMAN JJRuiz

Cargado por

Información del documentohacer clic para expandir la información del documentoProject management

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

14MMAN JJRuiz

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

14MMAN JJRuiz

Cargado por

Copyright:

Formatos disponibles

MÁSTER UNIVERSITARIO EN PROJECT MANAGEMENT

Módulo X. Metodologías tradicionales e innovadoras. Gestión de proyectos sectoriales

José Javier Ruíz Cobo

José Javier Ruíz Cobo

TEMA 1. METODOLOGÍAS DE GESTIÓN DE PROYECTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1. Metodologías, métodos, normas y procedimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2. Metodologías de Gestión Tradicionales y Ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3. Línea de tiempo de las metodologías de la gestión de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4. La normativa internacional: ISO 21500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

TEMA 2. MARCO DE PROCESOS: PRINCE2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2. Organización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3. Modelo de los 7 procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4. Procesos de PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.4.1. El Proceso de Puesta en Marcha del Proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.4.2. El Proceso de Dirección del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.4.3. El proceso de inicio de un proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4.4. El proceso de control de fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.5. El proceso de gestión de la entrega de productos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.4.6. El proceso de gestión de los límites de etapa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.4.7. El proceso de cierre del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.5. Comparativa PRINCE 2 vs. PMBOK® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

TEMA 3. METODOLOGÍAS AGILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1. Manifiesto por el desarrollo Agile de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2. Principios de Agile: el rol del líder de proyecto en Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3. Algunas técnicas y herramientas de Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3.4. Extreme Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4. Declaración de Interdependencia (DOI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

TEMA 4. SCRUM: EJEMPLO DE MARCO DE AGILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1. Historia de Scrum. Teoría de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2. Equipos de Scrum. Eventos de Scrum. Artefactos de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2.1. Equipos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2.2. Eventos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.3. Artefactos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3. Relación de Scrum con Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.1. Lean y la industria automotriz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3.2. Lean y la industria del Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

TEMA 5. LA GESTIÓN DE PROYECTOS EN DIFERENTES INDUSTRIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1. La gestión de proyectos en la industria de la construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2. La gestión de proyectos en la industria del software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

TEMA 6. DETERMINACIÓN DE LA MEJOR METODOLOGÍA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.1. Enfoques, metodologías y procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.2. Enfoques de management. Complejidad relativa y absoluta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.3. Project tracking y Project steering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.1. Project tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.3.2. Project Steering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

1.1. Metodologías, métodos, normas y procedimientos

•• Clarifica las metas y objetivos del proyecto.

•• Los procesos de trabajo son más eficientes y efectivos.

•• Permite mayor flexibilidad y adaptación de las lecciones aprendidas de proyecto a proyecto.

•• Mayor precisión en la planificación, identificación, gestión de riesgos, desafíos y complejidades.

•• Asegura un mayor grado de estandarización.

•• Roles claros e identificación de las responsabilidades, con lo que se mejora la comunicación.

•• Optimiza la calidad de los productos y entregables.

Los componentes de la metodología cubrirán:

ii. La selección de herramientas y técnicas para comunicar la entrega a la satisfacción de todos

iii. Un conjunto consolidado e integrado de mejores prácticas y valores apropiados de gestión de

A continuación, vamos a mostrar una forma de categorización de las metodologías de gestión de