Manual M1

EUROPEAN OPEN BUSINESS SCHOOL
MANUAL ACADÉMICO
La Dirección
de proyectos
en el S.XXI
EOBS.ES
M1: LA DIRECCIÓN DE PROYECTOS EN EL SXXI
INDICE
1. Introducción .......................................................................................................................... 3
2. La organización PMI® ............................................................................................................ 4
3. La Guía del PMBOK® ............................................................................................................ 10
4. Terminología común en Dirección de Proyectos ................................................................ 16
4.1. Dirección de Proyectos................................................................................................ 16
4.2. Proyecto, Programa y Portafolio ................................................................................. 16
4.3. Modelo de Madurez OPM3® ....................................................................................... 22
4.4. Restricciones Contrapuestas (Competing Constraints)............................................... 24
4.5. Supuestos (Assumptions) ............................................................................................ 26
4.6. Elaboración Progresiva ................................................................................................ 26
4.7. Oficina de Gestión de Proyectos o Programas (PMO) ................................................ 27
4.8. Sistema de Información para la Dirección de Proyectos ............................................ 28
4.9. Activos de los Procesos de la Organización (APO) ...................................................... 29
4.10. Factores Ambientales de la Empresa (FAE) ............................................................. 29
4.11. Ciclo de Vida de un Producto .................................................................................. 30
4.12. Fases de un Proyecto............................................................................................... 30
4.13. La Organización y la Cultura de la Organización Ejecutora ..................................... 31
4.14. La Estructura de la Organización Ejecutora............................................................. 32
5. Gestión de Proyectos 2.0 .................................................................................................... 35
6. Terminología del PMI® ........................................................................................................ 42
Anexo I: El Project Manager Ágil ................................................................................................. 45
European Open Business School 2

1. Introducción
Un proyecto no es solo un conjunto de tareas

relacionadas. Es una asignación que debe terminar sin
exceder un plazo y un presupuesto, cumpliendo unos
criterios de calidad.
En las organizaciones se distinguen

principalmente dos tipos de actividades: operaciones y
proyectos. Las operaciones consisten básicamente en
tareas repetitivas, la producción, la administración de
los recursos para "mantener las luces encendidas".
La gestión de proyectos hace posible los

cambios en las organizaciones. Una organización necesita gestionar proyectos cuando necesita
crear nuevos productos y servicios, ejecutar las propuestas del plan estratégico, expandirse a
nuevas regiones, a nuevos sectores, lanzar nuevas líneas de negocio, implantar cambios
tecnológicos, etc. Todo esto no se gestiona agrupando tareas, sino a través de un cuerpo de
conocimientos que básicamente permiten “proyectar” el futuro, para después conseguir los
objetivos de tiempo, coste, alcance y calidad. Aquí la figura clave es el director de proyectos
(project manager, en inglés), alguien encargado no de hacer las cosas, sino de hacer que las
cosas se hagan. El director de proyectos debe dominar muchas técnicas de gestión, pero sobre
todo ha de ser buen negociador, buen comunicador y buen líder.
La organización de gestión de proyectos más reconocida a nivel mundial es el Project

Management Institute (el PMI®), fundada en Pensilvania en 1969 y actualmente con unos
500.000 afiliados y presencia en casi 200 países. El PMI® defiende que la dirección de
proyectos es una profesión, que el director de proyectos debe cumplir un código deontológico
y que debe mantenerse permanentemente actualizado.
En un entorno empresarial cada día más competitivo y selectivo, en el que sólo

sobreviven las empresas que más rápidamente saben adaptarse a las necesidades cambiantes
de sus clientes, gestionar proyectos de forma óptima es irrenunciable, ya no sólo para seguir
en la brecha, sino para la generación de futuro y la sostenibilidad. Hasta ahora ha sido
importante optimizar las operaciones, y ya se ha recorrido un largo camino en este sentido
(especialización, factorías, globalización, herramientas, procesos, sistemas de calidad lean,
seis-sigma, etc.). Estos métodos han sido muy efectivos para aumentar la productividad y
reducir los costes operativos. Sin embargo, proyectos y operaciones son unidades de gestión
bien distintas. Según el PMI®, un proyecto es "una asignación temporal para crear un
producto, servicio o resultado único". Es decir, un proyecto es algo que nunca se ha hecho
antes igual, se realiza con un equipo de personas que la mayoría de las veces trabajan juntas
por primera vez, y que suele tener unas restricciones fuertes de alcance, tiempo, coste,
calidad, etc. Además, en un proyecto hay mucho en juego. Hay mucho interesado, gente que

gana o pierde con el proyecto. Hay muchas posibilidades de que un proyecto sea un éxito,
pero también hay muchas posibilidades de que sea un rotundo fracaso, que llegue a impactar
la imagen de la empresa, o incluso llegue a afectar al valor de la acción.
La buena noticia es que prácticamente todo lo que debe saber el director de proyectos
ya está inventado. Los grandes proyectos, como por ejemplo “llevar a un hombre a la luna” o
“remodelar el Canal de Panamá”, requieren la aplicación de toda una serie de procesos.
Cuando un director de proyectos asume un proyecto de estas características, debe imponer un
esquema de control basado en procesos. Si estos procesos no forman parte del cuerpo
normativo de la organización ejecutora, el director de proyectos tiene la responsabilidad de
crearlos para poder aplicarlos. Los directores de proyectos pueden agradecer al PMI® el
empeño y la constancia de más de 40 años formalizando todas las áreas de conocimiento
aplicables.
2. La organización PMI®
El Project Management Institute (PMI®) es la asociación profesional, sin ánimo de

lucro, para la gestión de proyectos más grande del mundo. Su objetivo principal es avanzar en
la práctica, ciencia y profesionalidad de la gestión de proyectos en el mundo, de forma
consciente y proactiva. Tiene como misión: Hacer que la dirección de proyectos sea
indispensable para alcanzar los resultados empresariales.
El PMI® se fundó en 1969 en el Instituto de Tecnología de Georgia por cinco

voluntarios: James Snyder, Gordon Davis, Eric Jennett, AE Engman, y Susan C. Gallagher. Su
objetivo inicial era establecer una organización donde los miembros pudieran compartir sus
experiencias en gestión de proyectos. En 1999, el PMI fue acreditado por la American National
Standards Institute (ANSI) como una Standard Development Organization (SDO).
Actualmente, el PMI® cuenta con unos 530.000 afiliados y tiene presencia en 208
países. Su sede central está en Pensilvania, EE.UU. PMI también tiene oficinas en Washington
DC y Pekín, así como los Centros Regionales de Servicios en Singapur, Bruselas, Bélgica y Nueva
Delhi y Bombay. Las delegaciones locales del PMI se denominan capítulos, existiendo más de
300 capítulos. Para afiliarse a un capítulo local, antes hay que ser miembro del PMI® global.
Hacerse miembro del PMI reporta una serie de beneficios importantes (acceso directo a
innumerables recursos para la dirección de proyectos). El PMI® promueve que todos los
profesionales de la gestión de proyectos utilicen las mejores prácticas locales y globales, se
relacionen entre sí y compartan recursos.

En la página web del PMI, www.pmi.org, hay muchas noticias e información

interesante para el público en general y muchos recursos disponibles para los socios:
En 1984, PMI introdujo el concepto de "la profesión" del Director de Proyectos, y creó
el título Profesional en Dirección de Proyectos o Project Management Professional (PMP®)
con sus requisitos de experiencia, conocimiento actualizado, titulación y código deontológico.
Como se verá en el siguiente capítulo, todo PMP® debe observar un código de conducta
profesional (debe ser responsable, respetuoso, equitativo y honesto).
Otras titulaciones que otorga el PMI® en la actualidad, son las siguientes:
 CAPM® Certified Associate in Project Management (Certificado en Dirección de Proyectos).

 PMI-ACP® PMI Agile Certified Practitioner (Practicante Certificado en Agile por el PMI).
 PMI-RPM® Risk Management Professional (Profesional en Gestión de Riesgos por el PMI).
 PMI-SP® Scheduling Professional (Profesional en Programación de Proyectos por el PMI).
 PgMP® Program Management Professional (Profesional en Dirección de Programas).
 PfMP® Portfolio Management Professional (Profesional en Dirección de Portafolios).
 OPM3® Organizatioanl Project Management Maturity Model Professional Certification (Certificado
Profesional en OPM3®).
El certificado PMP® es mundialmente reconocido. Para mantener el título, después de

aprobar el examen, cada PMP debe ganar 60 PDUs (Unidades de Desarrollo Profesional) cada
ciclo de 3 años, lo que supone un reciclaje continuo a través de diversas actividades como

tomar clases, asistir a congresos del PMI, contribuir a la investigación profesional o escribir y
publicar documentos sobre gestión de proyectos.
En la siguiente figura aparecen representadas las fases del proceso de certificación y

mantenimiento del título:
Solicitud del derecho a examen PMP® (Application Submission)
 Previamente a la solicitud, es preciso haber recibido formación presencial en gestión de proyectos

(no hay límite de antigüedad, puede ser formación recibida hace muchos años). Debe tener uno o
varios diplomas que acrediten al menos 35 horas de formación.
 Como primer paso, es recomendable asociarse al PMI®. Entre otras ventajas, hay beneficios
económicos:
- Por ser miembro del PMI®, la tasa de examen se reduce 150$ (de 555$ a 405$ el examen por
ordenador, de 400$ a 250$ el examen en papel). La afiliación cuesta 129$.
- Los miembros del PMI® pueden descargar una versión digital de la Guía del PMBOK®, con lo que
se pueden ahorrar los 69$ de la versión impresa.
 A través de la web del PMI®, pueden rellenarse los formularios de solicitud (pueden rellenarse
progresivamente, caducan a los 90 días).
 Los candidatos deben demostrar experiencia liderando proyectos durante los 8 años anteriores:
- Si es titulado medio, debe demostrar que ha trabajado en proyectos durante más de 60 meses. En
dichos proyectos, debe haberse dedicado como mínimo 7500 horas a tareas de dirección y
liderazgo.
- Si es titulado superior, debe demostrar que ha trabajado en proyectos durante más de 36 meses.
En dichos proyectos, debe haberse dedicado como mínimo 4500 horas a tareas de dirección y
liderazgo.
 Cuando se ha terminado de cumplimentar la solicitud, hay 5 días para hacer rectificaciones.
 Cuando la solicitud ya es firme, hay que pagar la tasa del examen (pago a través de la web del PMI).
 El PMI® revisará la solicitud y, si todo es correcto, contestará la aceptación antes de 5 días. A partir
de entonces, tiene 1 año para pasar el examen, pudiendo realizar el examen como máximo 3 veces

(repetir el examen cuesta 275$ a los miembros del PMI®). Si se suspende 3 veces en este período,
hay que esperar 1 año antes de volver a presentar la solicitud.
 El PMI® puede seleccionar su solicitud para realizar una auditoría, en cuyo caso, exigirá verificar la
información con las personas de contacto. Si no se supera la auditoría, PMI devuelve la tasa del
examen menos un coste administrativo de 100$.
Los formularios de solicitud son muy detallados. Por cada proyecto, además de la
información declarativa del mismo (datos del proyecto, organización ejecutora, datos de
contacto, etc.), es preciso indicar cuántas horas se han dedicado, como Director de Proyectos,
a las actividades de inicio, planificación, ejecución, control y cierre.
Preparación del Examen
De las preguntas del examen, un 25%, sobre conocimientos generales de gestión de

proyectos tiene su origen en otros libros distintos a la Guía del PMBOK®. El 75% restante son
preguntas directas sobre los contenidos la Guía del PMBOK®. Estas preguntas pueden ser de
dos tipos:
 Supuestos contextuales de gestión de proyectos: Aplicación directa de los conceptos.

 Preguntas sobre la estructura de los procesos de la Guía del PMBOK®. Las respuestas se deducen
