Decomposition in project management: how to break down project work

Decomposition is a planning technique that breaks project scope and deliverables into smaller, manageable components. You keep breaking them down until the team has enough detail to estimate, assign, carry out and track the work.

“Launch a new website” sounds like a plan. It is closer to an ambition. Who will write the content? What needs testing? Does the launch include training the people who will maintain it?

Decomposition helps you answer these questions before missing work becomes a missed deadline.

What is decomposition?

The Stakeholdermap project management dictionary defines decomposition as subdividing scope and deliverables until the work is detailed enough to support delivery, monitoring and control.

In plain English, you take a large piece of work and identify the smaller pieces needed to complete it.

Three terms help explain how this works:

Decomposition is commonly used to create a work breakdown structure (WBS): a hierarchy showing how the project's scope divides into smaller components. Decomposition is the technique; the WBS records the resulting breakdown.

A work package can still involve several activities. Producing an approved participant workbook might require drafting exercises, checking the instructions and approving the final document.

The WBS defines what the project must deliver. The schedule adds the activities, sequence and timing needed to deliver it. See PMI's explanation of the relationship between a WBS and a project schedule.

Why use decomposition?

A broad description can hide a surprising amount of work. Breaking it down makes that work visible and gives people something concrete to discuss.

For example, a team planning a training workshop might initially allow time for preparing slides and delivering the session. Decomposition prompts them to consider participant exercises, room access, equipment checks and feedback.

This helps you:

• Find omissions. Check whether the plan covers everything needed for a usable result.
• Improve estimates. Ask people to estimate defined pieces of work with clear boundaries.
• Clarify responsibility. Make it clear who owns each package and who accepts its output.
• Assess progress. Check completed outputs rather than relying on a vague “nearly finished”.
• Understand changes. Identify which components a new request affects before agreeing to it.

It also exposes disagreements. If the trainer expects printed workbooks but the organiser assumes digital copies, you want that conversation during planning.

When should you use it?

Use decomposition when you understand the project's purpose and need to turn its scope into a workable plan. It is particularly useful before committing to detailed estimates, assigning work or building a schedule.

You can also revisit the breakdown when an approved change adds a deliverable or new information makes an existing component clearer.

You do not need to pretend that distant work is fully understood. Define upcoming work in detail and keep later work at a broader level until you know enough to refine it. This approach is often called rolling wave planning. PMI discusses it in Developing and elaborating effective work breakdown structures.

For example, you can break down the preparation for a pilot workshop now. The work needed for a wider rollout may depend on what the pilot reveals.

Who should be involved?

The project manager usually coordinates the exercise, but the people doing and accepting the work should help shape it.

For a small workshop, this might be a short discussion between the organiser, trainer and commissioning manager. A larger project may need separate sessions with specialist teams.

Ask people about the work they understand. A polished chart cannot compensate for missing expertise.

How to decompose project work

1. Confirm the scope and boundaries

Write down the result the project must achieve, its main deliverables and any exclusions.

For a workshop, clarify whether the project includes recording the session, training absent staff or providing ongoing support. Do not let assumptions quietly become commitments.

2. Identify the main deliverables

Start with the major outputs. For the workshop, these might include an approved training pack, a delivered session and an evaluation report.

Include the work needed to manage and close the project. Reviews, coordination and handover still take effort, even when they do not appear in the final product.

3. Break each deliverable into smaller components

Ask: “What must this contain for us to call it complete?”

An approved training pack could contain a slide deck, participant workbook and facilitator guide. Check whether each component is clear enough to estimate and assign. Break it down further where necessary.

4. Check completeness and overlaps

The 100% rule means that the breakdown covers all the agreed scope. Within each branch, the smaller components must account for all the work in their parent component. Avoid counting the same work twice. These principles are explained in PMI's guidance on developing a WBS.

For the training pack, decide where exercise instructions belong. If both the workbook and facilitator guide contain them, distinguish the participant instructions from the trainer's delivery notes.

5. Describe each work package

A short label rarely tells the whole story. Record its boundaries and completion conditions in supporting notes, often called a WBS dictionary.

For example:

This is an illustrative entry. Adapt the fields to the decisions your project needs to make.

6. Use the packages to plan activities

For the workbook, activities might include writing the first draft, testing an exercise with a colleague, making corrections and obtaining approval.

Estimate those activities, identify their dependencies and assign resources. Keep the link to the work package so you can see which deliverable each activity supports.

Worked example: planning a training workshop

Imagine a project to deliver a two-hour workshop for 20 staff. The table shows one branch of its breakdown. It is not the complete project WBS.

Other branches would cover the remaining agreed scope, such as session arrangements, delivery, evaluation and project management.

Suppose someone now asks for a recording with captions. The existing breakdown helps you ask useful questions: Who will record it? Who will edit it? Who will check the captions? Where will it be hosted?

That request can now be assessed as additional work, with owners and estimates, before anyone promises it will be included.

How much detail is enough?

Use this practical check for each proposed work package:

• Can we explain what it includes and excludes?
• Can someone take responsibility for delivering it?
• Can the people doing the work make a useful estimate?
• Can we describe the evidence needed to accept it?
• Can we spot a problem early enough to act?

If the answers are unclear, investigate or break the component down further.

There is no useful reason to force every branch to the same depth. An unfamiliar software integration may need more detail than ordering standard equipment.

Stop when further breakdown adds administration without improving a planning or control decision. You need enough detail to manage the work, not an entry for every email.

Common mistakes

To try the technique, choose one deliverable from your current project. List its components with the person responsible for producing it, then agree how you will know each is complete.

Sources and further reading

• Stakeholdermap: Project Management Dictionary of Terms, D, source definition of decomposition.
• Paul Burek: The ABC basics of the WBS, PMI conference paper, 2013.
• PMI: Developing and elaborating effective work breakdown structures.

The workshop scenario and example work package are illustrative.