Shaping a Plan: Subtasks, Milestones, Board Columns & Progress
A plan is not a list. It is a shape: one level of subtasks, checkpoints that mean something, board columns that match how your team actually talks, and a progress figure you understand well enough not to be misled by.
Two project plans for the same job. The first is forty-one tasks in a flat list, sorted by whoever added them, with names like "Follow up" and "Sort out the wiring issue". The second is nine deliverables, each with three or four steps under it, four checkpoints with dates the client also has, and a board whose columns are the words the site foreman actually uses. Same work, same team, same budget. One of them will be abandoned by week three.
The difference is not diligence. It is that the second plan was shaped to be read at a glance by someone who is busy, and the first was shaped by the order things occurred to somebody. This post is about the shaping tools available, what each is genuinely for, and the one number on the project page you should not take at face value.
Start with what a task is and is not
One distinction to get out of the way, because it confuses people who have looked at the whole system: a task here is human work someone does. It is a different object from a workflow step in an approval chain — the thing that routes a purchase order to the right approver — even though both get called "tasks" in ordinary speech. This post is entirely about the first kind.
What a task carries, and how much of it you should fill in
Title and description
The title should say what "done" looks like. "Follow up" is not a task; "Get written sign-off from the client on the layout" is. This costs nothing and does more for a plan than any other single habit.
Assignee
Tasks are assigned to an employee record, not to a system user. That is deliberate: the person doing site work may not have a login at all. It has one consequence worth knowing — reminders only reach assignees who do have a linked login.
Start and due dates
Undated tasks are invisible to reminders, to the calendar and to overdue reporting. If a task genuinely has no date, that is a signal it is a note rather than a commitment.
Baseline dates
A separate pair of planned dates, held alongside the live ones. Set them when the plan is agreed and never touch them again — the gap between baseline and actual is the only honest record of how much the schedule moved.
Priority
Useful for filtering and for the My Tasks list. Not useful if everything is urgent, which is what happens within about a month unless somebody polices it.
Parent task
A task can have subtasks, and a subtask cannot itself have subtasks. This is enforced rather than advised. It is a constraint that saves you from yourself — see below.
Milestone and sprint
Two different ways of bundling tasks: a milestone is a checkpoint on the timeline, a sprint is a time-boxed batch. Neither is required, and most projects want one of the two rather than both.
Why subtasks stop at one level
You cannot nest a subtask under a subtask. This is not an oversight; it is enforced when the parent is set. And it is the single most valuable constraint in the module, because deep nesting is how plans die.
A four-level hierarchy always starts as an act of thoroughness and ends as a structure nobody can hold in their head, where the same work appears at two levels and nobody is sure which one to update. Two levels forces a decision every planner should be making anyway: is this a deliverable, or a step towards one? If your work genuinely needs three levels, the top level is not a task at all — it is a milestone, or it is a separate project.
If it produces something the client or the business receives
Make it a top-level task
Deliverables sit at the top level, with the steps to produce them as subtasks. Someone reading only the top level should see the shape of the whole job.
If it is a step towards a deliverable
Make it a subtask
Steps live one level down. They can have their own dates, assignee and dependencies, so nothing is lost by demoting them — you just stop cluttering the top-level view.
If it is a date the client cares about
Make it a milestone
Milestones are checkpoints, not work: a name, a due date, and a status of open, met or missed. Tasks are grouped under them. This is where "handover", "first payment due" and "practical completion" belong.
If it needs its own budget, customer or profitability figure
Make it a project
A phase big enough to have its own budget and margin is a project, not a task. Costing, invoicing and payouts all attach at project level, so burying a phase inside another project hides its economics.
Board columns in your own words
The default statuses are to-do, in progress, blocked, done and cancelled, and for a lot of work that is exactly right. But a project can define its own columns instead — with their own labels, colours and order — and those columns then drive both the board and the status picker on every task in that project.
The important part is that each custom column declares whether it means done or cancelled. That is what lets the system know a column called "Signed off" or "Handed over" is a finish line, so completion timestamps and progress counts stay correct. A column with no done flag is treated as work in progress no matter what you named it.
Name the finish line, and flag it
The done flag is the field people skip, and skipping it is expensive: a column called "Handed over" with no done flag leaves every finished task counted as work in progress, so your progress figure understates, completion timestamps never get set, and the daily reminder sweep keeps chasing people about work they finished last month. Renaming a column is cosmetic. Flagging it is what makes the rename mean something.
The progress percentage, and what it actually counts
The figure on the project page is straightforward and therefore easy to misread. It is the number of done tasks divided by the number of tasks that are not cancelled. Nothing else. Not effort, not story points, not hours logged, not budget consumed.
Why task-count progress flatters a badly shaped plan
The fix is not a cleverer metric. It is breaking the big task into subtasks so the count reflects reality — which is also the only way anyone can tell what is happening inside it. Read progress alongside budget consumed and the baseline variance, never on its own. The money view is in project budget vs actual.
A progress percentage measures how well your plan is shaped at least as much as how much work is done.
Which is a useful thing to know about it
The details that make a plan usable day to day
- Checklist items on a task, each tickable, with a count shown on the task. This is the right home for acceptance criteria — the four things that must be true before "tested" means tested.
- Labels, shared across the workspace and attachable to any task. Useful for cross-cutting views: everything blocked on a client, everything needing a vehicle, everything for one site.
- Comments with mentions, which notify the person mentioned. Keeping the discussion on the task rather than in a chat thread is what makes a task readable by someone joining in week six.
- Watchers, so people who need to know about a task without owning it get notified without being assigned it. This is the cure for assigning tasks to three people so nobody forgets.
- Attachments, held in the document vault rather than loose on the task, so file access follows the same rules as every other document in the system.
- Dependencies between tasks, which drive the critical path — covered properly in dependencies, slack and the critical path.
- Saved views on the My Tasks list: a named preset of filters — status, priority, assignee, label, due — per user. The single highest-return two minutes anyone on your team will spend, because it turns "find my overdue work" into one click.
- Daily due reminders, sent in-app each morning to assignees of open tasks that are overdue or due within three days.
On reminders, one honest limitation worth repeating: because tasks are assigned to employee records rather than logins, an assignee without a linked user account gets no reminder. For site teams and casual workers that is common, and it means the plan needs a person who reads it on their behalf rather than a notification that nobody receives.
Shaping a plan in eight passes
-
List the deliverables, not the activities
Six to twelve things the job produces. If you have thirty, some of them are steps. If you have three, some of them are hiding a lot.
-
Put the dates the client already knows about as milestones
Handover, inspection, payment stages. These are the dates you will be asked about, so they should be visible without opening anything.
-
Break each deliverable into steps as subtasks
Aim for steps a single person can finish in a few days. Anything longer than a week is hiding a decision, a dependency or a risk inside itself.
-
Wire the order as dependencies, not as dates
Encode that testing follows installation. Dates will move; the order will not.
-
Set the baseline and then leave it alone
Once the plan is agreed, set the baseline dates. From that moment the variance between baseline and live dates is the only unarguable record of slip.
-
Name the board columns the way the team speaks
If your team says "with the client", make that a column. Flag it correctly as in-progress rather than done, and remember the sprint caveat above.
-
Assign one owner per task
One name. Use watchers for everyone else who needs to know. Shared ownership is the most reliable way to produce an unowned task.
-
Get each person to save one view
My open work, sorted by due date. Two minutes each, and it is the difference between a plan people read and a plan people are told about in meetings.
What we do and do not do
What AWRA OpsHub does today
- Tasks with title, description, status, priority, assignee, start and due dates, and sort order.
- Exactly one level of subtasks, enforced when the parent is set.
- Baseline start and due dates held separately from live dates, with a variance figure in days.
- Milestones with a name, due date and open / met / missed status, with tasks grouped under them.
- Custom per-project board columns with labels, colours, order, and explicit done and cancelled semantics — honoured consistently by progress counts, completion timestamps, sprint metrics and the reminder sweep.
- Checklist items, labels, comments with mentions, watchers, attachments in the document vault, and dependencies.
- Per-user saved filter views on the My Tasks list.
- Daily in-app reminders for open tasks overdue or due within three days.
- Standalone tasks that belong to no project at all.
- Assignment to employee records, so people without system logins can still own work.
What it does not do
- More than one level of subtasks — deliberately, and we would push back before changing it.
- Progress weighted by effort, points or hours. The project progress figure is a task count, and a badly shaped plan will flatter itself.
- Automatic milestone status: open, met and missed are set by a person, not derived from whether the underlying tasks finished.
- Task-level budgets or costs. Money attaches at project level; a phase needing its own margin should be its own project.
- Email or SMS task reminders — reminders are in-app, and assignees without a linked login receive nothing.
- Resource levelling or workload balancing across people.
- Cross-project dependencies; a dependency links two tasks, and the critical path is computed within a project.
The progress-figure limitation is the one to internalise, because it will not announce itself: it is a genuinely useful number as long as you know it counts tasks and read it next to your budget and baseline figures.
The five habits that keep a plan alive past week three
- Every task title states what "done" looks like.
- Every task that matters has a due date and exactly one owner.
- Baselines set once at agreement, never adjusted afterwards.
- Big tasks broken down the moment somebody cannot say what is happening inside them.
- Every person has one saved view they actually open.
How to reuse a shape you have built is in templates and recurring work, the order and float in dependencies and the critical path, whether to run it in iterations in sprints, points and velocity, and what to record when it finishes in closing a project.
A plan people actually read
Deliverables with steps beneath them, milestones your client recognises, board columns in your own words, and a saved view for everyone who has work to do.
See project planning in AWRAFrequently asked questions
Why can I only create one level of subtasks?
Because it is enforced, and because deeper nesting is how plans stop being read. Two levels forces the useful question — is this a deliverable or a step towards one? — and keeps the top-level view legible to somebody who is busy. If you genuinely need a third level, that top item is a milestone or a separate project, and treating it as one gives you things a task cannot have, like its own budget and margin.
What does the project progress percentage measure?
Done tasks divided by tasks that are not cancelled. Nothing else — not effort, points, hours or money. That makes it easy to read and easy to misread: nine small finished tasks alongside one enormous open one reports 90%. Read it beside budget consumed and the baseline variance, and break large tasks down so the count reflects reality.
Can we rename the board columns to match how our team talks?
Yes. A project can define its own statuses with labels, colours and order, and they drive both the board and the task status picker. The one thing you must do is flag whether each column means done or cancelled — that is what keeps completion timestamps, progress counts, sprint burndown and the daily reminder sweep all correct. A finish-line column without the done flag leaves finished work counted as open and people still being reminded about it.
What is the difference between a milestone and a sprint?
A milestone is a checkpoint on the timeline — a name, a due date, and a status of open, met or missed — and it is usually a date your client also knows about. A sprint is a time-boxed batch of work for the team's own rhythm. Milestones are about commitments outwards; sprints are about capacity inwards. Most projects want one or the other rather than both.
Are milestones marked met automatically when their tasks finish?
No. Milestone status is set by a person. That is a deliberate limitation rather than an accident: a milestone often depends on something outside your task list — a client signature, an inspector's visit, a payment clearing — so deriving it from task completion would produce a confident wrong answer. If you want it derived, that is a fair request; today it is a decision somebody makes.
Who gets notified about a task, and how?
The assignee is notified when they are assigned and when the status changes; watchers are notified on activity without owning the task; mentions in comments notify the person named. There is also a daily in-app sweep for open tasks that are overdue or due within three days. All of it is in-app, and because tasks are assigned to employee records rather than logins, an assignee without a linked user account receives nothing — which is common for site and casual workers and worth planning around.
Can a task exist without a project?
Yes. A task may be standalone, which suits internal work that has no job to charge and no client to report to. It still supports assignment, dates, subtasks, checklists, labels, comments and watchers. What it will not have is project-level costing, since budgets, rates, invoicing and payouts all attach to a project.
