Curso · Tema 1 · Lección 11 de 19

Ejecución, control (PDCA) y cierre

El plan ya existe. Ahora hay que hacer el trabajo, saber de verdad cómo va, decidir qué hacer con cada desviación o cambio, contarlo a quien corresponde y, al final, cerrar bien para que lo aprendido no se pierda.

Lo que vas a ser capaz de hacer al terminar

Explicar la visión moderna de ejecución y control: inspección y adaptación continua, no "verificar que se cumple el plan".
Aplicar el ciclo PDCA a una situación de seguimiento y formular las preguntas clave de control.
Distinguir riesgo, problema (issue), petición de cambio, no conformidad y decisión, y saber qué registro va a cada uno.
Describir el control de cambios y enumerar las actividades del cierre, incluido por qué importan las lecciones aprendidas.

Por qué importa para el examen

Tema 1, diap. 62-64 (ejecución y control, PDCA) y 67-68 (cierre). En exámenes antiguos aparecen preguntas como "¿cuáles de estos son un tipo de registro del proyecto?" (petición de cambio, problema, riesgo, no conformidad) o emparejar procesos con su grupo (Ejecución, Monitorización y Control, Cierre). Ampliación: control integrado de cambios, informes de estado, medición del progreso, canales de comunicación y la práctica de lecciones aprendidas.

1. Ejecutar y controlar: la visión moderna

Las diapositivas lo plantean como un cambio de mentalidad: la ejecución y el control ya no se conciben como una mera verificación del cumplimiento del plan inicial, sino como un proceso dinámico de inspección y adaptación continua. Los controles rígidos y puntuales se sustituyen por revisiones frecuentes (daily stand-ups, revisiones de sprint) que detectan desviaciones pronto y permiten reorientar el rumbo de forma colaborativa, aceptando que el plan es una guía abierta a reescritura.Tema 1, diap. 62.

En concreto, se trata de cuatro cosas:

Ejecutar el trabajo planificado: coordinar personas y recursos para producir los entregables.
Medir progreso y resultados: no actividad ("hemos trabajado mucho"), sino avance verificable.
Gestionar cambios, riesgos, problemas y decisiones: cada uno con su tratamiento (sección 4).
Comunicar continuamente a los stakeholders: la información adecuada a cada uno (lección 8).

Esto no significa que "no haya plan" ni que "todo valga". Recuerda la lección 9: la línea base sigue ahí para medir cuánto te desvías; lo que cambia es que la desviación se trata como información para decidir, no como un fracaso que se esconde.

En el PMBOK 6 esto corresponde a dos grupos de procesos que funcionan a la vez, no uno detrás de otro: Ejecución (p. ej. "Dirigir y gestionar el trabajo del proyecto", "Gestionar la calidad", "Gestionar las comunicaciones") y Monitoreo y Control (p. ej. "Controlar el alcance", "Controlar el cronograma", "Realizar el control integrado de cambios", "Monitorear los riesgos").Ampliación. PMBOK 6, grupos de procesos (lección 2). En la 8ª ed. son las áreas de enfoque Ejecución y Seguimiento y control. Por eso en un examen antiguo era falso que "los procesos de Planificación deben ejecutarse antes que los de Ejecución y Control": se solapan y se repiten.

2. El ciclo PDCA

El ciclo PDCA (Plan-Do-Check-Act: planificar, hacer, verificar, actuar) aplicado al control de proyectos convierte la gestión en un bucle de mejora continua, de modo que cada desviación detectada sea una oportunidad de aprendizaje y no un fracaso del plan.Tema 1, diap. 63-64. Origen: Walter Shewhart (años 30) y W. Edwards Deming, que lo difundió en Japón; por eso también se llama "ciclo de Deming". Ver PDCA.

Fase	Qué se hace	TusBus, semana 8
Plan (planificar)	Fijar qué se quiere lograr y cómo	Plan de la iteración: terminar ingesta de GPS y pantalla de parada
Do (hacer)	Ejecutar	El equipo desarrolla
Check (verificar)	Medir y comparar con lo planificado	La ingesta funciona, pero la pantalla no: la API de GPS devuelve datos con 2 min de retraso
Act (actuar)	Decidir y ajustar: corregir, estandarizar lo que funcionó o cambiar el plan	Se registra un problema, se pide al ayuntamiento otra fuente de datos y se ajusta el plan de la siguiente iteración

