Two documents that always end up diverging
In many organisations, a contract’s schedule lives in MS Project and its costing in an Excel workbook. Both start from the same breakdown, then drift apart. A phase is rescheduled, but its cost stays on the old months. A task is split into three in the schedule, and the costing keeps a single line. After a few reviews, nobody knows which of the two is authoritative any more, and the planned expenditure curve no longer matches the schedule it is supposed to reflect.
Waterfall removes the question at the source: there is only one tree.
A task carries its estimate lines
A cost structure is a task tree. Seen from the side of time, it is the schedule: durations, dates, links. Seen from the side of money, it is the estimate: each estimate line is carried by a task and inherits its dates. Costing therefore means attaching lines to tasks, not building a second tree.
A line is costed in one of two ways, depending on the cost type of its cost category:
- Labour: you choose a resource role from the organisation chart, for example “Test engineer”. The role determines the cost category, and therefore the hourly rate. The line carries an effort in hours.
- Non-labour (supplies, subcontracting, expenses): you choose the category directly, and the line carries a quantity and a unit cost.
Two special cases make the model complete. A summary task can carry its own lines, for costs that are not tied to any specific task: overheads, licences, insurance. A milestone, a task of zero duration, can also carry lines: this is how a subcontracting down payment or the receipt of a supply is costed.
Fictional example
The task “Qualification testing”, lasting three months, carries three estimate lines.
| Line | Cost type | Calculation | Amount |
|---|---|---|---|
| Test engineer | Labour | 420 h × €82/h | €34,440 |
| Test technician | Labour | 300 h × €61/h | €18,300 |
| Test bench rental | Non-labour | 3 months × €4,500 | €13,500 |
| Task total | €66,240 | ||
If the task slips by four months and moves into the following year, its €66,240 slips with it. The workload plan of both roles, the planned expenditure curve and the application of inflation follow, with no re-entry.
What the shared tree provides at no extra cost
Because each line is placed in time by its task, four calculations follow directly:
- the planned value, by spreading the budgeted amounts over the dates of the tasks in the baseline revision;
- inflation, applied to each line according to the year in which its task consumes it;
- the cash outflows, by shifting those same dates by each line’s payment term (zero for labour);
- the earned value, earned task by task, when the estimate to complete of one of them falls to zero.
Waterfall makes no conversion between a duration and an effort. The duration is entered on the task, the effort on the line. The role’s calendar is only used to convert the former into dates and the latter into a monthly distribution, which gives the workload plan: how many hours, of which role, in which month. This is the view the manager then compares with each role’s capacity, across the whole portfolio.
Scheduling familiar to MS Project users
Schedules often come from MS Project, and so do their authors. Waterfall therefore deliberately follows the way it works:
- a scheduling mode per task: automatic, where the dates follow from the duration, the links and the calendar, or manual, where the user sets them;
- the four types of links (finish-to-start, start-to-start, finish-to-finish, start-to-finish), with a lag;
- total slack and the critical path;
- calendars per resource role, which give the hours worked on each day of the week.
Data entry goes through a single grid: collapsible tree, keyboard indentation, immediate recalculation. The Gantt chart can be viewed but not edited, so that a gesture never has a different effect depending on the view in which it is made. Two views are used for communication: the task breakdown (WBS), laid out for an A4 sheet at the chosen depth, and named timelines, which show only the tasks and milestones added to them, for an executive committee, a client or a team.
Exchanges with MS Project, in both directions, are described with the other file exchanges.
Contract breakdown, to answer in the terms of the order
The contract breakdown reproduces the purchase order’s structure of contract items, lots and deliverables. It is optional: costing and control work without it. But it serves two purposes. It generates a schedule skeleton, with a summary task per contract item and per lot, a task per deliverable and an end milestone, which avoids re-entering the structure of the contract. And because each contract item or lot stays attached to its task, the schedule and the estimate can be filtered on one of them, and the client can be presented with an estimate organised like their order.
Sub-projects, the level of accounting reconciliation
A second breakdown, independent of the first, groups estimate lines into sub-projects, whose codes are those the ERP assigns to the order. Expenditure is charged to these codes, never to a task. The sub-project is therefore the finest level at which budget and expenditure meet, and the level of financial progress. Its codes only exist once the order is placed, which is convenient: before it, there are no actual costs to reconcile.