A schedule that survives contact with the site.
We build, maintain and defend your project schedule. Chronos computes sequences, tests hypotheses and keeps the trace of every revision.
Let’s talk about your projectThe problem
-
The baseline schedule stopped being true by month three.
-
And nobody dares touch it anymore.
-
When the delay finally comes up for discussion, no one can say when the slippage started or what caused it.
The model
A schedule holds like code: one baseline, one branch per hypothesis, a merge when you decide, and a history nobody can rewrite.
- commita dated revision, attributed to its author
- brancha hypothesis tested without touching the reference schedule
- diffwhat changes between two scenarios, task by task
- mergethe decision taken, and the trace of who took it
- blamewho moved this task, when, and on what data
- checkoutthe exact state of the schedule at a past date
Functions
-
Queryable
The schedule answers a question asked in plain language
« Which tasks slipped since the last revision, and which of them touch the critical path? » An agent reads the data, computes, and names the tasks. A schedule file gets opened; this one gets asked.
-
Levelling
Spreads workload against real availability
It first looks for a solution that leaves the contractual date untouched. If it finds none, it says so, and shows what would have to move.
-
Smoothing
Cuts mobilisation peaks without extending the critical path
A mobilisation peak that drops one week in three is a real cost. Smoothing shaves it wherever float allows.
-
Critical path
Recalculated on every progress update
Not once a month for the report: every time the data changes.
-
Scenarios
Each hypothesis lives in its own branch
Two scenarios are compared task by task before one is chosen. The comparison is an object, not an impression.
-
Ledger
Every revision is dated and attributed
The state of the schedule at any past date can be reconstructed. That is what makes the account defensible months later.
-
Interoperability
Reads and writes the formats of the trade
The schedule stays in the tool where it lives. No re-entry, no migration.
Against current practice
| Current practice | With the engine | |
|---|---|---|
| Querying the schedule | open the file and search | ask the question in plain language |
| Updates | monthly, by hand | on every progress update |
| Revisions | the previous version is overwritten | dated, kept, replayable |
| Hypotheses | one file per scenario, compared by eye | branches compared task by task |
| Levelling | manual, untraced | under explicit constraint, the trade-off logged |
| State at a past date | recoverable if the backup exists | reconstructable at any date |
| Who decides | the planner | the planner; the engine computes and proposes |
Formats read and written
What the engine does not do
It does not replace the planner. The engine computes, tests and proposes. The call stays human, and is logged as such: who decided, when, and on what basis.
It invents no data. Without progress updates it concludes nothing. It flags what is missing rather than filling the gap with an assumption.
It does not replace knowledge of the site. The engine computes on what is reported to it. An event nobody flagged does not exist for it: its worth depends on what comes back from site, and it says when that is missing.