Purpose

Transformar un proyecto que ya pasó el Project Readiness Gate en un proyecto listo para operar.

Antes de comenzar formalmente la ejecución, el equipo debe contar con:

herramientas correctamente configuradas;
equipo asignado;
contexto compartido;
Master Project Plan validado;
milestones claros;
dependencias calendarizadas;
Content Plan cuando corresponda;
forma de trabajo acordada;
reglas de feedback definidas;
y kickoffs realizados.

El objetivo es evitar que un proyecto comience mientras todavía estamos intentando entender cómo organizarlo.

Trigger

Este proceso comienza cuando el Project Manager marca el proyecto como:

Ready
o
Ready with Open Items

en /nk.pulse.

El proyecto puede tener trabajo interno previo al Client Kickoff.

Sin embargo, no debe pasar formalmente a Active hasta completar este proceso.

Owner

Accountable: Project Manager.

Required participation

Project Manager
Design Lead
Tech Lead, cuando corresponda
Equipo asignado al proyecto

Team Assignment

El equipo del proyecto es asignado previamente por Leadership.

El PM recibe esa definición y es responsable de dejarla correctamente configurada en las herramientas del proyecto.

Source of Truth

/nk.pulse

Es la fuente central del proyecto.

Contiene, entre otras cosas:

Project Definition;
Master Project Plan;
milestones;
deliverables;
dependencies;
risks;
Content Plan;
project status;
información visible para el cliente.

El cliente accede a la información correspondiente mediante el /nk.pulse Client Portal.

Productive

Es la herramienta interna de ejecución del equipo.

Contiene:

boards;
tasks;
assignments;
planificación detallada;
seguimiento operativo.

El cliente no utiliza Productive.

/nk.pulse = project-level truth and client visibility.
Productive = internal execution.

Inputs

Antes de comenzar deben existir:

Project Definition aprobado.
Approved SOW / Proposal.
Readiness Status.
Equipo asignado.
Known Dependencies.
Known Risks.
Commitments.
Content responsibilities.
Open Items no bloqueantes.

Flow

1. Project Setup

El PM configura las herramientas y espacios necesarios para operar el proyecto.

/nk.pulse

Verificar:

Project Definition disponible.
Equipo asignado.
Client Portal configurado cuando corresponda.
Deliverables iniciales creados.
Dependencies importadas desde Project Definition.
Risks importados.
Open Items activos.
Project status correcto.

Productive

Debe crearse el proyecto utilizando el workflow estándar definido por /nk.

No deben utilizarse workflows personalizados salvo excepción explícitamente acordada.

Configurar como mínimo:

Project / Board.
Standard Workflow.
Equipo.
Owners.
Fases.
Milestones principales.
Fechas relevantes.
Budget / hours, cuando corresponda.
Links a /nk.pulse.
Figma.
Repositories.
Otros recursos relevantes.

El nombre definitivo del workflow estándar deberá documentarse una vez definido.

2. Internal Kickoff

El Internal Kickoff es obligatorio.

Su objetivo es que todo el equipo conozca el proyecto antes de comenzar a trabajar.

No reemplaza el Sales Handoff.

El equipo debería poder llegar al kickoff con Project Definition ya disponible y utilizar la reunión para alinear ejecución.

Cover at minimum

Context.
Expected Impact.
Scope.
Out of Scope.
Key Deliverables.
Timeline.
Milestones.
Team & Roles.
Known Risks.
Dependencies.
Content responsibilities.
Relevant Open Items.
Working dynamics.

El equipo debe terminar la reunión entendiendo:

qué estamos haciendo, por qué, hasta dónde llega y qué se espera de cada persona.

3. Master Project Plan

Todo proyecto debe tener un Master Project Plan high-level en /nk.pulse.

Este es el timeline oficial del proyecto.

Debe poder ser utilizado internamente y mostrado al cliente mediante el Client Portal.

Como mínimo debe contener:

Project phases.
Main deliverables.
Milestones.
Client presentations.
Feedback windows.
Dependencies.
QA periods.
Launch / Final Delivery.
Relevant buffers.

El plan no debe construirse utilizando únicamente la fecha final como punto de partida.

Debe representar una secuencia de trabajo que los responsables de cada disciplina consideren ejecutable.

Timeline Validation

El PM es responsable de construir el Master Project Plan.

Los Discipline Leads deben validar las partes correspondientes a sus áreas.

Design Lead

Valida:

Design phases.
Design deliverables.
Reviews.
Feedback periods.
Design dependencies.

Tech Lead

Valida, cuando corresponda:

Development phases.
Technical milestones.
QA periods.
Technical dependencies.
Launch requirements.

No se debe presentar al cliente un timeline que no haya sido previamente validado internamente.

Commercial Deadlines

Las fechas comprometidas durante Sales son constraints del proyecto.

Planning debe validar que el proyecto pueda ejecutarse razonablemente dentro de ellas.

Si el plan resultante demuestra que una fecha comprometida es inviable, debe escalarse antes del Client Kickoff.

Sales + PM + Discipline Leads deben evaluar la mejor alternativa.

Por ejemplo:

ajustar secuencia;
modificar staffing;
dividir entregas;
reducir scope;
modificar milestone;
revisar la fecha con el cliente.

Una deadline comercial no convierte automáticamente un plan inviable en viable.

4. Timeline Baseline

Una vez validado el Master Project Plan, /nk.pulse debe guardar:

Timeline Baseline v1

Esta baseline representa el plan inicial aprobado.

Las modificaciones posteriores pueden actualizar el Current Project Plan, pero deben mantener trazabilidad.

Esto permite posteriormente comparar:

Baseline → Current Plan → Actual

y entender por qué existieron desviaciones.

5. Discipline Plans

El Master Project Plan no necesita contener desde el comienzo todas las tareas del proyecto.

Cada Discipline Lead es responsable de bajar el detalle necesario cuando su fase está suficientemente definida.

Design

Design Lead debe crear y mantener su planificación detallada cuando corresponda.

Development

Tech Lead / Development Lead puede crear un plan detallado con tickets, assignments y fechas una vez que Development tenga suficiente definición para hacerlo responsablemente.

No es necesario bajar todo Development a tickets durante las primeras etapas si Discovery todavía puede modificar la solución.

Planning Principle

Plan the project high-level from the beginning. Detail the work when enough information exists to plan it responsibly.

6. Content Plan

Todo Website debe tener un Content Plan antes de pasar a Active.

Debe definir claramente:

AreaOwnerVolume / ScopeRequired ByImpact if DelayedContent CreationContent ApprovalContent LoadingContent MigrationTranslation

Cuando exista un Website anterior, debe quedar explícitamente definido:

si existe migración;
qué contenido se migra;
cuánto;
quién realiza la migración;
cómo se realizará;
qué necesita /nk para hacerlo;
cuándo debe completarse.

No se debe comenzar un Website sin entender quién y cómo resolverá el contenido.

Las responsabilidades ya definidas en Project Definition deben convertirse acá en fechas y dependencias concretas dentro del plan.

7. Dependencies Planning

Las Dependencies provenientes de Project Definition deben transformarse en elementos accionables del plan.

Cada Dependency debe tener:

Owner.
Required By.
Impact if Delayed.
Status.

Ejemplo:

Final English Content
Owner: Client
Required by: November 15
Blocks: Final UI / Content Loading

Dependencies y Risks continúan gestionándose desde /nk.pulse.

8. Project Cadences

Antes de comenzar deben definirse las cadencias necesarias para operar el proyecto.

No todos los proyectos necesitan exactamente las mismas reuniones.

Según corresponda, definir:

Internal Sync.
Client Status.
Design Review.
Client Presentation.
Demo.
QA Checkpoint.
Leadership / Risk Review.

Cada instancia debe existir porque cumple una función concreta, no por hábito.

9. Client Feedback Rules

Las reglas de feedback deben quedar claras antes de comenzar.

Como mínimo:

quién entrega feedback;
quién lo consolida;
dónde se entrega;
cuánto tiempo tiene el cliente para responder;
cuántas rondas existen cuando aplique;
quién tiene autoridad para aprobar.

Debe existir un Feedback SLA / expected response time definido.

Este plazo debería estar contemplado en el contrato y debe reforzarse durante el Client Kickoff.

Cuando el cliente entregue feedback fuera del período acordado, el PM deberá evaluar y comunicar su impacto sobre el timeline.

El formato específico para recopilar feedback se define en el proceso:

Production, Handoffs & Quality Assurance

10. Client Kickoff

El Client Kickoff es obligatorio.

Su objetivo es alinear a /nk y al cliente sobre cómo se operará el proyecto.

Como mínimo debe cubrir:

Team

PM.
Discipline Leads.
Client stakeholders.
Decision Maker.

Project

Context.
Expected Impact.
Scope.
Main Deliverables.

Planning

Project phases.
Milestones.
Timeline.
Client dependencies.
QA / Launch when applicable.

Ways of Working

Communication channels.
Meeting cadence.
Feedback process.
Feedback SLA.
Approval responsibilities.
Client Portal.

Next Steps

Debe quedar claro:

qué ocurre inmediatamente después;
qué necesita /nk;
qué necesita entregar el cliente;
cuándo es el próximo milestone.

11. Feedback Delays

El timeline se construye considerando períodos concretos de revisión y feedback.

Si el cliente entrega feedback fuera del período acordado, el proyecto no debe absorber automáticamente ese atraso reduciendo tiempo de Production, Design o QA.

El PM debe evaluar el impacto y actualizar el plan cuando corresponda.

La prioridad es proteger: