How to divide a project into phases and sub-phases

A large project cannot be managed in one piece: it cannot be estimated, assigned or measured. You have to divide it until each piece is something a person understands, estimates and can finish. That division, known in project management as a work breakdown structure, is the planning decision with the most consequences: estimates, tracking and even how progress is read depend on it. This guide proposes practical criteria for getting it right.

What a phase, a sub-phase and a task are

• Phase: a stage of the project with a recognisable result ("Analysis", "Testing", "Go-live"). It answers "where are we?".
• Sub-phase: a block with its own identity inside a phase, when the phase is too large to read at a glance ("Data migration" → "Customers", "Items").
• Task: the unit of work that is estimated, assigned and finished. It answers "who does what and how much does it cost?".

The golden rule: phases and sub-phases group; tasks get done. If a "phase" has no tasks under it, it is a label, not work.

How to divide, step by step

1. Start from results, not activities. Ask what must exist at the end of each stage (an approved analysis, migrated data, a tested system) and name the phase after that.
2. Cover the whole scope, and only the scope. The parts of a level must add up to 100% of their parent's work. If something is missing, it will turn up later as "unplanned work"; if there is too much, you are over-budgeting.
3. Use the project's natural order. In most projects phases follow a sequence (analysis, build, testing, delivery). If you work from templates, start from one that resembles your type of project.
4. Go down to tasks you can estimate. A good task is small enough to estimate with confidence and large enough to deserve tracking. As a guideline, between half a day and a week of work.
5. Review with someone else. The person who will do the work sees gaps the planner does not.

How many levels to use

Few. Almost all projects do well with two levels of phases (phase and sub-phase) and the tasks beneath; a third level only pays off in very large projects. Each extra level adds noise and maintenance work. A sign that there are too many levels: sub-phases with one or two tasks, or names that repeat their phase's.

A sign that there are too few: a phase with twenty tasks that mix different things. There, one sub-phase per topic makes tracking readable.

Example: rolling out a management tool

1. Analysis
2. Configuration
3. Data migration
   3.1 Customers
   3.2 Items
   3.3 Opening balances
4. Training
5. Acceptance testing
6. Go-live

Each sub-phase of "Data migration" has its own tasks (extract, clean, load, validate) and can be assigned to different people. That way "Data migration" shows as a block with its progress and its hours, and you can also tell in exactly which part it gets stuck.

Common mistakes

1. Dividing by people or departments instead of by results: the structure becomes tied to the team's organisation instead of the work.
2. Overlapping phases. If a task fits in two phases, progress and hours get split badly.
3. Giant tasks. A four-hundred-hour task hides any problem until the end and dominates the progress calculation.
4. Tiny tasks. Ten half-hour tasks cost more to manage than they bring.
5. A structure nobody maintains. A plan that is not updated when the scope changes stops describing the project.
6. Not estimating. Without estimated hours, the structure is no use for measuring progress or deviation.

Why it matters for progress

A project's progress is calculated from the bottom up: each task contributes according to its estimated hours, and each phase according to the weight of its own. A badly balanced structure (one huge phase with a single task, a small one with ten) distorts the result. The guide on weighted progress explains the formula with an example.

How it is structured in PjMan

The help pages describe each screen; here is the essence of how the division translates into PjMan:

• Up to three levels of phases (phase, sub-phase and sub-phase of that sub-phase), with tasks hanging from a phase at any level. (Phases and sub-phases)
• Project templates: when creating a project you can start from a template with the typical phases of its type (ERP implementation, software development, BI, architecture and engineering) or from a blank project. The phases are copied into the project and are yours: you can rename them, reorder them, move them to another parent or delete them, and changing the template later does not affect projects already created. You can also create your own templates. (Creating a project, Master data and catalogues)
• Automatic, stable codes (F001, T0004…) to find each phase and task when talking, and to ask the assistant about them.
• Progress and hours per phase, sub-phases included, and the calendar of the phases in the planning tab. (Planning and Gantt)
• Two views of the same plan: a list of phases with their tasks and a Kanban board by status. (Kanban or Gantt: when to use each)

Only the project's owning PM creates, moves and deletes phases; the rest of the team sees them read-only depending on their role, and a consultant sees only the tasks assigned to them. Deleting a phase also deletes its sub-phases and tasks, with the logged hours, so move anything you want to keep first.

Create your account or explore the demo.

Frequently asked questions

How many phases should a project have? There is no correct number. Between four and eight top-level phases is usual; what matters is that each has a recognisable result.

Can I change the structure while the project is running? Yes, and it is normal. Move tasks and phases when the scope changes, and record significant changes as change requests so you can justify them.

Phase or task? If it gets done and finished, it is a task. If it groups work that other people will do, it is a phase or a sub-phase.