00
Inicio
Ejecución y Control del Proyecto
Domina los procesos de involucramiento de stakeholders, reuniones efectivas, recopilación de datos y control de cambios según el PMBOK.
📘 Tema 136 Temas5 Simuladores16 Preguntas Quiz
6
Temas principales
5
Simuladores interactivos
16
Preguntas de quiz
15
Técnicas PMBOK
Mapa de Temas
Selecciona un tema para ir directamente a su contenido.
01
Gestionar Involucramiento de Interesados
Stakeholders, poder-interés, engagement
🤝 Stakeholders02
Reuniones y Eventos
Status, retrospectiva, workshops, gamificación
📅 Meetings03
Recopilación y Análisis de Datos
Predictivo, data mining, benchmarking, BI
📊 Analytics04
Control Integrado de Cambios
Proceso formal, CCB, scope creep
🔄 Change05
Análisis de Impacto de los Cambios
Sensibilidad, ROI, VPN, riesgos
⚡ Impact06
Gestionar Solicitudes de Cambio
6 fases, formato, CCB, trazabilidad
📝 Requests01
Tema
Gestionar Involucramiento de Interesados
Identifica, comprende y mantiene el compromiso de los stakeholders a lo largo del ciclo de vida del proyecto.
🤝 Stakeholders📊 Matriz Poder-Interés🎯 EngagementPMBOK 13.3
¿Qué es la Gestión del Involucramiento?
Proceso continuo y dinámico que asegura que los stakeholders estén comprometidos con el proyecto.
Un stakeholder es cualquier persona, grupo u organización que puede afectar o ser afectada por el proyecto. Sus intereses pueden cambiar a lo largo del tiempo, por eso la gestión es continua.
Reducción de Riesgos
Los interesados insatisfechos generan resistencia al cambio y falta de apoyo, convirtiéndose en fuentes de riesgo para el proyecto.
RiesgoAlineación de Objetivos
Mantener a los interesados informados y comprometidos reduce malentendidos y alinea sus expectativas con los objetivos del proyecto.
ComunicaciónMejora en Decisiones
Los stakeholders bien involucrados aportan perspectivas valiosas que mejoran la calidad de las decisiones del PM.
CalidadEstrategias de Involucramiento
Plan de Participación
▼Documento que detalla cómo y cuándo cada stakeholder será involucrado en el proyecto. Incluye: canales de comunicación, frecuencia de reportes, tipo de información para cada audiencia y niveles de participación esperados. Es parte del Plan de Gestión de Comunicaciones.
Revisiones Regulares
▼Reuniones periódicas con stakeholders clave para verificar que sus necesidades están siendo atendidas. Permite detectar cambios en expectativas y ajustar el plan de comunicación antes de que se conviertan en problemas mayores.
Comunicación Personalizada
▼Adaptar el mensaje según el tipo de interesado: informes técnicos detallados para el equipo, resúmenes ejecutivos para alta dirección, reportes de impacto para clientes. El mensaje correcto, al público correcto, en el momento correcto.
Técnicas del PMBOK para Gestión de Interesados
Matriz de Poder-Interés con Mapas de Calor
Herramienta de Clasificación Visual
Clasifica stakeholders en 4 cuadrantes según poder (capacidad de influir) e interés (cuánto les afecta). El mapa de calor añade intensidad de color para mostrar el nivel de compromiso actual.
Cargando stakeholders...
PODER ↑
Mantener Satisfecho
Alto poder · Bajo interés
Gestionar de Cerca
Alto poder · Alto interés
Monitorear
Bajo poder · Bajo interés
Mantener Informado
Bajo poder · Alto interés
INTERÉS →
0 / 8 correctos
Gestión de Expectativas
Técnica de Negociación y Mediación
Uso de técnicas de negociación y mediación para manejar expectativas contradictorias entre diferentes stakeholders. El PM actúa como facilitador neutral.
Caso real: En el proyecto ERP para InkaCorp S.A.C. — Lima, el área Financiera quiere el sistema en 3 meses, pero TI estima 6 meses mínimo.
🧩 Caso: Conflicto de expectativas entre Finanzas y TI
ResoluciónInkaCorp S.A.C. implementa un ERP. Finanzas exige go-live en 3 meses (cierre de año). TI dice que sin 6 meses habrá errores críticos. El Gerente General quiere que el PM encuentre una solución.
Estrategia de mediación:
1. Reunión tripartita: PM convoca a Finanzas, TI y Sponsor juntos.
2. Separar intereses de posiciones: Finanzas no necesita TODO el ERP — necesita el módulo de cierre contable.
3. Solución de compromiso: Módulo Financiero en 3 meses, módulos restantes en meses 4-6.
4. Documentar el acuerdo: Formalizar en el Plan de Proyecto con el Sponsor como aprobador.
5. Comunicar: Todos los stakeholders informados del nuevo plan.
Resultado: Expectativas alineadas, riesgo reducido, todos comprometidos.
1. Reunión tripartita: PM convoca a Finanzas, TI y Sponsor juntos.
2. Separar intereses de posiciones: Finanzas no necesita TODO el ERP — necesita el módulo de cierre contable.
3. Solución de compromiso: Módulo Financiero en 3 meses, módulos restantes en meses 4-6.
4. Documentar el acuerdo: Formalizar en el Plan de Proyecto con el Sponsor como aprobador.
5. Comunicar: Todos los stakeholders informados del nuevo plan.
Resultado: Expectativas alineadas, riesgo reducido, todos comprometidos.
Stakeholder Engagement Assessment Matrix
Matriz de Evaluación de Compromiso
Evalúa el nivel de compromiso actual (C) vs. el deseado (D) de cada stakeholder. La brecha entre ambos define las estrategias de involucramiento.
Niveles: D=Desconocedor · R=Resistente · N=Neutral · P=Partidario · L=Líder. La celda C/D indica que el stakeholder ya está en el nivel deseado.
Casos Prácticos — Contexto Peruano
📦 Caso 1: Digitalización de flota en Ferreyros S.A.
AnálisisFerreyros S.A. implementa un sistema de gestión de flota para 200 técnicos de campo. Stakeholders: Gerencia General (alto poder, alto interés), Técnicos de campo (bajo poder, alto interés), Sindicato (alto poder, bajo interés), Proveedores GPS (bajo poder, bajo interés).
Preguntas:
- ¿Cómo clasificas a cada stakeholder en la Matriz Poder-Interés?
- ¿Qué estrategia usas para el Sindicato?
- ¿Con qué frecuencia te comunicas con los Técnicos?
Clasificación y estrategias:
• Gerencia General → Gestionar de Cerca: reuniones semanales, dashboard ejecutivo.
• Técnicos de campo → Mantener Informados: boletín mensual, sesiones demo, canal de feedback.
• Sindicato → Mantener Satisfecho: reunión bimensual con actas, garantías de que el sistema no elimina puestos.
• Proveedores GPS → Monitorear: contacto según requerimiento técnico.
Clave para el Sindicato: Comunicar ANTES del lanzamiento que el sistema mejora condiciones de trabajo. Involucrar un representante como validador durante las pruebas.
• Gerencia General → Gestionar de Cerca: reuniones semanales, dashboard ejecutivo.
• Técnicos de campo → Mantener Informados: boletín mensual, sesiones demo, canal de feedback.
• Sindicato → Mantener Satisfecho: reunión bimensual con actas, garantías de que el sistema no elimina puestos.
• Proveedores GPS → Monitorear: contacto según requerimiento técnico.
Clave para el Sindicato: Comunicar ANTES del lanzamiento que el sistema mejora condiciones de trabajo. Involucrar un representante como validador durante las pruebas.
🏗️ Caso 2: Proyecto en San Isidro — Vecinos como stakeholders olvidados
IdentificaciónUn consorcio construye un edificio de 20 pisos en San Isidro. A mitad del proyecto, los vecinos comienzan a quejarse del ruido y vibraciones. El Municipio amenaza con parar la obra.
Preguntas:
- ¿Los vecinos eran stakeholders desde el inicio?
- ¿Qué hacer ahora que el Municipio amenaza?
Sí, los vecinos siempre fueron stakeholders — no se identificaron por falta de un análisis completo inicial.
Acciones inmediatas:
1. Reunión de emergencia con la Junta de Propietarios — escuchar sus preocupaciones.
2. Presentar al Municipio un Plan de Mitigación de Impacto (horarios restringidos, medidas de vibración).
3. Actualizar el Registro de Stakeholders incluyendo a la Junta y el Municipio.
4. Establecer canal de comunicación directo (correo semanal) con vecinos.
5. Considerar compensaciones o reparación de grietas detectadas para mantener la relación.
Acciones inmediatas:
1. Reunión de emergencia con la Junta de Propietarios — escuchar sus preocupaciones.
2. Presentar al Municipio un Plan de Mitigación de Impacto (horarios restringidos, medidas de vibración).
3. Actualizar el Registro de Stakeholders incluyendo a la Junta y el Municipio.
4. Establecer canal de comunicación directo (correo semanal) con vecinos.
5. Considerar compensaciones o reparación de grietas detectadas para mantener la relación.
Preguntas Frecuentes
¿Cuándo se actualiza el Registro de Stakeholders?
Es un documento vivo que se actualiza cuando: aparecen nuevos interesados, cambia el poder o interés de un stakeholder, se inicia una nueva fase, o cuando ocurre un evento significativo. No es un documento que se hace una vez y se archiva.
¿Cuál es la diferencia entre un stakeholder y un sponsor?
El Sponsor es un tipo específico de stakeholder con características especiales: proporciona recursos y apoyo, tiene autoridad para decisiones de alto nivel y responde por el proyecto ante la organización. Todos los sponsors son stakeholders, pero no al revés.
¿La gestión de stakeholders es lo mismo que la gestión de comunicaciones?
Están relacionadas pero son procesos distintos. La gestión de comunicaciones se enfoca en QUÉ comunicar, CON QUIÉN y POR QUÉ canal. La gestión de stakeholders va más allá: analiza expectativas, gestiona conflictos y busca mantener el compromiso activo. La comunicación es una herramienta dentro de la gestión de stakeholders.
¿Qué hacer cuando un stakeholder clave se vuelve opositor?
Primero entender las razones (entrevista 1:1, sin confrontación). Luego involucrarlos activamente en decisiones donde su input sea valioso — las personas apoyan lo que ayudan a crear. Buscar puntos en común entre sus intereses y los objetivos del proyecto. Si persiste la oposición, escalar al Sponsor. Documenta todo en el registro de problemas.
¿Cómo se mide el éxito de la gestión de stakeholders?
Mediante: encuestas de satisfacción de stakeholders, seguimiento de la Engagement Matrix (cerrar brechas), número de escalamientos o conflictos, nivel de participación en reuniones clave, y si los stakeholders actúan como promotores del proyecto ante terceros.
02
Tema
Reuniones y Eventos
Las reuniones efectivas son la columna vertebral de la comunicación en proyectos. Aprende a facilitarlas con técnicas probadas del PMBOK.
📅 Status Meetings🔄 Retrospectivas🎮 Gamificación🤖 IA en Reuniones
Tipos de Reuniones en Proyectos
Status Meeting
Evaluación regular del avance del proyecto frente al plan. Aborda desviaciones y actualiza a todos los involucrados sobre hitos y riesgos.
SemanalRetrospectiva
Analiza qué funcionó bien y qué mejorar. Común en metodologías ágiles al final de cada sprint o fase del proyecto.
Post-faseWorkshop
Evento colaborativo para diseñar soluciones, planificar sprints o resolver problemas específicos con el equipo y stakeholders.
Puntual🎯 Simulador — Constructor de Agenda Efectiva
Constructor de Agenda
Arrastra los ítems al orden correcto para cada tipo de reunión
📦 Ítems disponibles:
📋 Orden de la agenda:
Técnicas Avanzadas para Reuniones Efectivas
Técnicas de Gamificación en Reuniones
Facilitación Dinámica
Incorporar elementos de juego (puntos, tiempos, votaciones dinámicas) para aumentar la participación y creatividad del equipo en reuniones.
Técnicas populares: Dot Voting (votar con puntos adhesivos), Mad/Sad/Glad (retrospectivas), 1-2-4-All (decisiones en grupo), Fist to Five (consenso), Round Robin (turnos cronometrados de 60 seg).
Simulador: Facilita una Reunión
Elige la mejor técnica para cada situación — ¡tienes tiempo limitado!
0
Nivel 1/3
Cargando...
Software de Gestión de Reuniones
Herramientas Digitales
| Herramienta | Función principal | Ideal para | Plan gratuito |
|---|---|---|---|
| Lucid Meetings | Agendas estructuradas, minutas automáticas | Status meetings formales | ✅ Limitado |
| Hugo | Notas conectadas a CRM y proyectos | Equipos de ventas/proyectos | ✅ Sí |
| Notion | Bases de datos de reuniones, wikis | Documentación y seguimiento | ✅ Generoso |
| Miro | Pizarras virtuales para workshops | Workshops y retrospectivas | ✅ 3 tableros |
| MS Teams + Loop | Reuniones + notas colaborativas | Equipos corporativos grandes | ❌ De pago |
Uso de IA en Reuniones
Automatización y Análisis
Herramientas de IA para transcripción automática, resumen de minutas y extracción de acuerdos y tareas.
Herramientas IA: Otter.ai (transcripción), Fireflies.ai (resumen + tareas automáticas), Copilot en Teams (análisis de reuniones), Zoom AI (resúmenes automáticos post-sesión).
Casos Prácticos — Reuniones en Perú
🏦 Caso 1: Reuniones de status en Banco BCP — Proyecto app móvil
GestiónEl equipo lleva 3 meses en el proyecto. Las reuniones de status duran 2 horas y la asistencia bajó al 60%. El equipo dice que son "pérdida de tiempo".
Rediseño de la Status Meeting:
1. Formato 15-min standup diario: ¿Qué hice? ¿Qué haré? ¿Bloqueos? — solo equipo core.
2. Status semanal de 45 min con agenda fija enviada 24h antes: avance KPIs (10 min), desviaciones (15 min), decisiones (15 min), hitos (5 min).
3. Dashboard visible: Gantt y KPIs en pantalla compartida durante la reunión.
4. Regla "No agenda = reunión cancelada".
5. Minuta en 2 horas post-reunión con responsables y fechas.
1. Formato 15-min standup diario: ¿Qué hice? ¿Qué haré? ¿Bloqueos? — solo equipo core.
2. Status semanal de 45 min con agenda fija enviada 24h antes: avance KPIs (10 min), desviaciones (15 min), decisiones (15 min), hitos (5 min).
3. Dashboard visible: Gantt y KPIs en pantalla compartida durante la reunión.
4. Regla "No agenda = reunión cancelada".
5. Minuta en 2 horas post-reunión con responsables y fechas.
🏪 Caso 2: Retrospectiva tensa en proyecto Saga Falabella
FacilitaciónEl sprint 4 terminó con 3 bugs críticos en producción. En la retrospectiva, desarrollo y QA se culpan mutuamente. El ambiente es muy tenso.
Técnica "Mad/Sad/Glad" + Espacio Seguro:
1. Regla inicial: La retro busca mejorar el SISTEMA, no encontrar culpables de personas.
2. Tarjetas anónimas: Post-its con Mad (enojados), Sad (tristes), Glad (contentos). El anonimato reduce el miedo.
3. Agrupar por temas: Aparecerán patrones — proceso, comunicación, herramientas.
4. Dot Voting: Cada persona vota los 3 problemas más urgentes.
5. Solo 3 Action Items: Responsable + fecha. Pocas acciones que se cumplan es mejor que muchas que no.
1. Regla inicial: La retro busca mejorar el SISTEMA, no encontrar culpables de personas.
2. Tarjetas anónimas: Post-its con Mad (enojados), Sad (tristes), Glad (contentos). El anonimato reduce el miedo.
3. Agrupar por temas: Aparecerán patrones — proceso, comunicación, herramientas.
4. Dot Voting: Cada persona vota los 3 problemas más urgentes.
5. Solo 3 Action Items: Responsable + fecha. Pocas acciones que se cumplan es mejor que muchas que no.
FAQ — Reuniones y Eventos
¿Cuántas reuniones es demasiado en un proyecto?
No hay número exacto, pero si el tiempo en reuniones supera el 20% de la jornada laboral, hay demasiadas. Revisa si cada reunión tiene propósito claro, si puede resolverse por correo/chat, y si los asistentes realmente deben estar ahí.
¿Qué debe contener una minuta efectiva?
Fecha/hora/asistentes, objetivos de la reunión, DECISIONES tomadas (no lo que se discutió), ACTION ITEMS con tarea + responsable + fecha límite, y próxima reunión programada. Debe enviarse dentro de las 2 horas post-reunión.
¿Cómo manejar a participantes que siempre se salen del tema?
Técnica "Parking Lot": coloca una sección visible al inicio. Cuando alguien saca un tema fuera de agenda, el facilitador lo anota ahí: "Lo agendamos para después". Al final de la reunión, se revisa el parking lot y se decide si merece reunión aparte.
¿La retrospectiva es solo para proyectos ágiles?
No. El PMBOK incluye lecciones aprendidas al final de cada fase y al cierre del proyecto, con el mismo propósito. En proyectos predictivos se llaman "lecciones aprendidas" o "post-mortem". La frecuencia puede ser por fase, mensual o al cierre.
¿Cómo hacer reuniones virtuales más efectivas?
Activar cámaras (genera más compromiso), usar herramientas colaborativas (Miro, Jamboard), hacer check-in de 2 min al inicio, usar salas de trabajo para equipos pequeños, tener timekeeper visible, rotar el rol de facilitador, y jamás hacer reunión virtual sin agenda previa.
03
Tema
Recopilación y Análisis de Datos
Monitorea el proyecto con datos reales. Aplica análisis predictivo, data mining y benchmarking para tomar mejores decisiones basadas en evidencia.
📈 Análisis Predictivo⛏️ Data Mining🏆 Benchmarking📊 BI Tools
Tipos de Datos en Proyectos
Datos de Desempeño
Progreso del trabajo, calidad de entregables, costos incurridos, avance del cronograma. Base para el informe de performance (SPI/CPI).
SPI / CPIDatos de Riesgos
Identificación, evaluación de probabilidad e impacto, estado de respuestas a riesgos activos e identificados del proyecto.
Risk RegisterDatos de Satisfacción
Feedback de clientes y usuarios finales sobre el producto entregado. Se recoge mediante NPS, encuestas CSAT o entrevistas.
NPS / CSAT🎯 Simulador — Dashboard Analítico de Proyecto
Dashboard — InkaLogística S.A.C.
Interpreta los indicadores y elige la acción correcta del PM
—
SPI (Cronograma)
—
—
CPI (Costo)
—
—
% Avance Real
—
Cargando escenario...
Técnicas de Análisis de Datos — PMBOK
Análisis Predictivo
Modelado Estadístico y Algoritmos
Usa modelos estadísticos para prever desviaciones futuras basándose en datos actuales del proyecto. La metodología de Valor Ganado (EVM) es el estándar PMBOK.
Caso: En el mes 3 del proyecto, CPI = 0.80. El análisis predictivo calcula EAC = BAC/CPI, proyectando que el presupuesto total se incrementará 25%. Esto permite actuar ANTES de que sea irreversible.
| Fórmula EVM | Significado | Interpretación |
|---|---|---|
| SPI = EV/PV | Índice de desempeño del cronograma | <1 atrasado · >1 adelantado |
| CPI = EV/AC | Índice de desempeño del costo | <1 sobrecosto · >1 bajo presupuesto |
| EAC = BAC/CPI | Estimado a la conclusión | Costo total proyectado al terminar |
| ETC = EAC − AC | Estimado hasta completar | Costo restante proyectado |
Data Mining — Minería de Datos
Descubrimiento de Patrones Ocultos
Aplica técnicas para descubrir patrones no evidentes en grandes volúmenes de datos del proyecto. Útil para detectar correlaciones entre variables aparentemente no relacionadas.
Simulador Data Mining
Analiza los datos del proyecto e identifica el patrón oculto
| Semana | Entregables | Defectos | Horas trabajadas | Satisfacción |
|---|
Las celdas resaltadas indican las semanas con comportamiento atípico.
Benchmarking
Comparación con Mejores Prácticas del Sector
Compara el rendimiento de tu proyecto con proyectos similares para identificar brechas y oportunidades de mejora concretas.
🏢 Tu Proyecto
RetailPeru S.A.C.
RetailPeru S.A.C.
CPI0.82
SPI0.75
Defectos/sprint8
Satisfacción cliente72%
🏪 Referente A
Sector Retail — Lima
Sector Retail — Lima
CPI1.05
SPI0.98
Defectos/sprint2
Satisfacción cliente91%
💻 Referente B
Sector TI — Lima
Sector TI — Lima
CPI0.90
SPI0.88
Defectos/sprint4
Satisfacción cliente82%
Brecha crítica identificada: el doble de defectos por sprint respecto al promedio del sector. Acción: implementar code review obligatorio y pruebas automatizadas antes del próximo sprint.
Herramientas BI · Análisis en Tiempo Real · Dashboards Personalizados
Business Intelligence Aplicado a Proyectos
Las herramientas de BI como Power BI o Tableau permiten crear dashboards interactivos con datos en tiempo real, personalizados según el rol del usuario.
Casos — Análisis de Datos en Perú
🏥 Caso: Sistema de citas ClínicaVida S.A.C. — Análisis predictivo EVM
CálculoClínicaVida S.A.C. implementa un sistema de gestión de citas. En el mes 2 de 5: EV=S/40,000 · PV=S/60,000 · AC=S/55,000 · BAC=S/150,000.
Calcula y analiza:
- ¿Cuál es el CPI y qué significa?
- ¿Cuál es el EAC (estimado a la conclusión)?
- ¿Qué acción debe tomar el PM?
CPI = EV/AC = 40,000/55,000 = 0.73 → El proyecto gasta S/ 1.37 por cada S/ 1.00 de valor ganado. Está 27% sobre presupuesto.
EAC = BAC/CPI = 150,000/0.73 = S/ 205,479 → El proyecto costará ~S/ 55,000 más de lo planificado si continúa así.
Acción del PM: Reunión de emergencia con el sponsor. Analizar causas raíz. Emitir solicitud de cambio para ajustar línea base de costo. Considerar reducción de alcance si no se aprueba presupuesto adicional.
EAC = BAC/CPI = 150,000/0.73 = S/ 205,479 → El proyecto costará ~S/ 55,000 más de lo planificado si continúa así.
Acción del PM: Reunión de emergencia con el sponsor. Analizar causas raíz. Emitir solicitud de cambio para ajustar línea base de costo. Considerar reducción de alcance si no se aprueba presupuesto adicional.
FAQ — Recopilación y Análisis
¿Cuál es la diferencia entre datos, información e inteligencia?
Datos: hechos crudos (CPI=0.85). Información: datos con contexto (el proyecto está 15% sobre presupuesto). Inteligencia: información analizada que genera decisiones (si no ajustamos el equipo QA, el proyecto superará su presupuesto en S/50,000 para el mes 4). El PM debe transformar datos en inteligencia accionable.
¿Con qué frecuencia debo recopilar datos del proyecto?
Depende del tipo: Datos de desempeño (SPI/CPI): semanal o quincenal. Datos de riesgos: semanal. Datos de satisfacción del cliente: por hito o mensual. En proyectos ágiles, la velocidad del equipo se mide por sprint. La frecuencia debe estar en el Plan de Comunicaciones.
¿Cuándo es útil el Data Mining en proyectos?
Es especialmente útil en proyectos con gran volumen de datos: proyectos TI con logs de sistema, construcción con datos de materiales y tiempos, o programas con múltiples proyectos. Permite identificar patrones como: correlación entre horas extra y aumento de defectos, o entre ciertos proveedores y retrasos.
¿Cómo se diferencia Power BI de un simple Excel?
Excel es excelente para análisis ad-hoc. Power BI conecta múltiples fuentes en tiempo real, permite dashboards interactivos con drill-down, actualizaciones automáticas y compartir reportes en la nube. Para proyectos grandes con muchos stakeholders, Power BI ofrece una capa de visualización más robusta y accesible.
¿Qué es la "línea base de medición del desempeño"?
Es la combinación aprobada de alcance + cronograma + costo (BAC) que sirve como referencia para medir el desempeño. Solo puede cambiar mediante el proceso formal de Control Integrado de Cambios. Sin línea base, no hay benchmarking interno posible.
04
Tema
Control Integrado de Cambios
Proceso formal para gestionar modificaciones al proyecto de manera controlada. Nada cambia sin análisis, aprobación y documentación.
🔄 CCB🚫 Scope Creep📋 Change LogPMBOK 4.6
¿Qué es el Control Integrado de Cambios?
Proceso que asegura que cada cambio al proyecto sea identificado, analizado, aprobado o rechazado, e implementado de forma que no degrade la línea base sin la debida autorización.
Evita el Scope Creep
La "corrupción del alcance" es cuando el proyecto crece silenciosamente más allá de lo acordado. El CIC es el mecanismo de defensa principal.
ControlMantiene Coherencia
Asegura que alcance, tiempo, costo y calidad permanezcan alineados incluso cuando se producen cambios necesarios.
IntegraciónFacilita Comunicación
Establece un canal formal y transparente para la solicitud, evaluación y aprobación de cambios entre todos los stakeholders.
Comunicación🎯 Simulador — Flujo de Control de Cambios
Gestiona un Cambio en RetailPeru S.A.C.
Toma la decisión correcta en cada una de las 6 etapas del proceso
1. Recepción
2. Evaluación
3. Priorización
4. Decisión
5. Implementación
6. Monitoreo
Cargando escenario...
Mejores Prácticas del CIC
Líneas Base Claras
Sin líneas base definidas de alcance, tiempo y costo, no es posible medir si un cambio realmente impacta el plan.
Herramientas de Seguimiento
Jira, ServiceNow o Azure DevOps permiten documentar y rastrear todas las CRs con historial completo de decisiones.
Auditorías de Cambios
Revisiones periódicas del proceso para detectar mejoras: ¿Se siguen las 6 fases? ¿Los tiempos están dentro del SLA?
Proceso de Control de Cambios — 5 Pasos PMBOK
01
Recepción
Captura formal con ID único en el sistema
02
Evaluación
Análisis de impacto en costo, tiempo, calidad
03
Decisión CCB
Aprueba, rechaza o pide ajustes
04
Implementación
Ejecución + actualización documentación
05
Monitoreo
Seguimiento post-implementación
Constructor de Dashboard por Rol
Selecciona los KPIs que incluirías en el dashboard para el rol elegido. Las opciones con ⭐ son recomendadas para este rol.
Casos — Control de Cambios
💻 Caso: ERP en MinasAndes S.A. — Scope Creep clásico
IdentificaciónEl PM descubre que el equipo lleva 3 sprints implementando módulos no incluidos en el alcance original, porque "el cliente lo pedía verbalmente en las reuniones". Resultado: 40% sobrecosto y 6 semanas de atraso.
¿Qué proceso falló y cómo prevenirlo?
Proceso fallido: Control Integrado de Cambios — ningún cambio verbal debería implementarse sin pasar por el proceso formal.
Prevención:
• Política escrita en el contrato: todo cambio de alcance requiere CR formal y aprobación del CCB.
• Entrenamiento al equipo: ningún desarrollador implementa funcionalidades nuevas sin CR aprobada.
• Reuniones documentadas: solicitudes verbales del cliente se registran en acta y convierten en CRs formales.
• Change Log visible: tablero con todas las CRs (pendiente/aprobada/rechazada) visible para todos.
Prevención:
• Política escrita en el contrato: todo cambio de alcance requiere CR formal y aprobación del CCB.
• Entrenamiento al equipo: ningún desarrollador implementa funcionalidades nuevas sin CR aprobada.
• Reuniones documentadas: solicitudes verbales del cliente se registran en acta y convierten en CRs formales.
• Change Log visible: tablero con todas las CRs (pendiente/aprobada/rechazada) visible para todos.
FAQ — Control Integrado de Cambios
¿Todo cambio debe pasar por el CCB?
Depende del plan de gestión de cambios. Cambios que afectan líneas base (alcance, tiempo, costo) sí requieren CCB. Cambios menores sin impacto en líneas base pueden ser aprobados por el PM directamente. El plan debe definir umbrales de autorización claros.
¿Qué es el CCB y quién lo integra?
El CCB (Change Control Board) es el órgano formal de decisión sobre cambios. Generalmente incluye: el PM (siempre), el Sponsor o representante, líderes técnicos clave, representante del cliente, y según el caso: legal o finanzas. Su tamaño debe permitir decisiones ágiles.
¿Cuánto tiempo debe tomar el proceso de control de cambios?
Una CR de bajo impacto: 24-48 horas. Una CR mayor puede tomar 1-2 semanas para análisis completo y reunión del CCB. El plan de gestión de cambios debe definir SLAs para diferentes tipos de cambio y evitar cuellos de botella.
¿Un cambio rechazado puede volver a solicitarse?
Sí. Un cambio rechazado puede presentarse nuevamente si cambian las condiciones del proyecto, hay nueva información o se propone una versión modificada con menor impacto. El CCB debe documentar las razones del rechazo para que futuras solicitudes puedan abordarlas.
¿Qué pasa si se implementa un cambio sin aprobación del CCB?
Es un cambio no autorizado. El PM debe: documentarlo como lección aprendida, evaluar su impacto en las líneas base, presentarlo retroactivamente al CCB para formalización (o reversión), e identificar por qué falló el proceso. En contratos formales puede tener implicancias legales.
05
Tema
Análisis de Impacto de los Cambios
Antes de aprobar cualquier cambio, evalúa todas sus consecuencias: alcance, cronograma, costo, calidad, recursos y riesgos del proyecto.
📉 Sensibilidad💰 ROI / VPN⚠️ RiesgosPMBOK 4.6
Dimensiones del Análisis de Impacto
El análisis de impacto identifica todas las consecuencias de un cambio propuesto antes de aprobarlo. Ninguna dimensión puede ignorarse: un cambio "pequeño" de alcance puede tener impacto crítico en el cronograma.
Impacto en el Alcance
¿Qué entregables cambian? ¿Se añaden o eliminan requisitos? ¿Impacta la EDT (WBS) aprobada?
AlcanceImpacto en Cronograma
¿Afecta al camino crítico? ¿Cuántas semanas de retraso? ¿Qué hitos se mueven por el cambio?
TiempoImpacto en Costo
¿Cuánto cuesta implementar el cambio? ¿Hay ahorro? ¿Afecta la reserva de contingencia?
CostoImpacto en Calidad
¿El cambio mejora o degrada la calidad del entregable? ¿Requiere nuevas pruebas o validaciones?
Calidad🎯 Simulador — Analizador de Impacto (Triple Restricción)
Analizador de Impacto de Cambio
Evalúa cada dimensión con sliders y obtén una recomendación automática para el CCB
Cargando escenario...
✅ APROBAR
Índice de riesgo: 30% — Impacto manejable
1 = impacto mínimo · 10 = impacto crítico en el proyecto
Técnicas de Análisis de Impacto
Análisis de Sensibilidad
Modelado de Variables Clave
Mide cómo los cambios en una variable clave (costo, tiempo, recursos) afectan el resultado final. Identifica qué variables tienen mayor influencia sobre el proyecto.
Interpretación: Variaciones de costo por encima del 30% generan impactos desproporcionadamente altos. Ese es el punto de inflexión donde el cambio pasa de "manejable" a "crítico".
📐 Caso: Análisis de sensibilidad — Ampliación Tottus Miraflores
AnálisisEl proyecto evalúa un cambio: añadir piso adicional de estacionamiento. Costo base S/ 2M. Se analiza qué pasa si el costo del acero sube 10%, 20% o 30%.
• +10% acero → +S/ 180,000 → impacto BAJO (9% del presupuesto)
• +20% acero → +S/ 360,000 → impacto MEDIO (18% del presupuesto)
• +30% acero → +S/ 540,000 → impacto ALTO (27%) → revisar ROI del cambio
Recomendación: El acero es la variable más sensible. Asegurar precio fijo con el proveedor (contrato cerrado) antes de aprobar el cambio de alcance.
• +20% acero → +S/ 360,000 → impacto MEDIO (18% del presupuesto)
• +30% acero → +S/ 540,000 → impacto ALTO (27%) → revisar ROI del cambio
Recomendación: El acero es la variable más sensible. Asegurar precio fijo con el proveedor (contrato cerrado) antes de aprobar el cambio de alcance.
Métodos de Valoración del Impacto — ROI / VPN / Costo-Beneficio
Análisis Financiero del Cambio
Evalúa el impacto financiero de implementar un cambio usando tres métricas clave del análisis de proyectos.
ROI
(Beneficio − Inversión) / Inversión × 100. Mide el retorno porcentual sobre la inversión del cambio propuesto.
VPN
Valor Presente Neto: descuenta flujos futuros a valor actual. Si VPN > 0, el cambio agrega valor económico al proyecto.
Costo-Beneficio
Beneficio / Costo. Si el resultado es > 1, los beneficios superan los costos del cambio propuesto.
🧮 Calculadora — Valoración del cambio propuesto:
60%
ROI
1.60x
Costo-Beneficio
—
VPN
Evaluación de Riesgos del Cambio
Matriz Probabilidad × Impacto
Identifica y evalúa los nuevos riesgos que introduce el cambio propuesto usando la matriz estándar del PMBOK.
Haz clic en las etiquetas R1, R2, R3, R4 en la matriz para ver el detalle de cada riesgo introducido por el cambio propuesto.
| ID | Riesgo del Cambio | Prob. | Impacto | Score | Nivel |
|---|---|---|---|---|---|
| R1 | Rechazo del cambio por usuarios finales | 4/5 | 5/5 | 20 | CRÍTICO |
| R2 | Incremento de costo no previsto | 3/5 | 4/5 | 12 | ALTO |
| R3 | Incompatibilidad técnica | 2/5 | 3/5 | 6 | MEDIO |
| R4 | Demoras en aprobación del CCB | 5/5 | 2/5 | 10 | ALTO |
Casos — Análisis de Impacto
🏭 Caso: Cambio de proveedor en Antamina S.A. — Caterpillar vs Komatsu
Análisis completoEl proyecto de expansión de Antamina S.A. (Ancash) recibe una CR: reemplazar a Caterpillar por Komatsu a mitad del proyecto. El argumento: ahorro del 15% en costo de maquinaria.
Realiza el análisis en las 4 dimensiones:
🎯 Alcance: No altera entregables directamente, pero requiere revisar especificaciones técnicas de integración (impacto MEDIO).
📅 Cronograma: Re-negociar contrato + nuevos tiempos de entrega desde Japón (+8-12 semanas) + recertificación de operadores = +3 meses al cronograma (impacto ALTO).
💰 Costo: Ahorro bruto 15% vs. penalidades por atraso + costos de re-negociación + capacitación de operadores. Ahorro neto probable: negativo (impacto: puede resultar en sobrecosto).
✅ Calidad: Ambas marcas son equivalentes, pero la curva de aprendizaje con Komatsu puede generar errores en los primeros meses (impacto MEDIO).
Recomendación CCB: RECHAZAR. El ahorro en maquinaria es absorbido por los costos ocultos. Alternativa: negociar mejor precio con Caterpillar o aplicar el cambio al siguiente proyecto.
📅 Cronograma: Re-negociar contrato + nuevos tiempos de entrega desde Japón (+8-12 semanas) + recertificación de operadores = +3 meses al cronograma (impacto ALTO).
💰 Costo: Ahorro bruto 15% vs. penalidades por atraso + costos de re-negociación + capacitación de operadores. Ahorro neto probable: negativo (impacto: puede resultar en sobrecosto).
✅ Calidad: Ambas marcas son equivalentes, pero la curva de aprendizaje con Komatsu puede generar errores en los primeros meses (impacto MEDIO).
Recomendación CCB: RECHAZAR. El ahorro en maquinaria es absorbido por los costos ocultos. Alternativa: negociar mejor precio con Caterpillar o aplicar el cambio al siguiente proyecto.
FAQ — Análisis de Impacto
¿Quién realiza el análisis de impacto?
El PM coordina, pero no lo hace solo. Involucra a líderes técnicos (cronograma y calidad), área financiera (costo), arquitecto de solución (impacto técnico) y legal si hay implicancias contractuales. El análisis debe ser multidisciplinario para ser confiable.
¿Puede un cambio tener impacto positivo?
Absolutamente. Un cambio puede reducir costos, acortar el cronograma o mejorar la calidad. El análisis no busca rechazar cambios, sino tomar decisiones informadas. Un cambio con ROI positivo, sin impacto negativo en cronograma y que mejora la calidad debería aprobarse.
¿El VPN negativo siempre significa rechazar el cambio?
No necesariamente. Algunos cambios tienen valor estratégico, regulatorio o de satisfacción al cliente que no captura el VPN financiero. Un cambio exigido por INDECOPI puede tener VPN negativo pero es no negociable. El análisis financiero es un input, no el único criterio de decisión.
¿Cómo se documenta el análisis de impacto?
Se documenta en el formulario de Solicitud de Cambio en la sección "Análisis de Impacto". Debe incluir: impacto en cada dimensión (cuantificado), supuestos usados, riesgos identificados, alternativas evaluadas, y la recomendación del PM (aprobar/rechazar/modificar).
¿Cuándo es suficiente el análisis de impacto?
Cuando cubre todas las dimensiones relevantes, los involucrados clave han validado los números, y el CCB tiene suficiente información para decidir. La profundidad del análisis debe ser proporcional al tamaño e impacto del cambio.
06
Tema
Gestionar Solicitudes de Cambio
Las 6 fases para procesar, evaluar y ejecutar cambios de manera ordenada. Incluye el formato oficial de Solicitud de Cambio del PMBOK.
📝 6 Fases🏛️ CCB📋 Formato CR🔍 Trazabilidad
Las 6 Fases del Proceso de Solicitudes de Cambio
Un sistema bien diseñado asegura que solo los cambios que aportan valor y son factibles sean implementados. Cada solicitud de cambio (CR) debe seguir las 6 fases para mantener la estabilidad del proyecto.
01
Identificación
Captura formal con ID único
02
Evaluación
Análisis de impacto detallado
03
Priorización
Urgencia y valor del cambio
04
Decisión
CCB: aprueba o rechaza
05
Implementación
Ejecución + documentación
06
Monitoreo
Seguimiento post-cambio
Mantener Estabilidad
Gestionar adecuadamente las CRs mantiene la previsibilidad del proyecto evitando cambios no controlados.
EstabilidadAlineación Estratégica
Asegura que los cambios aprobados estén alineados con los objetivos estratégicos del proyecto y la organización.
EstrategiaControl de Costos
Minimiza los costos de cambios no planificados, que suelen ser 3-5x más caros que lo planificado.
CostoMejores Prácticas
Sistemas Automatizados de Cambio
▼Jira Service Management, ServiceNow o Azure DevOps permiten seguimiento automatizado de CRs, mejorando trazabilidad y transparencia. Cada cambio tiene historial completo: quién lo solicitó, quién lo aprobó, cuándo se implementó y cuál fue el resultado.
Comunicación Proactiva
▼Mantener a todos los stakeholders informados sobre el estado de sus solicitudes, incluyendo razones detalladas para cualquier rechazo. Un stakeholder que entiende POR QUÉ su cambio fue rechazado es mucho menos resistente que uno que solo recibe un "no".
Auditorías de Cambios
▼Revisiones periódicas (mensual o por fase) del proceso de gestión de cambios: ¿Se siguen las 6 fases? ¿Los tiempos de resolución están dentro del SLA? ¿Hay tipos de cambios recurrentes que sugieren fallas en el plan original? Las auditorías generan lecciones aprendidas valiosas.
Formato de Solicitud de Cambio — Interactivo
SOLICITUD DE CAMBIO
Formato PMBOK — Control Integrado de Cambios
CR-####
Campo obligatorio
Selecciona un tipo
Descripción obligatoria
Selecciona prioridad
Campo obligatorio
Estructura Completa del Formato
| Campo | Descripción | Obligatorio |
|---|---|---|
| ID de Solicitud | Identificador único generado por el sistema (CR-####) | ✅ Sí |
| Unidad Solicitante | Área funcional que requiere el cambio | ✅ Sí |
| Tipo de Cambio | Mejora / Defecto / Nueva Funcionalidad / Regulatorio | ✅ Sí |
| Fecha de Solicitud | Fecha en que se presentó la solicitud formalmente | ✅ Sí |
| Última Modificación | Fecha del cambio más reciente al formulario | Auto |
| Título | Línea resumen del nombre del cambio solicitado | ✅ Sí |
| Descripción | Texto libre describiendo el cambio y beneficio esperado | ✅ Sí |
| Prioridad | Alta / Media / Baja según urgencia e impacto en el proyecto | ✅ Sí |
| Nombre del Solicitante | Persona que somete la solicitud formalmente al CCB | ✅ Sí |
| Responsable de Implementación | Persona que ejecutará el cambio si es aprobado | ✅ Sí |
| Versión Planificada | Versión del producto donde se implementará el cambio | Opcional |
| Nombre del Proyecto | Proyecto al que pertenece la solicitud de cambio | ✅ Sí |
| Estatus | Pendiente / En análisis / Aprobado / Rechazado / Implementado | Auto |
| Verificador | Persona que valida que el cambio fue correctamente implementado | ✅ Sí |
Casos — Gestión de Solicitudes en Perú
🏦 Caso 1: 3 CRs simultáneas en proyecto BCP — ¿Cómo priorizas?
PriorizaciónEl proyecto de renovación de la app BCP recibe 3 CRs en la misma semana: CR-001: Error crítico en transferencias (bloquea 10,000 usuarios) | CR-002: Mejora de UX (solicitud de marketing) | CR-003: Cumplimiento SBS que entra en vigencia en 30 días.
¿En qué orden las prioriza el PM y por qué?
1. CR-001 (CRÍTICA — inmediata): Defecto que bloquea 10,000 usuarios activos. Hotfix en <24 horas. El PM puede aprobarlo directamente según umbrales de emergencia del plan de cambios.
2. CR-003 (ALTA — esta semana): La regulación SBS tiene fecha límite legal. CCB de emergencia esta semana. No hay margen para esperar.
3. CR-002 (MEDIA/BAJA — próximo sprint): La mejora de UX no tiene urgencia. Evaluar en el siguiente ciclo de planificación del CCB.
Lección: La priorización no es "primero en llegar" — es una evaluación objetiva de urgencia de negocio, impacto legal, valor al usuario y esfuerzo de implementación.
2. CR-003 (ALTA — esta semana): La regulación SBS tiene fecha límite legal. CCB de emergencia esta semana. No hay margen para esperar.
3. CR-002 (MEDIA/BAJA — próximo sprint): La mejora de UX no tiene urgencia. Evaluar en el siguiente ciclo de planificación del CCB.
Lección: La priorización no es "primero en llegar" — es una evaluación objetiva de urgencia de negocio, impacto legal, valor al usuario y esfuerzo de implementación.
🏪 Caso 2: Cambio rechazado sin explicación — Saga Falabella
ComunicaciónEl área de marketing de Saga Falabella envió una CR para añadir descuentos por geolocalización. El CCB la rechazó con un correo de una línea: "Rechazado". Marketing está molesta y dice que "TI nunca apoya las iniciativas comerciales".
¿Qué error cometió el CCB y cómo se repara?
Error: Falta de comunicación proactiva. Rechazar sin explicación genera frustración y resistencia.
Cómo reparar:
1. Reunión de 30 min con marketing para explicar las razones técnicas: complejidad de integración GPS, privacidad de datos según Ley N° 29733, riesgo de rendimiento.
2. Presentar plan alternativo: funcionalidad en v3.0 con análisis de viabilidad completo.
3. Lección aprendida: todo rechazo de CR debe incluir razón específica, criterios usados y alternativa propuesta si aplica.
Resultado: Marketing entiende el "por qué" y colabora en diseñar una versión simplificada viable para el sprint actual.
Cómo reparar:
1. Reunión de 30 min con marketing para explicar las razones técnicas: complejidad de integración GPS, privacidad de datos según Ley N° 29733, riesgo de rendimiento.
2. Presentar plan alternativo: funcionalidad en v3.0 con análisis de viabilidad completo.
3. Lección aprendida: todo rechazo de CR debe incluir razón específica, criterios usados y alternativa propuesta si aplica.
Resultado: Marketing entiende el "por qué" y colabora en diseñar una versión simplificada viable para el sprint actual.
FAQ — Solicitudes de Cambio
¿Cualquier persona puede generar una solicitud de cambio?
Sí, cualquier stakeholder puede identificar y proponer un cambio. Sin embargo, el proceso formal de registro generalmente es responsabilidad de una persona designada (PM, líder funcional o el área solicitante). Esto no significa que el cambio será aprobado — todos pasan por el mismo proceso de evaluación.
¿Qué es un "fast track" de cambios?
Proceso de aprobación acelerada para cambios urgentes o de bajo impacto. Un hotfix de seguridad crítico puede aprobarse en horas sin esperar la reunión semanal del CCB. El plan de gestión de cambios debe definir los criterios para el fast track y quién tiene autoridad para aprobarlo.
¿Cuántas solicitudes de cambio es "normal"?
No hay un número "correcto", pero muchas CRs pueden indicar: requisitos mal definidos al inicio, cambios frecuentes en el entorno de negocio, o falta de alineación con stakeholders. En proyectos bien planificados, el número de CRs debería ser bajo.
¿Cómo se registran las CRs rechazadas?
Las CRs rechazadas deben mantenerse en el Change Log con estado "Rechazado", las razones del rechazo, quién decidió y la fecha. Esto evita que la misma CR vuelva sin nueva justificación y sirve como evidencia ante auditorías.
¿Qué diferencia hay entre una CR y una lección aprendida?
Una CR es una solicitud de modificar algo en el proyecto actual. Una lección aprendida es conocimiento capturado sobre lo que funcionó o no, para mejorar proyectos futuros. Sin embargo, el análisis de por qué surgió una CR puede generar lecciones aprendidas muy valiosas para la organización.
Q1
Quiz
Quiz 1 — Temas 1, 2 y 3
Interesados · Reuniones y Eventos · Recopilación y Análisis de Datos. 8 preguntas con retroalimentación inmediata.
🎯 8 preguntas⏱️ Sin límite de tiempo✅ Feedback inmediato
1 / 8
Cargando pregunta...
preguntas correctas
Q2
Quiz
Quiz 2 — Temas 4, 5 y 6
Control Integrado de Cambios · Análisis de Impacto · Gestión de Solicitudes. 8 preguntas con retroalimentación inmediata.
🎯 8 preguntas⏱️ Sin límite de tiempo🏆 Resultado final
1 / 8
Cargando pregunta...
preguntas correctas
🎓
¡Completaste el Tema 13!
Has repasado los 6 temas de Ejecución y Control del Proyecto según el PMBOK: interesados, reuniones, datos, control de cambios, análisis de impacto y solicitudes de cambio.