La fase que más se olvida es Act: medir sin decidir nada es burocracia. Por eso las diapositivas dan unas preguntas clave para cada ciclo de control:

¿Vamos tarde? (y, por extensión, ¿vamos por encima de coste? ¿la calidad es la esperada?)
¿Qué ha cambiado? (requisitos, contexto, personas, supuestos)
¿Qué riesgo ha cambiado? (alguno ha crecido, se ha materializado o ha desaparecido)
¿Qué decisión debemos tomar ahora? (la pregunta que da sentido a las tres anteriores)

El PDCA aparece en muchos sitios del temario con otros nombres: el ciclo de gestión de riesgos (identificar → analizar → tratar → monitorizar, lección 12), la mejora del proceso de calidad (lección 15), las retrospectivas ágiles e incluso el ciclo DevOps (lección 18). Si entiendes PDCA, entiendes la lógica de todos.

3. Medir el progreso de verdad

La lección 1 lo avisaba: en software el progreso es invisible. Medirlo bien es la base del control.

Lo que no funciona: el "porcentaje completado" subjetivo

Si preguntas a un desarrollador "¿cuánto llevas?", la respuesta típica sube rápido hasta el 90 % y se queda ahí semanas: el síndrome del 90 % ("el primer 90 % del trabajo lleva el 90 % del tiempo; el 10 % restante, el otro 90 %"). Las diapositivas lo advierten en el Tema 2: medir "porcentaje completado" de funcionalidades puede generar una falsa sensación de precisión.Tema 2, diap. 52.

Lo que sí funciona

Hitos objetivos (lección 9): "pruebas de la API superadas en integración" se cumple o no.
Criterios de "terminado" binarios: una funcionalidad cuenta como hecha sólo cuando cumple sus criterios de aceptación (lección 4) o la Definition of Done. Reglas como 0/100 (no cuenta hasta que se termina) o 50/50 (la mitad al empezar, la otra mitad al terminar) evitan el porcentaje subjetivo.
Software funcionando: demos al final de cada iteración. El Manifiesto Ágil lo dice así: "software funcionando como medida principal de progreso".Principios del Manifiesto Ágil.
Gráficos de tendencia: burndown (trabajo pendiente que baja) o burnup (trabajo hecho que sube frente al alcance total, que también puede subir: así se ve el scope creep).
Valor ganado (EVM) para coste y plazo a la vez (lección 14).

Informar del estado

Un informe de estado resume para los stakeholders cómo va el proyecto: progreso frente a la línea base, hitos, riesgos y problemas principales, decisiones necesarias. Es habitual el semáforo RAG (Red-Amber-Green): verde = en control, ámbar = desviación que el equipo puede manejar, rojo = hace falta una decisión de arriba. Un informe que siempre está en verde hasta la semana antes de la entrega ("watermelon reporting": verde por fuera, rojo por dentro) es un fallo de gestión, normalmente por falta de seguridad psicológica (lección 16).

4. Riesgos, problemas, cambios y decisiones

"Gestionar cambios, riesgos, problemas y decisiones" (diap. 62) exige no mezclarlos, porque cada uno se trata de forma distinta. Por eso los proyectos llevan varios registros:

Registro	Qué contiene	Tiempo	TusBus
Riesgo	Algo incierto que podría ocurrir y afectar a los objetivos	Futuro	"El ayuntamiento podría retrasar el acceso a la API"
Problema (issue, incidencia)	Algo que ya ha ocurrido y hay que resolver	Presente	"La API devuelve datos con 2 minutos de retraso"
Petición de cambio	Solicitud formal de modificar algo de la línea base (alcance, plazo, coste…)	—	"Añadir pago de billetes desde la app"
No conformidad	Incumplimiento de un requisito, norma o procedimiento de calidad	Presente	"La pantalla de parada no cumple el contraste mínimo de accesibilidad"
Decisión	Qué se decidió, quién, cuándo y por qué	Pasado	"Se usa Flutter (ver ADR-003)"

