I am trying to understand the concepts between Product Based Planning and Work Based Planning and if there is a right way or a wrong way to plan.

I understand that Product Based Planning is done by listing the products, using nouns as the summary descriptions in a project plan and that Work Based Planning is done by using named phases like start-up, implementation or stages, using verbs as summary descriptions in a project plan.

I work in an organisation that utilises the Prince2 methodology, however I see more WBS plans or a hybrid of both WBS and PBS than I do see plans solely based on PBS.

I would be interested in reading the views of project professionals on this subject:

- is there a right or wrong way to planning i.e. is it just personal preference?

- are there projects where either PBS or WBS would only apply?

- can you use a hybrid of both?

Thank you for reading and I look forward to your views.

Regards, Pauline.


Simon Springate


WBS should represent 'WORK', start-up, implementation are stages or lifecycles and arguably have no place in a WBS.  For me the WBS has to be a list of the work packages you expect individuals to manage

PBS are distinct products tat will be produced, it can look a lot like the WBS but does not have to relate to who is managing the work

There is no reason not to have both on a project and many advantages if use both. 

At the end of the day the WBS and PBS are just more database reference points that can be used to break your schedule into manageable slices for updating, analysis or reporting




As Simon stated PBS = Product (delivered to the customer), WBS = all the work. The WBS though is still a ‘deliverables oriented breakdown of the project’.

In the past my feeling was the WBS simply extended the PBS to include all work such as managing the project (ie, 100% of the authorised budget).

More recently I’ve seen arguments the ‘product’ includes internal deliverables such as the schedule.  If this latter view becomes generally adopted there is no difference.

Grant Smith


It has always been my view that the WBS was simply an extension of the PBS. The PBS is produced first and outlines all the Project Deliverables and this should include all the Management Products such as the Schedule etc as already mentioned. Once all the Products have been identified on the PBS then the activities required to deliver each Product are identified and form the WBS. Each of the activities on the WBS becomes a discrete Work Package that can then be assigned out for production. Work Packages are often the drivers for EVM I believe although I have not yet had the opportunity to pursue that technique.

Regarding how these are displyed on the plan/schedule very much depends on the project and approach but typically I would expect to see the PBS/WBS structure mirrored with products being the high level milestones/rollups and work packages being the tasks (to varying levels of detail as required)


Neil Curtis

In my experience (aerospace & defence/systems engineering), to plan a project properly, you need to define both the products/deliverables and the work necessary to realise them.

During planning, define the products/deliverables (the "scope of supply") using a PBS, with the "system" to be delivered at level 1, "subsystems" at level 2 and so on. The PBS is populated with nouns. Each item in the PBS can usefully be tagged with its attributes, such as whether it will be made (in house) or bought (procured), and, for bought items, the supplier.

Also, define what work must be done to realise the scope of supply. Each item in the PBS must be designed, built, integrated, tested, qualified and handed over to its users, with some of these activities probably being undertaken by suppliers. The work necessary to realise the scope of supply is the core work of the project; management work will also be necessary. Define the scope of work using a WBS, with the project at level 1. Optimising the WBS involves many considerations, including the logical stages of the project, the product realisation processes being used and the project organisation (including suppliers). The WBS and the project organisation (defined in an organisation breakdown structure) should be such that the responsibility assignment matrix (WBS v. OBS) is straightforward. For multi-stage projects, I do use project stages at level 2 of the WBS, e.g. design & development, production, initial support. At the lowest formal level of the WBS are the work packages; at the level above this are the control accounts, which are logical groups of work packages assigned to an individual control account manager. Within the work packages are activities, described by verbs and nouns (e.g. "write test specification"); work packages have suitably descriptive names such as "system integration and testing".

The WBS goes in the schedule, where network logic, activity durations and resources are assigned. I recommend putting in the schedule only the WBS, milestones and external dependencies.

The planning process is highly iterative, for example being optimised with regard to identified risks. The outcome should be a well-planned project with, among other things, a properly defined scope of supply (defined by the PBS), a properly defined scope of work (defined by the WBS), an appropriate organisation breakdown structure and a straightforward responsibility assignment matrix.

Hope this helps!


Matt Whyndham

It's certainly not personal preference, but it depends on how you want to manage.  In my view, the same scope of work can be represented in many configurations of the WBS, and they are all mathematically equivalent but may be radically different as management tools.

