Sales Handoff → Project Readiness

Purpose

Asegurar que ningún proyecto pase de Sales a Delivery sin una definición clara y compartida de:

  • qué se vendió;
  • qué impacto busca generar el cliente;
  • cuál es el alcance;
  • qué compromisos existen;
  • qué dependencias y riesgos conocemos;
  • y qué información sigue pendiente.

El objetivo es que el equipo pueda empezar a planificar el proyecto con suficiente certeza, evitando reconstruir contexto después del kickoff o descubrir definiciones críticas durante Production.


Trigger

El proceso comienza formalmente cuando una oportunidad pasa a Won.

Sales puede comenzar a completar la información previamente, especialmente cuando el proyecto ya tiene suficiente nivel de definición.

Un proyecto no puede avanzar a Project Setup & Planning hasta completar este proceso y atravesar el Readiness Gate.


Owner

Accountable: Project Manager.

Required validation

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

Recommended / Optional participation

  • CCO
  • CTO
  • TSL

Sales es responsable de transferir correctamente toda la información y los acuerdos realizados durante la etapa comercial.

Una vez realizado el handoff, el Project Manager toma ownership de la definición operativa del proyecto y de mantenerla actualizada.


Source of Truth

Toda la información operativa del proyecto debe vivir en /nk.pulse.

Dentro del proyecto, Project Definition funciona como la fuente única de verdad para entender:

  • qué estamos haciendo;
  • por qué;
  • qué está incluido;
  • qué no está incluido;
  • qué se prometió;
  • qué necesitamos;
  • y qué decisiones siguen pendientes.

La información relevante no debería depender de Slack, emails, reuniones pasadas o conocimiento individual del equipo.

Project Definition es un documento vivo y debe mantenerse actualizado durante todo el proyecto.

→ See: Project Definition


Contractual Source

El Project Definition debe representar operativamente lo acordado con el cliente.

La fuente contractual siempre es el SOW / propuesta aprobada por el cliente.

El objetivo es que exista el menor gap posible entre ambos:

SOW / Proposal → Project Definition → Execution

Si durante el handoff aparece una contradicción entre lo vendido y la interpretación de Delivery, debe resolverse con Sales antes de marcar el proyecto como Ready.

El proceso también debe funcionar como feedback para que futuras propuestas y SOWs sean cada vez más precisos.


Inputs

Antes del handoff deben estar disponibles, cuando correspondan:

  • SOW / propuesta aprobada.
  • Questionnaires completados.
  • Información obtenida durante Sales.
  • Scope y deliverables acordados.
  • Fechas y commitments realizados al cliente.
  • Materiales compartidos por el cliente.
  • Riesgos, assumptions y dependencias conocidas.

Flow

1. Opportunity becomes Won

Sales confirma el proyecto y completa o actualiza el Project Definition en /nk.pulse.

2. Complete Project Definition

Sales debe dejar documentada toda la información obtenida durante la etapa comercial.

Como mínimo:

  • Context
  • Expected Impact
  • Scope
  • Out of Scope
  • Assumptions
  • Dependencies
  • Commitments
  • Content & Materials
  • Known Risks
  • Open Items

El alcance debe estar expresado en unidades concretas y con límites claros.

No es suficiente una descripción general del proyecto.

→ See: Project Definition
→ See: Scope Standards

3. Team Pre-read

Antes del Handoff Meeting, todos los participantes deberían revisar previamente el Project Definition.

El objetivo es que la reunión no sea el primer contacto del equipo con el proyecto.

Cada participante debería llegar preparado para identificar:

  • dudas;
  • inconsistencias;
  • riesgos;
  • dependencias;
  • o información faltante relacionada con su disciplina.

4. Handoff Meeting

El Handoff Meeting es obligatorio.

Required participants

  • Sales
  • Project Manager
  • Design Lead
  • Tech Lead, cuando corresponda

Recommended participants

  • CCO
  • CTO
  • TSL

Durante la reunión se recorre el Project Definition punto por punto.

La reunión no busca volver a presentar comercialmente el proyecto.

Busca validar que Sales y Delivery entienden lo mismo.

Las preguntas centrales son:

  • ¿Está claro qué estamos haciendo?
  • ¿El alcance está suficientemente definido?
  • ¿Lo documentado coincide con lo vendido?
  • ¿Existen compromisos que Delivery deba conocer?
  • ¿Las dependencias están identificadas?
  • ¿Existen riesgos relevantes?
  • ¿Hay algo que nos impida planificar responsablemente?