reconociendo el proceso al que se refiere el supuesto y recordando el nombre concreto de la
entrada, salida, técnica o herramienta. En total, se contabilizan unas 400 entradas-salidas y unas 200
técnicas-herramientas. Mejor que la memorización, se recomienda la comprensión del significado de
cada elemento, esto suele ser suficiente para deducir la respuesta.
Existen cursos de preparación para el examen PMP. Estos cursos sirven para acreditar
las 35 horas preceptivas de formación en gestión de proyectos. No es obligatorio, aunque sí
conveniente, que los imparta un REP (Registered Education Provider), formador acreditado por
el PMI®.
Se recomienda leer 2 veces como mínimo la Guía del PMBOK® (en español o en inglés).
Hay que tener en cuenta, sin embargo, que PMBOK es un libro de referencia, más que una guía
de estudio. Los contenidos están organizados para responder dudas del profesional, más que
para aprender a dirigir proyectos de principio a fin.
El grado de confianza necesario para presentarse al examen con tranquilidad se

obtiene a partir de los tests. Hay muchos juegos de preguntas disponibles, gratuitos o de pago,
interactivos o en libros. Hay que planificar un esfuerzo constante para hacer tests, más intenso
a medida que se aproxima la fecha del examen. Es aconsejable reservarse un mínimo 2
horas/día x 2 semanas para practicar los tests antes del día del examen.