I think another commenter here has said that responsibility for the packages is an important dimension.  Given a workpackage, can it be the basis of a contract?  If the contract would refer to items scattered all over the WBS, then it's probably more convenient to re-organise it.  I personally don't see anything wrong in aligning project phases and workpackages (indeed, resources are often committed for a given phase, so it makes some sense), but it shouldn't be the starting point.

There may not be a perfect answer, and you may be driven away from perfection by what other stakeholders' habits are (typically customers, programme managers, resource groups and suppliers).  The test of effectiveness should be used : does this way assist the management of the work better than the other way?

I also strongly prefer WBS organisation methods that are the same across the entire WBS, but sometimes this isn't possible either.

In any case, the PBS and WBS should be traceable from one to the other with ease.


Matt raised the comment "In any case, the PBS and WBS should be traceable from one to the other with ease.", which in my view is a key value.  In those early planning phases have you got PBS items without a corresponding WBS entry ?  Then perhaps there is work missing.  Have you got WBS activity without a PBS entry (at a similar hierarchical level) - perhaps you are doing something which is not needed.  This cross check can be part of the project quality control.  When I first started with projects, in ICT design, we were always hammered time and time again - start with the output and design backwards, so first understand WHAT the customer wants, then understand WHY, then work out HOW to do it, which should give you some WHEN it will be done by and WHO you will need - apologies to Kipling



You have clearly received lots of good advice here and for what its worth this is my take:

The PBS is a hierarchy of deliverables that are required to be produced and forms the basis from which a WBS can be derived. The WBS therefore defines how the project is put together and what it is making i.e. how are you going to do the job and can therefore be quite different to the PBS.



The WBS Dictionary should be at the centre of any planning you undertake. I have observed that one of main problems with the way in which project teams create schedules is a failure to involve those doing the work at the planning stage. A good WBS Dictionary will include information fields for Products or Work Packages. In my view the terminology is interchangeable primarily in the early planning stages when teams are trying to scope out a project and information or their thinking is not mature enough to help them dissect individual 'doing tasks' to support the completion of each product. Technically a PBS will create a Product Flow Diagram which is similar to a precedence network and with some additional work the results can be entered onto a Gantt chart. The network will change somewhat when teams begin to start adding the doing tasks into it but experience tells me that if the logic is sound then this baseline won’t change too much unless you add in or remove products. I can email you a WBS dictionary template if you think it will help you out.

Hi Pauline - I see you have had a number of comments relating to the concepts of WBS v PBS.

I have done a bit of research on this and, as usual in the field of project management, I have found there is no universal agreement on a meaning for these concepts.  Those involved in project management in different sectors continue to use labels like Work Breakdown Structure which in one place means one thing and in another something completely different.  Often WBS in one organisation would be viewed as a PBS in another.  At the end of the day it's no big deal comared to the question - have we used a sensible approach to create a picture of the project we are planning to do which will allow us to track things?

This inconsistency, while there appears to be a percetion that there is a set standard, continues to be one the major problems in building project management competency which, so far and sadly, I see little evidence of being tackled systematically.  This lack of consistency is one factor in my opinion which causes the profession to risk being seen as niche and causing more problemns than soving them.

Anyway with regards to your specific questions - the approach I have developed to differentiate product breakdown structures from work breakdown structures lies in the words "work" & "product".   If you like a WBS is an organised To Do List while a PBS is an organised Shopping List.

These are just two ways of thinking about a project which are aimed at the same thing - working out what needs to be delivered.  One approach focuses on tracking action while the other focuses on outputs.  There will always be a direct corollation between the two as we do the actions to achieve the outputs.  Some projects lend themselves more to one approach than the other, many benefit from both.  These are just two tools in your toolbox and experience of their use eventually mean you get a feel when to get them out and apply them to the project you are facing.

In relation to WBS I use the concept of "milestones" ie points in a project when groupings of tasks are completed.

Statements formed around milestones and task must include verbs.  In the case of milestones these will be in the past tense eg X completed, Y sent, Z delivered.  In the case of tasks and sub-tasks verbs will be in the present tense eg book venue, write presentation, lay foundations, obtain planning permission.

The project is then broken down using milestones as a key point and  tasks, sub-tasks (and broken down sub-sub-tasks, sub-sub-sub-tasks as many levels as make sense).

When it comes to the PBS approach I am then using nouns starting with an identification of the final product eg Kitchen Extension.

