Purpose

Asegurar que Sales y Delivery compartan la misma interpretación del proyecto antes de comenzar Project Setup & Planning.

El Handoff Meeting no es una presentación comercial del proyecto.

Es una instancia de validación donde el equipo revisa la definición existente, identifica inconsistencias, resuelve dudas críticas y confirma si el proyecto está suficientemente claro para avanzar.

When it happens

El Handoff Meeting ocurre una vez que:

• la oportunidad está en Won;
• Sales completó el Project Definition en /nk.pulse;
• la información comercial relevante está disponible;
• y el equipo tuvo oportunidad de revisar el material previamente.

El proyecto no puede avanzar a Project Setup & Planning antes de atravesar este gate.

Participants

Required

• Sales
• Project Manager
• Design Lead
• Tech Lead, cuando exista componente técnico

Recommended / Optional

• CCO
• CTO

Otros participantes pueden sumarse cuando exista una razón concreta relacionada con scope, riesgo o conocimiento del proyecto.

Before the Meeting

Pre-read

Todos los participantes deberían revisar previamente el Project Definition.

La reunión no debería ser el primer momento en que Delivery conoce el proyecto.

Cada participante debe llegar preparado para identificar:

• información faltante;
• contradicciones;
• riesgos;
• assumptions dudosos;
• dependencies;
• compromisos difíciles de cumplir;
• o cualquier punto que pueda impedir una planificación responsable.

Expected pre-read

Como mínimo revisar:

• Approved SOW / Proposal
• Project Context
• Expected Impact
• Scope
• Out of Scope
• Assumptions
• Dependencies
• Commitments
• Content & Materials
• Known Risks
• Open Items

Cuando corresponda:

• Web Questionnaire
• Branding Questionnaire
• documentación técnica;
• referencias compartidas por el cliente.

Meeting Flow

La reunión se realiza utilizando directamente el Project Definition en /nk.pulse.

No debería existir una presentación paralela salvo que sea realmente necesaria.

La revisión se realiza punto por punto.

1. Context & Expected Impact

Confirmar que el equipo entiende:

• por qué existe el proyecto;
• qué problema u oportunidad está abordando;
• qué espera conseguir el cliente;
• cómo se espera evaluar su impacto, cuando exista una métrica disponible.

Questions

• ¿Entendemos por qué el cliente está haciendo este proyecto?
• ¿Existe un outcome esperado claro?
• ¿Existe KPI o forma de medirlo?
• Si no existe, ¿está asignado quién deberá definirlo?

2. Scope

Revisar el alcance utilizando el Scope Standard correspondiente.

Questions

• ¿Está claro qué estamos produciendo?
• ¿Está expresado en unidades concretas?
• ¿Existe un límite cuantitativo?
• ¿Todos interpretamos ese límite de la misma manera?
• ¿Hay alguna parte del proyecto que todavía dependa de una interpretación individual?
• ¿Coincide con lo vendido al cliente?

Un scope general como:

Redesign del website.

no es suficiente.

3. Out of Scope

Confirmar explícitamente qué no está incluido.

Questions

• ¿Existen áreas donde el cliente podría razonablemente asumir que algo está incluido?
• ¿Esas exclusiones están documentadas?
• ¿La Scope Matrix está completa cuando corresponde?

4. Assumptions

Revisar las condiciones sobre las que se construyó el proyecto.

Questions

• ¿Qué asumimos para definir scope o timeline?
• ¿Depende el proyecto de alguna assumption especialmente riesgosa?
• ¿Qué pasa si esa assumption deja de ser cierta?

5. Dependencies & Materials

Revisar todo aquello que /nk necesita del cliente o de terceros.

Questions

• ¿Qué necesitamos?
• ¿Quién lo provee?
• ¿Cuándo lo necesitamos?
• ¿Qué pasa si llega tarde?
• ¿Tenemos claro quién crea, aprueba y carga el contenido?
• ¿Faltan accesos, assets o documentación?

6. Commitments

Sales debe hacer visibles todos los compromisos relevantes asumidos con el cliente.

Especialmente:

• hard deadlines;
• launch dates;
• milestones;
• technologies;
• integrations;
• review rounds;
• deliverables;
• special agreements;
• cualquier expectativa que Delivery necesite conocer.

Questions

• ¿Hay alguna promesa al cliente que no esté reflejada en Project Definition?
• ¿Existe algún commitment que Delivery considere riesgoso?
• ¿Hay algo que necesitemos aclarar antes de planificar?

7. Risks

Revisar los Known Risks.

No se busca construir una lista exhaustiva de riesgos hipotéticos.

Se busca hacer visibles aquellos que ya conocemos.

Questions

