Project Checklist guides · 4 of 4

Working the plan when it changes

Download this page: PDF · Markdown

Materials didn't land. The plan you built on Monday is wrong by Wednesday. Here's what Project Checklist does about it, and what it deliberately doesn't.

Every guide to planning a project stops at the point where you've made the plan.

That's not where the work is. The work is Wednesday, when the materials didn't land, the plan you built on Monday is wrong, and you've got to work out what that actually costs you.

The plan was always going to change

Worth saying plainly, because a lot of software implies otherwise: a plan that never changes isn't a good plan, it's a plan nobody's using.

The point of planning a project isn't to predict the future. It's so that when something moves, you can see what else moves with it — before your customer finds out, and before three subbies turn up to a site that isn't ready.

Move one thing, and see what follows

Drag a task to a new date on the Timeline, or change its dates in the task panel.

If other tasks were waiting on that one, you'll get asked:

Move the tasks that follow?

4 tasks depend on the one you moved. The project would finish on 24/11/2026 instead of 19/11/2026.

You'll see each task that would move, which list it's in, and its old and new dates. Then two buttons: Move them, or Leave them.

What you see after moving one task. Every task that would move, with its list and both dates. Under it, anything that stays put and why. Nothing changes until you press a button.

Nothing happens until you choose. The app works out the knock-on effects and shows you. It doesn't quietly rewrite your project while you're looking somewhere else.

That line about the finish date is usually the one that matters. Five days is the difference between a conversation with your customer today and an argument with them in three weeks.

Some things don't move

Under the moves you may see a short list headed Left where they are, with a reason next to each:

  • booked — someone's booked to be there and you've marked that booking as fixed. More on this below, because bookings are the one thing here that isn't a simple yes or no.
  • held — you've told it not to move this one. More on that below.
  • already done — the work's finished. Moving its dates would just be rewriting history.

When a task doesn't move, nothing after it moves either. That's deliberate — the app won't shuffle work past a fixed point and hand you a plan that can't happen.

Those tasks are the ones worth looking at. A booked task in that list means someone's booked for work that isn't ready yet, and you've just found out early enough to do something about it.

One task moves three days. The tasks behind it are proposed to move too, until a fixed task, which stays, and so does everything behind it. 16 Nov17 Nov18 Nov19 Nov20 Nov23 Nov24 Nov25 Nov26 Nov27 Nov30 Nov Deliver panels you moved this one Install and mount proposed to follow Electrical inspection stays: booked, fixed Grid connection waits on the inspection, so it stays too where it was proposed move, not yet made held, booked and fixed, or already done: never moved
The ripple stops at the first task that can't move. Nothing behind a fixed point is shuffled past it, so the plan you're shown is one that can actually happen.

Holding a date

Some dates aren't yours to move. The crane's hired. The inspector's coming Thursday. The customer's been told.

Open the task and tick Hold these dates — never move this task automatically. It gets a small marker on the Timeline, and from then on it sits in Left where they are instead of being rescheduled.

Use it for real-world commitments, not for everything. Hold too much and nothing can move, which means the app can't help you see what a delay actually costs.

Bookings, and the one decision worth making early

A task with someone booked on it is the interesting case, because two things are true at once. The booking is a real commitment on a real person's calendar. And if it can never move, one booked task in the middle of a project freezes everything behind it.

So you decide, per booking. Open the task's booking and you'll see:

Fixed — never move this booking automatically

Leave it unticked and the booking can be moved along with its task. Tick it and the task drops into Left where they are instead.

Movable is the default, including for bookings you made before this existed. That's safe because nothing happens on its own — every proposal is shown to you first, and any booking it intends to move is named:

Booked: Sam Ryan · Install crew · moves to 24/11/2026

So you see who's affected and where they'd end up, before anything changes.

Tick Fixed when the date is somebody else's to set. The inspector's coming Thursday. The crane's hired. The customer's taken the day off work. Those shouldn't shuffle because something upstream slipped.

Leave it unticked for your own crew's work, where moving the booking is exactly what you'd do anyway.

It checks whether the person is actually free

When a proposal moves a booking, the app looks at where that person would land — their leave, their working days, anything already booked — and tells you if there's a problem.

A clash never stops you. It's information, not a rule. Often it's a half-hour job you're happy to book over, and you're the one who knows that. It just makes sure you're not finding out on the day.

What it deliberately doesn't do

Worth being straight about, because it's the difference between a tool you can trust and one you have to check.

It won't move a booking without telling you. Bookings can move — that's usually what you want, or one booked task freezes the rest of the project. But every one it intends to move is named in the panel, with the person and the new date, and it checks whether they're free. Nobody's Thursday changes without appearing on your screen first. And any booking you've marked Fixed is never touched at all.

It only pulls work forward by what was gained. If something finishes early, the tasks waiting on it are offered the same number of working days earlier — not squeezed up to the earliest possible date. A gap you left on purpose, for a delivery lead time or curing, stays a gap. It's still a proposal you say yes or no to, it never moves a held task or a fixed booking, and it never moves anything into the past. Whether the people, materials and access are ready that early is still your call.

It won't decide anything. Every time, it shows you and asks. If you say Leave them, nothing moves and you'll be asked again next time something changes.

Seeing what's actually driving the date

On the Timeline there's a Longest chain toggle.

Turn it on and it highlights the run of tasks that decides when the project finishes. If you want to pull the end date in, that's the chain you have to shorten — anything not on it has slack, and speeding it up won't finish the job any sooner.

Longest chain on: the run of tasks that decides the finish date is highlighted; the others are faded and have slack. Longest chain Site visitDesign and quoteOrder panelsslack: could slip without moving the endGrid approvalDeliver panelsslack: could slip without moving the endInstallInspection Shorten a lit task and the end date comes in. Shorten a faded one and nothing changes.
The Longest chain toggle on the Timeline lights the tasks that decide when the project finishes. Usually there is one long wait on that chain that nobody had looked at.

It's also the fastest way to answer "why is this taking so long?" Usually there's one long wait on that chain that nobody had really looked at.

In practice

The routine is short:

  1. Plan the sequence on the Timeline when the project starts.
  2. Work the day-to-day on the Board.
  3. When something slips, change its date and look at what's proposed.
  4. Check what didn't move — that list is where your problems are.
  5. Tell the customer while it's still early news.

That's it. The plan isn't a promise you made in week one. It's the thing that tells you what a delay costs, on the day it happens.