I then use the question -  What is that product made up of?  - to start me on breaking the project down.  The disciplne is in sticking with products and product groups ie all nouns no verbs eg Planning Certificate, Kitchen Appliances, Kitchen Units, Foundations, Internal Walls, External Walls, Bricks.  The approach leads to a the construction of a diagram as you know which flows as follows The Final Product - Product Groups - Intemediate Products - Simple Products.  from the base of the diagram we are then saying I need to buy/procure these things (simple products) in order to use them to first make this thing  (intermediate products), sets of intermediat products are then brought together to complete product groups and once all the product groups are in place we have the final product ready for the Client.

To a degree as said in previous the WBS is an extension of the PBS because work has to be done to get the simple products (procurement) and then people have to do things with simple products to form intemediate products and intemediate product to complete product groups, etc.

I find the PBS from a project managers perspective to be all need when I want to empower my team to get on with doing work and am not bothered about tracking the length of time it takes them to do individual tasks - I just want the the product/s when I want them.

The PBS is also useful for reporting to the Client - at the end of the day they want to know what products they have ready and when they will get the rest.  they are not really interested in who is doing what tasks.  Milestones however from a WBS provide a similar function.

I wouldn't worry about using one or other or a hybrid and concentrate on using something that works and puts you in a position to sensible track and control both who is doing what and that outputs are delivered when you expect them to be.

Remember neither the WBS or PBS are intended to be sequenced or time constrained diagrams for that you need to move onto Product/Work Flow Diagrams (PFD, WFD).  Unfortunatey the way the human brain works means we tend to jump ahead and try to do several things at the same time which means we can end up with diagrams that are hybrids of WBS/PBS/WFD/PFD - but hey if it works!!!!!!

Finally you may also want to consider - Organisational Breakdown Structures (OBS), Cost Breakdown Structures (CBS), Resource Breakdown Structures (RBS), Risk Breakdown Structures (also RBS!!) which I found refered to in an article on http://toostep.com/insight/article---break-down-structures---wbs-obs-rbs-pbs-cbs-an-ove  No wonder we get confused!!!!!!

Hope this is of some help - though I am still confused!!








Omoruyi Elaho

Thank you for the light you shared on WBS and PBS, because I almost got confused about both  seeing that they focus on the same phases but with variations of depth.

Laura Taylor

Hi all,

Thanks for your contributions on this topic! The discussion so far has been summarised in a web briefing which looks at the following:

  • What is a Product Breakdown Structure?
  • What is a Work Breakdown structure
  • Tests for correctness - PBS / WBS
  • Use in running the project - PBS / WBS
  • Conclusion

Download the web briefing here

Web briefings are developed from the APM Community, resulting from discussions and questions asked, the content is developed from users’ responses and edited by APM.

Web briefings are constantly evolving and we look to the community to develop and improve them, therefore, please contribute to this discussion to create some valuable collaborative advice for your peers.

Beth May

The Web briefing is useful for understanding the use of PBS and WBS (and other similar breakdown structures).  However, the sample PBS provided in the Web briefing is less than ideal.  First, the specific names of the elements in the sample PBS aren't strictly in accordance with the intent of a PBS.  As an alternative to the top-level elements "Software Installed", "Software Tested", "Training Delivered", "Software Delivered to Users" (all of which sound more suitable for describing work activities), consider the PRODUCTS: "Installed Software", "Tested Software", "Trained Users", and "Deployed Software".  Also, while the sample PBS includes at the top level "Project Initiation Document", it doesn't include any other management documents, which seems out of balance.  Perhaps two products should be at the top: one that includes (and visually decomposes into) the interim deliverables (including the Project Initiation Document and other management documents) and one that includes (and visually decomposes into) the final user-facing deliverables (including training, manuals, etc.).

Another problem with the sample PBS is that the install disk is shown under "Software Delivered to Users" and not under "Software Installed" -- is the software initially installed (for testing) from an external server (which isn't shown), or from a disk (which isn't shown)? Perhaps the external product "Third Party Software" decomposes into sub-components that include: the install disk, license, and manuals (if not also training material), which should be shown.

Finally, the Web briefing makes the statement "There is no direct relationship between the structures of the WBS and the PBS" which is a little misleading. While the structure itself for each is in fact different, there should be a mapping between the WBS elements and PBS elements: as pointed out by Oldloggie and Matt Whyndham in the discussion above, if you have a PBS item with no corresponding WBS items, then there may be work missing from the WBS, and if you have a WBS item with no corresponding PBS items, then you may be doing work that is not needed, or your PBS may be incomplete.  The Web briefing does make this point later, which is good: "Products can be represented on the project plan as milestones and linked to the outputs of their associated work-packages. Whatever technique is used there needs to be traceability between the two."