Examen
Hay un proveedor exclusivo del examen PMP a nivel mundial, llamado Prometric. La
fecha del examen se reserva a través de la web de Prometric (http://www.prometric.com). Es
recomendable reservar la fecha, como muy tarde, 3 meses antes de que expire el plazo de 1
año desde la aceptación de la solicitud del PMI. He aquí algunos datos sobre el examen PMP®.
 El examen consta de 200 preguntas tipo test. Cada pregunta tiene 4 opciones, sólo una es correcta.
Los fallos no penalizan, luego hay que contestar todas las preguntas. El PMI® no publica los criterios
para aprobar el examen (cuánto puntúan las preguntas, qué porcentaje de aciertos se requiere para
aprobar, etc.). Sí se sabe que de las 200 preguntas, hay 25 que no puntúan (el PMI® analiza cómo
funcionan para evaluar si en un futuro pasan a formar parte del examen).
 El tiempo asignado para hacer el examen es de 4 horas. Antes hay una explicación guiada de la
aplicación (unos 5’) y después una encuesta (unos 15’).
 El examen asistido por ordenador permite marcar las respuestas dudosas para su posterior revisión.
Si se solicita la ayuda de la traducción al español, las preguntas se muestran a la vez en inglés y en
español.
 Cuando se completa el examen, instantáneamente se sabe si se ha superado o no. Se recibe un
informe indicando las fortalezas y las debilidades en cada una de las áreas del examen. Las áreas del
examen y su porcentaje de preguntas son: Inicio (13%), Planificación (24%), Ejecución (30%); Control
(25%), Cierre (8%).

Requisitos de Certificación Continua (CCR)
Una vez que se ha obtenido el título, cada PMP debe seguir el programa CCR
(Continuing Certification Requirements), que obliga a mantener el certificado activo, mediante
la obtención de unidades de desarrollo profesional, o PDU (Professional Development Units).
Deben conseguirse, como mínimo, 60 PDUs cada 3 años.
El programa CCR es el instrumento que impone el PMI® para que los PMP® mejoren
continuamente su conocimiento, se mantengan informados y relacionados. El profesional que
posee la credencial debe demostrar su compromiso con la profesión mediante la práctica
continuada.
Los medios más habituales para conseguir PDUs son los siguientes:
 Asistencia a las reuniones del capítulo local.

 Autoestudio en gestión de proyectos.
 Impartición de cursos de gestión de proyectos.
 Asistencia a cursos de gestión de proyectos.
 Seminarios online de gestión de proyectos.
 Actividades de voluntariado en el capítulo local.

3. La Guía del PMBOK®
La Guía de los Fundamentos para la Dirección de Proyectos (A Guide to the Project

Management Body of Knowledge, PMBOK® Guide) se publicó por primera vez como
whitepaper por el PMI® en 1983, con el propósito de documentar y estandarizar las prácticas
comúnmente aceptadas en gestión de proyectos. Pronto se convirtió en un estándar ANSI que
se reedita cada cuatro años. La primera edición se publicó en 1996, y la última edición hasta
ahora, la sexta, fue publicada en septiembre de 2017. En la actualidad está traducida a 11
idiomas, además del inglés y se calcula que circulan más de 5,6 millones de copias en todo el
mundo. Hoy día podemos decir que se trata del estándar más globalmente reconocido en
todas las comunidades de dirección de proyectos.
La Guía del PMBOK® es un libro con trece capítulos, cuatro anexos y un glosario:
 Sección I – Marco Conceptual de la Dirección de Proyectos:

 Capítulo 1 – Introducción
 Capítulo 2 – El entorno en el que operan los proyectos
 Capítulo 3 – El rol del Director del Proyecto
 Sección II – Áreas de Conocimiento de la Dirección de Proyectos:
 Capítulo 4 – Gestión de la Integración del Proyecto
 Capítulo 5 – Gestión del Alcance del Proyecto
 Capítulo 6 – Gestión del Tiempo del Proyecto
 Capítulo 7 – Gestión de los Costes del Proyecto
 Capítulo 8 – Gestión de la Calidad del Proyecto
 Capítulo 9 – Gestión de los Recursos Humanos del Proyecto
 Capítulo 10 – Gestión de las Comunicaciones del Proyecto
 Capítulo 11 – Gestión de los Riesgos del Proyecto
 Capítulo 12 – Gestión de las Adquisiciones del Proyecto
 Capítulo 13 – Gestión de los Interesados del Proyecto
 Otras secciones importantes:
 Parte 2 – El Estándar para la Dirección de Proyectos
 Apéndices – Glosario, Resumen de Conceptos Clave, Consideraciones sobre Adaptación,
Herramientas y Técnicas, Entornos de Proyectos (ágiles, iterativos, adaptativos e híbridos)

Es importante recalcar que la Guía del PMBOK® es una guía, no una metodología. Es
más bien un metamodelo: dice qué hay que hacer, pero no cómo hay que hacerlo. La gestión
de cada proyecto es única, y es responsabilidad del director de proyectos, junto con su equipo
de gestión, decidir qué procesos aplican, cómo han de configurarse los entregables, cómo han
de procesarse los cambios, cómo hay que gestionar los riesgos, las comunicaciones, la calidad,
las adquisiciones, etc. Una metodología describe una forma determinada de realizar los
trabajos. La Guía del PMBOK® no prescribe la forma exacta de ejecutar los proyectos. Se trata
de un marco de referencia que se puede implantar con distintas metodologías de dirección de
proyectos (como metodologías ágiles, en cascada, PRINCE2, etc.).
El cuerpo principal de la guía se centra en el desarrollo de las 10 áreas de conocimiento:

Por otra parte, en cualquier proyecto se reconocen 5 grupos de procesos:
Inicio Definir el nuevo proyecto o fase mediante la obtención de la autorización para

comenzar.
Planificación Establecer el alcance del proyecto, refinar los objetivos y definir el curso de acción
requerido para alcanzar los objetivos propuestos.
Ejecución Completar el trabajo definido en el plan para la dirección del proyecto a fin de
satisfacer las especificaciones del mismo.
Monitorización Monitorizar, analizar y regular el progreso y el desempeño del proyecto, para
y Control identificar áreas en las que el plan requiera cambios y para iniciar los cambios
correspondientes.
Cierre Finalizar todas las actividades a fin de cerrar formalmente el proyecto o una fase
del mismo.
Esta forma de agrupar los procesos que propone la Guía del PMBOK® nos habla de
especialización y objetivos de gestión a lo largo de un proyecto. Mientras que las áreas de
conocimiento se refieren a qué hay que saber para gestionar cualquier proyecto, los grupos de
procesos dicen qué hay que obtener en todo proyecto o fase:
 En el inicio hay que hacer que la organización tenga un debate estratégico sobre si el proyecto está
alineado, es oportuno y es más prioritario que otros, pues no habrá
recursos para ejecutar todas las iniciativas.
 En la planificación hay que “pensar antes de hacer”, hay que imaginar
el proyecto hasta donde alcance la información disponible y tratar de
cerrar una planificación completa (donde no se sabe todavía, se toman
supuestos).
 Cuando el proyecto está en marcha, hay que distinguir la ejecución
(hacer que las cosas se hagan, producir entregables de forma eficiente)
del control (separarse del trabajo para opinar y juzgar si es factible
cumplir los objetivos, y tomar acciones para corregir o mejorar el
desempeño).
 Finalmente, los proyectos se cierran, lo que quizá sea lo más
distintivo de la gestión de proyectos frente a la gestión de operaciones. Al director del proyecto le
gusta decir adiós: se asegura de que todo está terminado y entonces procede a cerrar formalmente
el proyecto para transferir los resultados a la siguiente fase, al cliente, o a la unidad organizativa
correspondiente.
Obsérvese que los grupos de procesos son consistentes con el modelo de mejora continua PDCA
de Deming: Plan = planificación; Do = ejecución; Check, Act = control.

Según la Guía del PMBOK®, un proyecto completo se gestiona siguiendo estos grupos
de procesos desde su inicio (cuando aún no se ha aprobado) hasta su cierre (cuando todo está
terminado y hay que formalizar su conclusión). Cuando un proyecto se divide en fases
secuenciales, los procesos de la Guía del PMBOK® se pueden aplicar de igual manera, es decir:
al comienzo de la primera fase habrá que justificar detalladamente el proyecto; y cuando
termine esa fase habrá que cerrarla oficialmente para volver a pensar si se dan las condiciones
para continuar con el lanzamiento de la siguiente fase. El proyecto podría cancelarse si ya no
es oportuno. Si se aprueba, habría que elaborar el acta de constitución para iniciar la siguiente
fase.
Es decir, en todo proyecto o fase se puede plantear la gestión siguiendo los grupos de
inicio, planificación, ejecución, control y cierre. El acrónimo IPECC sirve para recordar estos
cinco grandes grupos de gestión.
Por último, hay que tener en cuenta que los grupos de procesos no son secuenciales
necesariamente (no confundir grupos de procesos y fases del proyecto):
 Los grupos de inicio y cierre tendrán lugar al principio y final del proyecto o fase, respectivamente.
 Las tareas de planificación (estimación de tiempos, costes, recursos, riesgos, etc.) suelen mezclarse
con las de inicio (mientras se está decidiendo si el proyecto se realiza o no). A veces se decide que
no se aprueba un proyecto porque resulta demasiado largo, caro, incierto, no hay recursos
disponibles, no pueden subcontratarse algunas partes necesarias, etc.
 Algunas actividades del proyecto pueden comenzar su ejecución (y control) aun cuando no se ha
completado la planificación. Algunos proyectos necesitan realizar planes de negocio, estudios de
viabilidad, pruebas de concepto, etc., para saber si son factibles o no.
 La planificación puede refinarse a medida que se conozcan mejor los detalles del proyecto
(elaboración progresiva).
 La monitorización y el control tienen lugar durante todo el proyecto, desde su inicio hasta su fin.

Los 49 procesos descritos en la Guía del PMBOK® pueden representarse resumidamente en el

siguiente mapa de procesos, en inglés y en español, respectivamente:

Un elemento importante en la gestión de cualquier proyecto es la documentación. La Guía del

PMBOK® distingue entre los documentos del proyecto, que asisten al director del proyecto en
la gestión del proyecto, y el plan para la dirección del proyecto, que se compone de una serie
de planes secundarios.

4. Terminología común en Dirección de Proyectos

4.1. Dirección de Proyectos
La Guía del PMBOK® define la dirección de proyectos como: la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para
cumplir con los requisitos del mismo. Dirigir un proyecto por lo general incluye, entre otros
aspectos:
 Identificar requisitos.
 Abordar las diversas necesidades, inquietudes y expectativas de los interesados en la planificación y
la ejecución del proyecto.
 Establecer, mantener y realizar comunicaciones activas, eficaces y de naturaleza colaborativa entre
los interesados.
 Gestionar a los interesados para cumplir los requisitos del proyecto y generar los entregables del
mismo.
 Equilibrar las restricciones contrapuestas del proyecto que incluyen, entre otras:
- El alcance.
- La calidad.
- El cronograma.
- El presupuesto.
- Los recursos.
- Los riesgos.
4.2. Proyecto, Programa y Portafolio

La Guía del PMBOK® proporciona las siguientes definiciones de proyecto, programa y
portafolio:
 Proyecto: Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.
 Programa: Grupo de proyectos, subprogramas y actividades de programas relacionados cuya
gestión se realiza de manera coordinada para obtener beneficios que no se obtendrían si se
gestionaran en forma individual. Pueden incluir operaciones fuera del alcance de los proyectos.

 Portafolio (Cartera): Proyectos, programas, subportafolios y operaciones gestionados como un

grupo para alcanzar los objetivos estratégicos. Los componentes de la cartera no tienen por qué ser
interdependientes o estar directamente relacionados.

En cada caso, los objetivos de gestión son diferentes, como resume el siguiente cuadro
comparativo:
“do the thing right” “do the right thing”
PROYECTO PROGRAMA PORTAFOLIO

Project Manager (PM) Program Manager (PgM) Portfolio Manager (PfM)
Alcance Los proyectos tienen objetivos Los programas tienen un alcance Los portafolios tienen un alcance que
definidos. El alcance se elabora mayor y proporcionan beneficios más varía según los objetivos estratégicos
gradualmente a lo largo del ciclo de importantes. de la organización.
vida del proyecto.
Cambios Los PM prevén cambios e Los PgM deben esperar cambios Los PfM monitorizan constantemente
implementan procesos para controlar generados tanto a nivel interno como los cambios en un entorno interno y
los cambios externo del programa, y estar externo más amplio.
preparados para gestionarlos.
Planificación Los PM transforman gradualmente la Los PgM desarrollan el plan general Los PfM crean y mantienen los
información de alto nivel en planes del programa y crean planes de alto procesos y la comunicación necesaria
detallados a lo largo del ciclo de vida. nivel para guiar la planificación relacionada con el portafolio general.
detallada a nivel de componentes.
Dirección/ Los PM dirigen al equipo del proyecto Los PgM dirigen al personal del Los PfM pueden dirigir o coordinar al
Gestión a fin de cumplir con los objetivos del programa y a los directores del personal de gestión del portafolio y
mismo. proyecto. Brindan visión y liderazgo tienen la responsabilidad de informar
global. al portafolio general.
Éxito El éxito de un proyecto se mide por la El éxito se mide por el grado en el El éxito se mide en términos del
calidad del producto y del proyecto, que el programa satisface las rendimiento de la inversión y de los
la puntualidad, el cumplimiento con necesidades y beneficios que le beneficios del portafolio.
el presupuesto y el grado de dieron origen.
satisfacción del cliente.
Seguimiento Los PM monitorizan y controlan el Los PgM monitorizan el progreso de Los PfM realizan el seguimiento de
trabajo que consiste en obtener los los componentes de programas a fin los cambios estratégicos y asignación
productos, servicios o resultados para de asegurar que se cumpla con los de recursos, resultados de
los cuales el proyecto fue objetivos globales, cronogramas, rendimiento y riesgos del portafolio.
emprendido. presupuesto y beneficios del
programa.
A nivel proyecto, principalmente se persigue que se haga bien lo que se tiene que
hacer (sin desviaciones en plazos y costes), a nivel programa y cartera, se trata de elegir bien
qué hay que hacer y qué no hay que hacer (en términos de estrategia, rentabilidad y nuevas
capacidades).

Ejercicio 1. En las siguientes frases, indique si se trata de un proyecto, un programa o

un portafolio.
1 El éxito se mide por ausencia de retrasos y sobrecostes, calidad del producto y satisfacción del cliente.
2 El éxito se mide por el rendimiento agregado de los componentes.
3 El éxito se mide por el grado en que satisface las necesidades y entrega los beneficios.
4 El responsable gestiona al equipo del para conseguir los objetivos de plazo, coste y alcance.
5 El responsable gestiona a su equipo y a los Project Managers, aportando visión de liderazgo global.
6 El seguimiento se basa en el control del rendimiento agregado y KPIs.
El seguimiento se basa en el control del progreso de los componentes para asegurar los objetivos globales, plazos, costes y
7
beneficios consolidados.
8 El seguimiento se basa en el control de la producción de productos, servicios o resultados.
9 Tiene un alcance amplio orientado a la entrega de beneficios significativos para el negocio.
10 Tiene un alcance de negocio que cambia con los objetivos estratégicos de la organización.
11 Tiene un alcance que se elabora progresivamente durante todo el ciclo de vida.
12 El responsable espera cambios: Implanta procesos para mantenerlos gestionados y controlados.
El responsable monitoriza continuamente los cambios en un marco amplio orientado a la estrategia de la organización y al
13
negocio.
14 El responsable espera cambios dentro y fuera de su alcance: Se prepara para gestionarlos.
15 El responsable traslada progresivamente la información de alto nivel a planes detallados durante todo el ciclo de vida.
16 El responsable desarrolla el plan completo y crea planes de alto nivel para orientar los planes detallados.
17 El responsable crea y mantiene los procesos y comunicación necesarios sobre la planificación.
Solución: Proyecto: 1, 4, 8, 11, 12 y 15. Programa: 3, 5, 7, 9, 14 y 16. Portafolio: 2, 6, 10, 13 y

17.
Ejercicio 2. Usted acaba de ser contratado como Program Manager por una empresa
multinacional del sector turístico. Esta empresa está basada en España y tiene operaciones en
Latinoamérica, Reino Unido, Europa Central, EE.UU. y Asia. El departamento financiero ha
unificado recientemente los procesos financieros globales (Global Finance Processes:
Facturación, Cuentas a Cobrar, Cuentas a Pagar, Tesorería, Libro Mayor y Soporte Financiero).
Una de las líneas más importantes del plan estratégico 2013-2015 es centralizar y consolidar
las actividades financieras en 6 Centros de Servicios Compartidos (SSC -Shared Service Centers),
uno por región. Después de aprobar el correspondiente business case, se ha establecido un
programa denominado "GFP-SSC transition program" para centralizar progresivamente las
operaciones financieras. Este programa tiene inicialmente 23 componentes, entre proyectos y
operaciones, si bien este número fluctuará a medida que unos proyectos terminen y otros
comiencen. En el roadmap previsto a 3 años, en los primeros 6 meses se tiene el objetivo de
centralizar la facturación de todos los países en el SSC de España, y después se quiere hacer la
transición de cada centro en fases de 6 meses, empezando por el de Latinoamérica, ubicado en

República Dominicana. Usted contará con un equipo núcleo de 5 personas que deberá
contratar usted mismo. Su equipo deberá desplazarse a distintos países para coordinar cada
una de las fases del programa y supervisar a los Project Managers que dirijan los diferentes
proyectos.
Esta empresa tiene una fuerte cultura de gestión de proyectos, con alto número de PMPs en
los diferentes países, herramientas corporativas, procesos corporativos, órganos de gobierno,
etc. Sin embargo, no está acostumbrada a gestionar programas. De hecho, este es el primer
programa que se ejecuta y usted es el primer Program Manager. En el comité de dirección del
programa, que acaba de constituirse, hay dos altos ejecutivos que son escépticos sobre la
gestión por programas, ya que piensan que introduce más costes generales y no ven valor
añadido sobre la gestión por proyectos.
1. Uno de los ejecutivos escépticos con la gestión por programas quiere que vaya a verle mañana a su
despacho a primera hora. Quiere que usted le explique brevemente por qué hay que gestionar este
conjunto de proyectos como un programa y no como una suma de proyectos. ¿Qué argumentos
usará para convencerle?
2. Para formar parte de su Program Management Team, usted tiene que entrevistar a unos candidatos
que pueden ser internos o externos. ¿Qué habilidades juzgaría necesarias para formar parte de su
equipo?
3. De las diferentes áreas de gestión de su programa (gestión de beneficios, gobierno, gestión de
interesados y gestión estratégica), ¿cuál juzga más importante?
Solución:
1. El programa para este caso es necesario ya que se están desarrollando varios proyectos en
diferentes partes del mundo, lo que hace necesario la centralización de procesos tan importantes
para cualquier organización como son los resultados financieros". El mayor beneficio de llevar a
cabo este programa es la facilidad que se va a tener en la comunicación entre los diferentes países y
se dispondrá de información al instante de todas las regiones, garantizar una buena sincronización
entre las dependencias entre los proyectos de este, además que también puede permitir un uso mas
eficiente de los recursos mediante el establecimiento de prioridades y la integración de los
proyectos.
2. Aparte de las habilidades genéricas de gestión, en este programa habrá que tener muy en cuenta el
área de aplicación, es decir, el conocimiento específico sobre los procedimientos financieros del
sector.
3. Los programas siempre dan más importancia a la gestión de beneficios, para eso se crean, para dar
más beneficios que cada proyecto por separado.

Ejercicio 3. Su portafolio tiene 5 componentes, con los siguientes datos de presupuesto y

valor relativo:
 Proyecto Nº1: presupuesto 25.000 €; valor 30%

El proyecto 5 ya se está ejecutando, pero sobre el resto se puede tomar la decisión

sobre si aprobarlos, rechazarlos o aplazarlos. Debido a la política actual de recortes en su
empresa, le reducen a la mitad el presupuesto necesario para ejecutar toda la cartera. ¿Cuál
sería escenario de selección óptimo?
Solución:
Las herramientas de gestión de portafolios (Project Portfolio Management –PPM-)

permiten representar los portafolios con gráficas de escenarios de selección, con ayudas
visuales para decidir si seleccionar o no determinados componentes. De acuerdo a los datos
del enunciado, el proyecto 5 es obligatorio (forced in). Imaginemos un escenario en el que se
decide cancelar el proyecto 4 (forced out), no seleccionar el proyecto 2 y sí seleccionar los
proyectos 1 y 3.
Para justificar a la alta dirección que esta puede ser la decisión óptima, es muy útil
representar la gráfica de la frontera eficiente, que establece el límite óptimo superior de más
valor agregado con menor presupuesto dada cualquier combinación de proyectos. Por
definición, ninguna combinación de proyectos puede caer por encima de la frontera eficiente.
Como puede apreciarse en la figura, el 100% del valor se consigue con un presupuesto de
161k€, y si se no se selecciona ningún proyecto, el valor agregado es cero. En la figura se puede

observar que la selección de los proyectos 1, 3 y 5, con un presupuesto total de 79k€ y un valor
agregado del 64%, es muy justificable por estar cerca de la frontera eficiente, si bien
teóricamente con el mismo presupuesto se podría obtener un valor agregado de hasta un 77%,
y el mismo valor agregado se podría obtener con un menor presupuesto de 55k€.
4.3. Modelo de Madurez OPM3®
El modelo de madurez en gestión de proyectos corporativa propuesto por el PMI® se

denomina OPM3® (Organizational Project Management Maturity Model). Contiene un
conjunto de preguntas para determinar la madurez en gestión de proyectos, programas y
portafolios. A partir de los resultados, se propone un roadmap de mejora con objetivos muy
detallados y criterios de éxito (600 mejores prácticas, 2100 capacidades, 2200 indicadores
clave de desempeño). Las evaluaciones de madurez pueden ser realizadas oficialmente por
personas con la titulación Certificado Profesional en OPM3®.

Interesados (Stakeholders)
Son personas y organizaciones (e.g. clientes, patrocinadores, organización ejecutora,

público), involucrados activamente en el proyecto, o cuyos intereses pueden verse afectados
de manera positiva o negativa1 por la ejecución o conclusión del proyecto. También pueden
influir sobre el proyecto y sus entregables. Es una tarea crítica del director del proyecto el
transformar (combinar) las expectativas de los diversos
interesados en un conjunto coherente y manejable,
favorable a los objetivos y las necesidades del proyecto.
Los interesados presentes en los proyectos son, entre
otros:
 El Director del Proyecto (Project Manager).

 El Cliente: Interlocutor directo para el equipo de dirección
del proyecto, entre otras funciones, participa en las
reuniones de seguimiento, da el visto bueno en la
verificación de los entregables, etc.
 El usuario: Personas que usarán el producto del proyecto.
 La organización ejecutora: La empresa para la que trabaja el equipo del proyecto.
 Los miembros del equipo del proyecto: Las personas que realizan el trabajo.
 El equipo de dirección del proyecto: El grupo que gestiona la ejecución del proyecto, entre los que
se encuentra el Director del Proyecto y algunos miembros destacados del equipo. Es responsable de
identificar a los diferentes interesados, sus requerimientos, expectativas y objetivos, que suelen ser
2
diferentes .
 El patrocinador: Primer interesado en la conclusión exitosa del proyecto. Persona o grupo que
asigna el presupuesto al proyecto y lo autoriza.
 Influyentes: Personas no directamente relacionadas con el proyecto pero que pueden impactar en
sus resultados.
 La Oficina de Gestión de Proyectos o Programas (PMO).
1
Puede haber interesados positivos (como el patrocinador) y también negativos (e.g. los
ecologistas que quieren detener una proyecto de construcción).
2
Por ejemplo, el departamento financiero quiere minimizar los costes, el departamento
de marketing querrá el mayor número de funcionalidades y el departamento de Informática
querrá la última tecnología.

4.4. Restricciones Contrapuestas (Competing

Constraints)
Se denomina restricción a cualquier circunstancia que limite las opciones del equipo
de dirección del proyecto. Cualquier restricción aplicable, ya sea interna o externa, puede
afectar al desempeño del proyecto o de un proceso. Por ejemplo, una restricción del
cronograma suele presentarse bajo la forma de fechas fijas impuestas. Tienen carácter
contrapuesto porque variar cualquier restricción afecta al menos en otra. Por ejemplo, reducir
el plazo implica aumentar el presupuesto.
En versiones anteriores de la guía PMBOK se citaba “la triple restricción” plazo,

presupuesto y alcance3. La versión actual amplía a 6 las restricciones típicas (además de las 3
anteriores: recursos, riesgos y calidad4) y deja abierta la posibilidad de que sean aplicables
otras, dependiendo de las características del proyecto (como pueden ser la satisfacción del
cliente, las dependencias con otros proyectos, etc.)
Estas restricciones de gestión son contrapuestas, en el sentido de que si se altera una

de ellas, generalmente impacta en las otras. He aquí algunos ejemplos:
 Alcance: Si el equipo de dirección del proyecto decide aumentar el alcance (hay que generar 10
entregables más, por ejemplo), supondrá más presupuesto y más plazo. Si por ejemplo el plazo no
puede aumentarse, podría afectar a la calidad de los entregables, porque hay menos tiempo para
hacerlos del que originalmente se planificó.
 Plazo: Si hay que reducir el plazo, como consecuencia habrá que reducir el alcance. Si el plazo
aumenta (como consecuencia de un mayor alcance), habrá que aumentar el presupuesto.
3
Es decir, hay que entregar antes de unas fechas, sin rebasar unos costes y con una
determinada funcionalidad.
4
No se dispone de recursos ilimitados, no se puede entregar productos defectuosos, no
se deben ignorar posibles problemas identificados.

 Presupuesto: Si el presupuesto se reduce, la consecuencia es reducir el alcance. Si no se reduce el

alcance, se penaliza la calidad. Si el presupuesto aumenta (porque aumenta el alcance), también
habrá que aumentar el plazo.
 Recursos (materiales y humanos): A mayor disponibilidad de recursos, menor plazo (y coste).
 Riesgos: Si una persona clave trabaja a la vez en varios proyectos, y uno se retrasa, es muy probable
que el otro también se retrase. En general, si los riesgos no se consideran anticipadamente, pueden
afectar al alcance, presupuesto, plazo, calidad, etc. Responder a los riesgos limita las opciones de
gestión.

4.5. Supuestos (Assumptions)
Los supuestos son factores que, para los propósitos de la planificación, se

consideran verdaderos, reales o ciertos, sin necesidad de contar con
evidencia o demostración.
En los proyectos, sobre todo al principio, hay demasiadas

incógnitas, tantas que parece imposible estimar detalladamente plazos,
presupuestos, recursos, etc. Para completar una planificación realista,
donde no sabemos, tomamos supuestos. Por ejemplo: “suponiendo que el
proveedor entrega el hardware tal fecha, suponiendo que los técnicos
tienen esta tasa de productividad, suponiendo que el cliente asigna a este
personal clave que necesito para validar los requisitos a partir de tal fecha,
suponiendo… Entonces puedo estimar como fecha de entrega entre el 20
de abril y el 15 de mayo, con una confianza del 65%”
Estos supuestos han de monitorizarse continuamente, con el fin de mantener

actualizada la planificación a medida que vamos descubriendo nueva información del
proyecto. Normalmente se utiliza un registro de supuestos (assumption log).
4.6. Elaboración Progresiva
A veces se denomina también planificación gradual, progressive elaboration, rolling

wave planning, etc. Es una técnica que consiste en mejorar y agregar detalles continuamente a
un plan en la medida en que se cuente con información más detallada y específica y con
estimaciones más precisas, a medida que el proyecto avanza. De ese modo se podrán producir
planes más precisos y completos que sean el resultado de las reiteraciones sucesivas del
proceso de planificación.
Para practicar la elaboración progresiva, se pueden distinguir en el alcance aquellos

paquetes de trabajos sobre los que aún no se tienen suficientes detalles, que esperamos
descubrir más adelante (p.ej., dentro de 2 meses, en un proyecto de un año). A estos paquetes
no los llamamos paquetes de trabajo, sino paquetes de planificación. Cuando se conocen los
detalles, estos paquetes de planificación se descomponen en paquetes de trabajo. En un
cronograma no suelen representarse dichos los paquetes de planificación (o bien pueden
representarse como tareas resumen con fechas estimativas, sin descomposición en actividades
detalladas).

4.7. Oficina de Gestión de Proyectos o Programas (PMO)
Un cuerpo o entidad de la organización que tiene varias responsabilidades asignadas

con relación a la dirección centralizada y coordinada de aquellos proyectos que se encuentran
bajo su jurisdicción. Las responsabilidades de una oficina de dirección de proyectos pueden
variar, desde realizar funciones de apoyo para la dirección de proyectos hasta ser realmente
los responsables de la dirección de un proyecto.
Puede ser de varios tipos:
 PMO de apoyo (supportive PMO):

- Desempeñan un rol consultivo de cara a los proyectos,
suministrando plantillas, mejores prácticas, capacitación,
acceso a la información y lecciones aprendidas de otros
proyectos.
- Sirve como repositorio para los proyectos.
 PMO de control (controlling PMO):
- Proporcionan soporte y exigen cumplimiento por diferentes
medios.
- Este cumplimiento puede implicar la adopción de marcos o metodologías de dirección de
proyectos a través de plantillas, formularios y herramientas específicos, o conformidad en términos
de gobierno.
 PMO directiva (directive PMO):
- Ejerce n el control de los proyectos asumiendo la propia dirección de los mismos.

4.8. Sistema de Información para la Dirección de

Proyectos
El Sistema de Información para la Dirección de

Proyectos (Project Management Information System –PMIS-)
es un sistema de información compuesto por herramientas y
técnicas utilizado para recopilar, integrar y difundir los
resultados de los procesos de dirección de proyectos. Se usa
para respaldar todos los aspectos del proyecto desde el
comienzo hasta el cierre, y puede incluir tanto sistemas
manuales como automatizados.
Un término relacionado con el PMIS es el Sistema de

Gestión de Proyectos: conjunto de herramientas, tecnología,
metodología, recursos y procedimientos que se usa para
realizar un proyecto. La PMO también lo usa.
Muchas veces se confunden estos dos términos entre

sí, y también con las herramientas corporativas de gestión de
portafolios (Project Portfolio Management –PPM-). Hay que saber que un Sistema de
Información para la Dirección de Proyectos no se compone solo de herramientas. Las
herramientas de gestión de proyectos están experimentando un notable crecimiento. En la
actualidad hay muchas herramientas a disposición del equipo de dirección del proyecto. Por
otro lado, ya no se habla solo de herramientas de gestión de proyectos, sino que cada día es
más frecuente ver cómo estas herramientas se especializan en tareas (task management tools,
como Asana), documentos (Enterprise Content Management tools –ECM-, como Dropbox,
Google Drive, etc.), herramientas para colaborar en línea por internet (como Skype,
GoToMeeting, etc.)

4.9. Activos de los Procesos de la Organización (APO)
Los Activos de los Procesos de la Organización, que se abrevia como APO (en inglés se
dice Organizational Process Assets –OPA-) son los planes, procesos, políticas, procedimientos y
bases de conocimiento específicos de la organización ejecutora. Abarcan planes, políticas,
procedimientos y directrices, ya sean formales o informales.
 Pueden referirse a procesos y procedimientos relativos a los

procesos de gestión de los grupos de inicio, planificación, ejecución,
control y cierre.
 También abarcan las bases de conocimiento de la organización,
como las lecciones aprendidas y la información histórica. En su más
amplio sentido, cualquier documento generado en cualquier
proyecto (actas, informes, planes, cronogramas, plantillas, bases para
las estimaciones, presentaciones finales, comunicaciones, etc.) es
susceptible de poder reutilizarse como APO.
4.10. Factores Ambientales de la Empresa (FAE)
Los Factores Ambientales de la Empresa, que se abrevia como FAE (en inglés se dice
Enterprise Environmental Factors –EEF-) hacen referencia a condiciones que no están bajo el
control del equipo del proyecto y que influyen, restringen o dirigen el proyecto. Entre los
factores ambientales de la empresa, se incluyen:
 La cultura, estructura y gobierno de la organización.

 La distribución geográfica de instalaciones y recursos.
 Los estándares de la industria o gubernamentales.
 Las infraestructuras.
 Los recursos humanos existentes.
 La administración de personal.
 Los sistemas de autorización de trabajos de la empresa.
 Las condiciones del mercado.
 La tolerancia al riesgo por parte de los interesados.
 El clima político.
 Los canales de comunicación establecidos en la organización.
 Las bases de datos comerciales.
 El sistema de información para la dirección de proyectos.

4.11. Ciclo de Vida de un Producto
El ciclo de vida de un proyecto es generalmente parte del ciclo de vida de un producto.

El ciclo de vida de un producto abarca desde su concepción hasta su retirada del mercado.
Generalmente comienza con un plan de negocio, sigue el proyecto que genera el producto.
Después de finalizar el proyecto comienza la fase de operación y soporte del producto.
4.12. Fases de un Proyecto
El ciclo de vida de un proyecto abarca las fases necesarias en un proyecto desde su

principio a su fin. Un proyecto generalmente se divide en fases. Cada fase puede representarse
así:
El ciclo de vida de un proyecto puede verse como una sucesión de fases. Cada fase
concluye cuando se revisan y aprueban sus entregables. Un entregable es un producto que
debe poder medirse y verificarse. Estos hitos de revisión al final de cada fase se denominan
"stage gates", "phase exits" ó "kill points". Cuando se aprueba la finalización de una fase, esto
no significa necesariamente que automáticamente comience la fase siguiente. Debe obtenerse
antes otra aprobación y ha de celebrarse otra reunión de lanzamiento. La transición entre una
fase y la siguiente supone la aprobación de ciertos entregables.

Generalmente, en cada fase se define:
 El trabajo que ha de realizarse.

 Los hitos de entrega.
 Los recursos necesarios.
 Los mecanismos de control a utilizar.
En cada fase, el coste suele ser bajo al principio, alto en la parte intermedia y vuelve a bajar al
final:
 Al comienzo, se realiza la planificación que no genera muchos costes.

 Después viene la ejecución del proyecto, donde se desarrolla el trabajo planificado y involucrando a
muchas personas, se compran materiales y se ejecutan todas las tareas, lo cual cuesta mucho dinero.
 A la conclusión, las personas van pasando a otros proyectos, lo cual reduce los costes.
En cada fase, las incertidumbres y los riesgos son altos al principio y bajos al final. La
razón por la que ocurre esto se denomina "elaboración progresiva":
 Al principio, los objetivos son amplios, y se van concretando en objetivos detallados

progresivamente.
 Lo mismo ocurre con las actividades: Al principio se tienen actividades de alto nivel, y se van
definiendo a medida que el proyecto avanza.
En cada fase, la influencia de los interesados es alta al principio y baja al final, debido
al coste que tendrían los cambios. Por ejemplo, si 10 días antes de finalizar un proyecto de
construcción de un edificio se decide añadir una 4ª planta, los costes serían
desproporcionados, comparados con los costes si la decisión se hubiera tomado durante la
planificación.
4.13. La Organización y la Cultura de la Organización

Ejecutora
Ejemplos de empresas con organización diferente:
 Empresas que se dedican a realizar proyectos para otras empresas (e.g. empresas de consultoría):
Estas organizaciones ejecutan un proyecto tras otro para sus clientes.
 Empresas que han adoptado la gestión por proyectos (e.g. fabricante de teléfonos móviles que
lanza un proyecto para generar cada nuevo producto). Han implementado sistemas y procesos de
gestión de proyectos para desarrollar sus operaciones.
 Empresas no orientadas a la gestión por proyectos. Carecen de herramientas y procesos para
gestionar proyectos. Es menos probable la ejecución exitosa de un proyecto en este tipo de
organizaciones.

Ejemplos de empresas con tipos de cultura diferente:
 Empresas emprendedoras: Aceptan proyectos de alto riesgo.

 Empresas de jerarquía rígida: Pueden dificultar la autoridad del Director de Proyectos.
4.14. La Estructura de la Organización Ejecutora
La organización ejecutora puede ser de tres tipos: funcional, matricial y proyectizada:
 Funcional: Organizaciones tradicionales que trabajan en silos separados (e.g. recursos humanos,
contabilidad, producción, marketing, finanzas). Los directores de proyectos tienen poca autoridad
formal, lo que se traduce en dificultades para conseguir recursos. Suelen reportar a un gerente
funcional. Trabajan a tiempo parcial en el proyecto.
 Proyectizada: La mayoría de los empleados trabajan en proyectos. Los directores de proyectos
tienen mucha autoridad y visibilidad.
 Matricial: Tiene elementos de las dos anteriores. Pueden ser de 3 tipos: matricial fuerte, débil y
equilibrada. El personal asignado a proyectos suele reportar al gerente funcional y al director de
proyectos. Son débiles o fuertes según el grado de autonomía, autoridad y recursos disponibles
para los Directores de Proyecto.
La siguiente tabla representa el peso de los directores de proyectos según el tipo de

organización ejecutora:
MATRICIAL PROYEC-
FUNCIONAL
Débil Equilibrada Fuerte TIZADA
Poca / Limitad Baja / Moderada Alta /

Autoridad
ninguna a moderada / alta casi total
Disponibilidad Poca / Limitad Baja / Moderada Alta /

de recursos ninguna a moderada / alta casi total
Gerente Director Director

Control del Gerente Combinaci
funcion del del
Presupuesto funcional ón
al proyecto proyecto
Dedicación Parcial Parcial Completa Completa Completa

A continuación se representa el contraste de un organigrama típico en una

organización funcional, frente al organigrama típico en una organización proyectizada:
En una organización funcional no suele haber un director del proyecto responsable del
proyecto. Cuando el proyecto implica a varios departamentos, el control se reparte entre los
gerentes funcionales, que asumen las labores de coordinación. Las personas involucradas
reportan exclusivamente a su responsable funcional.
 Por el contrario, en una organización proyectizada, sí existe la figura del director de proyectos, que
es el máximo responsable del proyecto y tiene autoridad sobre las personas que configuran su
equipo de trabajo.

A continuación se representan los organigramas típicos de las organizaciones

matriciales:
Las organizaciones matriciales tienen un modelo de gestión de proyectos intermedio:

Las personas del equipo siguen reportando a sus gerentes funcionales, pero además reportan
al órgano de coordinación del proyecto. Al contrario que en las organizaciones funcionales, el
control no es asumido por los gerentes funcionales. A diferencia de las organizaciones
proyectizadas, pero las personas del equipo siguen reportando a sus gerentes funcionales:
 En una organización matricial débil no suele haber un director del proyecto responsable del
proyecto. Cuando el proyecto implica a varios departamentos, el control ya no se reparte entre los
gerentes funcionales, como ocurría en las organizaciones funcionales, sino que el control es asumido
dentro del equipo, aunque no hay un máximo responsable del proyecto y esto plantea problemas de
autoridad e ineficiencia en la toma de decisiones.
 Una organización matricial equilibrada se diferencia de una matricial débil en cuanto a que ya sí
existe la figura del Director del Proyecto con responsabilidad y autoridad, si bien pertenece a un
departamento y reporta a su responsable funcional.
 Una organización matricial fuerte se diferencia de una matricial equilibrada en cuanto a que el
Director del Proyecto no pertenece a un departamento funcional, y por lo tanto es más neutral.

5. Gestión de Proyectos 2.0
Si pudiéramos generalizar los roles que asumen las personas involucradas en la gestión
Si pudiéramos generalizar los roles que asumen las personas involucradas en la gestión de
proyectos dentro de cualquier organización ejecutora, ¿cuáles serían esos roles? A
continuación vamos a examinar una propuesta de 10 roles: 5 del lado de la gestión de la
demanda y otros 5 del lado de la gestión del suministro.
Todo proyecto que ha de ser gestionado de forma profesional, no solo como una serie
de tareas relacionadas, exige trabajar en equipo y que haya un responsable de terminar
cumpliendo los objetivos de gestión de plazo, coste, alcance, calidad, etc. Así pues, ya sabemos
que como mínimo hay dos roles imprescindibles: los encargados de hacer el trabajo en equipo
(Team Members) y el encargado de coordinar al equipo y gestionar para cumplir los objetivos
de gestión del proyecto (Project Manager).
Según la Guía del PMBOK®, el Project Manager es la persona nombrada por la

organización ejecutora para liderar al equipo, siendo responsable de alcanzar los
objetivos del proyecto.

Los Team Members son los individuos que respaldan al project manager en la
realización del trabajo del proyecto para alcanzar sus objetivos.
Los proyectos no se hacen en el vacío. Si es un proyecto interno realizado con

recursos propios, estos recursos pertenecerán a una unidad de negocio dentro de la
organización. Si es un proyecto realizado para un cliente, el proveedor empleará recursos
también desde un departamento o unidad de negocio de la organización proveedora. Cuando
se trata de un proyecto cros-departamental, es buena práctica que una unidad de negocio
encabece el liderazgo y la responsabilidad. Esto me permite concluir que siempre hay una
unidad de negocio (Business Unit) responsable del proyecto, ejerciendo la persona
responsable de esta unidad un tercer rol bien diferenciado, que podríamos llamar gerente
funcional (Functional Manager).
El principal interés del Functional Manager consiste en aprobar y vigilar la utilización

de sus recursos contra sus objetivos de negocio (o su cuenta de resultados). Según la Guía del
PMBOK®, el Functional Manager es alguien con autoridad de dirección sobre una unidad de
la organización dentro de una organización funcional. el gerente de cualquier grupo que
efectivamente realiza un producto o presta un servicio. a veces se le denomina g erente
de línea.
En gestión empresarial se acostumbra a utilizar terminología relacionada con la

orientación al servicio cliente-proveedor para delimitar las funciones y los procesos
corporativos. En gestión de proyectos también se suele utilizar esta terminología, gestión de
la demanda y gestión del suministro, para especializar las funciones separando dos grupos: 1)
los que piden o proponen proyectos (demand management) y 2) los que utilizan recursos
para ejecutar proyectos (supply management).
Claramente, Project Managers y Team Members se encuentran en supply

