MODULO 1 MDGP Interactivo.

EUROPEAN OPEN BUSINESS SCHOOL - MDGP
EN EL S.XXI
PROYECTOS
DIRECCIÓN DE
DIRECCIÓN DE PROYECTOS EN EL SIGLO XXI
ÍNDICE
1. INTRODUCCIÓN 3
2. LA ORGANIZACIÓN PMI® 5
3. LA GUÍA DEL PMBOK® 10
4. TERMINOLOGÍA COMÚN EN DIRECCIÓN DE PROYECTOS 16
4.1. Tipos de proyectos 16
4.2. Dirección de Proyectos 16
4.3. Proyecto, Programa y Portafolio 17
4.4. Modelo de Madurez OPM3® 21
4.5. Restricciones Contrapuestas (Competing Constraints) 22
4.6. Supuestos (Assumptions) 23
4.7. Elaboración Progresiva 24
4.8. Oficina de Gestión de Proyectos o Programas (PMO) 25
4.9. Sistema de Información para la Dirección de Proyectos 25
4.10. Activos de los Procesos de la Organización (APO) 26
4.11. Factores Ambientales de la Empresa (FAE) 26
4.12. Ciclo de Vida de un Producto 27
4.13. Fases de un Proyecto 27
4.14. La Organización y la Cultura de la Organización Ejecutora 28
4.15. La Estructura de la Organización Ejecutora 29
5. GESTIÓN DE PROYECTOS 2.0 32
6. TERMINOLOGÍA DEL PMI 37
7. ANEXO I: EL PROJECT MANAGER ÁGIL 40

1.
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
INTRODUCCIÓN
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 600.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
3
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.
4
DIRECCIÓN DE PROYECTOS EN EL SXXI
2.
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.
LA ORGANIZACIÓN PMI®
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 más de 600.000 afiliados (agosto

de 2022) 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 (chapters, en inglés), 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:
5
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® Organizational 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.
6
● 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
139USD.
- 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.
7
● 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.
El examen puede realizarse en un centro Prometric (visita la web del PMI para localizar el más
cercano a tu domicilio) o, debido a la pandemia Covid19, online mediante ordenador con webcam
desde tu casa.
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
8
del examen. Las áreas del examen y su porcentaje de preguntas son: Procesos (50%),
Personas (42%) y Negocios (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.
9
3.
La 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 GUÍA DEL PMBOK®
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.
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, motivar a tu equipo, gestionar su desempeño,
asegurar el conocimiento generado en el proyecto, velar por
el desarrollo del negocio, 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, para proyectos Predictivos (iniciamos

el curso con este tipo de proyectos, más clásicos. Los proyectos
Adaptativos y su gestión, se verá en el módulo 9), se refleja en la
versión 6 del PMBoK y se centra en el desarrollo de las 10 áreas de
conocimiento
10
Por otra parte, en cualquier proyecto Predictivo 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® versión 6, 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).
11
● 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.
12
Es decir, en todo proyecto o fase predictiva 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, para la gestión de proyectos Predictivos, descritos en la Guía del PMBOK®
pueden representarse resumidamente en el siguiente mapa de procesos, en inglés y en español,
respectivamente:
13
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.
14
15
4.
4.1. TIPOS DE PROYECTOS
En este curso vamos a diferenciar dos tipos de proyectos, como ya

habéis podido leer con anterioridad. Por un lado, aquellos proyectos
“clásicos”, tradicionales o más antiguos, que en sociedades
avanzadas se llevan haciendo durante años para dotar a los países
y comunidades de infraestructuras (carreteras, puentes, puertos,
TERMINOLOGÍA COMÚN EN
DIRECCIÓN DE PROYECTOS
túneles, centrales eléctricas o hidráulicas, transporte eléctrico,

grandes edificios, etc.) a los que llamamos Predictivos; y aquellos
proyectos más “modernos”, relacionados con tecnologías muy
avanzadas, (como la ciencia médica y biología, telecomunicaciones,
industria aero-espacial, desarrollo de vacunas, programación de
software, exploración del Universo, etc.), que se caracterizan por
un elevado grado de incertidumbre y a los que denominamos
Adaptativos. Cada tipo de proyecto tiene sus metodologías de
gestión adecuadas, que son muy diferentes entre un tipo y otro de
proyecto.
Hay que reseñar, que un proyecto puede tener partes de su ciclo

