Speaker1: Now, in projects, we typically have two breakdown structures. Once we understand the customer's requirements, we look at providing products that will meet those requirements and the first type of breakdown structure is a product-breakdown structure. It can be in a diagram form, typically is, but could also be a list of components, it's like a shopping list. What products do we need to produce so we meet the customer's requirements? And, once we've got that list, we understand what we're producing, we can go onto a work-breakdown structure, which is still hierarchical in nature, just like the product-breakdown structure is, but it will also apply the activities to those products and show us not only what we're producing, but the work packages required to produce them. So, typically, when would we require a product-breakdown structure?

Jo: We need it right from the very beginning, because I, I favour the diagram type product-breakdown structure, and we need it right from the get-go in concept, because it helps us define the scope, it shows us what's included and what's excluded from the-, from the project. So, I built a house a few years ago, my total knowledge of house construction was taken from Grand Designs, so I didn't really know what I was doing. So, in the concept phase, the first thing I did was I, I created a very simple breakdown structure. So, I had 'Built House' at the top, because it's a product, I then thought about, 'Well, what, what do we need to do?' Well, we know there's, like, a, a pre-build work, so there'd be design, that'd be one group. There will be the build itself, so that'd be another group, and then there will be the, sort of, interior design, and the interior work, that'd be another group. Underneath design, we'd put in things like building regulations. Now, building regulations is a product, and we do need it, but it's not something that we will be writing as part of the project, so therefore it's external, so it went in as an external product under the design. We put in appointed architect and obviously drawings as products. In the build, I just put foundation, structure, HVAC which is the heating and ventilation system, and the roof. And what I did in concept is when I spoke to the architect, I showed her what I had, and I said, 'This is what I think I'm looking at,' and she added to it, and so I started to understand the scope a lot more from this picture, this hierarchical picture, of all the products. Give me a bulleted list and I find it very hard to grasp the concept of what I'm looking at and actually to identify what's missing. When we then went into the definition phase, and we had the build contractor on board, he added an awful lot more to that breakdown structure, so now I've got a really good picture of the scope of, of the project.

Speaker1: And why would we then need a work-breakdown structure?

Jo: Well, because as, as the name suggests, product breakdown is all about the products. What we can do then is, for example, take the foundation from the product-breakdown structure, that's our final product, and underneath it put all of the activities, and with those activities we can parcel them up into work packages. So, it's quite easy to start with products, then identify what we're going to do to produce that product.

Speaker1: So, to sum up, we have two breakdown structures, a product-breakdown structure, which just shows the deliverables, the products that need to be produced to meet the customer's requirements, what will be produced by the project in scope, what is required but being produced outside for the project, external products, out of scope. It's a hierarchical breakdown, but it just shows us the deliverables. We then lead onto a work-breakdown structure, where the activities are added to show how we're going to produce those deliverables that leads us to showing each work package that needs to be executed in order to produce the deliverables that's needed for the project.

Jo: Exactly, yeah.

Typical breakdown structures

About