management. El rol Functional Manager lo veo en el lado demand management de los que
piden/supervisan.

Expliquemos un poco mejor la función de project demand management:
En las organizaciones hay roles enfocados en gestionar la demanda de proyectos. Los

posibles proyectos que se podrían proponer hay que saber cómo compararlos y priorizarlos,
porque no tiene sentido hacerlos todos, ni se dispondría de los recursos necesarios. Estos
gestores de la demanda no suelen utilizar la palabra “proyecto”, prefieren otras palabras
como ideas, iniciativas, peticiones, inversiones, propuestas, etc.(en inglés: idea, initiative,
request, investment, proposal, commercial bid, etc.). Los project managers suelen
decir proyecto en estado de inicio para referirse a los proyectos que aún no se han
autorizado, y esto suele ser confuso para el resto.
A mí me resulta útil usar la palabra Request para gestión de la demanda y Project para
gestión del suministro (me estoy refiriendo a lo mismo, solo que nombrándolo de forma
diferente). Incluso los estados del ciclo de vida de iniciativas y proyectos suelen entenderse
mejor si los diferenciamos:
Podríamos identificar un cuarto rol específico, Requester, para referirnos a quien

solicita proyectos, trabaja para que se aprueben y después necesita saber principalmente
cuándo y cómo han acabado.
En las organizaciones que venden proyectos, el Requester no sería otro que el

