A closed list of exchanges
Waterfall exchanges project data with the outside world through seven flows only, all triggered from within Waterfall by an authorised user:
| Data | Direction | Format | When |
|---|---|---|---|
| Schedule | MS Project → Waterfall | MS Project XML | on demand |
| Schedule | Waterfall → MS Project | MS Project XML | on demand |
| Estimate | Excel → Waterfall | “Estimate” Excel | during the costing phase |
| Estimate | Waterfall → Excel | “Estimate” Excel | on demand |
| Estimate to complete | Excel → Waterfall | “Estimate to complete” Excel | at every review |
| Estimate to complete | Waterfall → Excel | “Estimate to complete” Excel | at every review |
| Actual costs | Excel → Waterfall | “Actual costs” Excel, extracted from the ERP | at every review |
Why a closed list? Because every exchange must have a specified format, check and replay rule. An undeclared exchange would escape those rules.
Three rules common to every import
- A report before anything is applied. Lines read, lines rejected with their reason, differences from the existing data: the user sees the effect of the file before the project is changed. Cancelling at this stage leaves the project unchanged.
- A single operation. The import is applied in full or not at all. An incident cannot leave an estimate or imported costs half-loaded, which would skew the indicators without anything flagging it.
- Never into a marked revision. Imports apply to the draft revision. If the project has none, the import creates one from the latest marked revision.
MS Project: a lossless round trip
A project’s first schedule often comes from MS Project. Waterfall imports files in the XML format of MS Project 2010 and later: for each task, its name, description, position in the tree, duration, scheduling mode and, in manual mode, its dates; and the links with their type and lag. A leaf task with zero duration becomes a milestone. A task carrying a date constraint is imported in manual mode with the dates from the file, and the report says so.
Some things are never imported: progress, resources, calendars, costs and custom fields. Resources and calendars are managed by Waterfall alone, and the report states what was ignored.
On export, each task carries its Waterfall identifier and its calendar. Reimported after being reworked in MS Project, the schedule updates the existing tasks without touching their estimate lines or their status; new tasks are created. And a schedule exported then reimported unchanged comes back identical, with no difference in the report: proof that both tools compute the same dates from the same durations and the same calendars.
Excel: the estimate and the estimate to complete
Estimates are often built in Excel before they reach a tool. The “Estimate” format presents a summary followed by one sheet per lot of the contract breakdown. The import relies on the identifier each line carries: a known line is updated (quantity, effort or unit cost, role, sub-project, payment terms) without touching its budgeted amount; a line without an identifier is created; a line missing from the file is deleted, unless its task has started. Reimporting the same file gives the same estimate.
The “Estimate to complete” format is used for periodic reviews. The exported file goes out to the lot owners, comes back completed, and each line is matched to its own. Only the re-estimated quantities are changed, never the budgeted amounts, and a line missing from the file keeps its value.
The Excel formats are versioned: a file prepared on an outdated template is rejected with a message naming the expected format, instead of being misread. And their headers do not depend on the interface language: an estimate exported by a French-speaking user can be reimported by an English-speaking colleague.
The ERP: actual costs without double counting
Waterfall does not produce actual costs: it receives them from the ERP, as an Excel extract over a given period. It keeps no direct connection to the ERP.
- The document number identifies each entry. Extracts run from one date to another and two periods may overlap: an entry already imported is updated instead of being counted twice. Two imports of the same file give the same total.
- Cost assignment is read from the WBS element. The ERP’s cost assignment code carries the project code and the sub-project code. An entry belonging to another project is rejected; an entry whose sub-project has not yet been declared is kept, and attached as soon as that sub-project is created.
- An entry can be excluded from the tracked scope. Accounting records everything charged to a project; project control only tracks what was budgeted. An excluded entry can still be viewed but enters no indicator, and its exclusion survives later imports.
- Every import is logged: date, author, extracted period, lines created, updated and ignored.
Spending is reconciled with the budget at sub-project level, the only level where the two worlds meet: timesheets and invoices are never charged to a task. This is the basis on which financial progress and the cost performance index are computed.