En muchas empresas se agrupan en un "RAID log" (Risks, Assumptions, Issues, Dependencies/Decisions). Lo que no es un registro de gestión: el plan del proyecto, un fichero de datos de prueba, el comentario de un fichero fuente.

La distinción riesgo/problema es la más preguntada: un riesgo que se materializa se convierte en problema. Si estaba identificado y tenía un plan de contingencia, se activa (lección 13). "Confundir riesgo con problema ya ocurrido" es uno de los errores frecuentes que listan las diapositivas.Tema 2, diap. 44.

Control de cambios

En software los requisitos cambian (lección 1), y eso no es un fallo: lo que es un fallo es que cambien sin control (scope creep). El control integrado de cambios es el procedimiento para decidir cada cambio con información:Ampliación. PMBOK 6, §4.6 "Realizar el control integrado de cambios".

Petición de cambio→Análisis de impacto→Decisión→Actualizar línea base y planes→Comunicar

Análisis de impacto: ¿qué afecta en alcance, plazo, coste, calidad, riesgos? Aquí sirve la matriz de trazabilidad (lección 4): te dice qué diseño, código y pruebas cuelgan del requisito que cambia.
Decisión: la toma quien tenga autoridad según la gobernanza (lección 17): un comité de control de cambios (CCB), el sponsor, o el JP si está dentro de su tolerancia (PRINCE2, "gestión por excepción", lección 2).
Si se aprueba, se actualiza la línea base: es la única forma legítima de cambiarla.

En ágil el mecanismo es otro, pero la idea es la misma: el cambio entra como un elemento nuevo en el backlog, el Product Owner lo prioriza frente a lo demás, y lo que entra hace salir otra cosa del sprint o de la entrega. Las diapositivas lo resumen en la tabla de costes: tradicional = "analizar impacto en presupuesto/plazo"; ágil = "re-priorizar backlog".Tema 2, diap. 54.

5. Comunicar continuamente

Las diapositivas del Tema 1 dicen que la comunicación ineficaz es la principal causa de retrasos y errores, y recomiendan canales claros, reuniones periódicas (daily, retrospectivas), documentación "justa y suficiente" y equilibrio entre comunicación síncrona y asíncrona para evitar saturación.Tema 1, diap. 65.

Un dato que explica por qué la comunicación se complica tan rápido: en un grupo de n personas, el número de canales de comunicación posibles es

Canales = n · (n − 1) / 2 5 personas → 10 canales 10 personas → 45 canales 20 personas → 190 canales

Doblar el equipo multiplica por más de cuatro los canales. Es una de las razones de la ley de Brooks (lección 16) y de que los equipos ágiles sean pequeños.Ampliación. Brooks, F. (1975). The Mythical Man-Month; PMBOK 6, "Planificar la gestión de las comunicaciones".

El plan de comunicaciones (lección 8, stakeholders) responde: qué información necesita cada stakeholder, con qué frecuencia, por qué canal y quién la envía. Al concejal le basta un informe mensual con el semáforo y los hitos; al equipo, la daily y el tablero.

6. El cierre del proyecto

El cierre es una fase crítica que va más allá de entregar el producto: incluye la verificación final de requisitos, la documentación de lecciones aprendidas, la liberación de recursos, la transferencia a operaciones y la celebración del logro, para que el proyecto se archive de forma ordenada y su conocimiento perdure.Tema 1, diap. 67-68.

Actividad	Qué significa	Si se omite…
Verificar aceptación de entregables	El cliente acepta formalmente, contra los criterios de aceptación	El proyecto "no termina nunca": siempre falta un ajuste
Cerrar contratos y documentación	Cerrar contratos con proveedores, pagos, archivar documentación	Facturas pendientes, disputas, nadie sabe dónde está nada
Transferir conocimiento y operación	Entregar el sistema al equipo que lo opera y mantiene (documentación, formación, runbooks)	Operación recibe una caja negra; los fallos llegan al equipo de desarrollo ya disuelto
Registrar lecciones aprendidas	Qué funcionó, qué no, qué haríamos distinto	La organización repite los mismos errores; no hay datos para estimar por analogía
Liberar recursos	Las personas y equipos vuelven a su departamento o a otros proyectos	Personas "colgadas" de un proyecto que no acaba; costes que siguen corriendo
Celebrar el logro	Reconocer el trabajo del equipo	Desmotivación; el siguiente proyecto empieza con desgaste

Recuerda la lección 1: el cierre es el punto en que el producto pasa de proyecto a operación. Y un proyecto también se cierra cuando se cancela: si el estudio de viabilidad o el seguimiento muestran que ya no merece la pena, cerrarlo pronto y bien (con lecciones aprendidas) es una buena decisión de gestión, no un fracaso del JP.

En un contexto DevOps, el producto no "se entrega y se olvida": se sigue desplegando y operando. Por eso las diapositivas matizan que el cierre determina el fin del proceso de desarrollo inicial: el proyecto termina, el producto sigue vivo en operación (lección 18).

Lecciones aprendidas, bien hechas

Las lecciones aprendidas son la memoria de la organización. Aparecen en el temario como técnica de identificación de riesgos ("lecciones aprendidas de proyectos anteriores", lección 12) y son la base de la estimación por analogía (lección 10). Para que sirvan:

No esperar al final: el PMBOK recomienda recogerlas durante todo el proyecto; en ágil, cada retrospectiva es una pequeña sesión de lecciones aprendidas.
Sin culpables (blameless): se analiza qué falló en el sistema (proceso, información, herramientas), no quién. Si la gente teme ser señalada, oculta lo importante.Ampliación. Google, Site Reliability Engineering, cap. 15 "Postmortem Culture".
Accionables y localizables: "la API del ayuntamiento tardó 6 semanas en estar disponible; en el próximo proyecto con ellos, pedir acceso en la firma del contrato" es útil. "Comunicar mejor" no lo es.

Trampas típicas

"Controlar es comprobar que se cumple el plan inicial": hoy es inspeccionar y adaptar; el plan es una guía.
"Un riesgo y un problema son lo mismo": el riesgo es futuro e incierto; el problema ya ha ocurrido.
"Los procesos de Planificación terminan antes de que empiece la Ejecución": se solapan y se repiten durante todo el proyecto.
"El cierre es entregar el producto": incluye aceptación formal, contratos, transferencia, lecciones aprendidas, liberar recursos.
"Un cambio aprobado se mete en el plan y ya está": hay que actualizar la línea base y comunicarlo.
"En PDCA lo importante es medir": medir sin actuar (Act) no sirve de nada.

Práctica

Empareja cada situación de TusBus con el registro al que pertenece.

"El proveedor de mapas podría subir sus precios el año que viene"
"El servidor de pruebas lleva dos días caído y bloquea al equipo"
"El concejal pide añadir avisos de incidencias en las líneas"
"La revisión detecta que el código no sigue el estándar de nombres acordado"
"Se acuerda usar PostgreSQL en vez de MongoDB, y se explica por qué"

Riesgo = podría ocurrir; problema = ya ha ocurrido; petición de cambio = modificar la línea base; no conformidad = incumplir un estándar o requisito; decisión = qué se eligió y por qué (en arquitectura, un ADR).

Asocia cada acción con su fase del ciclo PDCA.

Fijar los objetivos de la iteración y cómo alcanzarlos
Desarrollar las funcionalidades de la iteración
Comparar lo conseguido con lo planificado
Decidir ajustar el plan de la siguiente iteración

Planificar, hacer, verificar (medir y comparar) y actuar (decidir y ajustar).

Un equipo de 8 personas, ¿cuántos canales de comunicación posibles tiene?

8 · 7 / 2 = 28. Con 4 personas serían 6: el doble de personas, casi cinco veces más canales.

Tres semanas seguidas, el desarrollador del backend informa de que su módulo está "al 90 %". ¿Qué debería hacer el JP?

Medir con criterios objetivos qué partes cumplen ya su aceptación
Añadir otro desarrollador al módulo para ayudarle a terminar el 10 %
Confiar en él, porque es quien mejor conoce el estado real del módulo
Marcar el módulo como terminado para que el informe de estado salga verde

