La presentación de una solicitud de cambio debe mostrar la diferencia entre el plan aprobado y la modificación propuesta. Expón ante quien decide el compromiso actual, lo que se quiere añadir, sus consecuencias y las opciones disponibles. Un requisito nuevo no queda aprobado por aparecer en la última diapositiva.
Cuando los responsables correspondientes hayan validado el análisis de impacto, puedes utilizar Presenti para organizar la solicitud de cambio en un borrador de diapositivas. Incluye los supuestos y el estado de aprobación en el texto de entrada. Forman parte de la solicitud; no son detalles que deban desaparecer al resumirla.
Empieza por el plan de referencia aprobado
Supongamos que un equipo prepara un piloto interno de reservas. El alcance acordado incluye un formulario de reserva, confirmaciones por correo y un informe semanal de utilización. El lanzamiento está previsto para el final de la sexta semana y el presupuesto aprobado es de 40 000 dólares. Ahora, el patrocinador del proyecto solicita añadir inicio de sesión único antes de lanzar el piloto.
Estas cifras ficticias se utilizan en todo el ejemplo. Las estimaciones del equipo son supuestos didácticos, no precios ni promesas de entrega de una integración real.
La primera diapositiva debe distinguir lo que ya está comprometido de lo que se solicita. Junto al alcance, indica la versión del plan de referencia o el documento de aprobación para que los participantes puedan consultarlo. Si el plan vigente ya ha cambiado, concilia primero ese registro antes de compararlo con una propuesta nueva.
La guía de Microsoft para evaluar cambios de proyecto, en inglés, trata el impacto en los requisitos, la financiación y las fechas, así como la autoridad necesaria para aprobar una solicitud. La presentación debe respetar las reglas de aprobación del proyecto. Una plantilla genérica no determina quién tiene esa autoridad.
Muestra el impacto adicional, no solo el nuevo total
En el ejemplo, el responsable técnico estima que añadir inicio de sesión único requerirá 8000 dólares más y diez días laborables adicionales respecto al plan actual. La estimación supone que la configuración del sistema de identidad, las cuentas de prueba y las personas encargadas de la revisión estarán disponibles cuando se necesiten. Esos supuestos deben figurar junto a la estimación.
| Elemento | Plan aprobado | Cambio propuesto | Resultado si se aprueba |
|---|---|---|---|
| Alcance | Formulario de reserva, confirmaciones por correo e informe semanal | Añadir inicio de sesión único | Alcance actual más la integración y las tareas de aceptación acordadas |
| Presupuesto | 40 000 dólares | Incremento estimado de 8000 dólares | Total estimado de 48 000 dólares |
| Lanzamiento del piloto | Final de la sexta semana | Ampliación estimada de diez días laborables | Final de la octava semana con el calendario de cinco días del ejemplo, sin festivos ni conflictos de recursos |
| Dependencias | Requisitos previos del piloto actual | Configuración de identidad, cuentas de prueba y revisión de la integración | Habrá que revisar la estimación si se retrasa alguna dependencia |
El incremento equivale al 20 % del presupuesto original: 8000 ÷ 40 000 dólares. Ese porcentaje aporta contexto, pero no es una regla automática de aprobación. Tampoco una estimación de diez días de trabajo implica necesariamente retrasar diez días el lanzamiento. En este ejemplo se supone de forma explícita que el trabajo adicional prolonga la secuencia que determina el lanzamiento. En un plan real, muestra las dependencias y la capacidad disponible que justifican el impacto en el calendario.
Evita dar una nueva fecha exacta cuando el equipo solo haya estimado una duración y todavía no se hayan confirmado los requisitos previos. Si hace falta una fecha concreta, calcúlala con el responsable del calendario usando el calendario del proyecto.
Presenta opciones que realmente puedan aprobarse
La disyuntiva «aceptar o rechazar» puede ocultar una alternativa intermedia útil. Para esta solicitud, compara tres posibilidades con los mismos criterios:
| Opción | Qué cambia | Consecuencia principal | Qué falta confirmar |
|---|---|---|---|
| Añadir la integración antes del lanzamiento | Mantener todos los entregables actuales y añadir inicio de sesión único | Total estimado de 48 000 dólares y ampliación de diez días laborables | Dependencias, capacidad de revisión y aprobación del cambio |
| Mantener el piloto actual y planificar la integración después | Conservar el alcance aprobado y evaluar una versión posterior independiente | La fecha de lanzamiento del plan de referencia sigue siendo la base de planificación | Si el acceso actual sigue siendo aceptable y si integrar más adelante generaría trabajo adicional |
| Intercambiar entregables dentro del alcance del piloto | Evaluar la sustitución o el aplazamiento de otro entregable | El efecto en el coste y la fecha aún no está estimado | Qué entregable puede cambiar, sus dependencias y una estimación revisada |
La tercera opción no significa automáticamente «mismo presupuesto, misma fecha». Retirar un informe no demuestra que sus recursos o su tiempo puedan trasladarse a una integración. Señala expresamente que esa opción no tiene estimación y, si sigue siendo atractiva, solicita un análisis de impacto.
La segunda opción también necesita una condición. Si el requisito nuevo es obligatorio para que funcione el piloto, quizá no pueda aplazarse. La presentación debe mostrar ese límite, en vez de mantener en la tabla una opción cómoda pero inviable.
Estructura la solicitud de cambio en seis diapositivas
- Decisión solicitada. Identifica el cambio, la opción recomendada y la fecha límite para decidir.
- Compromiso actual. Muestra el alcance, el presupuesto y los hitos aprobados, junto con la referencia del plan de partida.
- Motivo de la solicitud. Explica quién necesita el cambio y qué ocurre si se aplaza. Distingue un requisito obligatorio de una preferencia.
- Impacto. Expón los incrementos de coste, plazo, trabajo y dependencias. Indica qué responsables aportan las estimaciones.
- Alternativas. Compara opciones viables y la cuestión pendiente de cada una.
- Registro de la decisión. Deja campos claros para la decisión real, las condiciones, la persona que decide y la fecha.
Lleva al anexo los detalles del diseño técnico y el desglose de las estimaciones. La secuencia principal debe explicar las consecuencias sin obligar a quien aprueba a revisar cada tarea. Comparar el alcance antes y después suele ser más claro que mostrar una hoja de ruta general donde el nuevo requisito queda oculto entre trabajos ya previstos.
Gestiona la incertidumbre y los datos nuevos durante la reunión
Si una dependencia cambia durante la reunión, señala qué parte de la recomendación se ve afectada. Por ejemplo, la falta de cuentas de prueba puede invalidar la ampliación de diez días. Registra que hace falta actualizar la estimación, en vez de defender una cifra que ya no se sostiene.
Una decisión condicionada debe ser igual de precisa. «Proceder si el responsable técnico confirma la estimación y el patrocinador aprueba el incremento de presupuesto» no equivale a «Aprobado». No uses el mismo verde para ambos estados ni elimines las condiciones de la última diapositiva.
Después de la reunión, conserva la versión de la solicitud que se debatió y vincula a ella la decisión registrada. Actualiza el plan de ejecución únicamente mediante el procedimiento de cambios acordado. Una presentación revisada, por sí sola, no indica al equipo qué alcance, fecha o presupuesto tiene ahora validez.
Redacta las instrucciones sin dar el cambio por aprobado
Pega las instrucciones revisadas en Presenti para organizarlas en un borrador de diapositivas editable. Incluye el plan de referencia, las estimaciones y los supuestos en el texto de origen; introducir solo un tema como «solicitud de cambio» dejaría demasiados elementos de la justificación sin definir.
Crea una presentación de seis diapositivas sobre una solicitud ficticia de cambio para un piloto interno de reservas. Alcance aprobado: formulario de reserva, confirmaciones por correo e informe semanal de utilización. Presupuesto aprobado: 40 000 dólares. Lanzamiento previsto: final de la sexta semana. Ampliación solicitada: inicio de sesión único antes del lanzamiento. Estimación del responsable técnico: 8000 dólares adicionales y diez días laborables que prolongan la secuencia de lanzamiento, suponiendo que la configuración de identidad, las cuentas de prueba y los revisores estén disponibles. Utiliza una semana de cinco días laborables sin festivos solo para este ejemplo. Compara añadir la integración ahora, mantener el piloto actual y evaluar una versión posterior, e intercambiar entregables con una nueva estimación. No asignes coste ni fecha a la opción de intercambio aún no estimada. Mantén visibles los requisitos obligatorios, los supuestos y las condiciones de aprobación. Deja vacíos los campos de la decisión real y de la persona que aprueba; no inventes una aprobación.
Revisa el borrador para detectar cambios sutiles de significado: que «estimado» se convierta en «confirmado», una opción condicionada en una promesa o una decisión pendiente en una aprobación. Estas diferencias importan más que el tema visual elegido. La presentación terminada debe facilitar la evaluación de la solicitud y conservar los compromisos originales.
