Milestones or tasks? Planning a project

A project in myWork24 is built from two things that look alike and are not: milestones and tasks. Getting the split right is most of what makes a project easy to run.

The one-line test

Somebody does it and somebody checks it → it is a task.
It is the moment you decide "we may move on now" → it is a milestone.

A milestone is a gate the project passes through. A task is a piece of work one person does. Work never happens "in" a milestone — it happens in the tasks under it.

Project, milestones as dated gates, tasks under each milestone; the last required task accepted closes the milestone and the next one starts

What each one gives you

A milestone carries:

a target date — milestone dates (and the project's own date) are what turn the project On track / At risk / Overdue;
a share of the project's % complete — progress is counted in milestones, not tasks;
its own chat channel and its own documents folder;
if you choose, the department that delivers it, and that department's leader, who plans its tasks;
a type that decides how it closes: Work group or Generic (closes when its required tasks are done), Design sign-off (needs the client's signature), Production (Work Order) (closes when its Work Order closes) and Acceptance test (FAT) (closes on a recorded pass).

A task carries:

one owner and a due date;
a reviewer — the owner cannot approve their own work;
the brief (what to do) and the output — free text, or a form with fixed fields when you need the answers as data;
its own files, sub-tasks and KPI score.

A task linked to a milestone is either required (the milestone cannot close without it) or optional (a record of the work only). When the reviewer accepts the last required task, the milestone closes itself. A task that is finished but not yet reviewed does not count — it waits for the review, or for the automatic approval after 48 hours.

Plan the tasks up front: they wait for their milestone

You can write every milestone's tasks on day one. A task you create on a milestone that has not started yet is held: it stays a draft only you can see. The person or team it is for does not find it in their list and is not notified, so nobody is asked to clear the racks before the layout they need exists.

A task created on a milestone that has not started is held: a draft the assignee or team cannot see, and nobody is notified. When the milestone starts or is completed, held tasks are released and their people are told. If the milestone is cancelled, held tasks are cancelled with it.

Starting the milestone releases them. Every held task becomes Ready to start - unless it also waits for an earlier step of the milestone, or its person is not at work (then it goes out at their next clock-in). A person is notified; for a team, each member gets one message with a link, and the first to claim it owns it. The same happens if the milestone is completed or closes on its own.
Cancelling the milestone cancels them, with the milestone's reason. Nobody was told about them, so nobody is told now. Cancelling the whole project does the same.
On a milestone that has already started, a new task goes out straight away - unless you set it to start after another task, or to go out at their next clock-in.
New task on the milestone page takes the title, the details, who it is for (a person, or a team to claim it), a due date and a priority.
The milestone page shows how many tasks are waiting, and each one carries a Waiting chip.

Finish writing the held tasks before you press Start: every draft on the milestone goes out at that moment, finished or not. Linking a task that already exists does not hold it, because it has already reached its person.

Tasks one after another inside a milestone

Sometimes the work of one milestone has to happen in order - weld, then paint, then wire. Keep it one milestone and give its tasks an order; do not split it into a milestone per step.

Set order on the milestone page gives each task a step: 1 first, 2 when every step-1 task is handed over (finished for review), and so on. Tasks with the same number run side by side; leave a task without a number if it never waits.
A step that is not its turn yet is Waiting: its people do not see it and are not notified. It goes out by itself when the step before it is handed over - at its person's next clock-in if they are away.
New task on the milestone page has Starts after (it suggests the last step's tasks) and Send it to them: as soon as it can start, or at their next clock-in.
Each task card shows its Step and, while it waits, what it is waiting for. A task already started is never taken back.

Why not a milestone per step? Every milestone is a workspace - its own chat, documents folder, dates and status reminders - so four steps would become four of each. And a milestone closes only when its tasks are reviewed, so each hand-over would wait for the reviewer. A step goes out as soon as the work before it is finished. How waiting works in detail: Waiting tasks: one after another, and sent when people arrive.

Rules of thumb

Few milestones. Two to five is right for most projects: one per real change of phase or decision — design frozen, prototype built, test passed, delivered.
Not a milestone per person or per discipline. If the steps overlap and loop back on each other, keep them as tasks under one milestone, each with its own owner and due date.
Every milestone has at least one required task. A milestone with nothing under it has nobody doing it.
Give a milestone to the department that delivers it when the work needs a discipline you do not run. One of its managers names a leader, who plans the tasks; you keep what and by when. See Giving a milestone to a department.
One task per deliverable and owner. "Draw the SLD" is a task; "Electrical" is not.
Ask who needs to watch the date. If the whole project should go At risk when it slips, it is a milestone date. If only the owner and reviewer need to know, it is a task due date — task dates do not change the project's status.
Order belongs in milestones only when the next phase genuinely must wait. You cannot build a prototype from an unfrozen design — that is a gate. Spec, SLD and mechanical drawings feed each other — those are tasks.
Order inside a milestone is a step order, not more milestones. When the tasks of one phase must happen one after another, keep one milestone and give its tasks steps (Set order).

Example 1 — developing a new product

A 160 kW DC EV charging station with battery storage, from specification to first prototype.

Milestones

Design — due on the design-freeze date.
Manufacturing prototype — type Production (Work Order); it closes when the prototype Work Order closes.
(optional) Prototype test — type Acceptance test (FAT); "built" and "works" are different facts, and only the second should clear the product for production.

Tasks under Design (all required, each with its own owner and due date)

Specification & component finalisation — the technical lead, with an output form (charger, battery, grid, environment, component list) so the numbers are captured once and reused by everybody after.
Outdoor cabinet revision — the mechanical engineer.
SLD & electrical detail drawings.
Mechanical design & technical drawings.

Why not three design milestones (specification → SLD → mechanical)? Because the three overlap: the cabinet revision changes the component list, the component list changes the SLD. Three gates a few days apart would either be ignored or force a false order. The progress bar is coarser this way (it moves when Design closes, not before) — the task list is where you watch the detail.

Example 2 — a container BESS for a client

Here the client must sign drawings before anything is built, so the gates are real and separate: Design sign-off milestones (SLD, GA drawing) that need the client's signature, then Production (Work Order), then Acceptance test (FAT). Under each, tasks for the people doing the work — draw the SLD, collect the client's comments, issue revision B. See Running a container BESS project for the full walk-through.

Example 3 — a small internal job

Moving the workshop's test bench: three people, one week, nothing to sign. Use one milestone ("Bench moved and working") with a required task each, or no milestone at all — a project can simply hold a set of tasks. If one person does it in a day, it is not a project: create a task.

Common mistakes

A milestone for every task. You get a wall of gates with nobody named on them.
A task called "Phase 1 complete". Completing a phase is the milestone closing — it is not work anybody does.
Expecting a late task to turn the project red. Only milestone dates and the project date do that. Put a milestone date on anything the whole project must not miss.
A required task left cancelled. The milestone cannot close on cancelled work; the page warns you. Make it optional, or link the task that replaced it.

Seeing the plan on a calendar

The project's Timeline tab draws the milestones as bars on a calendar, with their tasks underneath, and its Forecast switch shows where the remaining dates are heading after a milestone finishes late or early. Milestone dates are what it draws, which is one more reason to give every milestone a target date. How to read it is covered in Reading a project's Timeline.

Changing your mind

The structure is not fixed. On a milestone's page, Edit renames it, changes its type or moves its date; Cancel milestone drops one you no longer need, with a reason that stays on the timeline (a cancelled milestone no longer counts towards % complete). Tasks already linked stay where they are — re-link them under the milestone they now belong to. Cancelling a milestone that has not started also cancels the tasks held on it.