Una presentación de inicio de proyecto debe dejar al equipo con unos límites de alcance compartidos, responsabilidades asignadas y un primer punto de control. Aprovecha la reunión para resolver las decisiones que afectan al trabajo inmediato, no para leer en voz alta todo el plan. Una agenda breve y un registro visible de decisiones resultan más útiles que una larga serie de diapositivas de contexto.
Pensemos en un proyecto ficticio de portal interno de solicitudes. La primera versión permitirá a los empleados solicitar equipos y viajes, y a los responsables aprobar las solicitudes o devolverlas. En la reunión de inicio hay que decidir si las solicitudes de acceso también entran en esa versión.
La agenda y la tabla de alcance que aparecen a continuación pueden convertirse en un borrador de presentación de inicio de proyecto a partir de texto en Presenti. Añade los datos reales del proyecto antes de generarlo y conserva después las decisiones en las diapositivas o en el registro del equipo.
Una agenda de 30 minutos que puedes adaptar
Envía la agenda y un resumen del proyecto con antelación. Los asistentes deben saber qué decisión requiere su aportación y qué material sirve solo de contexto. Si prevés que un debate pendiente necesitará quince minutos, dale ese espacio en lugar de esconderlo entre las presentaciones personales.
| Tiempo | Conversación | Resultado |
|---|---|---|
| 00:00–04:00 | Por qué existe el proyecto y a quién sirve | Un propósito acordado |
| 04:00–12:00 | Límites de la primera versión y decisión sobre las solicitudes de acceso | Registro de lo incluido, lo excluido y lo pendiente |
| 12:00–18:00 | Responsabilidades y autoridad para decidir | Responsables de la entrega, la aceptación y la dependencia sin resolver |
| 18:00–25:00 | Primer punto de control y sus dependencias | Entregable, condición de aceptación y fecha prevista |
| 25:00–30:00 | Repaso de decisiones y confirmación de las próximas acciones | Registro de decisiones y fecha de la siguiente reunión |
Este horario es un ejemplo, no una regla universal. Una reunión entre varias empresas puede requerir sesiones específicas para contratos, seguridad o diseño técnico. Programa esas reuniones de forma explícita en lugar de convertir el inicio del proyecto en un taller para resolverlo todo.
Haz visible la decisión de alcance
«Crear un portal de solicitudes» admite demasiadas interpretaciones. Muestra los límites de la versión en una diapositiva y coloca la decisión pendiente en una fila aparte. El equipo ficticio parte de esta información:
| Elemento | Situación inicial | Qué hay que decidir |
|---|---|---|
| Solicitud de equipos | Primera versión | Campos obligatorios y rol de aprobación |
| Solicitud de viajes | Primera versión | Traspaso de la aprobación al área financiera |
| Solicitud de acceso | Sin decidir | ¿Incluir una aprobación manual o posponerla hasta conocer la integración de identidades? |
| Asignación automática de accesos | Fuera de la primera versión | No se asume ese compromiso en esta reunión |
La persona que patrocina el proyecto decide posponer las solicitudes de acceso porque aún no se han definido el equipo receptor ni el trabajo de integración. Registra tanto la decisión como el motivo: «Las solicitudes de acceso quedan fuera de la primera versión; TI estimará el trabajo antes de la siguiente revisión de alcance». No conviertas «pospuesto» en «próximamente disponible» en una diapositiva posterior.
Sustituye el organigrama por tres preguntas sobre responsabilidades
Identifica quién dirige el trabajo, quién acepta el resultado y quién puede cambiar el alcance. En este ejemplo, la persona responsable de la entrega coordina el desarrollo; la de operaciones acepta el piloto según sus criterios; y la que patrocina el proyecto decide si un nuevo tipo de solicitud cambia los límites de la versión. Un contacto del área financiera aporta las reglas de aprobación de viajes, pero eso no lo convierte automáticamente en responsable del proyecto.
Si utilizas RACI, escribe la acción junto a las siglas. «Responsable último: patrocinador» informa menos que «El patrocinador aprueba los cambios en el alcance de la primera versión». En las dependencias, identifica también a quien recibe el trabajo, no solo a quien envía la solicitud.
La guía de PMI sobre reuniones de lanzamiento incluye objetivos, inclusiones y exclusiones de alcance, estrategia, riesgos, supuestos y responsabilidad sobre las tareas. Una presentación de inicio lleva esos temas a la conversación; no sustituye la autorización del proyecto ni un plan detallado.
Define qué demostrará el primer punto de control
El primer punto de control consiste en probar el recorrido de una solicitud de equipos, no en declarar «prototipo terminado». Un empleado del piloto debe poder enviar una solicitud; un responsable, devolverla indicando el motivo; y el empleado, encontrar el resultado. La persona responsable de operaciones observará la prueba y decidirá si el recorrido está listo para un piloto reducido.
Coloca los requisitos previos junto a la fecha: finanzas debe aportar la regla de aprobación y TI debe proporcionar cuentas de prueba. Si uno de esos elementos se retrasa, el equipo revisa el punto de control en lugar de reducir silenciosamente el tiempo de prueba. En los hitos posteriores, utiliza el mismo esquema de entregable y aceptación. Antes de comprometer esa fecha de revisión, una presentación de planificación de capacidad permite comparar el trabajo necesario con las horas realmente disponibles del equipo.
Repasa este registro de decisiones antes de cerrar
Quien presenta puede terminar la reunión con el siguiente registro, completado durante la sesión:
Decisión: La primera versión incluye solicitudes de equipos y viajes. Exclusiones: Solicitudes de acceso y asignación automática de accesos. Motivo: No se han resuelto el responsable de las solicitudes de acceso ni el esfuerzo de integración. Próxima acción: TI estima el recorrido de las solicitudes de acceso para la siguiente revisión de alcance. Primer punto de control: Enviar, devolver y recuperar una solicitud de equipos. Responsable de aceptación: Responsable de operaciones. Dependencias: Cuentas de prueba y reglas de aprobación de finanzas. Próxima revisión: [fecha y responsable de la reunión].
Distribuye el registro después de la reunión junto con las diapositivas. Los nuevos integrantes deben poder distinguir los límites acordados de las ideas planteadas durante la conversación. Si algo cambia, actualiza la decisión con su motivo y responsable en lugar de borrar el historial.
Crea la presentación de inicio en Presenti a partir de la agenda, la tabla de alcance y el punto de control. Una presentación útil es la que el equipo puede consultar cuando surge la primera duda sobre el alcance, no la que solo se veía bien durante la reunión.