comercial que gestiona el ciclo de venta del proyecto. Por analogía, en las organizaciones
cliente podríamos identificar este mismo rol para referirnos a la persona encargada de
proponer proyectos internos. El rol Requester gestiona sus solicitudes de forma similar
al Project Manager sus proyectos:

Es decir, el Requester puede etiquetar que una solicitud está propuesta si aún no se
ha ganado/autorizado, en progreso si ya se está ejecutando, y cerrada si se ha completado. A
veces se decide aplazar una propuesta esperando un momento más propicio para decidir.
Cuando la propuesta se desestima o se pierde, puede marcarla como rechazada.
De forma simétrica, el Project Manager puede reconocer que el proyecto aún no se ha

autorizado si está en estado inicio. Cuando el proyecto se autoriza, es útil distinguir dos
estados: en planificación cuando aún no se pueden consumir recursos ni presupuesto y en
ejecución en caso contrario. Cuando el proyecto pasa a estado cierre ya no se pueden imputar
horas/gastos. Finalmente, cuando el proyecto se archiva se cierra el dossier y ya no se puede
actualizar la información.
Continuemos ahora con el quinto rol, el gestor de recursos o Resource Manager:
En muchas organizaciones existe un rol particular para gestionar grupos de personas

asignables a proyectos, normalmente denominado Resource Manager. Entre sus
responsabilidades se encuentran gestionar el plan de capacidad para asegurar que hay
recursos disponibles para atender las previsiones de los proyectos. El indicador que más
importancia suele tener para ellos es la tasa de utilización, que deben mantener controlada
entre ciertos umbrales según las categorías profesionales. También tienen responsabilidades

compartidas con el departamento de RRHH: contratación, plan de carrera profesional,

formación, incentivos, bajas, ausencias, etc.
El sexto rol sería el interesado, o Stakeholder:
Según la Guía del PMBOK®, un Stakeholder es un individuo, grupo u organización que

puede afectar, verse afectado, o percibirse a sí mismo como posible afectado por una decisión,
actividad o resultado de un proyecto.
Rol número 7, el patrocinador o Sponsor:
Formalmente, los proyectos son autorizados por el Sponsor. Según la Guía del
PMBOK®, es una persona o grupo que provee recursos y apoyo para el proyecto, programa
o portafolio y que es responsable de facilitar su éxito. alguien de peso en la organización
debe poner su firma en el acta de constitución para autorizar el proyecto . El sentido que
tiene esa autorización es más o menos el siguiente:
“Nos hemos comprometido para gastar el dinero de la organización y el tiempo de

