La cadena ITTO — un solo hilo por un proyecto real
En la app: Project → follow the thread: Charter → WBS → Registers → Gantt → Variance
Referencia. El complemento de ITTO explicado. Allí aprendes qué es un ITTO y exploras los 40 processes; aquí ves el dependency graph desplegarse en un solo hilo de un proyecto real.
El replanteamiento que hay que llevar: ITTO no son cuarenta listas — es un dependency graph, donde el output de un process es el input del siguiente. Esta página lo demuestra en la construcción del Coral Ridge Resort — un hotel frente al mar de $48,000,000 con un schedule baseline que termina el 31 August 2028.
La cadena — un solo hilo por Coral Ridge
Sigue un solo hilo: ¿podemos empezar a construir la estructura? Observa cómo cada output se convierte en el siguiente input.
1 · Initiate Project
Coral Ridge empieza como una intención, no como un proyecto. Initiate Project lo convierte en uno.
- Inputs: el business case, el mandato del sponsor
- Tool: expert judgement, y una conversación sobre qué significa "done"
- Output: el project charter — que fija el margen de presupuesto de $48M y nombra la temporada de apertura que la obra debe alcanzar
El charter es el primer artefacto real. Todo lo que sigue lo cita.
2 · Define Scope
- Input: el charter (un output del paso 1)
- Tool: decomposition
- Output: la WBS — work packages reales, incluidos
1.2.4 Coastal & environmental clearance,1.3.2 Piling on coastal soil,1.4.1 RCC frame — floors 1–5
Fíjate en el traspaso. No podrías haber descompuesto el scope antes de que existiera el charter, porque no habrías tenido nada contra lo que descomponer.
3 · Identify Risks
- Input: la WBS (output del paso 2) y los site surveys
- Tool: expert judgement, site investigation
- Outputs: entradas del register. Tres reales de Coral Ridge:
| Entry | Type | Status |
|---|---|---|
| Coastal water table is high; piling reaches competent strata by −22 m | Assumption | Confirmed |
| ECA clearance granted before superstructure | Constraint | Pending |
| Monsoon (Jun–Sep) halts external works ~10 weeks/yr | Assumption | Confirmed |
Ten presente la tercera. Un monzón que detiene el trabajo exterior diez semanas al año no es un risk al que respondes — es un constraint alrededor del cual planificas el schedule. Esa distinción está a punto de importar.
4 · Develop Schedule
Aquí es donde la cadena rinde. Mira qué tiene que existir ya:
- Inputs: la WBS (paso 2), las estimaciones de duración, y las entradas del register del paso 3 — las ventanas de monzón y la dependencia del ECA
- Tools: el critical path method; y PERT para
1.3.2 Piling, porque la profundidad de cimentación sobre estratos costeros es genuinamente incierta - Output: el schedule baseline — que termina el 31 August 2028
¿Por qué PERT solo en el piling? Porque es la única duración que nadie puede afirmar con confianza. La tool se elige para ajustarse a la incertidumbre, no se aplica de forma uniforme. Eso es lo que significan "tools and techniques" en la práctica — un menú del que seleccionas, no un procedimiento que sigues.
Y el constraint del ECA es la razón por la que la superstructure no puede sencillamente programarse
pronto. La clearance es un output de un process de permisos que sigue pending. Hasta que
exista, 1.4.1 RCC frame tiene un input que no puede obtener.
Entonces: ¿podemos empezar a construir la estructura? No — e ITTO te dice exactamente por qué, sin que nadie tenga que explicarlo.
5 · Monitor Schedule
- Input: el schedule baseline (output del paso 4) más el progreso real
- Tool: variance analysis, earned value
- Outputs: variance, forecasts, y change requests
Y un change request es un input de Assess Changes, cuyo output puede ser un re-baseline — que se convierte en el nuevo input de Monitor Schedule.
La cadena se cierra en un bucle. Eso es lo que la cuadrícula no puede mostrarte.
Qué significa esto para cómo estudias
La cadena de arriba tocó cinco processes. Nadie memorizó nada y, aun así, los inputs eran todos predecibles — porque un input no es más que un output que alguien ya produjo.
Tres reglas que generalizan:
Los outputs son sustantivos; las tools son verbos. Baselines, registers, charters, plans — esos son outputs. Decomposition, estimation, analysis, judgement — esas son tools. Si un término nombra un documento, casi nunca es una tool.
Los plans son outputs de los processes de planificación e inputs de todo lo demás. "Plan Schedule" produce el schedule management plan — las reglas. "Develop Schedule" consume esas reglas y produce el baseline — las fechas. Dos processes distintos, dos outputs distintos, y los candidatos los confunden constantemente.
Si un process produce algo, algo más adelante lo consume. Un output sin consumidor suele significar que has leído mal el process — o que estás produciendo documentación que nadie usa, lo cual es un problema en sí mismo.
Dónde ves esto en VanillaPM
La cadena no es un recurso didáctico — es cómo está cableada la app, y puedes hacer clic en ella.
Abre la muestra de Coral Ridge (python manage.py seed_tutorial) y sigue el mismo hilo: la pestaña
Charter contiene el output del paso 1; WBS el del paso 2; los Risk and Assumption
registers el del paso 3; el Gantt los consume todos y produce el baseline; y la vista
Variance es el paso 5, que devuelve los change requests a governance.
Cada flecha de la cadena de arriba es una foreign key real en una base de datos real. Ese es el argumento más convincente de que ITTO describe algo verdadero: no puedes construir una herramienta de proyectos que funcione sin él, lo llames ITTO o no.
Vuelve al concepto y a los 40 processes: ITTO explicado. ¿Necesitas una búsqueda? Hoja de referencia ITTO. ¿Listo para las tareas recorridas? Empieza en P1 · Develop a common vision.