El mapa de la disciplina
Proyecto, programa y portfolio; quién manda en un proyecto; y qué son PMBOK, PRINCE2, ISO 21500, CMMI y SWEBOK, y cómo encajan entre sí.
- Clasificar una iniciativa como proyecto, programa o portfolio y justificarlo.
- Decir cuánta autoridad tiene el jefe de proyecto según la estructura de la organización.
- Distinguir los estándares de gestión de proyectos (PMBOK, PRINCE2, ISO 21500) de los que no lo son (CMMI, ISO 27001, SWEBOK, Métrica 3…).
- Explicar qué cambió del PMBOK 6 (procesos) al 7 (principios y dominios) y al 8.
- Situar cualquier acción de gestión en su área de conocimiento o dominio.
Las diapositivas citan el PMBOK 7 como referencia fundamentalTema 1, diap. 73 y 76: PMBOK 7, The Standard for Project Management, IEEE. pero no lo desarrollan. Esta lección es casi toda ampliación: es el vocabulario común que cualquier profesor de gestión da por sabido. Los exámenes antiguos preguntaban justo esto: portfolio frente a programa, qué estándares son "de gestión de proyectos", a qué grupo de procesos pertenece una actividad o en qué área cae una acción.
1. Proyecto, programa y portfolio
En la lección 1 viste qué es un proyecto. Pero las organizaciones no tienen un proyecto, tienen decenas, y necesitan agruparlos. El PMI define tres niveles:Definiciones del PMI (PMBOK 6, §1.2.3; The Standard for Program Management; The Standard for Portfolio Management). Resumen abierto en PMI Learning Library.
| Proyecto | Programa | Portfolio (cartera) | |
|---|---|---|---|
| Qué es | Esfuerzo temporal para un resultado único | Grupo de proyectos (y subprogramas) relacionados, gestionados de forma coordinada para obtener beneficios que no se obtendrían gestionándolos por separado | Colección de proyectos, programas, subportfolios y operaciones, gestionados como grupo para alcanzar objetivos estratégicos |
| ¿Sus componentes están relacionados? | — | Sí, contribuyen a un beneficio común | No necesariamente; basta con que sirvan a la estrategia |
| Pregunta que responde | ¿Lo hacemos bien? (entregar) | ¿Obtenemos el beneficio conjunto? (coordinar) | ¿Hacemos los proyectos correctos? (seleccionar, priorizar) |
| Actividades típicas | Charter, plan, ejecución, control, cierre | Coordinar dependencias e interfaces entre proyectos, gestionar beneficios | Identificar, evaluar, priorizar, seleccionar y autorizar iniciativas; equilibrar inversión y resolver conflictos de recursos entre ellas |
| Horizonte | Hasta que termina | Hasta que se obtienen los beneficios | Continuo (sigue la estrategia) |
Con TusBus: la app TusBus es un proyecto. Si el ayuntamiento lanza "Movilidad Inteligente 2027" con la app, las pantallas en las paradas, el billete por móvil y la reorganización de líneas, y quiere que juntos reduzcan un 15 % el uso del coche, eso es un programa: los proyectos se necesitan unos a otros (el billete usa la app, las pantallas usan los mismos datos de GPS) y el beneficio sólo aparece si se coordinan. Y el conjunto de todas las inversiones del área de tecnología del ayuntamiento (el programa de movilidad, la renovación del padrón, el mantenimiento de la web municipal, que es una operación) es su portfolio.
- "Un portfolio sólo contiene proyectos y subprogramas": falso. Contiene proyectos, programas, subportfolios y operaciones.
- "El portfolio busca eficiencia en la gestión conjunta de proyectos interrelacionados": eso describe un programa. El portfolio busca alineamiento estratégico y el máximo beneficio de la inversión.
- "Si varios proyectos comparten recursos o tecnología, hay que crear un programa": cuidado. Compartir recursos no basta: lo que define el programa es que gestionarlos juntos produce un beneficio que por separado no habría. Los conflictos de recursos entre proyectos no relacionados se resuelven en el nivel de portfolio.
- Elaborar el charter o el plan de un proyecto no son actividades de portfolio: son del propio proyecto. El portfolio identifica, prioriza, selecciona y autoriza.
Dónde encaja la oficina de proyectos (PMO)
Una PMO (Project Management Office) es la estructura de la organización que estandariza cómo se gestionan los proyectos: plantillas, herramientas, formación, informes y, a veces, la gestión directa de proyectos. Puede ser de apoyo (aconseja), de control (exige cumplir sus normas) o directiva (gestiona los proyectos ella misma).Tipos de PMO: PMBOK 6, §2.4.4.3. Es pieza de gobernanza, que verás en la lección 17.
2. ¿Quién manda? Estructuras organizativas
En la lección 1 viste que el equipo de un proyecto es temporal y no sigue la estructura de departamentos. Pero ¿quién tiene la autoridad sobre esas personas? Depende de la estructura de la organización:Ampliación. Estructuras e influencia en los proyectos: PMBOK 6, tabla 2-1; también en SWEBOK v4, KA Software Engineering Management.
| Estructura | Cómo es | Autoridad del jefe de proyecto (JP) |
|---|---|---|
| Funcional | Organizada por departamentos (desarrollo, sistemas, marketing). El proyecto se "pide prestado" a los departamentos. | Muy baja o nula. Manda el jefe de departamento; el JP es a menudo un coordinador a tiempo parcial. |
| Matricial débil | Departamentos fuertes; el JP es coordinador o "facilitador". | Baja. |
| Matricial equilibrada | El JP y el jefe funcional comparten la autoridad. Cada persona tiene dos jefes. | Media. Fuente frecuente de conflictos. |
| Matricial fuerte | Existen JP de dedicación completa, a menudo en una PMO. | Alta. |
| Orientada a proyectos (projectized) | La organización se estructura en proyectos (típico en consultoras). El equipo depende del proyecto. | Muy alta, casi total. |
Tu consultora de 12 personas que hace TusBus es casi seguro orientada a proyectos: el JP decide. En cambio, si el ayuntamiento hiciera la app con su propio departamento de informática, sería probablemente funcional o matricial débil: el JP tendría que negociar cada hora de cada programador con su jefe de sección. Por eso, en un examen, "en un proyecto, generalmente el gestor tiene la máxima autoridad o conexión directa con quien la tiene" describe el ideal del proyecto, mientras que "existe una línea jerárquica formal entre el gestor y una autoridad superior funcional" describe la operación.
Los roles que aparecen en todos los marcos
- Patrocinador (sponsor): quien aporta los recursos y respalda el proyecto ante la dirección. Aprueba el charter, decide los cambios grandes, quita obstáculos. Sin sponsor, el proyecto no tiene quien lo defienda.
- Jefe de proyecto (JP, project manager): responsable de que el equipo consiga los objetivos. Planifica, coordina, controla, comunica. En marcos ágiles su papel se reparte (Product Owner, Scrum Master, el propio equipo).
- Cliente / usuarios: quien paga y quien usa (no siempre coinciden: en TusBus paga el ayuntamiento y usan los viajeros).
- Equipo del proyecto: quien hace el trabajo.
- Comité de dirección (steering committee): órgano que toma decisiones por encima del JP; en PRINCE2 se llama Project Board.
- Product Owner (ágil): decide el orden del trabajo según el valor; representa al negocio.
3. Los estándares: qué es cada uno
Hay muchas siglas. Lo importante es saber de qué trata cada una, porque el examen pregunta "¿cuáles son específicos de gestión de proyectos?".
| Nombre | Quién | Qué es | ¿De gestión de proyectos? |
|---|---|---|---|
| PMBOK® Guide | PMI (EE. UU.) | Guía de los fundamentos de la dirección de proyectos. La más citada del mundo. Ediciones 6 (2017), 7 (2021), 8 (2025). | Sí |
| PRINCE2® | Gobierno británico → AXELOS → PeopleCert | PRojects IN Controlled Environments. Un método prescriptivo: dice qué roles, procesos y documentos usar. 7ª ed. en 2023. | Sí |
| ISO 21500 / 21502 | ISO | Norma internacional. ISO 21500:2021 da el contexto y conceptos de la gestión de proyectos, programas y portfolios; ISO 21502:2020 es la guía de gestión de proyectos. | Sí |
| CMMI | CMMI Institute (ISACA) | Modelo de madurez de procesos de una organización (niveles 1-5: inicial, gestionado, definido, gestionado cuantitativamente, optimizado). Incluye prácticas de planificación y control, pero su objeto es la mejora de procesos. | No (mejora de procesos) |
| ISO/IEC 27001 (familia 27000) | ISO/IEC | Sistemas de gestión de la seguridad de la información. | No (seguridad) |
| ISO/IEC 25010 | ISO/IEC | Modelo de calidad del producto software (lección 15). | No (calidad) |
| SWEBOK v4 | IEEE Computer Society | Cuerpo de conocimiento de toda la ingeniería del software; la gestión es una de sus áreas. | No (es más amplio) |
| Métrica 3 | Administración española | Metodología de desarrollo de sistemas de información para la administración pública; tiene una "interfaz" de gestión de proyectos, pero es una metodología de desarrollo. | No (desarrollo) |
| Scrum / Manifiesto Ágil | Schwaber y Sutherland / 17 autores (2001) | Marco ágil y su filosofía. Gestionan trabajo de forma adaptativa (lección 7). | Marco de trabajo ágil |
| DevOps | — | Cultura y prácticas que unen desarrollo y operación (lección 18). No es un estándar. | No |
El PMBOK te dice qué hay que saber para gestionar (un cuerpo de conocimiento, descriptivo). PRINCE2 te dice cómo hacerlo paso a paso (un método, prescriptivo). Se complementan: muchas empresas europeas usan PRINCE2 como método con conocimientos del PMBOK.
PRINCE2 en lo esencial
PRINCE2 7 se organiza en 7 principios, 7 prácticas y 7 procesos, con un elemento nuevo, personas.KnowledgeTrain: diferencias PRINCE2 6 y 7. Fuente primaria: PeopleCert, Managing Successful Projects with PRINCE2, 7ª ed. (2023). Los principios son los que más se preguntan, porque son ideas universales:
- Justificación de negocio continua: el proyecto debe seguir teniendo sentido económico durante toda su vida; si deja de tenerlo, se cancela.
- Aprender de la experiencia (lecciones aprendidas, lección 11).
- Roles y responsabilidades definidos.
- Gestionar por fases (stages): se autoriza fase a fase, no todo de golpe.
- Gestionar por excepción: se fijan tolerancias (p. ej. ±10 % de coste); mientras el JP esté dentro, decide solo; si se van a superar, escala al comité. Lo verás reaparecer como "tolerancias" en riesgos (lección 13).
- Centrarse en los productos (entregables definidos con criterios de calidad).
- Adaptar al entorno del proyecto (tailoring).
Las prácticas (antes "temas") son: caso de negocio, organización, calidad, planes, riesgo, incidencias (issues) y progreso.
4. PMBOK: tres ediciones, dos filosofías
El PMBOK ha cambiado de enfoque, y el examen puede preguntar por cualquiera de sus versiones: la 6ª es la que domina en la literatura y en exámenes antiguos, la 7ª es la que citan las diapositivas, la 8ª es la vigente.
PMBOK 6 (2017): procesos
Organiza la gestión en 49 procesos, clasificados de dos formas a la vez:
- En 5 grupos de procesos: Inicio, Planificación, Ejecución, Seguimiento y control, Cierre.
- En 10 áreas de conocimiento: Integración, Alcance, Cronograma (en la 5ª ed. "Tiempo"), Costes, Calidad, Recursos (en la 5ª "Recursos Humanos"), Comunicaciones, Riesgos, Adquisiciones e Interesados (stakeholders).
Los grupos de procesos no son fases del proyecto. Un proyecto tiene fases (análisis, diseño, construcción… o sprints), y dentro de cada fase se ejecutan los cinco grupos. Además, los grupos se solapan e iteran: mientras ejecutas, controlas; si el control detecta una desviación, vuelves a planificar. Por eso son falsas:
- "El PMBOK no considera fases; sus grupos de procesos se aplican siempre al proyecto global de principio a fin."
- "Los procesos de Planificación deben ejecutarse antes que los de Ejecución y Control" (en sentido estricto: la planificación es continua; se replanifica durante todo el proyecto).
Ejemplos de procesos que conviene saber colocar, porque salen en preguntas de emparejar:
| Grupo | Procesos típicos |
|---|---|
| Inicio | Desarrollar el acta de constitución (Project Charter) · Identificar a los interesados |
| Planificación | Recopilar requisitos · Definir el alcance · Crear la EDT · Definir y secuenciar actividades · Estimar duraciones y costes · Determinar el presupuesto · Planificar la gestión de calidad, riesgos, comunicaciones, adquisiciones… |
| Ejecución | Dirigir y gestionar el trabajo (aquí cae "hacer el diseño técnico" o "programar") · Gestionar la calidad (aseguramiento) · Adquirir y desarrollar el equipo · Gestionar las comunicaciones · Efectuar las adquisiciones |
| Seguimiento y control | Controlar el alcance · Controlar el cronograma y los costes · Controlar la calidad · Monitorizar los riesgos · Control integrado de cambios |
| Cierre | Cerrar el proyecto o la fase (en la 5ª ed. también "cerrar las adquisiciones") |
Fíjate en una pista: identificar a los interesados y desarrollar el charter son las dos únicas cosas que se hacen al inicio. Hacer la EDT, planificar la calidad o gestionar costes vienen después. Una pregunta clásica es "¿qué debe hacerse al inicio del proyecto?": identificar interesados y el Project Charter.
Las áreas de conocimiento, aplicadas
Otra pregunta clásica: "¿en qué área situarías esta acción?". Aprende a reconocer el objeto de la acción:
| Acción | Área | Por qué |
|---|---|---|
| Hacer una matriz de trazabilidad de requisitos | Alcance | Asegura que se hace todo lo pactado y sólo eso |
| Estimar la duración de cada tarea | Cronograma | Es tiempo |
| Controlar que no se supere el presupuesto (o las horas asignadas) | Costes | En software, horas = dinero |
| Revisión entre pares del documento de arquitectura; auditoría de procesos | Calidad | Comprueba el cumplimiento de estándares |
| Explicar a cada persona su rol y funciones | Recursos | Gestión del equipo |
| Montar una wiki del proyecto; enviar el informe de estado | Comunicaciones | Información a quien la necesita |
| Reunirse porque la tecnología es nueva y no la dominamos; alguien se ha puesto enfermo y no sabemos cuándo vuelve | Riesgos | Incertidumbre sobre los objetivos |
| Redactar un pliego de condiciones (RFP) para subcontratar; reunión de arranque con un proveedor | Adquisiciones | Comprar fuera |
| Hacer la lista de implicados y decidir cómo involucrarlos | Interesados | Stakeholders |
| Control integrado de cambios; coordinar todo el plan | Integración | Une todas las áreas |
PMBOK 7 (2021): principios y dominios
La 7ª edición rompe con los procesos.Resumen verificado de la 7ª y 8ª en 4PMTI; fuente primaria: PMI, PMBOK Guide. Su razón: los proyectos modernos (sobre todo de software) no siguen recetas, así que el PMBOK pasa a describir principios (cómo pensar) y dominios de desempeño (qué áreas de actividad hay que cuidar para lograr resultados), y propone adaptar (tailoring) el enfoque al proyecto. Es independiente del enfoque: sirve para predictivo, ágil e híbrido.
- 12 principios: ser un administrador diligente (stewardship) · crear un entorno colaborativo de equipo · involucrar a los interesados · centrarse en el valor · pensamiento sistémico · liderazgo · adaptar (tailoring) · calidad · complejidad · riesgo · adaptabilidad y resiliencia · gestionar el cambio.
- 8 dominios: Interesados · Equipo · Enfoque de desarrollo y ciclo de vida · Planificación · Trabajo del proyecto · Entrega · Medición · Incertidumbre.
El dominio de Incertidumbre es justo el que citan las diapositivas en riesgos: "riesgo = efecto de la incertidumbre sobre los objetivos".Tema 2, diap. 8.
PMBOK 8 (noviembre de 2025): síntesis
La 8ª edición recupera parte de la estructura de procesos sin perder los principios:
- 6 principios: adoptar una visión holística · centrarse en el valor · integrar la calidad · ser un líder responsable · integrar la sostenibilidad · construir una cultura de empoderamiento.
- 7 dominios: Gobernanza · Alcance · Cronograma · Finanzas · Interesados · Recursos · Riesgo.
- 5 áreas de enfoque: Inicio · Planificación · Ejecución · Seguimiento y control · Cierre (los antiguos grupos de procesos, ahora como áreas de enfoque).
- Unos 40 procesos no prescriptivos (frente a 49 en la 6ª).
6ª = receta (procesos × áreas). 7ª = filosofía (principios × dominios, sin procesos). 8ª = síntesis (pocos principios + dominios + vuelven los procesos, flexibles). El hilo conductor de la evolución es el mismo que verás en todo el curso: pasar de "seguir el plan" a "entregar valor adaptándose a la incertidumbre".
5. SWEBOK: la gestión dentro de la ingeniería del software
El SWEBOK v4 (IEEE Computer Society, 2024) describe lo que todo ingeniero del software debería saber, en 18 áreas de conocimiento (requisitos, arquitectura, diseño, construcción, pruebas, operaciones, mantenimiento, configuración, gestión, procesos, modelos, calidad, seguridad, práctica profesional, economía…).SWEBOK v4.0, gratuito. El área Software Engineering Management cubre: iniciación y definición del alcance, planificación, ejecución, revisión y evaluación, cierre y medición. Es, casi literalmente, el índice de nuestro Tema 1. El área Software Engineering Economics cubre lo que veremos en costes y viabilidad.
6. El mapa del curso con esta brújula
Ahora puedes situar cada lección en el PMBOK 6 (áreas) y en el 8 (dominios):
| Lecciones | Área PMBOK 6 | Dominio PMBOK 8 |
|---|---|---|
| 3 Definición, charter | Integración, Alcance | Gobernanza, Alcance |
| 4-5 Requisitos, priorización | Alcance | Alcance |
| 8 Stakeholders | Interesados | Interesados |
| 9-10 Planificación, estimación | Cronograma, Costes | Cronograma, Finanzas |
| 12-13 Riesgos | Riesgos | Riesgo |
| 14 Costes | Costes | Finanzas |
| 15 Calidad | Calidad | (principio "integrar la calidad") |
| 16 Personas | Recursos, Comunicaciones | Recursos |
| 17 Gobernanza | Integración | Gobernanza |
Práctica
Responde sin mirar arriba. Si dudas, elige y lee la explicación: el error razonado enseña más que el acierto por suerte.
¿Qué afirmaciones corresponden a un portfolio (las que no, describen un programa)?
- Puede contener proyectos, programas, subportfolios y operaciones
- Busca eficiencia coordinando proyectos que están interrelacionados
- Sus componentes no tienen por qué estar relacionados entre sí
- Agrupa proyectos para obtener un beneficio conjunto imposible por separado
- Se gestiona para estar alineado con los objetivos estratégicos
- Debe ayudar a resolver conflictos de recursos entre muchas iniciativas
¿Qué actividades tienen sentido en la gestión de un portfolio?
- Identificar los posibles proyectos de la organización
- Elaborar el plan detallado de cada uno de los proyectos
- Priorizar y seleccionar qué iniciativas se van a hacer
- Redactar el project charter de cada uno de los proyectos
- Autorizar las iniciativas que se han seleccionado
- Asignar los roles concretos dentro de cada proyecto
Una gran empresa organizada por departamentos asigna a Lucía como "jefa de proyecto" de una nueva intranet. Los programadores siguen dependiendo del jefe de desarrollo, que decide sus horas. ¿Qué estructura es y cuánta autoridad tiene Lucía?
- Orientada a proyectos: Lucía tiene una autoridad casi total sobre el equipo
- Matricial fuerte: Lucía tiene una autoridad alta y dedicación completa al proyecto
- Funcional o matricial débil: la autoridad de Lucía es baja y debe negociar
- Matricial equilibrada: la autoridad se reparte a partes iguales con el jefe
¿Cuáles de los siguientes son estándares o métodos específicos de gestión de proyectos?
- ISO/IEC 27001
- PMBOK Guide
- CMMI
- PRINCE2
- DevOps
- ISO 21500
Empareja cada proceso del PMBOK 6 con su grupo de procesos.
- Desarrollar el acta de constitución del proyecto
- Identificar a los interesados
- Crear la EDT (estructura de desglose del trabajo)
- Realizar el diseño técnico del software
- Controlar la calidad de los entregables
- Planificar la gestión de los riesgos
- Cerrar el proyecto o la fase
Verdadero o falso: "El PMBOK no considera fases; sus grupos de procesos se aplican siempre al proyecto global, de principio a fin".
- Verdadero
- Falso
¿En qué área de conocimiento del PMBOK 6 sitúas cada acción?
- Redactar un pliego de condiciones para externalizar parte del desarrollo
- Hacer una revisión entre pares del documento de arquitectura
- Construir una matriz de trazabilidad de los requisitos
- Enviar a todos los implicados un informe de estado del proyecto
- Analizar qué pasa si la tecnología elegida resulta inmadura
- Vigilar que no se sobrepasa el presupuesto aprobado
- Listar quién se ve afectado por el proyecto y cómo implicarlo
¿Qué describe mejor el cambio del PMBOK 6 al PMBOK 7?
- Pasa de 10 áreas a 5, porque se fusionan las que se solapaban entre sí
- Pasa de procesos prescriptivos a principios y dominios de desempeño
- Pasa de un enfoque ágil a uno predictivo, más adecuado para la industria
- Pasa de describir proyectos a describir solo programas y los portfolios
Un comité aprueba un proyecto con un presupuesto de 100.000 € y una tolerancia de ±10 %. A mitad del proyecto, el JP prevé un coste final de 106.000 €. Según el principio de PRINCE2 "gestionar por excepción", ¿qué hace?
- Convoca de urgencia al comité para que apruebe el nuevo coste previsto
- Detiene el proyecto hasta que el comité revise todas las cifras de coste
- Sigue gestionando él mismo, porque está dentro de la tolerancia acordada
- Recorta alcance sin consultar para volver exactamente a los 100.000 €
Explica con un ejemplo propio por qué los grupos de procesos del PMBOK 6 no son fases del proyecto.
Repaso espaciado · lección 1
¿Cuál de estas iniciativas es una operación y no un proyecto?
- Desarrollar un módulo de pagos para la app de una cadena de tiendas
- Atender cada semana las peticiones de soporte de la app de las tiendas
- Elaborar un estudio de viabilidad de una app para la cadena de tiendas
- Migrar la base de datos de la app de las tiendas a un proveedor cloud
¿Cuáles son las seis restricciones del proyecto y qué añade la visión moderna a la tríada clásica?
Para profundizar
PMI Learning Library: relaciones y diferencias entre gestión de programas y de proyectos (inglés, artículo de congreso) y, para el portfolio, Implementing strategy: program and project portfolio management. Después, ojea el índice del SWEBOK v4, capítulo Software Engineering Management: verás que cada apartado es una lección de este curso.
Si quieres ver el PMBOK 8 por dentro sin comprarlo: el resumen de 4PMTI.
Si algo no te queda claro, pega el párrafo en un asistente (Claude en el móvil sirve) y pídele otro ejemplo o que te haga preguntas. Para dudas sobre qué entra o cómo lo interpreta el profesor, la tutoría es la fuente más fiable.
Resumen imprimible: Referencia · Fundamentos.