Purpose

Project Definition es la fuente única de verdad sobre qué proyecto estamos haciendo, por qué, bajo qué condiciones y con qué alcance.

Se crea durante el Sales Handoff y vive dentro de /nk.pulse durante toda la vida del proyecto.

Su objetivo es que cualquier persona que se incorpore al proyecto pueda entender, sin depender de conversaciones previas:

• qué necesita el cliente;
• qué impacto buscamos generar;
• qué vendimos;
• qué está incluido y qué no;
• qué compromisos asumimos;
• qué necesitamos del cliente o de terceros;
• qué riesgos conocemos;
• y qué decisiones siguen pendientes.

No es un documento de kickoff que se completa una vez y se abandona.

Es un living document que debe mantenerse actualizado cuando cambian o se terminan de definir aspectos estructurales del proyecto.

Ownership

Initial Owner

Sales es responsable de completar inicialmente Project Definition con toda la información obtenida y acordada durante el proceso comercial.

Ongoing Owner

Después del Sales Handoff, el Project Manager toma ownership de mantener Project Definition actualizado.

Validators

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

Recommended participation

• CCO
• CTO
• SE

Source of Truth

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

No debería ser necesario revisar:

• Slack;
• emails;
• notas personales;
• recordings;
• documentos paralelos;
• memoria de quienes participaron de Sales;

para entender una definición importante del proyecto.

Estos canales pueden ser utilizados para conversar o tomar decisiones, pero cualquier decisión que afecte Project Definition debe terminar reflejada en /nk.pulse.

Relationship with the SOW

Project Definition no reemplaza el SOW o propuesta aprobada por el cliente.

La fuente contractual sigue siendo:

Approved SOW / Proposal

Project Definition transforma ese acuerdo en una definición operativa que Delivery pueda ejecutar.

Idealmente:

SOW → Project Definition

deberían describir exactamente el mismo proyecto con diferente nivel de detalle.

Project Definition:

• no puede ampliar silenciosamente lo vendido;
• no puede eliminar compromisos realizados al cliente;
• no puede reinterpretar unilateralmente una ambigüedad contractual.

Si aparece una contradicción, debe resolverse con Sales antes de continuar.

La existencia de gaps recurrentes entre SOW y Project Definition debe utilizarse como feedback para mejorar futuras propuestas comerciales.

Baseline & Change History

Cuando un proyecto atraviesa el Readiness Gate, su Project Definition pasa a representar el initial project baseline.

A partir de ese momento, Project Definition puede evolucionar, pero los cambios relevantes deben mantener trazabilidad.

Debemos poder saber:

• qué cambió;
• cuál era la definición anterior;
• cuándo cambió;
• por qué;
• quién tomó o aprobó la decisión;
• y qué impacto tuvo sobre scope, timeline o presupuesto cuando corresponda.

Por lo tanto, /nk.pulse debería distinguir conceptualmente entre:

Current Project Definition

La versión vigente del proyecto.

Change / Decision History

El registro de cómo llegamos a esa versión.

Una definición nueva no debería borrar silenciosamente la anterior.

Required Sections

1. Project Context

Debe permitir entender rápidamente de qué se trata el proyecto y por qué existe.

Required information

• Client
• Project Name
• Project Type
• Short Project Description
• Business / Project Context
• Relevant background
• Main stakeholders
• Decision Maker
• People responsible for approvals

El contexto debe ser suficientemente claro para una persona que no participó del proceso comercial.

2. Expected Impact

Todo proyecto debería intentar responder:

What should change for the client's business as a result of this project?

No alcanza únicamente con definir qué vamos a producir.

Siempre que sea posible, Sales debería obtener esta información durante la etapa comercial y transmitir al cliente que /nk busca trabajar con un enfoque orientado a impacto.

Ideally

Debe quedar documentado:

• Business Objective
• KPI
• Current situation / baseline
• Expected result / target
• How it will be measured

When there is no KPI yet

Debe definirse al menos:

• cuál es el resultado esperado;
• qué señal observable permitiría saber si estamos avanzando hacia ese resultado;
• y cómo podríamos medirlo posteriormente.

Ejemplo:

Business Objective
Mejorar la capacidad del website de generar oportunidades comerciales.

KPI
Qualified leads per month.

O, si todavía no existe medición:

Expected Outcome
Que más usuarios interesados terminen iniciando contacto con la empresa.

Observable Signal
Aumento en formularios completados o contactos iniciados.

No contar con un KPI definido no bloquea Project Readiness.

En ese caso debe quedar como Open Item asignado al PM para trabajar con el cliente durante el inicio del proyecto.

3. Scope

Scope define qué trabajo compró el cliente y cuál es el límite del engagement.

No puede consistir únicamente en una descripción general como:

“Website redesign.”

o:

“UX/UI for the new platform.”

Debe estar expresado mediante unidades concretas y límites objetivos.

Cada proyecto debe definir:

Delivery Model

Cómo está estructurado el engagement.

Ejemplos:

• Component-based Website
• Fixed-structure Website
• UX/UI Discovery + Design
• Branding

Deliverables

Qué entregables concretos producirá /nk.

Scope Units

Cuál es la unidad utilizada para medir el alcance.

Dependiendo del proyecto:

• Components
• Pages
• Templates
• User Flows
• Unique Screens
• Design Capacity
• Brand Applications
• Other defined deliverables

Quantity / Scope Limit

Todo elemento cuantificable debe tener una cantidad o límite.

Por ejemplo:

4 S Components
6 M Components
3 L Components
1 XL Component

o:

Up to 5 core user flows and 30 unique screens.

Variants

Cuando corresponda:

• Platforms
• Breakpoints
• Languages
• Themes
• Markets
• Other variants

Para conocer cómo debe definirse el alcance según tipo de proyecto:

→ Website Scope Standard
→ UX/UI Scope Standard
→ Branding Scope Standard

4. Out of Scope

Debe quedar explícitamente documentado qué no forma parte del engagement.

No debería depender exclusivamente de una cláusula genérica como:

“Anything not explicitly listed is excluded.”

Además de esa protección general, se deben identificar las exclusiones que razonablemente podrían generar dudas.

Ejemplos:

• Copywriting not included.
• Content migration not included.
• E-commerce not included.
• New backend functionality not included.
• Integrations other than those explicitly listed are not included.
• Translation services not included.

Para proyectos con Scope Matrix, todo elemento marcado como:

Not Included

se considera automáticamente Out of Scope.

5. Assumptions

Assumptions son condiciones que se consideraron verdaderas al definir scope, timeline o esfuerzo.

Ejemplos:

Client will provide final copy before Production.

Existing APIs are documented and ready to consume.

Website will launch in one language.

Client will provide all photography assets.

Toda assumption relevante debe estar documentada.

Si deja de ser verdadera durante el proyecto, el PM debe evaluar si genera impacto sobre:

• scope;
• timeline;
• effort;
• cost.

6. Dependencies

Debe registrarse todo aquello que /nk necesita de otra persona, empresa o sistema para poder cumplir correctamente el proyecto.

Cada Dependency debe indicar:

Dependency → Owner → Required by → Impact if delayed → Status

Ejemplos:

• API documentation.
• Brand assets.
• Final copy.
• Legal approval.
• Infrastructure access.
• Photography.
• Client feedback.
• Third-party credentials.

Las dependencies no deberían quedar registradas únicamente como una lista.

Deben poder ser gestionadas.

7. Commitments

Todo compromiso realizado durante Sales que pueda afectar Delivery debe quedar documentado.

Como mínimo cuando corresponda:

• Hard deadlines
• Launch dates
• Milestones
• Deliverables
• Technologies
• Integrations
• Review rounds
• Environments
• Participation expected from /nk
• Particular client requirements
• Special agreements

El objetivo es evitar que Delivery descubra compromisos comerciales durante el proyecto.

8. Content & Materials

Debe estar claro qué contenido y materiales necesita el proyecto y quién es responsable por ellos.

Cuando corresponda:

Content

• Who creates it?
• Who approves it?
• Who loads it?
• Is copywriting included?
• Is migration included?
• When must content be available?

Materials

• Brand Guidelines
• Logos
• Photography
• Videos
• Illustrations
• Existing Design Files
• Existing Product / Website
• Documentation
• APIs
• Repositories
• Credentials / Accesses

Todo elemento todavía no disponible debe convertirse en Dependency u Open Item.

9. Known Risks

Debe registrarse cualquier situación conocida que pueda afectar la ejecución del proyecto.

Ejemplos:

• Aggressive deadline.
• Client with limited availability.
• Multiple stakeholders.
• Decision Maker not involved in day-to-day reviews.
• Critical third-party dependency.
• Content not yet available.
• Poorly documented integration.
• Significant technical constraint.
• Internal client approvals with long lead times.

No buscamos predecir todos los problemas posibles.

Buscamos hacer visibles aquellos que ya conocemos antes de empezar.

10. Open Items

Cualquier definición pendiente debe estar gestionada explícitamente.

Cada Open Item debe contener:

• Item / Question
• Owner
• Due Date or Milestone
• Impact
• Status
• Resolution

No es suficiente escribir:

“Pending client.”

Debe quedar claro quién es responsable de conseguir la respuesta y cuándo la necesitamos.

Blocking vs Non-blocking Open Items

No todos los pendientes impiden que un proyecto avance.

Non-blocking

Ejemplos:

• credencial que necesitaremos más adelante;
• fotografías que llegarán antes de Production;
• contacto técnico pendiente;
• KPI que se terminará de definir durante kickoff.

El proyecto puede quedar:

Ready with Open Items

si esos pendientes están correctamente gestionados.

Blocking

Un Open Item bloquea Project Readiness cuando afecta materialmente qué estamos haciendo.

Ejemplos:

• cantidad de componentes sin definir;
• cantidad de páginas/templates sin definir;
• no saber si una integración está incluida;
• no saber quién produce el contenido;
• funcionalidad potencial sin definición de scope;
• plataforma todavía indefinida;
• deliverable importante ambiguo.

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

Scope Changes

Discovery y Production pueden aportar nueva información y mejorar la definición del proyecto.

Eso es esperado.

Pero:

Refining the solution does not mean silently expanding the scope.

Cuando una decisión implique un cambio material en:

• Components
• Pages / Templates
• Screens
• User Flows
• Deliverables
• Features
• Integrations
• Platforms
• Complexity
• Effort

deberá evaluarse mediante el proceso de Project Health & Change Control.

Según el caso, puede requerir:

• actualización interna;
• scope adjustment;
• timeline adjustment;
• Change Request;
• Change Order.

La Current Project Definition debe actualizarse una vez aprobada la decisión, manteniendo el historial correspondiente.

Update Rules

Project Definition debe actualizarse cuando exista una modificación relevante en:

• Scope
• Out of Scope
• Assumptions
• Dependencies
• Commitments
• Expected Impact
• Stakeholders / Decision Makers
• Relevant project constraints

No es necesario convertirlo en un registro de cada decisión menor del proyecto.

La pregunta para decidir si actualizarlo debería ser:

¿Esta información sería importante para que alguien entienda correctamente qué proyecto estamos ejecutando hoy?

Si la respuesta es sí, debe reflejarse en Project Definition.

Validation

Antes de atravesar Project Readiness:

Sales

Confirma que Project Definition representa correctamente lo acordado durante Sales.

Design Lead

Valida el alcance, assumptions, dependencies y deliverables relacionados con Design.

Tech Lead

Cuando corresponda, valida:

• technical scope;
• integrations;
• technical assumptions;
• technical dependencies;
• relevant constraints.

Project Manager

Valida que la definición general sea suficientemente clara para poder planificar y gestionar el proyecto.

El PM es quien posteriormente cambia el Readiness Status en /nk.pulse.

Minimum Completion Checklist

Antes del Handoff Meeting:

• Project Context completed.
• Expected Impact documented or identified as Open Item.
• Scope defined.
• Scope Limit defined.
• Out of Scope documented.
• Assumptions documented.
• Dependencies documented.
• Commitments documented.
• Content responsibilities defined.
• Relevant materials identified.
• Known Risks documented.
• Stakeholders identified.
• Decision Maker identified.
• Open Items documented.
• Every Open Item has an Owner.
• Every Open Item has a Due Date or Milestone.
• No known scope-critical definition is intentionally left undocumented.

Evidence

No se requiere un documento adicional.

La evidencia es el propio Project Definition dentro de /nk.pulse, junto con:

• validation status;
• open items;
• change history;
• readiness status.