Structure Without Arithmetic
Tasks here can have subtasks, and subtasks can have their own. The tree is real, it survives cloning, and it is used to order work. What it never does is add anything up.
A work breakdown structure has two jobs. One is to organise: here is the shape of the work. The other is to aggregate: here is what the shape adds up to. Most tools do the first, and the second is where they quietly stop.
The tree is real
A task can have a parent and can have children, both relations are properly declared, and the hierarchy is used in earnest — when a project is cloned, tasks are deliberately processed parents before children so that each copied subtask can be pointed at its new parent.
That is not the behaviour of a field somebody added and forgot. Somebody built the tree and then had to think about it again elsewhere.
And it does not add up
A task carries estimated hours and story points. A parent task carries its own estimated hours and its own story points, and those numbers have nothing to do with its children.
There is no roll-up anywhere: not of estimates, not of logged hours, not of story points, not of cost. A parent with five subtasks totalling forty hours shows whatever was typed into its own field, which is usually nothing.
A parent and its five subtasks
The fourth row matters: project totals are right, because they sum the project's own records rather than walking the hierarchy. It is only the intermediate levels that have no numbers.
The project total is correct and every level between a task and the project is blank. A work breakdown structure that only adds up at the top is an outline.
Why it matters more the deeper you go
On a flat project with twenty tasks, none of this is felt. The project total is right, every task is visible, and nobody wanted a subtotal.
On a project with six workstreams, each broken into phases, each broken into tasks, the intermediate levels are exactly where management happens. "How is the civils workstream doing" is a question about a branch of the tree, and the answer requires adding up that branch.
So the deeper and more useful your breakdown, the less the numbers follow it — which is precisely backwards from what you want, and it is why a team that invests in a good structure often ends up maintaining the totals in a spreadsheet alongside it.
The workaround, and it is a real one
Use milestones as the aggregation level rather than parent tasks. Tasks carry a milestone, milestones are a first-class structure, and grouping by milestone gives you a reporting level that parent tasks do not.
It is flatter than a tree — one level rather than many — and for most projects one level is what people actually report on. Keep parent tasks for organising a screen and milestones for anything you need a number about.
One thing, and it is a view rather than a schema change
The hierarchy exists and the numbers exist. What is missing is the walk between them, and that is a query rather than a redesign.
Roll-up on the task tree
Estimated hours, logged hours, story points and cost aggregated from descendants onto each parent, shown alongside the parent's own figures rather than replacing them — because a parent task can legitimately have work of its own. Displayed as a tree with subtotals per branch, which is the screen the structure has been waiting for.
Branch progress as a derived figure
Percentage complete for a branch computed from its descendants rather than typed. It is the number people put in status reports, and today it is produced by a person estimating rather than by adding anything up.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your breakdowns run more than two levels deep, this is the one to raise.
Talk to us about work breakdown reportingWhat AWRA OpsHub does today
- Parent and child task relations, used for organisation and correctly remapped when a project is cloned.
- Estimated hours and story points per task.
- Milestones as a first-class grouping that tasks belong to.
- Project-level actual cost aggregated from labour, purchases, expenses and issued stock.
- Sprints, checklists and dependencies alongside the hierarchy.
What it does not do
- Any roll-up of estimated hours from subtasks to a parent.
- Any roll-up of logged hours, story points or cost.
- Any percentage-complete derived from descendants.
- Any tree view showing subtotals per branch.
- Any constraint that a parent cannot be completed while children are open.
Not ours, by choice
- Project totals are correct and are computed from the project's own records rather than by walking the tree, so nothing on this page suggests the cost figures are wrong. What is missing is the intermediate levels.
- The last item in the not-built list is worth its own thought: nothing prevents completing a parent while its subtasks are open, so a tree can report itself finished while containing unfinished work.
- Nothing here is Indian, Pakistani, Bangladeshi or Sri Lankan. South Asia is here because large delivery teams with deep work-breakdown structures are ordinary there, which is where a non-summing hierarchy costs the most.
Four questions about work breakdown structures
Does a parent task show the total of its children?
A good answer sounds like
Yes, as a subtotal.
What it actually means
The question that separates a tree from an outline. Ours does not.
How deep can the hierarchy go?
A good answer sounds like
A number, or unlimited.
What it actually means
Worth knowing before you design a breakdown around it.
Can I complete a parent with open children?
A good answer sounds like
No.
What it actually means
Ours permits it. A tree that reports itself finished while containing open work is a reporting hazard.
What level do your reports group at?
A good answer sounds like
A named level.
What it actually means
If the only levels are task and project, milestones are your aggregation layer whether you planned that or not.
Our position
Use parent tasks to organise a screen and milestones to aggregate a number — that is the division the product actually supports, and fighting it produces a spreadsheet. Keep breakdowns shallow unless somebody is prepared to maintain the intermediate totals by hand, because the software will not.
Group by milestone, not by parent
It is the one level in this structure that reports cleanly, and using it deliberately saves rebuilding your totals somewhere else.
Talk about project structureFrequently asked questions
Can I log time against a parent task?
Yes, and it counts as that task's own time rather than as part of any total for its children. That is why a roll-up would need to show a parent's own figures alongside the aggregate rather than replacing them.
Do subtasks appear in the critical path?
They are tasks, so they participate in the dependency graph like any other. The hierarchy and the dependency graph are separate structures — being somebody's child does not create a dependency.
Is there a limit on nesting depth?
The relation is a plain parent reference, so depth is not constrained by the model. What constrains it in practice is that nothing aggregates, so a deep tree becomes progressively harder to report on rather than progressively more informative.