ciertas personas de la organización para ejecutar este proyecto en lugar de otros
propuestos, porque en el momento de tomar la decisión, este proyecto era más alineado,
más rentable, más oportuno para los intereses de la organización.”

El octavo rol podría ser la PMO, también desde el lado de demand

management porque ayudan con la carga administrativa cuando se lanza un proyecto:
Según la Guía del PMBOK®, la PMO es una estructura de la organización que

estandariza los procesos de gobierno relacionados con el proyecto y facilita el
intercambio de recursos, metodologías, herramientas y técnicas.
Aunque es discutible, el rol de la PMO lo veo en el lado de gestión de la demanda, más

que en gestión del suministro, por 2 motivos:
 Hay muchos tipos de PMO, me gusta la simplificación que hace la Guía del PMBOK cuando
hablan de PMO de soporte, de control y directiva. Creo que la PMO directiva sí estaría en
suministro, pero los otros 2 tipos, que son los más habituales, me encajan más en gestión
de la demanda: PMO de soporte facilita el trabajo de los PM y ahorran burocracia; PMO de
control tiene como objetivo principal reportar los grandes indicadores y el resumen
ejecutivo de los proyectos.
 Me gusta la distinción involucrado/comprometido (chicken/pig). La PMO puede llegar a
ser muy influyente en los proyectos, pero “no se la juegan”.
Por otro lado, en el lado del supply management tenemos también dos roles
orientados a gestionar programas y portafolios, que se definen así en la Guía del PMBOK®:
 Un programa es un grupo de proyectos, subprogramas y actividades de programas

relacionados cuya gestión se realiza de manera coordinada para obtener beneficios
que no se obtendrían si se gestionaran en forma individual.
 Un portafolio es un grupo de proyectos, programas, subportafolios y operaciones

gestionados como un grupo para alcanzar los objetivos estratégicos.

Consecuentemente, habrá otros dos roles más en supply management: Program

Manager y Portfolio Manager. Podemos observar una jerarquía entre PfM > PgM > PM dado
que un proyecto puede pertenecer a un programa (o no), y a cero, uno o varios portafolios. A
su vez, un programa puede incluirse en cero, uno o varios portafolios.
Resumiendo la interrelación de estos 10 roles en una sola frase:
El Project Manager puede reportar a un Program Manager o Portfolio Manager, pero

necesita que los Team Members hagan las tareas técnicas, y a su vez los team members son
gestionados por Resource Managers. Estos roles pueden encuadrarse en la gestión del
suministro de proyectos. Por el lado de la gestión demanda de proyectos,
tenemos Requesters que solicitan proyectos, Sponsors que los aprueban, Functional
Managers que asumen la ejecución en sus business units, y también tenemos la PMO dando
soporte administrativo y de control, y Stakeholders internos y externos a la organización
ejecutora.

6. Terminología del PMI®
 Adaptive Life Cycle (Ciclo de Vida Adaptativo): Un ciclo de vida del proyecto, también conocido
como método orientado al cambio o método ágil, que busca facilitar el cambio y requiere un alto
grado de participación continua de los interesados. Los ciclos de vida adaptativos también son
iterativos e incrementales, pero difieren en que las iteraciones son muy rápidas (normalmente 2–4
semanas de duración) y son fijas en tiempo y recursos.
 Assumption (Supuesto): Un factor del proceso de planificación que se considera verdadero, real o
cierto, sin prueba ni demostración.
 Constraint (Restricción): Un factor limitante que afecta la ejecución de un proyecto, programa,
portafolio o proceso.
 Enterprise Environmental Factors (Factores Ambientales de la Empresa): Condiciones que no
están bajo el control directo del equipo y que influyen, restringen o dirigen el proyecto, programa o
portafolio.
 Functional Organization (Organización Funcional): Una organización jerárquica en la cual cada
empleado tiene definido claramente un superior y el personal está agrupado por áreas de
especialización dirigidas por una persona con experiencia en esa área.
 Incremental Life Cycle (Ciclo de Vida Incremental): Un ciclo de vida del proyecto donde
habitualmente el alcance del proyecto se determina, tempranamente en el ciclo de vida del
proyecto, pero las estimaciones de tiempo y coste se modifican periódicamente conforme aumenta
el entendimiento del equipo del proyecto sobre el producto. Las iteraciones desarrollan el producto
a través de una serie de ciclos repetidos, mientras que los incrementos se añaden sucesivamente a
la funcionalidad del producto.
 Iterative Life Cycle (Ciclo de Vida Iterativo): Un ciclo de vida del proyecto donde habitualmente el
alcance se determina, tempranamente en el ciclo de vida del proyecto, pero cuyas estimaciones de
tiempo y coste se modifican periódicamente conforme aumenta el entendimiento del equipo del
proyecto sobre el producto. Las iteraciones desarrollan el producto a través de una serie de ciclos
repetidos, mientras que los incrementos se añaden sucesivamente a la funcionalidad del producto.
 Life Cycle (Ciclo de Vida): La serie de fases que atraviesa un proyecto desde su inicio hasta su
cierre. Véase ciclo de vida del proyecto.
 Matrix Organization (Organización Matricial): Una estructura de organización en la cual el
director del proyecto comparte con los gerentes funcionales la responsabilidad de asignar
prioridades y de dirigir el trabajo de las personas asignadas al proyecto.
 Organizational Process Assets (Activos de los Procesos de la Organización): Planes, procesos,
políticas, procedimientos y bases de conocimiento que son específicos de la organización ejecutora
y que son utilizados por la misma.
 Organizational Project Management Maturity (Madurez de la Dirección de Proyectos de una
Organización): El nivel de capacidad de una organización para producir los resultados estratégicos
deseados de un modo predecible, controlable y confiable.
 Performing Organization (Organización Ejecutora): Una empresa cuyo personal está
directamente involucrado en realizar el trabajo del proyecto o del programa.
 Portfolio (Portafolio): Proyectos, programas, subportafolios y operaciones gestionados como un
grupo para alcanzar los objetivos estratégicos.
 Product (Producto): Un artículo producido, que es cuantificable y que puede ser un elemento
terminado o un componente. Otras palabras para hacer referencia a los productos son materiales y
bienes. Compárese con resultado. Véase también entregable.

 Program (Programa): Un grupo de proyectos, subprogramas y actividades de programas

relacionados cuya gestión se realiza de manera coordinada para obtener beneficios que no se
obtendrían si se gestionaran en forma individual.
 Progressive Elaboration (Elaboración Progresiva): El proceso iterativo de incrementar el nivel de
detalle de un plan para la dirección del proyecto a medida que se cuenta con mayor cantidad de
información y con estimaciones más precisas.
 Project (Proyecto): Un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o
resultado único.
 Project Based Organizations –PBOs- (Organizaciones Basadas en Proyectos): Diversas formas de
organización que implican la creación de sistemas temporales para la realización de proyectos. Las
PBOs conducen la mayoría de sus actividades como proyectos y/o priorizan los enfoques de
proyecto frente a los enfoques funcionales.
 Project Governance (Gobierno del Proyecto): La alineación de los objetivos del proyecto con la
estrategia de la organización más grande por parte del patrocinador del proyecto y del equipo del
proyecto. El gobierno de un proyecto se define y debe integrarse al contexto más amplio del
programa o de la organización que lo patrocina, pero se mantiene separada del gobierno de la
organización.
 Project Management (Dirección de Proyectos): La aplicación de conocimientos, habilidades,
herramientas y técnicas a actividades del proyecto para cumplir con los requisitos del mismo.
 Project Management Body of Knowledge (Fundamentos para la Dirección de Proyectos): Una
expresión inclusiva que describe la suma de conocimientos de la profesión de Dirección de
Proyectos. Al igual que en otras profesiones, como la abogacía, la medicina y las ciencias
económicas, los fundamentos se apoyan en los usuarios y académicos que los aplican y desarrollan.
El conjunto de los Fundamentos para la Dirección de Proyectos incluye prácticas tradicionales
comprobadas y ampliamente utilizadas, así como prácticas innovadoras emergentes para la
profesión. Los fundamentos incluyen tanto material publicado como no publicado. Estos
fundamentos están en constante evolución. La Guía del PMBOK® identifica un subconjunto de
Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas.
 Project Management Information System (Sistema de Información para la Dirección de
Proyectos): Un sistema de información compuesto por herramientas y técnicas utilizadas para
recopilar, integrar y difundir las salidas de los procesos de la dirección de proyectos. Se utiliza para
respaldar todos los aspectos del proyecto desde el inicio hasta el cierre, y puede incluir tanto
sistemas manuales como automatizados.
 Project Management Office –PMO- (Oficina de Dirección de Proyectos): Una estructura de la
organización que estandariza los procesos de gobierno relacionados con el proyecto y facilita el
intercambio de recursos, metodologías, herramientas y técnicas.
 Project Management Staff (Personal de Dirección de Proyectos): Los miembros del equipo del
proyecto que realizan actividades de dirección del proyecto tales como la gestión del cronograma,
las comunicaciones, los riesgos, etc.
 Project Management System (Sistema de Gestión de Proyectos): La suma de los procesos,
herramientas, técnicas, metodologías, recursos y procedimientos necesarios para gestionar un
proyecto.
 Project Management Team (Equipo de Dirección del Proyecto): Los miembros del equipo del
proyecto que participan directamente en las actividades de dirección del mismo. En algunos
proyectos más pequeños, el equipo de dirección del proyecto puede incluir prácticamente a todos
los miembros del equipo del proyecto.
 Project Manager –PM- (Director del Proyecto): La persona nombrada por la organización
ejecutora para liderar al equipo que es responsable de alcanzar los objetivos del proyecto.

 Project Phase (Fase del Proyecto): Un conjunto de actividades del proyecto relacionadas
lógicamente que culmina con la finalización de uno o más entregables.
 Project Team (Equipo del Proyecto): Un conjunto de individuos que respaldan al director del
proyecto en la realización del trabajo del proyecto para alcanzar sus objetivos.
 Projectized Organization (Organización Orientada a Proyectos): Cualquier estructura
organizativa en la que el director del proyecto tenga plena autoridad para asignar prioridades,
asignar recursos y dirigir el trabajo de las personas asignadas al proyecto.
 Sponsoring Organization (Organización Patrocinadora): La entidad responsable de proporcionar
el patrocinador del proyecto y los medios para su financiación, así como otros recursos del proyecto.
 Stakeholder (Interesado): Un individuo, grupo u organización que puede afectar, verse afectado, o
percibirse a sí mismo como posible afectado por una decisión, actividad o resultado de un proyecto.
 Subproject (Subproyecto): Una porción más pequeña del proyecto creada cuando un proyecto es
subdividido en componentes o partes más fáciles de gestionar.

Anexo I: El Project Manager Ágil
Muchas veces se ataca la figura del project manager y la disciplina del project
management. Se da el mensaje de que los project managers ya no somos necesarios en los
proyectos software. Se dice que estamos en el lado oscuro. Impedimos el buen desempeño
del equipo, el trabajo de buena calidad, la orientación al valor, el ritmo sostenible, el espíritu
de equipo, la creatividad, el sentido común, etc., etc.
Es verdad que muchas veces se observa todo esto en los proyectos software, pero
¿seguro que siempre es por culpa del project manager? Y cuando lo es, ¿seguro que ese
project manager está dirigiendo correctamente el proyecto ágil? Si se prescinde del rol del
project manager, ¿quién se va a responsabilizar de terminar el proyecto en plazo y dentro del
coste aprobado? Muchos jefes se preguntarán: Entonces ¿a quién le vamos a echar la culpa
cuando el proyecto salga mal?
Demonizar la figura del project manager, o la práctica de la gestión de proyectos, es una

simplificación injusta y desacertada. El estado actual y las tendencias del project management
van justo en el sentido contrario:
 Los marcos y métodos de gestión de proyectos reconocen que hay dos tipos mayoritarios
de ciclos de vida de desarrollo de proyectos: 1) Ciclo de Vida Predictivo (= en cascada) y 2)
Ciclo de Vida Adaptativo (= ágil= orientado al valor= orientado a los cambios).
 Los organismos de certificación en gestión de proyectos más reconocidos están
