En la literatura clásica de gestión de proyectos se habla mucho de requisitos, cambios, paquetes de trabajo y resultados. Sin embargo, casi siempre falta una distinción fundamental: la separación clara entre requirements, changes, deliverables y el product scope. Solo cuando estos conceptos se diferencian correctamente se vuelve visible cómo funcionan realmente los proyectos y por qué muchos modelos de gobernanza tropiezan en la práctica.

Para hacer esta distinción más tangible, usemos un ejemplo sencillo: una fábrica de sardinas.

Imaginemos una pequeña fábrica con ocho empleados y una máquina que produce cinco latas de sardinas por minuto. Este es el estado actual (AS‑IS). El propietario tiene ahora un objetivo: aumentar la producción a diez latas por minuto. Este objetivo describe el estado futuro (TO‑BE) — y eso es un requirement. Un requirement define cómo debería ser el mundo en el futuro, sin especificar cómo llegar allí.

La pregunta de cómo se alcanzará el estado futuro conduce a la decisión de cambio (change decision). Un change no es una unidad de trabajo ni un objeto de resultado. Es una decisión de gobernanza que determina cómo se modificará el estado actual para alcanzar el estado futuro. En la fábrica de sardinas, el change consiste en tres elementos: ampliar la nave, comprar una segunda máquina y contratar ocho empleados adicionales. Estas tres medidas forman el change: la decisión sobre cómo pasar de cinco a diez latas por minuto.

Pero la implementación de este change produce una gran cantidad de deliverables. Y aquí es donde la distinción suele volverse confusa en los proyectos reales. Un deliverable es un objeto de resultado: un artefacto, un documento, un objeto físico o un resultado listo para aprobación que surge de la implementación de un change. Los deliverables no son la decisión en sí; son los resultados concretos que emergen de esa decisión.

La ampliación de la nave produce planos de construcción, solicitudes de permisos, documentos de licitación, contratos, conceptos de seguridad y, finalmente, la nueva nave. La compra de la segunda máquina produce análisis de necesidades, comparaciones de proveedores, órdenes de compra, contratos, planes de instalación, protocolos de prueba y la máquina como resultado físico. La contratación de nuevos empleados produce descripciones de puestos, anuncios, listas de candidatos, contratos laborales, materiales de formación y planes de incorporación.

Esto deja claro que un change produce muchos deliverables. La relación no es 1:1 sino 1:n. El change es el desencadenante; los deliverables son los resultados. El change modifica el estado; los deliverables documentan o implementan esa modificación.

Cuando entra en juego el contenido del producto

Y aquí entra el product scope. El product scope no incluye los requirements ni los changes. Incluye únicamente los deliverables creados mediante la implementación de los changes. El product scope describe lo que realmente existe al final: la nueva nave, la segunda máquina, los empleados formados, las aprobaciones operativas, los protocolos de prueba y todos los demás objetos de resultado que permiten el nuevo estado de producción.

En este punto aparece otra peculiaridad estructural — una que se observa en casi todas las grandes iniciativas de transformación, especialmente en programas SAP. La change decision suele tomarse muy temprano. Un comité directivo decide introducir SAP, armonizar procesos o implementar determinados módulos. Esta decisión es un change, porque altera fundamentalmente el estado actual. Pero los deliverables concretos que surgirán de esta decisión aún son completamente desconocidos en ese momento. Se elaboran más tarde, dentro de la Outcome Delivery Structure (ODS) — ya sea un proyecto, un programa o un portafolio.

La ODS es la estructura en la que se crean los deliverables. Por eso una carta de proyecto contiene las change decisions, pero no los deliverables. Los deliverables surgen solo cuando los equipos comienzan a operacionalizar la change decision. Los requirements suelen permanecer invisibles para muchos miembros del proyecto, porque rara vez se documentan correctamente y aún menos se comunican de forma clara. La change decision, sin embargo, es visible porque aparece en la carta. Los deliverables se vuelven visibles más tarde, porque surgen del trabajo realizado dentro de la ODS.

Esto crea una cadena clara y completa: los requirements definen el estado futuro. Los changes definen la decisión sobre cómo alcanzarlo. Los deliverables son los objetos de resultado de esa decisión. Y el product scope consiste exclusivamente en esos objetos de resultado. Solo la combinación de estas cuatro capas permite la transición del estado actual al estado futuro — y solo los deliverables forman el alcance real del producto.

La fábrica de sardinas muestra de manera sencilla lo que también es cierto en proyectos complejos: los changes son gobernanza. Los deliverables son resultados. El product scope consiste en los deliverables. Y solo cuando estas capas se separan claramente, la gestión de proyectos funciona realmente bien.

Muchos proyectos fallan porque los changes se deciden sin requirements claros y porque el esfuerzo se estima a nivel de change en lugar de a nivel de deliverable. Los changes son gobernanza. Los deliverables son trabajo. Solo los deliverables generan esfuerzo, riesgo y product scope.

La ilusión del cambio (Change Illusion)

En muchos proyectos surge una ilusión peculiar — una que solo se hace visible cuando la terminología se separa correctamente: la Change Illusion. Aparece cuando una change decision se vende como scope, aunque en realidad es solo una decisión de gobernanza. La organización decide, por ejemplo, “vamos a construir una nueva fábrica”. Esta frase suena a scope, se siente como scope y se presenta como scope ante el comité directivo. Pero en realidad es solo un change — una decisión sobre cómo se modificará el estado actual. El scope surge más tarde, cuando se definen los deliverables.

La fábrica de sardinas lo muestra claramente. Primero se decide “crear una nueva fábrica”. Esa es la change decision. Pero en cuanto comienza el proyecto, esta decisión se elabora progresivamente: la fábrica se convierte en una nueva nave, luego en una segunda máquina, luego en más personal, luego en nuevos procesos, luego en conceptos de seguridad y finalmente en un conjunto completo de objetos de resultado. Esta elaboración progresiva no es scope elaboration — es change elaboration, la expansión de la change decision que más tarde conduce a deliverables reales.

PMI habla de “progressive elaboration”, normalmente refiriéndose al scope. Pero en la práctica, lo que se elabora no es el scope, sino el change. La change decision se toma temprano y se documenta en la carta del proyecto. Se vende como scope, aunque el scope solo surge a nivel de deliverable. Los deliverables aún son completamente desconocidos en ese momento. Surgen más tarde, dentro de la Outcome Delivery Structure — ya sea un proyecto, un programa o un portafolio.

Esta peculiaridad conduce a un problema sistémico: el esfuerzo se estima a nivel de change, aunque el esfuerzo solo existe a nivel de deliverable. Se estima “ampliar la nave”, no los planos, permisos, licitaciones, contratos, conceptos de seguridad y aprobaciones. Se estima “una segunda máquina”, no el análisis de necesidades, la comparación de proveedores, el pedido, la instalación, las pruebas y la puesta en marcha. Se estima “más personal”, no las descripciones de puestos, anuncios, entrevistas, contratos, formación y planes de incorporación.

Así surge la Change Illusion: la creencia de que el change es el scope. Pero el scope solo surge más tarde, cuando se definen los deliverables. Y es precisamente aquí donde muchos proyectos fallan. Los changes no coinciden con los requirements porque los requirements suelen permanecer invisibles.

Actualización

Este artículo ofrece una introducción simplificada a los conceptos analizados. En la revista Change Illusion Journal se puede consultar una versión ampliada que incluye definiciones formales, la Estructura de Entrega de Resultados (ODS), los Entregables de Transición (TD), el Flujo de Entregables de Transición y el modelo de la «Ilusión del Cambio».

List of terms