de vida que se ajusten a ambas formas de gestión y en cada una de
esas fases diferentes podremos, y deberemos, aplicar metodologías
de gestión diferentes.
4.2. 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.
16
- El presupuesto.
- Los recursos.
- Los riesgos.
4.3. 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 Los programas tienen un Los portafolios tienen un
objetivos definidos. El alcance mayor y propor- alcance que varía según
alcance se elabora gra- cionan beneficios más los objetivos estratégicos
dualmente a lo largo del importantes. de la organización.
ciclo de vida del proyec-
to.
17
Cambios Los PM prevén cambios Los PgM deben esperar Los PfM monitorizan cons-
e implementan procesos cambios generados tan- tantemente los cambios
para controlar los cam- to a nivel interno como en un entorno interno y
bios externo del programa, externo más amplio.
y estar preparados para
gestionarlos.
Planificación Los PM transforman Los PgM desarrollan el Los PfM crean y man-
gradualmente la infor- plan general del progra- tienen los procesos y la
mación de alto nivel en ma y crean planes de comunicación necesaria
planes detallados a lo alto nivel para guiar la relacionada con el porta-
largo del ciclo de vida. planificación detallada a folio general.
nivel de componentes.
Dirección/ Los PM dirigen al equi- Los PgM dirigen al per- Los PfM pueden dirigir o
Gestión po del proyecto a fin de sonal del programa y a coordinar al personal de
cumplir con los objetivos los directores del pro- gestión del portafolio y
del mismo. yecto. Brindan visión y tienen la responsabilidad
liderazgo global. de informar al portafolio
general.
Éxito El éxito de un proyecto El éxito se mide por el El éxito se mide en térmi-
se mide por la calidad grado en el que el pro- nos del rendimiento de la
del producto y del programa satisface las ne- inversión y de los benefi-
yecto, la puntualidad, cesidades y beneficios cios del portafolio.
el cumplimiento con el que le dieron origen.
presupuesto y el gra-
do de satisfacción del
cliente.
Seguimiento Los PM monitorizan y Los PgM monitorizan el Los PfM realizan el segui-
controlan el trabajo que progreso de los compo- miento de los cambios
consiste en obtener los nentes de programas a estratégicos y asignación
productos, servicios fin de asegurar que se de recursos, resultados de
o resultados para los cumpla con los objetivos rendimiento y riesgos del
cuales el proyecto fue globales, cronogramas, portafolio.
emprendido. presupuesto y benefi-
cios 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.
El éxito se mide por ausencia de retrasos y sobrecostes, calidad del producto y satisfac-
1
ció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.
El responsable gestiona al equipo del para conseguir los objetivos de plazo, coste y alcan-
4
ce.
El responsable gestiona a su equipo y a los Project Managers, aportando visión de lideraz-
5
go global.
6 El seguimiento se basa en el control del rendimiento agregado y KPIs.
18
El seguimiento se basa en el control del progreso de los componentes para asegurar los
7
objetivos globales, plazos, costes y beneficios consolidados.
8 El seguimiento se basa en el control de la producción de productos, servicios o resultados.
Tiene un alcance amplio orientado a la entrega de beneficios significativos para el nego-
9
cio.
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 con-
trolados.
13 El responsable monitoriza continuamente los cambios en un marco amplio orientado a la

estrategia de la organización y al 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 planifica-

ció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
19
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:
4. 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 más eficiente de los recursos mediante el establecimiento de prioridades y la
integración de los proyectos.
5. 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.
6. 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
20
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.4. 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, 2.100
capacidades, 2.200 indicadores clave de
desempeño). Las evaluaciones de madurez pueden ser realizadas
oficialmente por personas con la titulación Certificado Profesional en OPM3®.
21
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 diferentes2.
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).
4.5. 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
1 Puede haber interesados positivos (como el patrocinador) y también negativos (e.g. los ecologistas que quieren detener
un 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.
22
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.
● 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.
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.
23
4.6. 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.7. 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).
24
4.8. 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):
Ejercen el control de los proyectos asumiendo la propia dirección de los mismos.
4.9. 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
25
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.10. 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.11. 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.
26
● 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.12. 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.13. FASES DE UN PROYECTO
El 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í:
27
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”
o “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 e

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.14. 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
28
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.15. 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-TIZADA
FUNCIONAL
Débil Equilibrada Fuerte
Poca / nin- Baja / mo- Alta / casi
Autoridad Limitada Moderada / alta
guna derada total
Disponibilidad Poca / nin- Baja / mo- Alta / casi
Limitada Moderada / alta
de recursos guna derada total
Control del Pre- Gerente Gerente Combina- Director del pro- Director del
supuesto funcional funcional ción yecto 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:
29
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:
30
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.
31
5.
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.
GESTIÓN DE PROYECTOS 2.0
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.
32
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 gerente 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:
33
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
34
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 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 y 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. Una 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®:
35
● 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.
36
DIRECCIÓN DE PROYECTOS EN EL SXXI
6.
● 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 de los ciclos
de vida predictivos en que las iteraciones son muy rápidas
TERMINOLOGÍA DEL PMI
(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.
37
● 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
38
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.
39
7.
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.
ANEXO I: EL PROJECT
Es verdad que muchas veces se observa todo esto en los proyectos

MANAGER ÁGIL
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:
40
En un proyecto predictivo se cierran la mayor parte de los requisitos al principio y después se

avanza por fases secuenciales. 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
41
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:
42
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.
43
● 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.
44
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.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.
1.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.
1.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.
1.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.
1.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.
1.6. Mejorar la creatividad experimentando con nuevas técnicas e ideas sobre los
procesos, para descubrir formas de trabajar más eficientes y eficaces.
1.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.
1.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.
1.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.
45
En el dominio 2. Entregar conforme al Valor:
2.1. Definir Valor Positivo:
Definir entregables identificando unidades que puedan producirse incrementalmente

para maximizar su valor para los interesados minimizando las actividades que no aporten
valor.
Refinar los requisitos lo más tarde posible consensuando los criterios de aceptación de
las funcionalidades para entregar valor.
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:
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.
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.
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:
Priorizar las unidades de trabajo a través de la colaboración con los interesados para
optimizar el valor de los entregables.
Realizar revisiones y mantenimientos frecuentes de los resultados del trabajo priorizando

y manteniendo internamente la calidad para reducir el coste total del desarrollo
incremental.
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:
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.
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.
Re-priorizar periódicamente los requisitos para reflejar cambios en el entorno y

necesidades o preferencias de los interesados para maximizar el valor.
46
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.
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:
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.
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
Establecer relaciones con los interesados construyendo acuerdos de trabajo entre los
interesados clave para promover la participación y la colaboración efectiva.
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.
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:
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.
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.
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.
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.
47
En el dominio 4. Desempeño del Equipo:
4.1. Desarrollo del Equipo:
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.
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:
Animar a los miembros del equipo a convertirse en especialistas generalistas para reducir
el tamaño del equipo y los cuellos de botella,
Contribuir a la auto-organización del trabajo facultando a otros y fomentando el liderazgo

emergente para generar soluciones efectivas y gestionar la complejidad.
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:
Facilitar la estrecha comunicación dentro del equipo y con los interesados externos
apropiados mediante la co-ubicación o el uso de herramientas de colaboración para
reducir la mala comunicación y el retrabajo.
Reducir distracciones para establecer resultados predecibles y optimizar el valor

entregado.
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.
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:
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.
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
48
de compromiso y reducir la incertidumbre.
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:
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, la complejidad y/o la
criticidad de los entregables del proyecto para maximizar el valor.
Inspeccionar y adaptar el plan del proyecto para reflejar los cambios en los requisitos,
cronograma y 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:
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.
Ajustar la capacidad incorporando demandas de operación y mantenimiento y otros

factores para crear un rango de estimación actualizado.
Crear un rango de estimación para el alcance inicial, el cronograma y el coste, que reflejen
el nivel actual de conocimiento, en un alto nivel, del esfuerzo necesario para entregar el
proyecto y desarrollar un punto inicial para gestionar el proyecto.
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.
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:
● 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.
● 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.
● 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.
● Mantener una lista de amenazas y problemas visible, monitorizada y priorizada para
49
elevar la responsabilidad, promover la actuación y monitorizar quién es dueño y el estado

de resolución.
● 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):
● 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.
● 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.
● Buscar retroalimentación del producto a partir de entregas incrementales y