incorporando titulaciones específicas para gestionar proyectos software y han modificado
las titulaciones generalistas para que los aspirantes tengan una base mínima de gestión de
proyectos ágiles.
 La mayoría de las organizaciones públicas y privadas están adaptando sus métodos y
modelos de gestión, reconociendo que en sus portafolios hay proyectos predictivos y
adaptativos, y es curioso que aplican modelos ágiles no solo para los proyectos software,
sino también para los proyectos de negocio en fases creativas o experimentales, o cuando
simplemente los requisitos no están claros.

El project manager de hoy día no es un profesional completo si no sabe cómo se

gestionan los dos tipos de proyectos:
En un proyecto predictivo se cierran la mayor parte de los requisitos al principio y

después se avanza por fases sencuenciales. Son ejemplos típicos los proyectos de ingeniería y
construcción, denominados a veces EPC: engineering, procurement and construction. El rol
del project manager en estos proyectos consiste en cerrar un plan para la dirección del
proyecto –que incluye un diagrama Gantt y otros muchos componentes que podrán
modificarse si es necesario– para utilizarlo a modo de “partitura” para dirigir a los miembros
del equipo como si fueran los músicos. En las reuniones de seguimiento, se compara el
desempeño real con el planificado y se toman acciones correctoras para acercarnos a las líneas
base. De esta manera, midiendo y ajustando sucesivamente, logramos cumplir el plazo, el
coste, etc.
Si estamos hablando de un proyecto software en cascada, se cierran todos los

requisitos técnicos, después se desarrolla y se cierra todo el modelo funcional, después se
diseña y se aprueba toda la arquitectura, después se acomete la fase de desarrollo, y
finalmente la fase de pruebas y el pase a producción.

Cuando se sabe claramente casi todo lo que hay que hacer, es muy eficiente trabajar
por lotes: primero todos los requisitos, luego toda la especificación funcional, etc. Ya que nos
ponemos a desarrollar el sistema de información en español, hagámoslo también en inglés...
Igual que el agua no vuelve hacia arriba en una cascada, una vez se avanza a la siguiente fase,
ya no se vuelve a la anterior. Como todo el mundo sabe, este modelo en cascada
generalmente no funciona para informática de gestión ni para desarrollos web, pero sigue
usándose para desarrollar software de misión crítica –por ejemplo en el sector aeronáutico–
, software embebido –sirva como ejemplo el software que puede haber en un coche
autónomo–, o bien en productos software con un componente muy alto de requisitos no
funcionales, o con un roadmap muy predeterminado, etc.
¿Por qué no sirve el modelo en cascada para la mayoría de proyectos software,

dirigidos a usuarios finales que deben utilizarlos para realizar determinadas operativas?
Sencillamente, porque es muy difícil, si no imposible, cerrar apropiadamente los requisitos del
sistema de información. Si trabajamos en cascada y entregamos por primera vez después de 5
meses, lo más probable es que se rechace mucha funcionalidad y haya que asumir mucho
retrabajo.
El gran drama del software es que “el cliente no sabe lo que quiere, solo sabe lo que
no quiere”, de ahí que sea tan rentable hacer iteraciones frecuentes para demostrar algo
funcionando, típicamente cada 2 semanas.
En un plazo de proyecto predeterminado para realizar un trabajo que se visualiza en

líneas generales con los requisitos de alto nivel, y con un tamaño de equipo más o menos
estable, se puede calcular fácilmente una primera estimación del presupuesto.
En un proyecto real estamos desarrollando una herramienta con ayuda de una

software Factory en india. En terminología Scrum, nosotros nos consideramos “chicken”. En el
proyecto asumimos los roles de business analyst y project manager. Hablamos con el Product
Owner y detrás hay un equipo técnico y el Scrum Master.

Usamos Asana para gestionar las listas y los tableros y Slack para la comunicación
continua. Compartimos el product backlog con el product owner, no vemos los sprint backlogs
ni atendemos ya a los daily standups (es muy pronto aquí en España). Tenemos visibilidad
sobre el tamaño en horas de cada historia. Practican integración continua: Cuando terminan
una historia, la despliegan al entorno de pruebas y mueven la tarjeta del tablero de “in
progress” a la columna “testing”. Nos llega la notificación de Asana y ya sabemos que tenemos
pendiente hacer las pruebas. Si las pruebas se superan, marcamos la historia como terminada
y nosotros mismos la movemos a la columna “done”. En caso contrario, la retornamos a “in
progress”. Mientras escribo esto veo que tengo pendiente validar 3 historias:
Diariamente, el Scrum Master actualiza la gráfica de quemado. Aquí pueden ver la del
mes pasado –a partir de la segunda release, los sprints son mensuales y facturan
mensualmente las horas incurridas.

Para controlar un proyecto ágil no suele servir de mucho hacer un Gantt. Veríamos
tareas resumen con las releases una detrás de otra, pero el proyecto generalmente va en
fecha, siendo las únicas desviaciones ocasionadas por algún que otro spike de vez en cuando.
En nuestro caso, al principio planteamos 5 releases:
 En la primera release, el resultado fue el prototipo PDF dinámico de la aplicación móvil:

unos 100 mockups en Balsamiq que pudimos mostrar a muchos colegas para validar y
corregir muchos enfoques sin contratar todavía a la software factory.
 En la release 2, la orientación al valor consistió en el desarrollo iOS y Android de la
primera versión de la aplicación móvil. No es funcional pero sí permite navegar y mostrar
la funcionalidad de alto nivel.
 En la release 3 desarrollamos la primera versión de la aplicación web, que permitía usar
todos los roles salvo el Resource Manager y usar la estructura de proyectos, programas y
portafolios.
 En la release 4, se implementó la funcionalidad básica para proyectos y recursos: el rol de
resource manager, gestión de pools, flujo de aprobación de horas y gastos, etc.
 En la release 5, estamos implantando lo que faltaba para liberar la versión beta: entorno
multi-organización, invitación entre usuarios, seguimiento de proyectos, EVM, Gantt,
gestión de tareas y cuentas de control.
La fecha que manejamos para terminar esta última release, y por tanto el proyecto, es
dentro de dos meses, más menos una iteración.
En esta experiencia de gestión de un proyecto ágil, nos parece que las labores que
estamos realizando día a día encajan bastante bien con el rol de agile practitioner delineado
por PMI®. En el texto que usa PMI® para especificar el examen PMI-ACP® se describen 7
dominios que resumen las principales áreas de responsabilidad del Director de Proyectos Ágil.

1. Principios Ágiles: Explorar, fomentar y aplicar principios ágiles en el contexto del equipo del
proyecto y la organización.
2. Entregar conforme al valor: Entregar resultados de valor produciendo entregas

incrementales de alto valor revisables, pronto y a menudo, basándose en las prioridades de los
interesados. Hacer que los interesados proporcionen retroalimentación a partir de estas
entregas, con el fin de priorizar y mejorar las entregas incrementales futuras.
3. Involucrar a los interesados: Gestionar la involucración de los interesados actuales y futuros

generando un entorno de confianza que permita alinear sus necesidades y expectativas y
equilibrar sus peticiones haciendo que comprendan el coste/esfuerzo que suponen. Promover
la participación y la colaboración a lo largo del ciclo de vida del proyecto y proporcionar las
herramientas para la toma de decisiones eficaces e informadas.
4. Desempeño del equipo: Crear un entorno de confianza, aprendizaje, colaboración y

resolución de conflictos que fomente la auto-organización del equipo, mejore las relaciones
entre los miembros del equipo y cultive una cultura de alto rendimiento.
5. Planificar de forma adaptativa: Producir y mantener un plan que evolucione desde el inicio
hasta el cierre, basado en objetivos, valor, riesgos, restricciones, retroalimentación de
interesados y revisión de los hallazgos.
6. Detectar y solucionar problemas: Identificar continuamente problemas, impedimentos y

riesgos. Priorizarlos y resolverlos de manera oportuna. Monitorizar y comunicar el estado de
resolución de los problemas e implementar las mejoras de procesos que eviten que vuelvan a
ocurrir.
7. Mejorar continuamente (Producto, Proceso, Personas): Mejorar continuamente la calidad,

efectividad y el valor del producto, del proceso y del equipo.

¿A alguien le parece que un project manager que es responsable de todo esto de

verdad estorba al equipo ágil?
Si quedan todavía dudas, profundicemos un poco más. En cada uno de estos dominios
de práctica, los project managers realizan una serie de actividades. Veamos la lista de tareas
que según el PMI® debería practicar en su día a día el project manager ágil:
En el dominio 1. Principios Ágiles:
1. Fomentar los principios ágiles modelándolos y discutiendo los valores ágiles para
desarrollar un entendimiento común dentro del equipo y entre el equipo y los interesados.
2. Ayudar a asegurar que todos tengan un entendimiento común de los valores y principios
ágiles, de las prácticas ágiles y la terminología empleada para trabajar de manera efectiva.
3. Apoyar el cambio en la organización educando e influenciando sobre los procesos,
comportamientos y personas para hacer la organización más eficaz y eficiente.
4. Practicar la visualización por medio de radiadores de información muy visibles que
muestren el progreso y desempeño real del equipo para fomentar la transparencia y la
confianza.
5. Fomentar un entorno de seguridad y confianza, permitiendo que todos experimenten y
cometan errores para que puedan aprender y mejorar continuamente la forma de
trabajar.
6. Mejorar la creatividad experimentando con nuevas técnicas e ideas sobre los procesos,
para descubrir formas de trabajar más eficientes y eficaces.
7. Fomentar que los miembros del equipo compartan el conocimiento colaborando y
trabajando juntos para reducir los riesgos de islas de conocimiento y cuellos de botella.
8. Estimular el liderazgo emergente dentro del equipo estableciendo un entorno respetuoso
y seguro en el que puedan probarse nuevos enfoques para producir mejoras y fomentar la
auto-organización y el facultamiento.
9. Practicar el liderazgo servicial ayudando y estimulando a otros en sus esfuerzos, de
manera que puedan trabajar a su máximo nivel y continuar mejorando.
En el dominio 2. Entregar conforme al Valor:

2.1. Definir Valor Positivo:
1. Definir entregables identificando unidades que puedan producirse incrementalmente para

maximizar su valor para los interesados minimizando las actividades que no aporten valor.
2. Refinar los requisitos lo más tarde posible consensuando los criterios de aceptación de las
funcionalidades para entregar valor.
3. Seleccionar y adaptar los procesos del equipo basándose en las características del
proyecto y de la organización así como la experiencia del equipo para optimizar la entrega
del valor.
2.2. Evitar Inconvenientes Potenciales:
1. Planificar entregas incrementales pequeñas organizando los requisitos en funcionalidades

mínimas vendibles o productos mínimos viables, para facilitar anticipadamente el
reconocimiento y la entrega de valor.
2. Limitar el tamaño de los incrementos y mejorar la frecuencia de las revisiones con los
interesados apropiados para identificar y responder a los riesgos pronto y al mínimo coste.
3. Solicitar retroalimentación a clientes y usuarios mediante la demostración frecuente de los
incrementos para confirmar y mejorar el valor para el negocio.
2.3. Priorización:
1. Priorizar las unidades de trabajo a través de la colaboración con los interesados para
optimizar el valor de los entregables.
2. Realizar revisiones y mantenimientos frecuentes de los resultados del trabajo priorizando
y manteniendo internamente la calidad para reducir el coste total del desarrollo
incremental.
3. Identificar y priorizar continuamente los factores ambientales, operacionales y de
infraestructura para mejorar la calidad y el valor de los entregables.
2.4. Desarrollo Incremental:
1. Realizar revisiones operativas y/o puntos de control periódicos con los interesados para
obtener retroalimentación y correcciones al trabajo en curso y planificado.

2. Equilibrar el desarrollo de unidades entregables y esfuerzos de reducción de riesgos

