PMI PMP: Alcance, Requisitos y Control de Cambios — Guía de estudio

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Forma parte de la PMP — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de PMI, o realiza tests cronometrados en ExamRoll.io.

Obtención de requisitos, trazabilidad y la RTM

La integridad del alcance comienza mucho antes de que se estime el primer paquete de trabajo; comienza con una obtención de requisitos disciplinada. La obtención no es un único taller; es una actividad por capas que combina entrevistas, talleres facilitados (sesiones JAD, sprints de diseño), análisis de documentos, observación (“job shadowing”), creación de prototipos, cuestionarios y diagramas de contexto. Cada técnica saca a la luz un tipo de requisito diferente: requisitos de negocio (el porqué), requisitos de las partes interesadas (el quién quiere qué), requisitos de la solución (funcionales y no funcionales), requisitos de transición, requisitos del proyecto y requisitos de calidad. Omitir cualquier capa produce un fracaso predecible; por ejemplo, capturar los requisitos funcionales sin los no funcionales conduce a un sistema que “funciona” pero no puede escalar.

Una vez capturados, los requisitos deben ser trazables. La Matriz de trazabilidad de requisitos (RTM) vincula cada requisito de forma bidireccional con (a) el objetivo de negocio o beneficio que lo justifica, (b) el entregable de la WBS que lo producirá, (c) el elemento de diseño o historia de usuario que lo implementa, (d) el caso de prueba que lo verifica y (e) la parte interesada que es dueña de la aceptación. Una RTM madura también incluye la prioridad, el estado, la fuente y el ID de la solicitud de cambio. La RTM es el arma más poderosa contra la corrupción del alcance y el “baño de oro” (gold-plating): cualquier cambio propuesto que no pueda ser trazado hasta un objetivo de negocio aprobado es un candidato para el rechazo, y cualquier objetivo sin un caso de prueba representa una afirmación de finalización no verificable.

Una estructura de fila típica de una RTM:

• R-042
  • Descripción: El sistema soporta SSO
  • Objetivo de negocio: Reducir los tickets de soporte de inicio de sesión en un 30%
  • Ref. WBS: 1.3.2
  • Prioridad: Obligatorio (Must)
  • Caso de prueba: TC-118
  • Criterios de aceptación: Inicio de sesión con SAML 2.0 <2 seg
  • Propietario: CIO
  • Estado: Aprobado

Línea base del alcance, WBS y criterios de aceptación

La línea base del alcance es un trío aprobado formalmente: el enunciado del alcance, la WBS y el diccionario de la WBS. No es una lista de deseos; es la descripción, referenciada contractualmente, de lo que significa “terminado”. La WBS (Estructura de Desglose del Trabajo) descompone los entregables (nunca las actividades) hasta el nivel de paquete de trabajo, respetando la regla del 100%: la suma de los elementos hijos es igual al padre, ni más ni menos. Cada paquete de trabajo terminal obtiene una entrada en el diccionario de la WBS que describe el alcance del trabajo, los criterios de aceptación, los supuestos, el recurso responsable, el identificador del código de cuentas, las fechas de los hitos y los requisitos de calidad. Esto es lo que hace que la estimación sea defendible y el control posible; no se puede ganar valor por un trabajo que no se ha definido.

Los criterios de aceptación deben ser específicos, medibles y negociados antes de que comience el trabajo. “Interfaz fácil de usar” no es un criterio; “finalización de la tarea en ≤3 clics con una tasa de error <2% en las pruebas de usabilidad” sí lo es. Cada entregable requiere la aprobación de las partes interesadas frente a estos criterios a través de una actividad de validación formal, típicamente el proceso de Validar el Alcance, que produce entregables aceptados y solicitudes de cambio para aquellos que fallan. La lección implícita en los escenarios donde una parte interesada se niega a dar su aprobación cerca del cierre es inequívoca: los criterios de aceptación y la validación intermedia deberían haberse ejecutado durante toda la ejecución, no posponerse hasta el final. Cuando un entregable es rechazado en el cierre, el movimiento correcto es registrar la brecha, generar una solicitud de cambio para remediarla, reevaluar el impacto en el cronograma y el costo, y gestionarla a través del control de cambios, no argumentar que el trabajo “cumplía con la especificación”.

Priorización del backlog y MVP