Es el síndrome del 90 %: el porcentaje subjetivo da falsa precisión. Hay que pasar a medidas binarias (qué funcionalidades cumplen sus criterios, qué pruebas pasan) y averiguar qué bloquea. Añadir gente sin entender el problema puede empeorarlo (ley de Brooks).

El ayuntamiento pide añadir pago de billetes a TusBus a mitad del desarrollo. Siguiendo el control de cambios, ¿qué va primero?

Analizar su impacto en alcance, plazo, coste, calidad y riesgos
Implementarlo enseguida para mantener contento al cliente
Rechazarlo, porque la línea base aprobada no se puede tocar
Actualizar la línea base para incluirlo y luego estudiarlo

Petición → análisis de impacto → decisión por quien tiene autoridad → actualizar línea base → comunicar. La línea base sí puede cambiar, pero sólo con este procedimiento.

¿Qué actividades forman parte del cierre del proyecto según el temario?

Verificar la aceptación de los entregables
Transferir conocimiento y operación
Elaborar el Project Charter definitivo
Registrar lecciones aprendidas
Liberar los recursos del proyecto
Calcular el camino crítico final

Cierre: aceptación, contratos y documentación, transferencia, lecciones aprendidas, liberar recursos (y celebrar). El charter es de inicio; el camino crítico, de planificación y control.

Verdadero o falso: "Si se cancela un proyecto a mitad porque deja de tener sentido de negocio, no es necesario hacer el cierre".

Verdadero
Falso

Falso. Un proyecto cancelado también debe cerrarse: contratos, liberar recursos, archivar y, sobre todo, lecciones aprendidas (¿por qué no lo detectamos antes?). Cancelar pronto un proyecto sin sentido es una buena decisión.

TusBus lleva 2 semanas de retraso. Usando las preguntas clave de control de las diapositivas, ¿qué se preguntaría el JP en la reunión de seguimiento? Formula al menos tres y di cuál es la más importante.

¿Vamos tarde? (sí, 2 semanas; ¿en el camino crítico?) · ¿Qué ha cambiado? (p. ej. la API de GPS llegó tarde, cambió algún requisito) · ¿Qué riesgo ha cambiado? (¿la dependencia del ayuntamiento es ahora más probable que vuelva a fallar?, ¿peligra la fecha de la feria?) · ¿Qué decisión debemos tomar ahora? (recortar alcance Could/Should, fast tracking, pedir más plazo, activar contingencia). La más importante es la última: medir sin decidir no sirve (la A de PDCA).

Repaso espaciado · lecciones 2, 6, 10

¿Qué técnica de estimación es la más adecuada en la fase de concepto, sin EDT y con un proyecto anterior muy parecido?

Por analogía con el proyecto anterior
Ascendente desde los paquetes de trabajo
Planning poker con el equipo de desarrollo
Simulación Monte Carlo del camino crítico

Analogía: rápida, barata y útil al inicio si hay un proyecto comparable con datos. La ascendente requiere EDT; Monte Carlo requiere una red y distribuciones.

En PRINCE2, "gestionar por excepción" significa que…

El JP sólo informa al comité cuando el proyecto ya ha fracasado
El comité aprueba de forma individual cada decisión del proyecto
Los proyectos excepcionales se gestionan fuera de la metodología
El JP decide dentro de unas tolerancias y escala si las va a superar

Se delegan tolerancias (coste, plazo, alcance…); dentro de ellas decide el JP; si prevé superarlas, escala.

Para profundizar

Fuente principal recomendada

SWEBOK v4, KA Software Engineering Management, apartados "Software Project Enactment" (ejecución, control, informes) y "Closure". Para la cultura de análisis sin culpables: Google SRE Book, cap. 15 (gratuito, inglés).

¿Dudas?

Pide a un asistente que te dé 10 situaciones de un proyecto y clasifícalas tú en riesgo, problema, petición de cambio, no conformidad o decisión; luego que te corrija. Es exactamente el tipo de pregunta de emparejar que ha salido en exámenes.

Resúmenes imprimibles: Fundamentos · Glosario.