demostraciones frecuentes para mejorar el valor del producto.
● 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.
● 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.
● 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.
50
Teléfono : +34 919 058 955
Whatsapp : +34 627 86 14 40
info@eobs.es
eobs.es

MODULO 1 MDGP Interactivo.

Cargado por

Copyright:

Formatos disponibles

MODULO 1 MDGP Interactivo.

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

MODULO 1 MDGP Interactivo.

Cargado por

Copyright:

Formatos disponibles

EUROPEAN OPEN BUSINESS SCHOOL - MDGP

3. LA GUÍA DEL PMBOK® 10

4. TERMINOLOGÍA COMÚN EN DIRECCIÓN DE PROYECTOS 16

4.1. Tipos de proyectos 16

4.2. Dirección de Proyectos 16

4.3. Proyecto, Programa y Portafolio 17

4.4. Modelo de Madurez OPM3® 21

4.5. Restricciones Contrapuestas (Competing Constraints) 22

4.6. Supuestos (Assumptions) 23

4.7. Elaboración Progresiva 24

4.8. Oficina de Gestión de Proyectos o Programas (PMO) 25

4.9. Sistema de Información para la Dirección de Proyectos 25

4.10. Activos de los Procesos de la Organización (APO) 26

4.11. Factores Ambientales de la Empresa (FAE) 26

4.12. Ciclo de Vida de un Producto 27

4.13. Fases de un Proyecto 27

4.14. La Organización y la Cultura de la Organización Ejecutora 28

4.15. La Estructura de la Organización Ejecutora 29

5. GESTIÓN DE PROYECTOS 2.0 32

6. TERMINOLOGÍA DEL PMI 37

7. ANEXO I: EL PROJECT MANAGER ÁGIL 40

En las organizaciones se distinguen principalmente dos tipos de

básicamente en tareas repetitivas, la producción, la administración

La gestión de proyectos hace posible los cambios en las

La organización de gestión de proyectos más reconocida a nivel

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

afectar al valor de la acción.

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

Actualmente, el PMI® cuenta con más de 600.000 afiliados (agosto

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

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

● CAPM® Certified Associate in Project Management (Certificado en Dirección de

● PMI-RPM® Risk Management Professional (Profesional en Gestión de Riesgos por el

● 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® Organizational Project Management Maturity Model Professional Certification

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

Solicitud del derecho a examen PMP® (Application Submission)

● Previamente a la solicitud, es preciso haber recibido formación presencial en gestión

- Si es titulado medio, debe demostrar que ha trabajado en proyectos durante más de

- Si es titulado superior, debe demostrar que ha trabajado en proyectos durante más

● Cuando se ha terminado de cumplimentar la solicitud, hay 5 días para hacer rectificaciones.

● El PMI® revisará la solicitud y, si todo es correcto, contestará la aceptación antes de 5

Preparación del Examen

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

He aquí algunos datos sobre el examen PMP®.

● Cuando se completa el examen, instantáneamente se sabe si se ha superado o no. Se

Requisitos de Certificación Continua (CCR)

● 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.

la sexta, fue publicada en septiembre de 2017. En la actualidad está

Es importante recalcar que la Guía del PMBOK® es una guía, no

El cuerpo principal de la guía, para proyectos Predictivos (iniciamos

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