En entornos adaptativos e híbridos, el alcance se expresa como un product backlog priorizado en lugar de una línea base congelada. Las técnicas de priorización incluyen MoSCoW (Must, Should, Could, Won’t), WSJF (Weighted Shortest Job First), análisis de Kano (características básicas, de rendimiento, de deleite) y matrices simples de valor/esfuerzo. El propósito es siempre el mismo: secuenciar el trabajo para que el mayor valor de negocio se entregue primero, y para que si el proyecto se interrumpe, el incremento liberado aun así resuelva un problema real.

El Producto Mínimo Viable (MVP) es la porción más pequeña de funcionalidad que entrega valor medible y permite el aprendizaje validado. No es la “fase uno de un plan fijo”; es una herramienta para probar hipótesis. Entregar el MVP de forma temprana expone los supuestos a usuarios reales, genera retroalimentación para el refinamiento del backlog y protege contra el patrón de fracaso clásico donde los equipos entregan características que nadie usa. Cuando las partes interesadas se quejan de que “la funcionalidad entregada no es lo que el negocio necesitaba”, la causa raíz casi siempre está aguas arriba: la priorización no estaba ligada a objetivos de negocio validados, y no se liberó ningún incremento temprano para probar los supuestos. La disciplina correctiva es realizar el refinamiento del backlog con el negocio, ponderar los elementos por beneficio, lanzar de forma incremental y volver a priorizar después de cada demostración.

Solicitudes de cambio, el CCB y el Control Integrado de Cambios

Una vez que existen las líneas base, toda alteración —incluidas las “pequeñas”— pasa por el proceso Realizar el Control Integrado de Cambios. El flujo de trabajo es: (1) presentar una solicitud de cambio que documente el qué, el porqué y el beneficio esperado; (2) registrarla en el registro de cambios; (3) realizar un análisis de impacto sobre el alcance, el cronograma, el costo, la calidad, los recursos, el riesgo y las adquisiciones (el análisis de impacto en los siete frentes); (4) dirigirla al Comité de Control de Cambios (CCB) para su aprobación, aplazamiento o rechazo; (5) si se aprueba, actualizar las líneas base afectadas, la RTM, la WBS, el registro de riesgos, el registro de supuestos y comunicarlo a todos los interesados afectados; (6) si se rechaza o se aplaza, conservar el registro para auditorías y lecciones aprendidas.

La composición del CCB debe corresponder a los umbrales de autoridad: patrocinador, dueño del negocio, líder técnico, PM y, a menudo, finanzas y calidad. Los cambios pequeños no están exentos; se gestionan mediante una autoridad delegada predefinida (p. ej., el PM puede aprobar cambios con un impacto inferior a 5000 $ y 2 días), pero aun así se registran. La suposición de que un cambio “menor” no tiene ningún efecto en la línea base es donde los proyectos se desangran silenciosamente: quince cambios menores que cuestan “solo medio día” cada uno consumen un colchón de tres semanas sin que nadie se dé cuenta.

Evaluación de impacto y disciplina con los supuestos e incidencias

Una evaluación de impacto adecuada no es un párrafo en un correo electrónico. Cuantifica el delta en el cronograma (mediante el análisis de la red del proyecto y el consumo de la holgura), en el costo (mano de obra, materiales, uso de la contingencia), en la calidad (riesgo de defectos, cobertura de pruebas), en el riesgo (nuevas amenazas introducidas o existentes amplificadas) y en la participación de los interesados. Si un cambio consume la contingencia, se debe actualizar el análisis de reservas. Si invalida un supuesto —por ejemplo, que una API de terceros permanecería estable—, se actualiza el registro de supuestos y se vuelven a verificar todos los requisitos dependientes. Los nuevos problemas que surjan del cambio se registran en el registro de incidencias con un responsable y una fecha de vencimiento.

Por qué fallan las trampas comunes

Considere los cuatro patrones recurrentes de respuestas incorrectas:

• Entregar funcionalidades de bajo valor fracasa porque se invirtió un esfuerzo sin trazabilidad hacia el beneficio del negocio. La disciplina de la RTM y el MVP existe precisamente para evitar esto; omitirlos significa que el equipo está optimizando la producción (output), no el resultado (outcome).
• Aceptar adiciones tardías al alcance de manera informal fracasa porque elude el análisis de impacto. La adición puede consumir la holgura que necesita otro trabajo o puede introducir un riesgo que invalide la estrategia de pruebas. Sin la visibilidad del CCB, nadie es responsable cuando el cronograma se retrasa.
• Implementar cambios sin una solicitud de cambio fracasa porque corrompe la línea base: el análisis de varianza futuro pierde sentido y los cálculos de valor ganado se desvían de la realidad. También erosiona la gobernanza: una vez que se tolera la omisión de un canal oficial, toda la disciplina se derrumba.
• Asumir que los cambios pequeños no tienen impacto fracasa porque el impacto es acumulativo y, a menudo, no lineal. Un cambio de una sola línea de código puede desencadenar pruebas de regresión en docenas de módulos; un ajuste “menor” en las especificaciones puede requerir una nueva aprobación por parte de un regulador. La regla es: primero evaluar, segundo categorizar, nunca asumir.

Cuando un cliente solicita cambios de alcance semanalmente, la respuesta correcta es triple: dirigir cada solicitud a través del proceso formal de control de cambios, realizar y compartir el análisis de impacto para que el cliente vea el costo real de cada cambio, y volver a involucrar al patrocinador y al CCB para reajustar las expectativas y, cuando sea apropiado, replanificar o establecer una nueva línea base. El silencio, la aceptación informal o el rechazo unilateral son todos fracasos de la misma disciplina.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Health está a mitad de una implementación de 18 meses y 4,2 millones de dólares de una nueva plataforma de admisión de pacientes destinada a reducir el tiempo de ingreso en urgencias en un 30 %. Priya, la directora de proyectos (PM), lidera un equipo híbrido de 22 personas que incluye personal clínico, de TI y del proveedor. Durante la revisión del Sprint 9, la directora de enfermería (CNO) solicita que el sistema también capture datos sobre los determinantes sociales de la salud, una petición que el responsable clínico califica de «esencial», pero que nunca estuvo en la declaración de alcance original ni en el product backlog.

Desafío: Priya debe decidir cómo gestionar la solicitud de la CNO sin desviar el cronograma de lanzamiento, inflar los costos o desestimar a una parte interesada de alto nivel cuyo apoyo para la adopción es fundamental para el éxito del proyecto.

Enfoque recomendado:

1. Registrar la petición como una solicitud de cambio formal en el sistema de control de cambios en lugar de aceptarla verbalmente en la revisión del sprint, y agradecer a la CNO por haberla planteado.
2. Trazar la solicitud a través de la Matriz de Trazabilidad de Requisitos (RTM): identificar si se corresponde con un objetivo de negocio existente (reducción del tiempo de admisión) o si introduce un nuevo flujo de beneficios, y señalar cualquier impacto posterior en la EDT (WBS), el diseño y los casos de prueba.
3. Convocar al analista de negocio y al responsable clínico en un plazo de 48 horas para realizar un análisis de impacto, estimando el esfuerzo, la diferencia de costo, el impacto en el cronograma y las dependencias del modelo de datos del proveedor, además de los impactos no funcionales como HIPAA y la carga de generación de informes.
4. Presentar el análisis al Comité de Control de Cambios (CCB) con tres opciones: posponerlo a la Fase 2, absorberlo mediante una repriorización eliminando un elemento del backlog de menor valor y tamaño equivalente, o aprobarlo con una actualización formal de la línea base del presupuesto y el cronograma.
5. Actualizar la RTM, la línea base del alcance y el registro de comunicaciones para reflejar la decisión del CCB, e informar personalmente a la CNO sobre el resultado y el razonamiento.
6. Añadir una acción en la retrospectiva para revisar por qué los datos sobre determinantes sociales se omitieron durante la obtención inicial de requisitos, probablemente debido a un análisis de stakeholders incompleto del liderazgo de enfermería.

Por qué funciona este enfoque: Canalizar la solicitud a través de un control de cambios documentado protege la línea base sin dejar de honrar a la parte interesada: la solicitud no se rechaza ni se absorbe en silencio, ambos fallos clásicos de la gestión del alcance. Trazar la solicitud a través de la RTM asegura que la decisión se base en el valor para el negocio en lugar de en la antigüedad de la parte interesada, y el paso de la retrospectiva fortalece la obtención de requisitos en el futuro. Esto evita los dos grandes escollos: el scope creep (expansión descontrolada) y la alienación de las partes interesadas (negativa rígida).

← Agile · Todos los dominios · Gestión de Riesgos e Incidencias →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →