5 Tests to Decide Task vs Subtask for PMs, Deliverable First
A task is a standalone piece of work with its own owner, deadline, and deliverable. A subtask is a smaller step inside that task, one that can’t stand alone and doesn’t need its own schedule, report, or set of assignees. If a work item needs independent dates, multiple people attached, or its own tracking history, it’s a task. If it’s just a checkbox on the way to finishing something bigger, keep it a subtask.
TL;DR:
- Only tasks with independent dates, ownership, or tracking should be promoted from subtasks to full tasks, based on clear visibility triggers.
- Subtasks are often invisible on higher-level views, allowing undetected delays that can disrupt overall project progress.
- Promoting a subtask involves transferring history, setting dependencies, and updating reports to reflect its new status as a task.
- Most projects benefit from having fewer, well-defined subtasks rather than multiple layered levels, simplifying management and oversight.
- Project management tools can restrict subtask creation or enforce order, preventing micro-work from obscuring scope and accountability.
Table of Contents
- Task vs subtask: definitions that actually matter
- How tasks and subtasks fit into a WBS and project schedule
- When to use a subtask vs promote it to a task
- Tool behaviour and limits you need to plan around
- Creating and promoting subtasks the right way
- Three quick examples across disciplines
- Why fewer layers beats more structure
- A simpler way to keep tasks and subtasks honest
- Sources
- FAQ
Task vs subtask: definitions that actually matter
Confusion here usually comes from mixing up three different things: the task, the subtask, and the summary task (sometimes called a container task or parent task). Getting these straight saves arguments later.
A task is a deliverable-focused unit of work. Someone owns it, it has a deadline, and finishing it produces something a stakeholder can point to. A subtask is one of the steps inside that task. It’s not a deliverable in its own right, it’s part of the sequence needed to produce one. A summary task is a roll-up container, a heading that groups related subtasks and reflects their combined progress and dates.
The lowest level of a proper work breakdown structure is called a work package, and PMI’s own guidance is specific about what qualifies:
- It must be assignable to a single owner or team.
- It must be estimable in time and effort.
- It must be measurable so you can say definitively it’s done.
If a subtask fails any of those three tests, it’s not really a subtask yet, it’s a vague intention wearing a checkbox.
How tasks and subtasks fit into a WBS and project schedule
The Practice Standard for Work Breakdown Structures from PMI rests on one rule that gets ignored constantly: the 100% rule. A WBS is built from deliverables, described as nouns (“client onboarding kit,” not “onboard the client”). The moment you switch to verbs, you’ve left the WBS and entered the schedule.
That distinction sounds academic until it isn’t. A common error is treating the WBS as if it were just a fancy task list. It isn’t. The WBS defines what gets delivered; tasks and subtasks in the schedule define how and when the work happens.
- Deliverables live in the WBS, activities live in the schedule.
- Subtasks are schedule-layer items, they describe action, not outcome.
- Conflating the two causes scope errors: teams start scheduling things that were never properly scoped as deliverables in the first place.
Keeping the WBS noun-based first, then breaking deliverables into scheduled tasks and subtasks second, catches missing work before it becomes a missed deadline.
When to use a subtask vs promote it to a task
Most teams don’t need a framework for this, they need five quick tests. Run through them whenever you’re deciding how to log a piece of work.
- Ownership. One person, one subtask. The moment two or more people need separate accountability on the same item, it’s a task.
- Reporting visibility. If a stakeholder will ask “where’s that at?” and expect a dashboard answer, it needs to be a task, not buried inside a parent.
- Duration. The 8/80 rule is a decent heuristic here: work packages generally sit between 8 and 80 hours of effort. A subtask that’s ballooned past that range is probably a task in disguise.
- Independent scheduling. Does it have its own due date that isn’t just inherited from the parent? Does it depend on something external? That’s a task-level need.
- Tracking depth. If it needs its own comment thread, its own timesheet entries, or dependencies pointing at other work items entirely, promote it.
Pro Tip: Ask “can this thing miss its deadline without anyone outside the parent task noticing?” If the answer is no, it’s not a subtask anymore. It’s a task you’ve been hiding.
The underlying pattern across all five tests is visibility. Subtasks are meant to be invisible admin, small steps nobody above the task level needs to see individually. The second something needs its own spotlight, keeping it as a subtask just creates confusion about who’s actually accountable.
Tool behaviour and limits you need to plan around
That creates real friction once a project scales.
- Subtasks are often invisible on higher-level boards or roll-up views, so a stalled subtask can sit unnoticed while the parent task looks “on track.”
- Some tools restrict comment history, timesheets, or independent notes on subtasks, a limitation flagged directly in PMSuite’s own help documentation.
- In Microsoft Project, indenting a task turns it into a subtask, and its dates typically roll up into the parent’s summary bar, which can quietly constrain scheduling flexibility.
- Deleting a summary task in most platforms deletes every subtask beneath it, a behaviour Microsoft’s own project documentation warns against, along with advice to assign resources at the subtask level rather than the summary level to avoid overallocation.
Some platforms let you enforce order here through workflow rules, for instance restricting subtask creation until the parent reaches a specific status. That single governance rule stops the most common failure mode: people spinning up subtasks before the parent task has even been scoped properly, which is how “reporting blindness” creeps in, dashboards that look clean while a mess of untracked micro-work sits underneath them.
Creating and promoting subtasks the right way
A good subtask has a clear title, a one-line acceptance criterion, a single owner, and dates that sit inside the parent task’s window, not outside it. That’s it. If any of those four things are missing, fix that before adding the subtask, not after.
Promoting a subtask to a full task takes a few extra minutes most teams skip:
- Migrate the history. Copy over comments, attachments, and any time already logged, most tools don’t offer a one-click “promote” button, so this is a manual recreate-and-link job.
- Set independent dependencies. Once it’s a task, define what it actually depends on, don’t leave it inheriting the old parent’s schedule by default.
- Update reporting links. Make sure it now appears on whatever dashboard or status report the team actually checks.
- Gate the next one. Use a status rule so nobody creates a fresh subtask under an unscoped parent again.
Three quick examples across disciplines
Design: A task called “Finalise brand style guide” might carry subtasks for colour palette, typography selection, and logo variants, each a quick, single-owner step that never needs its own deadline.
Software: “Build user authentication” starts as one task with subtasks for the login form and password reset flow. Once the reset flow needs its own QA cycle, a different assignee, and separate timesheet tracking, it stops being a subtask and becomes its own ticket.
Marketing: A campaign task, “Launch Q3 email series,” might hold subtasks for draft copy, creative assets, and send scheduling, three small steps feeding one deliverable, none of them needing independent reporting.
Why fewer layers beats more structure
Three levels of decomposition, project, deliverable group, work package, solves nearly every governance headache I’ve seen. Add a fourth or fifth layer and you’re not managing work anymore, you’re managing a hierarchy. Most teams don’t need more subtasks. They need fewer, tighter ones, and the discipline to promote the ones that have outgrown the role.
— Greg
A simpler way to keep tasks and subtasks honest
There are solid ways to handle this with spreadsheets, sticky notes, or a heavyweight enterprise platform, but most small teams end up fighting the tool instead of the work. Some project management platforms take a plainer approach: flexible workspaces where tasks and subtasks stay visible instead of buried three clicks deep, plus built-in messaging and file attachments so context doesn’t get lost when a subtask gets promoted.
If you’re migrating from spreadsheets, some platforms import them directly with no manual re-entry, and offer data export without vendor lock-in or analytics mining of project data. Pricing is transparent: $5 AUD a month for individuals, $9 AUD a month per seat for teams. If your current tool is hiding subtasks from your dashboards or capping what you can track on them, it’s worth checking whether Seven fits better, there’s a free trial to test it against your own project before committing to anything.
Sources
- How to create a work breakdown structure (Project Management Formula)
- Create and work with subtasks and summary tasks in Project desktop - Microsoft Support
FAQ
What is an example of a subtask?
A subtask is a small, single-owner step inside a bigger task, for example “select colour palette” sitting under the task “finalise brand style guide.” It doesn’t need its own deadline or report because its progress is captured by the parent task.
What are the three types of tasks?
Most WBS frameworks distinguish summary tasks (roll-up containers), tasks (deliverable-focused work items), and subtasks (the steps inside a task). Some guides also mention milestones as a fourth category, markers with zero duration used to flag key dates.
How do I make a task a subtask in a project?
In tools like Microsoft Project, indenting a task underneath another turns it into a subtask, and the parent automatically becomes a summary task. In other platforms, you typically drag the item under a parent or assign it a “parent task” field.
What is another term for a subtask?
Common alternatives include “child task,” “sub-item,” or “checklist item,” depending on the platform. In formal WBS terminology, the lowest-level item is usually called a work package once it meets the assignable, estimable, and measurable criteria.