• ¿Hay algún riesgo evidente que todavía no esté registrado?
• ¿Hay una deadline especialmente agresiva?
• ¿Hay dependencias externas críticas?
• ¿Hay problemas de disponibilidad o governance del lado cliente?
• ¿Existe algún riesgo de scope o complejidad?

8. Open Items

Revisar uno por uno todos los pendientes.

Cada Open Item debe tener:

Owner + Due Date / Milestone + Impact + Status

Para cada uno debe definirse:

• si puede resolverse después del Handoff;
• o si bloquea Readiness.

Blocking Rule

Un proyecto puede avanzar con información todavía pendiente.

No puede avanzar con scope materialmente indefinido.

Examples of non-blocking Open Items

• credencial necesaria más adelante;
• contacto técnico pendiente;
• fotografías con fecha futura acordada;
• KPI a definir durante kickoff.

Examples of blocking Open Items

• cantidad de componentes sin definir;
• sitemap o cantidad de templates sin definición cuando forma parte del scope;
• integración potencial sin saber si está incluida;
• funcionalidad importante ambigua;
• no saber quién produce el contenido;
• deliverable relevante no definido;
• inconsistencia entre Project Definition y lo firmado.

Ready with Open Items does not mean Ready with Undefined Scope.

Discipline Validation

Al finalizar la revisión, cada responsable valida su área.

Design Lead

Confirma que entiende y valida:

• Design scope
• Deliverables
• Assumptions
• Dependencies
• Relevant risks

Tech Lead

Cuando corresponda, confirma que entiende y valida:

• Technical scope
• Integrations
• Technical assumptions
• Technical dependencies
• Relevant constraints and risks

Project Manager

Valida que:

• la definición general sea suficientemente clara;
• todos los pendientes estén gestionados;
• no existan contradicciones relevantes;
• el proyecto pueda comenzar a planificarse responsablemente.

When something does not match

Si durante el handoff aparece una inconsistencia entre:

• lo firmado;
• lo transmitido por Sales;
• lo entendido por Delivery;
• o las condiciones reales del proyecto;

no debe ignorarse para resolverla después.

Sales y el equipo del proyecto deben acordar cómo resolverla antes de avanzar.

Según el caso puede implicar:

• aclarar la definición;
• ajustar scope;
• modificar timeline;
• dividir entregas en fases;
• cambiar el approach;
• revisar staffing;
• o acordar una modificación comercial con el cliente.

El objetivo es proteger simultáneamente:

• la relación con el cliente;
• la calidad del proyecto;
• y la estabilidad operativa y económica de /nk.

Readiness Gate

Una vez finalizada la reunión y resueltos los blockers, el Project Manager asigna el estado del proyecto en /nk.pulse.

Ready

El proyecto cuenta con toda la información necesaria para comenzar Project Setup & Planning.

No existen blockers relevantes.

Ready with Open Items

El proyecto puede comenzar a planificarse aunque existan pendientes.

Todos los Open Items tienen:

• Owner
• Due Date / Milestone
• Impact identificado

Ninguno deja materialmente indefinido el scope.

Not Ready

Existe al menos una definición, contradicción o dependencia suficientemente importante como para impedir una planificación responsable.

El proyecto permanece en este estado hasta resolverla.

Who sets the status

Design Lead y Tech Lead realizan sus validaciones correspondientes.

El Project Manager es la única persona que finalmente cambia el Readiness Status en /nk.pulse.

Si alguno de los responsables no valida su área, el proyecto no debe marcarse Ready hasta resolver la situación.

Definition of Done

El Handoff Meeting & Readiness Gate está completo cuando:

• Todos los participantes requeridos asistieron.
• El equipo realizó el pre-read.
• Project Definition fue revisado punto por punto.
• Scope fue validado.
• Out of Scope fue revisado.
• Assumptions fueron revisados.
• Dependencies fueron revisadas.
• Commitments fueron revisados.
• Risks fueron revisados.
• Open Items fueron revisados.
• Todos los Open Items tienen Owner y Due Date / Milestone.
• Los blockers fueron resueltos o el proyecto quedó Not Ready.
• Design Lead realizó su validación.
• Tech Lead realizó su validación cuando corresponde.
• PM realizó su validación.
• PM asignó un Readiness Status en /nk.pulse.

Evidence

Toda la evidencia debe quedar en /nk.pulse:

• Project Definition
• Validation status
• Open Items
• Readiness Status

No debería ser necesario generar minutas o documentación paralela si las decisiones relevantes quedaron correctamente registradas en el sistema.

Output

El proceso termina con uno de estos tres resultados:

Ready → Project Setup & Planning

Ready with Open Items → Project Setup & Planning + tracked Open Items

Not Ready → Resolve blockers → repeat Readiness validation