Estimates, dependencies and the schedule

Most tools ask you to place bars on a chart and then keep them in step by hand. Waymarq works the other way round: you say how long things take and what depends on what, and the dates fall out of that.

Estimates

Give each task an estimate in days (whole or fractional). This is the single most valuable field in the app — the schedule, the delivery forecast and the workload report all derive from it.

A task with no estimate gets no dates. That's deliberate: a plan that admits which parts aren't estimated is more useful than one that quietly invents them. Unestimated tasks are counted and surfaced rather than hidden.

Dependencies

On a task, Depends on lists what must finish first. Waymarq then never schedules that task to start before its prerequisites end, and:

• Refuses circular dependencies outright.
• Draws the relationships as arrows on the timeline and the roadmap.
• Warns you before a drag on the Gantt would break an order, rather than letting it silently happen.

Phases can depend on phases too, which is what makes them run in sequence. Waymarq removes redundant links automatically — if C depends on B and B depends on A, you don't need to say C depends on A, and adding it would just draw a line that teaches nobody anything.

Working days and holidays

Scheduling only ever uses your organisation's working week, skipping your observed public holidays. A five-day estimate on a Mon–Fri week spans a full working week.

Dates follow a length

Most people know how long a task is before they know its dates. When you add a task, its start defaults to the working day after the last dated task in that phase — so a sequence typed in order follows on by itself — and typing a number of days sets the due date. On an existing task, moving the start date moves the due date with it so the task keeps its length in working days (a Wednesday–Friday task given a Monday start becomes Monday–Wednesday), and the Length field under the dates lets you change the length directly.

Concurrency

Project settings → how many tasks may run at once. Dependencies say what can't overlap; concurrency says what doesn't, despite being allowed to — one person can't work five unrelated tasks simultaneously. Without a limit, a plan with few dependencies schedules everything on day one and reports a delivery date nobody could hit.

Set it to roughly the number of people who can work in parallel.

Rebuilding the schedule

Two operations, deliberately different:

• Save and reschedule (Project settings) rebuilds every date from the estimates and dependencies. Right for a project still being planned.

• Reschedule the remainder reflows only the not-started work, leaving anything done or in progress exactly where it is. Right for a project already underway — someone may have logged time against those dates, or told a client them.

• Move the plan is neither of those, and it's the one you want when a project has simply
  slipped. Change the start date and Waymarq notices that work is still sitting on dates from
  before the move; the project overview then offers to shift everything not yet started by the same
  number of days. Durations, spacing and order are untouched — the plan isn't rebuilt, it's moved —
  which also means a task with no estimate keeps its dates instead of losing them, and the phases
  move with the work. You see exactly what would move before anything does.

  Pinned dates come along with it by default, unlike a rebuild. A pin means "don't work this one
  out again", and a shift doesn't: it keeps the arrangement the pin was protecting and only changes
  where that arrangement sits. It matters because dragging bars on the Gantt pins the whole batch,
  so a plan you arranged by hand is a plan that is entirely pinned — and leaving those out would
  mean the offer did nothing. If one of them is a real commitment rather than an arrangement, untick
  the box in the dialog and it stays where it is.

Completed work never pushes future work, whatever date it carries.

Pinning a date that isn't a calculation

Most dates in a project are worked out for you. Some aren't: a client deadline, a contractual milestone, a site visit, a meeting you're recording as a task. Those are commitments, and a rebuild shouldn't quietly move them.

Open the task, and under its dates use Pin these dates. The scheduler then works around it — the dates are never rewritten, the task never shows up as having moved, it still takes up capacity on the days it occupies, and anything depending on it is scheduled after it finishes. A pinned task shows a pin beside its name on the Gantt, so you can see at a glance which dates the scheduler has been told to leave alone.

Dragging a bar is not pinning. Arranging a plan on the Gantt saves the dates you placed, and a reschedule started from that same save works around them rather than undoing your work — but it does not mark them permanently. Pinning is a separate, deliberate act, because the two mean different things: one is "this is where I have put it for now", the other is "this date is a commitment". (Until recently dragging did pin, which meant a plan arranged by hand was a plan entirely opted out of scheduling. If an older project of yours has pins you did not intend, the Gantt now shows them and you can clear each from the task.)

A plan imported from a document is the one case where dates do arrive pinned, and that is deliberate: they came from your client's own file, and the point of importing rather than retyping is that they survive. Clear them from the tasks if you would rather Waymarq worked the schedule out.

A pinned task doesn't need an estimate. That's the point: the things worth pinning usually don't have one, and an unestimated task would otherwise have its dates cleared.

Pin sparingly. Every pinned date is one the scheduler can no longer help you with, and a plan where everything is pinned is a plan that can't respond to anything changing. If a pinned date starts to look wrong, move it yourself — nothing else will.

How much work is it?

Next to the delivery date, the project overview shows Work in this plan — the total effort in the project, in working days, added up from the estimates on its tasks. It's the answer to "how big is this job", as opposed to "when will it be done", and the two are genuinely different questions: how long it takes depends on how many people are on it and what has to wait for what.

Three things travel with that number, because it isn't safe on its own:

• What's missing. A total adds up the tasks that have an estimate and quietly skips the ones that don't. So if anything is unestimated, the card says so and calls the figure a floor rather than a total — the real number is higher.
• Whose number it is. An estimate written by AI looks exactly like one you wrote, once it's inside a sum. The card tells you how many have actually been confirmed by a person.
• How many people it assumes. The plan is scheduled for however many tasks you allow to run at once — one, unless you've changed it. That's why a modest amount of work can still stretch over months. Change it in Project settings and the schedule reflows.

Each phase carries its own figure too, so you can see which stage of the work is the expensive one — and what it's worth if you decide to defer it.

Anticipated delivery

The project overview shows an Anticipated delivery figure: when the work that's actually left is due to finish, measured against your deadline. It's computed over pending work only, so a completed task can never move it, and it tells you plainly how much it excludes — backlog items and anything unestimated.