What exists today
- The specification: more than two hundred requirements, each with an identifier, a rationale and an observable verification criterion. It describes the complete behaviour of the first version, as well as its technical architecture.
- The API contract: some one hundred and fifty operations, written by hand in OpenAPI. It is authoritative: the interface client is generated from it, and a service that departed from it would be rejected by the CI chain.
- The mockup: the complete interface, running against a fake service that serves the examples from the contract. You can run it on your own machine from the repository.
- The foundation: the tooling, the coding rules for each language and the chain that checks every change.
The usable product, the one that costs and controls a real project, does not exist yet. The functions described in the Principles pages are those the specification defines, and they will be delivered in the order below.
The build order
The order follows business dependencies, not the numbering: a project cannot be created without reference data, a cost line only exists through an import, and the occurrence of a risk is costed through the estimate to complete.
| Epic | Scope | Status |
|---|---|---|
EP-01 |
Development foundation The tooling, the coding rules and the CI chain that all code goes through. |
delivered |
EP-02 |
Front-end mockup on a simulated contract Every screen, wired to a fake service that serves the examples from the API contract. |
delivered |
EP-03 |
Accounts, authentication and authorisation The first real service: API, database, identity, authorisation roles and permissions. On its delivery, an online demo opens to testers. |
in progress |
EP-14 |
Front-end mockup: finishing touches Completing the mockup screens, in parallel with EP-03. |
to be planned |
EP-05 |
Company reference data Organisation, resource roles, calendars, cost types and cost categories, hourly rates. |
to be planned |
EP-04 |
Projects, revisions and lifecycle Creating projects, revisions and marking them, the baseline revision. |
to be planned |
EP-06 |
Scheduling The schedule grid, the Gantt chart, the critical path, the MS Project round trip. |
to be planned |
EP-07 |
Costing and estimates Estimate lines, rates, inflation, the workload plan, the Excel round trip for the estimate. |
to be planned |
EP-09 |
Actual costs, estimate to complete and cost import Importing costs from the ERP, re-estimation and its Excel round trip. |
to be planned |
EP-10 |
Project indicators Earned value, indices, estimates at completion and curves. |
to be planned |
EP-08 |
Contract amendments, risks and risk provisions Differentials, risks, their provisions, occurrence and coverage. |
to be planned |
EP-11 |
Portfolio Consolidated views across all projects. |
to be planned |
EP-13 |
Operations and production deployment Packaging, backup and deployment of the platform. |
to be planned |
File exchanges have no epic of their own: each round trip is validated in the functional block that uses it (MS Project with scheduling, the estimate with costing, the estimate to complete with actual costs).
How the product is built
After the mockup, each epic is a vertical slice: contract, business core, API, screen and tests. Delivering the whole service and then the whole interface would leave nothing to see until the end.
- Each requirement of the specification is closed by a single epic, which verifies it in full.
- The acceptance criteria of the user stories restate the requirements’ verification criterion word for word, worked examples included: they are what become the test cases.
- Work arrives in batches: one batch, one branch, one pull request, of roughly one thousand to one thousand five hundred lines including tests, so that a careful review remains possible.
- The CI chain checks, tests and measures requirement coverage on every pull request. Agents may scope, develop and review; merging an epic into the main branch always remains a human decision.
Following progress
The detailed roadmap, with the user stories of each epic, is published in the repository. Reading that directory is enough to know where the project stands, without opening the issues.