Proyecto de migración a la nube con estimación en conflicto
Una empresa mediana planea migrar 40 servidores a la nube en 6 meses. El patrocinador (director de TI) aprobó un presupuesto basado en la estimación optimista del proveedor de nube: 4 meses y 3 ingenieros. El equipo interno estimó 7 meses con los mismos recursos, pero fue presionado a 'alinearse' con la cifra del proveedor. A la semana 6, la migración de los primeros 5 servidores tomó 3 semanas en lugar de 1, porque dos aplicaciones dependen de un directorio activo que no estaba inventariado. El director de TI pide un reporte de estado 'en verde' porque el cronograma aún no muestra retraso formal. El equipo teme represalias si reporta la desviación.
1. ¿Qué debe reportar el líder del proyecto y cómo debe manejar la presión de reportar 'en verde'?
Read the worked answer
Debe reportar el estado real, con evidencia, y no 'en verde'. El razonamiento:
- Datos observados: 5 servidores en 3 semanas = 1.67 servidores/semana, frente a la línea base implícita de 10 servidores/mes (2.5/semana). A ese ritmo, 40 servidores tomarían ~24 semanas solo para lo migrado, sin contar el descubrimiento de dependencias.
- Causa raíz identificada: dependencia no inventariada (directorio activo). Esto no es un retraso puntual; es evidencia de que el inventario de dependencias estaba incompleto, lo que afecta a los 35 servidores restantes.
- Integridad del reporte: un semáforo 'verde' con esta evidencia sería una distorsión de la información y trasladaría el riesgo al patrocinador sin su conocimiento. El valor del reporte es permitir decisiones, no tranquilizar.
Acción: presentar el estado con el indicador de avance real, la proyección recalculada, la causa raíz y una solicitud de decisión (renegociar alcance, plazo o recursos). Documentar la solicitud por escrito para dejar trazabilidad.
2. El patrocinador insiste en mantener la fecha y el presupuesto originales. ¿Qué opciones de decisión puedes ofrecerle y con qué criterios debería elegir?
Read the worked answer
Ofrecer opciones explícitas con impacto cuantificado, no una sola respuesta:
- A. Reducir alcance: migrar primero los servidores sin dependencias del directorio activo (por ejemplo, 25 de 40) y dejar el resto para una segunda ola. Cumple fecha y presupuesto, pero deja deuda de migración.
- B. Ampliar plazo: mantener los 40 servidores con una fecha recalculada a partir del ritmo observado y del inventario de dependencias pendiente.
- C. Ampliar recursos: añadir personal para el descubrimiento de dependencias y la remediación del directorio activo; solo funciona si el cuello de botella es capacidad y no conocimiento.
- D. Aceptar el riesgo explícito: mantener fecha y alcance, registrando el riesgo de incumplimiento y su impacto, con revisión en un hito intermedio.
Criterios de elección: costo de un día de retraso frente al costo de migrar incompleto; cuántos servidores dependen del directorio activo (define el alcance real de A); y si el equipo tiene capacidad ociosa (define la viabilidad de C). El líder no decide solo: presenta el análisis y deja la decisión al patrocinador, documentada.