The ITTO chain — one thread through a real project

Reference. The companion to ITTO explained. There you learn what an ITTO is and explore all 40 processes; here you watch the dependency graph play out on one real thread of one real project.

The reframe to carry in: ITTO is not forty lists — it is a dependency graph, where one process's output is the next one's input. This page proves it on the Coral Ridge Resort build — a $48,000,000 beachfront hotel with a schedule baseline ending 31 August 2028.

The chain — one thread through Coral Ridge

Follow a single thread: can we start building the frame? Watch how each output becomes the next input.

1 · Initiate Project

Coral Ridge begins as an intent, not a project. Initiate Project turns it into one.

• Inputs: the business case, the sponsor's mandate
• Tool: expert judgement, and a conversation about what "done" means
• Output: the project charter — which fixes the $48M budget envelope and names the opening season the build has to hit

The charter is the first real artefact. Everything downstream cites it.

2 · Define Scope

• Input: the charter (an output from step 1)
• Tool: decomposition
• Output: the WBS — real work packages, including 1.2.4 Coastal & environmental clearance, 1.3.2 Piling on coastal soil, 1.4.1 RCC frame — floors 1–5

Notice the handoff. You could not have decomposed the scope before the charter existed, because you would have had nothing to decompose against.

3 · Identify Risks

• Input: the WBS (output of step 2) and the site surveys
• Tool: expert judgement, site investigation
• Outputs: register entries. Three real ones from 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

Keep the third one in view. A monsoon that stops external work for ten weeks a year is not a risk you respond to — it is a constraint you schedule around. That distinction is about to matter.

4 · Develop Schedule

Here is where the chain pays off. Look at what has to already exist:

• Inputs: the WBS (step 2), the duration estimates, and the register entries from step 3 — the monsoon windows and the ECA dependency
• Tools: the critical path method; and PERT for 1.3.2 Piling, because founding depth on coastal strata is genuinely uncertain
• Output: the schedule baseline — ending 31 August 2028

Why PERT only on the piling? Because that is the one duration nobody can state confidently. The tool is chosen to fit the uncertainty, not applied uniformly. That is what "tools and techniques" means in practice — a menu you select from, not a procedure you follow.

And the ECA constraint is why the superstructure cannot simply be scheduled early. The clearance is an output of a permitting process that is still pending. Until it exists, 1.4.1 RCC frame has an input it cannot get.

So: can we start building the frame? No — and ITTO tells you exactly why, without anyone having to explain it.

5 · Monitor Schedule

• Input: the schedule baseline (output of step 4) plus actual progress
• Tool: variance analysis, earned value
• Outputs: variance, forecasts, and change requests

And a change request is an input to Assess Changes, whose output may be a re-baseline — which becomes the new input to Monitor Schedule.

The chain closes into a loop. That is the bit the grid cannot show you.

What this means for how you study

The chain above touched five processes. Nobody memorised anything, and yet the inputs were all predictable — because an input is just an output somebody else already produced.

Three rules that generalise:

Outputs are nouns; tools are verbs. Baselines, registers, charters, plans — those are outputs. Decomposition, estimation, analysis, judgement — those are tools. If a term names a document, it is almost never a tool.

Plans are outputs of planning processes and inputs to everything else. "Plan Schedule" outputs the schedule management plan — the rules. "Develop Schedule" consumes those rules and outputs the baseline — the dates. Two different processes, two different outputs, and candidates confuse them constantly.

If a process produces something, something downstream consumes it. An output with no consumer usually means you have misread the process — or you are producing documentation nobody uses, which is its own problem.

Where you see this in VanillaPM

The chain is not a teaching device — it is how the app is wired, and you can click it.

Open the Coral Ridge sample (python manage.py seed_tutorial) and follow the same thread: the Charter tab holds step 1's output; WBS holds step 2's; the Risk and Assumption registers hold step 3's; the Gantt consumes all of them and produces the baseline; and the Variance view is step 5 feeding change requests back into governance.

Every arrow in the chain above is a real foreign key in a real database. That is the most convincing argument that ITTO describes something true: you cannot build a working project tool without it, whether or not you call it ITTO.

---

Back to the concept and all 40 processes: ITTO explained. Need a lookup: ITTO cheat sheet. Ready for the walked tasks? Start at P1 · Develop a common vision — the same Coral Ridge project, one ECO task at a time.