Una presentación de traspaso de proyecto debe demostrar si el equipo receptor puede asumir la responsabilidad del trabajo, no solo si el equipo del proyecto ha terminado de construirlo. Explica qué se ha aceptado, qué ha demostrado el equipo receptor, qué asuntos siguen abiertos y quién responderá después del traspaso.
Separa tres decisiones: aceptar un entregable, autorizar su uso operativo y cerrar formalmente el proyecto. Pueden ocurrir en momentos distintos. Cuando las pruebas y las responsabilidades propuestas estén claras, convierte el informe de traspaso en un borrador de presentación editable. Las diapositivas deben facilitar la revisión de esas decisiones, no sustituirlas.
Define exactamente qué se va a traspasar
«El proyecto está terminado» es demasiado amplio para orientar al siguiente equipo. Indica el servicio, proceso o activo que se transfiere, su versión, la persona que lo recibirá y el momento previsto del traspaso. Señala también lo que queda fuera, como una función de informes prevista para más adelante o un proceso anterior ajeno al alcance.
El estudio de APM sobre el traspaso de proyectos, en inglés lo aborda como una transición, no como una fecha aislada. Destaca la claridad de responsabilidades, la transferencia de conocimientos útiles y la participación de quienes recibirán el resultado. Es una buena base para la presentación: muestra las condiciones para asumir el trabajo, no una meta meramente ceremonial.
Por ejemplo, un proyecto ha creado un nuevo proceso de solicitudes de equipamiento para un equipo interno de operaciones. Incluye un formulario, reglas de asignación, un manual operativo y un procedimiento de excepciones. La persona que recibirá la responsabilidad será quien dirige operaciones. Es un caso ficticio para explicar la presentación, no una implementación de Presenti ni una afirmación sobre funciones de automatización del producto.
La primera diapositiva podría decir: «Traspasar el proceso de solicitudes cuando se acepte el procedimiento de excepciones, la persona suplente supere la prueba y se acuerde quién prestará soporte». El título indica lo que se propone y lo que todavía impide el traspaso. No esconde una condición pendiente bajo una etiqueta verde de «completado».
Distingue los entregables aceptados de la preparación operativa
Antes de diseñar las diapositivas, prepara un registro breve de entregables. Para cada resultado importante, muestra la versión, el criterio de aceptación y la prueba correspondiente. «Enviado a operaciones» acredita una entrega; no demuestra que operaciones lo haya revisado o aceptado.
| Entregable | Prueba en el proyecto ficticio | Qué queda pendiente |
|---|---|---|
| Formulario v1.3 | La persona responsable del equipo receptor aceptó los campos requeridos y envió una solicitud normal de prueba. | No se ha registrado ningún problema abierto del formulario. |
| Reglas de asignación v1.2 | Las solicitudes normales llegaron a la cola prevista durante la prueba. | La cobertura durante ausencias no ha superado la prueba completa. |
| Manual operativo v1.0 | La persona titular siguió el procedimiento habitual sin instrucciones continuas del responsable del proyecto. | La persona suplente no pudo abrir las instrucciones de excepciones durante la prueba. |
| Procedimiento de excepciones v0.9 | Un borrador identifica el rol propuesto para las escalaciones. | El equipo receptor no ha aceptado el procedimiento ni demostrado su ejecución. |
Conserva el registro real de aceptación en el sistema acordado para el proyecto, con la persona que aprobó, la fecha y la versión. Enlázalo o haz referencia a él desde la diapositiva. El resumen de una presentación no sustituye los registros de aprobación exigidos por el contrato o la organización.
No conviertas la tabla en «75 % preparado» porque tres filas parezcan casi terminadas. No son unidades equivalentes de preparación, y una sola vía de excepciones sin resolver puede importar más que varios documentos completos. Describe directamente la condición pendiente.
Muestra lo que el equipo receptor puede hacer sin tu ayuda
A menudo, la diapositiva más reveladora procede de una prueba realizada por el equipo receptor. Elige acciones parecidas al trabajo habitual y una excepción verosímil. El objetivo es encontrar carencias de conocimientos, acceso o responsabilidad mientras el equipo del proyecto aún está disponible.
En este ejemplo, pide al equipo receptor que tramite una solicitud normal, encuentre el procedimiento vigente, gestione una solicitud durante la ausencia de la persona titular e identifique dónde registrar una excepción sin resolver. Utiliza datos de prueba autorizados y el entorno acordado para el ejercicio.
En la prueba ficticia, la solicitud normal se resuelve correctamente. El caso de ausencia llega a la cola de la persona suplente, pero esta no puede abrir las instrucciones de excepciones. Es un hallazgo más preciso y útil que «falta formación»: identifica un problema concreto de acceso y procedimiento que puede asignarse y volver a probarse.
La solución no consiste solo en enviar otro documento. La persona responsable debe habilitar el acceso aprobado, confirmar qué procedimiento está vigente y repetir el mismo caso de ausencia. Registra lo que suceda. Asistir a una sesión de formación no demuestra que esta tarea concreta pueda ejecutarse.
Si no es posible terminar una prueba antes del traspaso previsto, explica por qué y quién puede aceptar el riesgo resultante. No marques como superada una prueba que no se ha realizado. Cuando la condición pendiente impide un uso seguro o viable, la propuesta adecuada es aplazar esa parte del traspaso, no rebajar la redacción del criterio de aceptación.
Muestra qué cambia después de repetir la prueba
Llamemos R1 al ensayo fallido descrito arriba. Para mostrar cómo evoluciona la decisión, supongamos una segunda prueba, R2, después de corregir el acceso. Es una continuación ficticia, no una prueba realizada con un cliente. Se repite la ausencia del responsable principal en el entorno de prueba autorizado y con datos permitidos.
| Campo del registro R2 | Ejemplo cumplimentado |
|---|---|
| Escenario y versiones | Ausencia del responsable principal; formulario v1.3, reglas de enrutamiento v1.2, guía operativa v1.0 y procedimiento de excepciones v0.9, todavía en borrador. |
| Resultado esperado | El suplente abre la guía y tramita la excepción de prueba sin instrucciones paso a paso del equipo del proyecto. |
| Resultado observado en este supuesto | El suplente abre la guía, registra la excepción y completa la escalación de prueba sin ayuda. |
| Pruebas que hay que conservar | Referencia del caso, fecha de ejecución, versiones utilizadas y registro de revisión del equipo receptor; en un proyecto real deben enlazarse las pruebas correspondientes. |
| Problema que puede cerrarse | El fallo de acceso de R1 queda resuelto para este escenario y estas versiones. |
| Condiciones que siguen abiertas | La aprobación del procedimiento de excepciones y el reparto de responsabilidades de soporte no están confirmados. |
El resultado permite cambiar una afirmación concreta: el suplente ya pudo completar ese caso de prueba. No convierte el procedimiento v0.9 en una versión aprobada para uso operativo. Tampoco confirma otros escenarios ni autoriza el traspaso completo.
La decisión del ejemplo podría redactarse así: «Se aplaza el traspaso operativo. El problema de acceso queda resuelto para el caso R2. El responsable receptor debe confirmar la versión aceptada del procedimiento; el patrocinador y el responsable receptor deben acordar el soporte. Se mantiene la responsabilidad operativa vigente y no se fija aún una fecha efectiva de traspaso». Es un modelo de registro, no una aprobación real.
Cuando se aporten las pruebas pendientes, la persona autorizada podrá reconsiderar la decisión y registrar versiones, límites, responsable y fecha efectiva. Si cambia el procedimiento, deberá valorar si hay que repetir el escenario. La tabla de asuntos abiertos que sigue conserva la situación inicial de R1: en el registro vigente se actualiza por separado la fila de acceso y se conserva su historial, sin marcar todas las condiciones como resueltas por haber superado una prueba.
Asigna responsables y límites a cada asunto pendiente
Un traspaso puede incluir trabajo abierto, pero cada pendiente necesita un acuerdo explícito. Muestra quién lo resolverá, quién se ocupará de la operación diaria mientras tanto, qué límite temporal o funcional se aplica y quién está autorizado para aceptarlo. Pueden ser personas con roles distintos.
| Asunto abierto | Acuerdo propuesto | Prueba necesaria para cerrarlo |
|---|---|---|
| La persona suplente no puede acceder a las instrucciones de excepciones | La persona responsable de accesos del proyecto corrige el permiso; quien dirige el equipo receptor organiza otra prueba. | La persona suplente completa el caso de ausencia con el manual vigente. |
| El procedimiento de excepciones no está aceptado | La persona responsable de operaciones lo revisa con quien dirige el proyecto; asistir a una reunión no implica aprobarlo. | El registro identifica la versión aceptada y sus posibles límites. |
| No se ha acordado quién dará soporte tras el traspaso | La persona patrocinadora del proyecto y quien dirige el equipo receptor confirman contactos, periodo de cobertura y escalación. | Ambos equipos saben qué rol atiende cada tipo de solicitud. |
En este ejemplo, el traspaso propuesto sigue condicionado a los dos primeros puntos. También debe acordarse el soporte antes de cambiar las responsabilidades. La tabla recoge propuestas, no compromisos que personas reales ya hayan adquirido.
En otro proyecto, un defecto visual menor podría aceptarse como trabajo posterior. Eso no significa que cualquier fallo pueda transferirse al siguiente equipo. Aplica los criterios de aceptación y la autoridad de decisión reales, y muestra los límites a quienes van a utilizar el resultado.
Explica cómo funcionará la primera semana de operación
Una diapositiva de soporte debe aclarar qué ocurrirá cuando alguien necesite ayuda después del traspaso. Identifica el contacto operativo principal, la persona suplente, el contacto del proyecto durante el periodo de apoyo que se acuerde y la vía para una incidencia urgente. Indica cuándo termina o se revisa ese acuerdo temporal.
No inventes una promesa de dos semanas de soporte porque encaje en la diapositiva. Si aún no se han acordado la duración o la disponibilidad, márcalas como decisiones pendientes. Distingue pedir ayuda de autorizar un cambio en el alcance aceptado.
En el ejemplo, quien dirige el equipo receptor propone revisar las excepciones abiertas durante la primera semana. La revisión serviría para confirmar si la sustitución funciona en la práctica y si hay que corregir el manual. No reabriría silenciosamente el alcance terminado ni garantizaría que el equipo del proyecto asumiera todas las nuevas solicitudes.
Facilita el acceso al manual vigente, las pruebas de aceptación y el registro de incidencias. Si el cambio forma parte de un plan operativo más amplio, vincúlalo con sus responsables y calendario de revisión, descritos en esta guía en inglés, en lugar de crear en las diapositivas unas responsabilidades incompatibles.
Guía la reunión con seis diapositivas
La reunión debe conducir a una decisión sobre la responsabilidad, no limitarse a dejar constancia de que se presentó un documento.
- Propuesta de traspaso: proceso, versión, responsable receptor, momento previsto y condiciones.
- Alcance aceptado: entregables principales, pruebas de aceptación y exclusiones explícitas.
- Demostración del equipo receptor: tareas normales y excepcionales realizadas, resultados observados y carencias.
- Pendientes: bloqueos, trabajo posterior aceptado, responsables y prueba necesaria para resolver cada punto.
- Soporte operativo: contactos, suplencias, apoyo temporal del proyecto y límites de escalación.
- Registro de decisión: continuar, continuar dentro de límites aprobados o aplazar; documentar la decisión autorizada y la próxima revisión.
Usa una tabla estrecha para las condiciones sin resolver y una línea temporal sencilla para el cambio de responsabilidad del soporte. No reduzcas todo el plan del proyecto hasta hacerlo caber en una diapositiva. Los procedimientos detallados van en los materiales de referencia; la presentación recoge las pruebas y decisiones que el equipo receptor necesita ahora.
Crea el borrador con las pruebas y registra la decisión real
Utiliza estas instrucciones después de sustituir el ejemplo por información aprobada. Mantén la diferencia entre tarea terminada, entregable aceptado y acción propuesta.
El siguiente texto conserva la situación de R1, antes de la repetición hipotética R2. Si preparas una presentación posterior, sustituye ese estado solo por resultados y decisiones verificados; no copies el resultado ilustrativo de R2 como si hubiera ocurrido en tu proyecto.
Crea una presentación de traspaso de seis diapositivas para el proceso ficticio de solicitudes de equipamiento descrito arriba. La audiencia es la persona patrocinadora del proyecto y el equipo receptor de operaciones. Incluye la propuesta de traspaso, el alcance aceptado, los resultados reales de la prueba, las condiciones pendientes, el soporte y la decisión necesaria. La solicitud normal funcionó; la persona suplente no pudo abrir las instrucciones de excepciones durante la prueba y todavía no ha superado una repetición; el procedimiento de excepciones no está aceptado. No marques el proyecto como cerrado, no inventes aprobaciones ni presentes el soporte propuesto como acordado. Deja identificados los responsables y fechas que falte completar.
Lee con cuidado la conclusión generada. «Listo para el traspaso» tergiversaría esta información; «Listo cuando se cumplan las condiciones indicadas» conserva el sentido de la propuesta. Contrasta la última diapositiva con el resultado real de la reunión antes de distribuirla.
Tras la decisión autorizada, actualiza en el registro de origen y en la presentación quién recibe la responsabilidad, la fecha efectiva, los límites aceptados y las acciones pendientes. Después podrá considerarse el cierre del proyecto mediante el proceso habitual de la organización. Un traspaso útil es aquel con el que el equipo receptor puede trabajar, no el que termina con la diapositiva más rotunda.