incorporando tanto trabajos para producir valor como para reducir riesgos en la pila, para
maximizar la propuesta de valor total a lo largo del tiempo.
3. Re-priorizar periódicamente los requisitos para reflejar cambios en el entorno y
necesidades o preferencias de los interesados para maximizar el valor.
4. Recopilar y priorizar requisitos relevantes no funcionales (como de operación y seguridad)
considerando el entorno en que la solución será usada para minimizar la probabilidad de
fallo.
5. Realizar revisiones frecuentes de los productos del trabajo con inspecciones, revisiones,
y/o pruebas para identificar e incorporar mejoras en el proceso completo y el
producto/servicio.
En el dominio 3. Involucrar a los Interesados:
3.1. Comprender las Necesidades de los Interesados:
1. Identificar e involucrar a los interesados efectivos y facultados a través de revisiones

periódicas para asegurar que el equipo es conocedor de los intereses, necesidades y
expectativas de los interesados.
2. Identificar e involucrar a los interesados (actuales y futuros) promoviendo la compartición
del conocimiento desde el principio y durante todo el proyecto para asegurar un flujo sin
obstáculos de la información y el valor durante toda la vida del proyecto.
3.2. Asegurar la Involucración de los Interesados
1. Establecer relaciones con los interesados construyendo acuerdos de trabajo entre los
interesados clave para promover la participación y la colaboración efectiva.
2. Mantener la involucración adecuada de los interesados continuamente evaluando los
cambios en el proyecto y la organización para asegurar que los interesados se involucran
apropiadamente.
3. Establecer comportamientos colaborativos entre los miembros de la organización
fomentando la toma de decisiones y la resolución de conflictos en grupo para mejorar la
calidad de las decisiones y reducir el tiempo requerido para decidir.
3.3. Gestionar las Expectativas de los Interesados:

1. Establecer una visión común de los diversos incrementos del proyecto (productos,
entregables, releases, iteraciones) desarrollando una visión de alto nivel y apoyando los
objetivos para alinear las expectativas de los interesados y generar confianza.
2. Establecer y mantener un conocimiento compartido de los criterios de éxito, entregables y
acuerdos aceptables facilitando la concienciación entre los interesados para alinear
expectativas y generar confianza.
3. Proporcionar transparencia en relación al estado del trabajo comunicando el progreso del
equipo, la calidad del trabajo, los impedimentos y los riesgos, para ayudar a los principales
interesados a tomar decisiones informadas.
4. Proporcionar pronósticos detallados compensando la necesidad de certidumbre y los
beneficios de la adaptabilidad, de tal forma que los interesados puedan planificar de
manera efectiva.
En el dominio 4. Desempeño del Equipo:
4.1. Desarrollo del Equipo:
1. Cooperar con los otros miembros del equipo para idear reglas básicas y procesos internos
para fomentar la coherencia del equipo y fortalecer el compromiso de los miembros del
equipo con los resultados compartidos.
2. Ayudar a crear un equipo que tenga las habilidades interpersonales y técnicas necesarias
para conseguir todos los objetivos conocidos del proyecto para crear valor para el negocio
con el mínimo retraso.
4.2. Facultamiento del Equipo:
1. Animar a los miembros del equipo a convertirse en especialistas generalistas para reducir
el tamaño del equipo y los cuellos de botella,
2. Contribuir a la auto-organización del trabajo facultando a otros y fomentando el liderazgo
emergente para generar soluciones efectivas y gestionar la complejidad.
3. Descubrir continuamente los factores de motivación y desmotivación del equipo y
personales y asegurar que la moral del equipo esté alta y los miembros del equipo
permanezcan motivados y productivos a lo largo del proyecto.
4.3. Colaboración y Compromiso del Equipo:

1. Facilitar la estrecha comunicación dentro del equipo y con los interesados externos
apropiados mediante la coubicación o el uso de herramientas de colaboración para reducir
la mala comunicación y el retrabajo.
2. Reducir distracciones para establecer resultados predecibles y optimizar el valor
entregado.
3. Participar en la alineación de los objetivos del proyecto y del equipo compartiendo una
visión del proyecto para asegurar que el equipo comprende cómo encajan sus objetivos en
los objetivos del proyecto.
4. Animar al equipo a medir su velocidad monitorizando y midiendo el desempeño real en
iteraciones previas o releases para que los miembros ganen una mejor comprensión de su
capacidad y creen pronósticos más precisos.
En el dominio 5. Planificar de forma Adaptativa:
5.1. Niveles de Planificación:
1. Planificar a múltiples niveles (estratégico, release, iteración, día) creando un detalle

apropiado usando planificación gradual y elaboración progresiva para equilibrar la
predictibilidad de los resultados con la capacidad de explotar oportunidades.
2. Hacer que las actividades de planificación sean visibles y transparentes fomentando la
participación de los interesados clave y publicando los resultados para mejorar el nivel de
compromiso y reducir la incertidumbre.
3. A medida que se desenvuelve el proyecto, situar y gestionar las expectativas de los
interesados estableciendo progresivamente niveles específicos de compromiso para
asegurar un entendimiento común de los entregables esperados.
5.2. Adaptación:
1. Adaptar la cadencia y el proceso de planificación a partir de los resultados de las

retrospectivas periódicas sobre las características y/o el tamaño/complejidad/criticidad de
los entregables del proyecto para maximizar el valor.
2. Inspeccionar y adaptar el plan del proyecto para reflejar los cambios en los requisitos,
cronograma, presupuesto, y mover prioridades teniendo en cuenta el aprendizaje del
equipo, la experiencia en las entregas, la retroalimentación de los interesados y los
defectos, para maximizar el valor de negocio entregado.

5.3. Determinación del Tamaño y Estimación Ágil:
1. Poner tamaño a los elementos usando técnicas de elaboración progresiva para determinar
el tamaño probable del proyecto independientemente de la velocidad y de variables
externas.
2. Ajustar la capacidad incorporando demandas de operación y mantenimiento y otros
factores para crear un rango de estimación actualizado.
3. Crear un rango de estimación para el alcance inicial, el cronograma y el coste que reflejen
el nivel actual de conocimiento de alto nivel del esfuerzo necesario para entregar el
proyecto, para desarrollar un punto inicial para gestionar el proyecto.
4. Refinar los rangos de estimación de alcance, cronograma y costes que reflejen el
conocimiento último del esfuerzo necesario para entregar y gestionar el proyecto.
5. Usar continuamente datos de los cambios en la capacidad de recursos, tamaño de
proyectos, y métricas de velocidad para evaluar la estimación hasta la conclusión.
En el dominio 6. Detectar y Solucionar Problemas:
1. Crear un entorno abierto y seguro estimulando la conversación y la experimentación, para

que afloren problemas e impedimentos que frenan al equipo o impiden su capacidad de
entregar valor.
2. Identificar amenazas y problemas educando e involucrando al equipo en varios puntos del
proyecto para que los resuelvan oportunamente y mejoren los procesos que causan los
problemas.
3. Asegurar que los problemas se resuelven por los miembros del equipo adecuados y/o se
resitúan las expectativas a la luz de los problemas que no pueden resolverse para
maximizar el valor entregado.
4. Mantener una lista de amenazas y problemas visible, monitorizada y priorizada para elevar
la responsabilidad, promover la actuación y monitorizar quién es dueño y el estado de
resolución.
5. Comunicar el estado de las amenazas y los problemas manteniendo una lista de amenazas
e incorporando actividades en la pila de trabajo para proporcionar transparencia.

En el dominio 7. Mejorar Continuamente (Producto, Proceso, Personas):
1. Adaptar el proceso revisando e integrando periódicamente las prácticas del equipo, la

cultura de la organización, y los objetivos de entrega para asegurar la efectividad del
equipo dentro de las guías y normas de la organización establecidas.
2. Mejorar los procesos del equipo realizando retrospectivas frecuentes y experimentos de
mejora para mejorar continuamente la efectividad del equipo, del proyecto y de la
organización.
3. Buscar retroalimentación del producto a partir de entregas incrementales y
demostraciones frecuentes para mejorar el valor del producto.
4. Crear un entorno de aprendizaje continuo proporcionando oportunidades a las personas
de desarrollar sus habilidades para desarrollar un equipo más productivo de especialistas
generalistas.
5. Cuestionar los elementos de proceso existentes realizando un análisis del flujo del valor y
eliminando desperdicios para mejorar la eficiencia individual y la efectividad del equipo.
6. Crear mejoras del sistema a partir de la difusión del conocimiento y las prácticas a través
de los proyectos y los límites organizativos para evitar que se repitan problemas
identificados y mejorar la efectividad de la organización como un todo.


Manual M1

Cargado por

Copyright:

Formatos disponibles

Manual M1

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

Manual M1

Cargado por

Copyright:

Formatos disponibles

EUROPEAN OPEN BUSINESS SCHOOL

European Open Business School 2

Un proyecto no es solo un conjunto de tareas

En las organizaciones se distinguen

La gestión de proyectos hace posible los

La organización de gestión de proyectos más reconocida a nivel mundial es el Project

En un entorno empresarial cada día más competitivo y selectivo, en el que sólo

European Open Business School 3

El Project Management Institute (PMI®) es la asociación profesional, sin ánimo de

El PMI® se fundó en 1969 en el Instituto de Tecnología de Georgia por cinco

European Open Business School 4

En la página web del PMI, www.pmi.org, hay muchas noticias e información

Otras titulaciones que otorga el PMI® en la actualidad, son las siguientes:

 CAPM® Certified Associate in Project Management (Certificado en Dirección de Proyectos).

El certificado PMP® es mundialmente reconocido. Para mantener el título, después de

European Open Business School 5

En la siguiente figura aparecen representadas las fases del proceso de certificación y

Solicitud del derecho a examen PMP® (Application Submission)

 Previamente a la solicitud, es preciso haber recibido formación presencial en gestión de proyectos

European Open Business School 6

Preparación del Examen

De las preguntas del examen, un 25%, sobre conocimientos generales de gestión de

 Supuestos contextuales de gestión de proyectos: Aplicación directa de los conceptos.

El grado de confianza necesario para presentarse al examen con tranquilidad se

European Open Business School 7

European Open Business School 8

Requisitos de Certificación Continua (CCR)

 Asistencia a las reuniones del capítulo local.

European Open Business School 9

3. La Guía del PMBOK®

La Guía de los Fundamentos para la Dirección de Proyectos (A Guide to the Project

 Sección I – Marco Conceptual de la Dirección de Proyectos:

European Open Business School 10

El cuerpo principal de la guía se centra en el desarrollo de las 10 áreas de conocimiento:

European Open Business School 11

Por otra parte, en cualquier proyecto se reconocen 5 grupos de procesos:

Inicio Definir el nuevo proyecto o fase mediante la obtención de la autorización para

European Open Business School 12

European Open Business School 13

Los 49 procesos descritos en la Guía del PMBOK® pueden representarse resumidamente en el

European Open Business School 14

Un elemento importante en la gestión de cualquier proyecto es la documentación. La Guía del

European Open Business School 15

4. Terminología común en Dirección de Proyectos

4.2. Proyecto, Programa y Portafolio

European Open Business School 16

 Portafolio (Cartera): Proyectos, programas, subportafolios y operaciones gestionados como un

European Open Business School 17

“do the thing right” “do the right thing”

PROYECTO PROGRAMA PORTAFOLIO

European Open Business School 18

Ejercicio 1. En las siguientes frases, indique si se trata de un proyecto, un programa o

Solución: Proyecto: 1, 4, 8, 11, 12 y 15. Programa: 3, 5, 7, 9, 14 y 16. Portafolio: 2, 6, 10, 13 y

European Open Business School 19

European Open Business School 20

Ejercicio 3. Su portafolio tiene 5 componentes, con los siguientes datos de presupuesto y

 Proyecto Nº1: presupuesto 25.000 €; valor 30%

El proyecto 5 ya se está ejecutando, pero sobre el resto se puede tomar la decisión

Las herramientas de gestión de portafolios (Project Portfolio Management –PPM-)