→ See: Handoff Meeting & Readiness Gate

5. Discipline Validation

Luego de revisar el proyecto:

Design Lead valida los aspectos relacionados con Design.

Tech Lead valida los aspectos técnicos cuando corresponda.

PM valida que la información sea suficiente para gestionar y planificar el proyecto.

Una validación no significa que no existan pendientes.

Significa que no existen incógnitas críticas no identificadas dentro del área correspondiente.

6. Resolve Blocking Open Items

Todo pendiente debe tener como mínimo:

Owner + Due Date / Milestone + Impact + Status

Puede haber Open Items que se resuelvan durante el proyecto.

Pero un proyecto no puede avanzar si alguno de esos pendientes deja materialmente indefinido el scope.

Examples of acceptable Open Items:

  • una credencial que será necesaria más adelante;
  • entrega futura de assets;
  • contacto técnico pendiente;
  • definición final de un KPI.

Examples of blocking Open Items:

  • cantidad de componentes;
  • páginas/templates incluidos;
  • si una integración forma parte del proyecto;
  • quién produce contenido;
  • si una funcionalidad está incluida o no.
Ready with Open Items does not mean Ready with Undefined Scope.

7. Readiness Gate

Una vez completadas las validaciones, el PM asigna uno de los siguientes estados.

Ready

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

Ready with Open Items

Existen pendientes conocidos, pero ninguno impide planificar responsablemente.

Todos tienen:

  • Owner
  • Due date / milestone
  • Impact identificado

Not Ready

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

El proyecto no debe avanzar hasta resolverla.

8. Ready for Project Setup & Planning

El Project Manager es la única persona que cambia el proyecto a Ready en /nk.pulse.

Solo después de este punto puede comenzar formalmente:

Project Setup & Planning


Core Rules

No undefined scope

Un proyecto no debe comenzar dependiendo de interpretaciones individuales sobre qué está incluido.

One source of truth

Si una decisión relevante cambia, /nk.pulse debe reflejarla.

Every open item has an owner

No existen pendientes bajo conceptos como:

“Lo vemos después.”

Todo pendiente debe estar explícitamente gestionado.

Impact before output

Además de entender qué vamos a producir, debemos entender:

¿Qué espera cambiar el cliente en su negocio gracias a este proyecto?

Siempre que sea posible, ese impacto debería expresarse mediante KPIs.

Cuando no exista un KPI concreto, debe quedar definido al menos el resultado esperado y qué señal permitiría saber si estamos avanzando hacia ese resultado.

Discovery can refine, not silently expand

Discovery puede modificar la solución inicialmente imaginada.

No puede ampliar silenciosamente el alcance contratado.

Los cambios materiales deberán gestionarse posteriormente mediante el proceso de Change Control.


Outputs

Al finalizar este proceso deben existir:

  • Project Definition completo en /nk.pulse.
  • Scope definido y cuantificado.
  • Open Items identificados.
  • Risks y Dependencies registrados.
  • Validación de PM.
  • Validación de Design Lead.
  • Validación de Tech Lead cuando corresponda.
  • Readiness Status definido.

Definition of Done

El Sales Handoff está completo cuando:

  • SOW / propuesta aprobada está disponible.
  • Project Definition está completo.
  • Scope está expresado en unidades concretas.
  • Existe un límite de alcance cuando corresponda.
  • In Scope y Out of Scope son claros.
  • Assumptions están documentados.
  • Dependencies están documentadas.
  • Commitments realizados al cliente están registrados.
  • Stakeholders y Decision Maker están identificados.
  • Expected Impact está documentado o asignado al PM como Open Item.
  • Todos los Open Items tienen Owner y Due Date / Milestone.
  • No existen Open Items que dejen materialmente indefinido el scope.
  • El Handoff Meeting fue realizado.
  • Design Lead validó.
  • Tech Lead validó cuando corresponde.
  • PM validó.
  • PM asignó un Readiness Status.

Evidence

Todo el cumplimiento del proceso debe quedar registrado en /nk.pulse.

No debería requerirse evidencia adicional fuera del sistema.


Next Process

Ready → Project Setup & Planning