A Move That Breaks a Dependency Is Saved, Not Refused
A plan is re-planned one task at a time, and halfway through a re-plan it is always broken. A Gantt that refuses the first move forces planners back to the spreadsheet. Since 14 October the AWRA timeline takes the move, says what it broke, and offers to push everything downstream.
A software team in Nairobi is building a payments API for a client. On Monday the API build slips three days — a dependency on the client’s sandbox credentials that arrived late. Integration testing waits for the API. The client demo waits for testing. The documentation task waits too, but it had four days of slack. The project lead needs all of that re-planned before the client’s Tuesday call, and she has twenty minutes.
Reading the timeline
Open a project and choose Timeline. Every task with both a start and a due date is a bar. Done tasks are drawn as done, critical-path tasks are marked, and once someone has used Set baseline a thin line under each bar shows where it was originally planned. Milestones are diamonds; dependencies are arrows from a task to the tasks that wait for it; non-working days on your working calendar are shaded; a Today line marks the present. Day, Week and Month change the zoom.
Hovering over a bar shows its dates, length, assignee, estimate and slack, and how many days late or early it is against the baseline. Below the chart a Table view lists the same tasks with start, due, assignee and critical-path flag — the accessible way to read the plan, and the quickest way to check an exact date. Tasks without both dates are listed under Unscheduled rather than guessed onto the chart. A very large project shows its first 600 tasks by start date and says so.
Moving work, by mouse or keyboard
| To do this | Mouse | Keyboard |
|---|---|---|
| Move a task, keeping its length | Drag the bar | Tab to the bar, then Left or Right |
| Change only the due date | Drag the bar’s right edge | Shift with Left or Right |
| Open the task | Click it | Enter |
Each move is saved straight away. Moving a task is editing it, so it needs the permission to edit tasks as well as access to project planning; moving a milestone needs project planning. Someone who can see the timeline but not change it is told so under the chart, rather than finding out when a drag snaps back. In the mobile app the timeline is read-only.
The move that breaks something
Dependencies here are finish-to-start: a task may start no earlier than the day after the task it depends on is due. When a move breaks that rule, the timeline saves it and flags it rather than refusing. Planners rarely re-plan in dependency order — they move the task they are worried about, then its neighbours — and a chart that rejects every intermediate state is a chart nobody re-plans on.
- Moved before its predecessor finishes. The task you moved now starts before something it depends on is done. Only you can resolve that, by moving one of the two; the warning says which.
- Successors now start too early. Tasks waiting on the one you moved now start before it finishes. The warning offers Push successors later.
The chart does not refuse a broken plan. It refuses to let you forget that it is broken.
Push successors later
Push successors later moves each affected open successor later by exactly the days needed, keeps its duration, and repeats down the chain until nothing starts too early. It never pulls a task earlier, so a successor with enough slack to absorb the slip is left where it is. Done and cancelled tasks are never moved; they are reported, because rewriting the dates on finished work rewrites history.
The Nairobi re-plan
With a baseline set, the line under each pushed bar now shows it three days late against the plan agreed at kickoff.
That last note is the useful one for Tuesday’s call. The baseline still holds the original plan, so the client sees three days of slip on three tasks, the reason, and the new demo date — not a chart that quietly changed. Why baselines matter is the subject of the plan you agreed to and the one you have; why slack decides which delays matter is in dependencies, slack and the critical path.
Five minutes with any Gantt
Drag a task so it breaks a dependency.
A good answer sounds like
Saved, with a warning naming the link.
What it tells you
Refused means re-planning happens elsewhere; silent means it breaks unseen.
Push the downstream tasks.
A good answer sounds like
Later by exactly the slip, durations kept, slack respected.
What it tells you
A push that moves everything ignores the slack you planned.
Re-plan without a mouse.
A good answer sounds like
Keyboard moves, plus a table of the same dates.
What it tells you
A chart only a mouse can read is a chart some of your team cannot.
Our position
Set a baseline at kickoff, give every task a start and a due date so it leaves the Unscheduled list, and draw the dependencies that actually exist. Then re-plan on the chart: move the task that slipped, read the warning, and push. The value is not in the drag; it is in never again finding out on demo day that a slip three tasks upstream was nobody’s to notice.
What AWRA OpsHub does today
- A timeline with task bars, baselines, milestones, dependency arrows, the critical path, shaded non-working days and a Today line, at Day, Week and Month zoom.
- A Table view of the same tasks and dates, an Unscheduled list for tasks without both dates, and the first 600 tasks by start date on large projects.
- Drag to move a task or change its due date, and the same by keyboard, saved immediately and gated by edit-task and project-planning permissions.
- Finish-to-start dependency warnings in both directions on a move that breaks one, with the move saved.
- Push successors later: open successors moved later by the days needed down the chain, durations kept, done and cancelled tasks reported rather than moved.
More we can add to your workspace
- A lag on a dependency, such as seven days of curing between a slab pour and stripping the formwork.
- An undo for the last move made on the chart.
- Dragging and re-planning from the mobile timeline.
Where we point you to a specialist
- Which task should give way when two depend on the same resource is a planning judgement. The timeline shows the clash and moves what you tell it to; it never chooses for you.
A timeline for longer chains
Finish-to-start with a push covers most delivery plans. Construction and engineering plans tend to ask for more.
Lag on a dependency
A fixed wait between two tasks — curing, drying, a statutory notice period — carried through every push.
Undo the last move
One click to put back the move you just made, and the pushes that followed it.
Re-plan on the phone
Moving a task from the mobile timeline for site managers who are never at a desk.
Tell us what your schedules look like and we will return a written scope and cost.
Scope schedulingSee the planning tools
The timeline, dependencies, baselines and the critical path on one page.
Project planning & GanttFrequently asked questions
How do I reschedule a task on the AWRA Gantt?
Drag its bar to move it, keeping its length, or drag the right edge to change only the due date. By keyboard, Tab to the bar and use Left or Right to move it a day, or Shift with Left or Right to change the due date. Each move is saved straight away.
What happens if a move breaks a dependency?
The move is saved and flagged. If the moved task now starts before its predecessor finishes, you resolve it by moving one of the two. If tasks that depend on it now start too early, the warning offers Push successors later.
What does Push successors later do?
It moves each affected open successor later by exactly the days needed, keeping its duration, and repeats down the chain. It never moves a task earlier and never moves done or cancelled tasks.
Why are some tasks not on the chart?
A task needs both a start and a due date to be drawn. Tasks missing either are listed under Unscheduled below the chart.
Can I move tasks from the mobile app?
The mobile app shows the timeline read-only. Moving tasks is done on the web.
