Why the plan stops being true
The plan was right on the day it was approved. Then one task slipped by three days, a designer went on holiday, and a client moved a milestone forward.
Each change is small. Following it through is not: the slipped task pushes four others, two of them now land on a person who already has a full week, and the milestone that moved forward depends on both. Somebody opens the Gantt chart and starts dragging bars. After an hour the dates look plausible, and nobody can say whether the plan is still feasible - only that it no longer shows red.
Rosters work the same way. Coverage for next week is built by hand from a spreadsheet of who can do what, then rebuilt when two people call in sick, and a gap nobody noticed shows up on Saturday morning.
None of this is a discipline problem. A plan with a hundred tasks and a dozen people has more interacting rules than a person can keep in their head while dragging bars.
What that costs
- The plan is decoration. Once it stops being recalculated it stops being believed, and the real schedule moves into people's heads.
- Overload is found late. Nobody sees that one person is booked at 160% in week three until week three.
- Every replan starts from zero. Redrawing by hand also moves work that did not need to move, and people learn to ignore the new dates.
- Rosters have holes. A shift that needs a certified person is covered by somebody who is not, because the spreadsheet did not know.
What is different here
The plan is recalculated, not redrawn. Press recalculate and a solver finds a schedule that satisfies every dependency, every person's capacity, every earliest start and every hard finish at once. Work that has already started is pinned; tasks with slack stay where they were instead of jumping around. The plan changes as little as the new facts require.
Nothing is written until somebody agrees. The result arrives as a preview next to the current plan. Apply it, or leave it. If the data changed while you were looking, it will not apply a stale plan; if you applied and regret it, one step undoes the whole run.
If there is no feasible plan, it says why. Instead of a schedule that quietly breaks a rule, you get the rules that could not be met: which resource, which day, by how much.
Shifts come from the same engine. Coverage requirements, skills and unavailability go in; a roster that covers demand with the right people comes out, to be checked, adjusted by hand and published.
Where to go next
- What you can do - project recalculation, preview and undo, critical path and resource load, and shift rosters from requirement to timesheet.
- Under the hood - the constraint solver, why the plan is never written back on its own, and how the service is kept away from your data.
The first application built on it is Projects.