Project planning using Work Breakdown Structure

    Written by HarmonyPSA on 2017-05-25 Last updated 2018-06-27 - 3 minute read

This post deals with a concept called the Work Breakdown Structure (WBS) a way of logically and hierarchically decomposing a project to help plan, manage and control delivery.

The first message is that a WBS is not a random sub-division. Each level of the hierarchy matters, it has a role to perform and this should be maintained both in the plan and also during reporting cycles.

The second message is that a WBS is also applicable to Agile development projects, though I guess many Agile purists may dispute this.

Traditionally, WBS are rendered in a tree view, though in its most complete form, it should also apply to the project organisation chart and of course also the budget. In this way it allows for a clear responsibility sub-division.

Either way, a WBS allows progress and expenditure to roll-up from the lowest tracked level of output (and the quality processes and controls) to the total endeavour in a way that each level presents a consistent and rational slice through the project. So, applying WBS thinking is a major advantage to organisations seeking ISO 9000/9001 accreditation.

For very large projects, the number of levels may be greater, but the 5-level model described below is a good working one that is useful from small projects in the 10s of man-days up to a few 1000; typical sizes for development projects.

The conventional names, level designations and purposes are:

Level 0        Project; simply the entire work being undertaken

Level 1        Organisation; a Level 1 Gantt is sometimes referred to as a summary Gantt, however, its purpose is to show involvement, productivity and progress by team, discipline or phase, not dependencies.

Level 2        Task; below organisation we have task, meaning the level at which dependencies are tracked and the level that can generate a Dependency Gantt and PERT (Project Evaluation and Review Technique) diagram. The skill of a planning engineer would be to ensure that all dependencies are modelled at a single WBS level, not cross level. In Agile methodologies, a Sprint is likely to be modelled as a Level 2 task. In very large projects, sub-tasks are used to increase the visibility of task internal dependencies and cross task dependencies, however, always resist the temptation to plan dependencies across levels, packing the plan with summary tasks if necessary.

Level 3        Deliverable; tasks (and sub-tasks) are decomposed into deliverables (just as a Sprint decomposes into features). Typically deliverables within a single task should be of the same class as this enables simple progress comparisons and revised estimating based on measured deliverable productivity.

Level 4        Process; the way a deliverable is constructed, checked and approved is sometimes called the deliverable process cycle and stages in this process cycle can be mapped to standard % complete milestones (or limits) to help control over-reporting. A common failing in software development plans is to place the process cycle on the level 2 task plan. In fact, as this is repeatable and “unit of deliverable” based, it is normally a waste of time to draw the plan for it.

When looking at PSA tools and the manner in which they are structured, consider these definitions and question how they are modelled, in particular where quality management accreditation is one of the reasons to purchase a PSA. Many PSA tools fall down on the project planning side and over-simplify a clear WBS model into a multi-level task structure. While this may work in some cases, this lack of structure and level clarity will hamper project control and reporting once the project gets beyond a few days endeavour. In particular, check that a repeatable deliverable process cycle can be modelled or ISO accreditation will be even harder to achieve.

This structure was designed in the early 60s to enforce planning rules and support clear project control, decades before PRINCE2. Correctly implemented, it provides nowhere to hide and so supports and directs accountability while simultaneously enforcing quality standards.


About the Author: Harmony Business Systems Ltd (HBS) is the company behind HarmonyPSA, the most complete cloud PSA software on the market. Developed with functionality to cater for even the most complex needs of MSPs, VARs, ISVs and Professional Services organisations, HarmonyPSA truly is the next generation of PSA systems. HBS is an independent company based in the UK. Follow HarmonyPSA on , LinkedIn or Website

Tags: budget breakdown, Business, ISV, organisation and accountability, project control, project planning, Software Business, WBS


Recent posts

Subscribe to our blog