In a meeting or a series of meetings, where you have all important experts and your (core) team members present, you start identifying all items that should be part of your project to deliver your main or end deliverable. This also includes 'management deliverables' such as documents you use for project control. Think of documents like a Project Initiation Document, communication plan, risk register, etcetera. This breakdown of a product is called the PBS (Product Breakdown Structure).
If, for instance you consider the example of a motorcycle, the main deliverable 'engine' is further subdivided into: Transmission, Head, Battery. Head is further subdivided into Pistons and Rings. Note that you could keep doing this up to the bolts and screws level, and thereby easily overdo this breaking down.
WBS (Work Breakdown Structure)
For planning and estimatingpurposes it is wise to stop at a certain point, and start mentioning the work (tasks) that is needed to produce these elements of the PBS. This is where your WBS (Work Breakdown Structure) starts. Since you are creating a model, just as a maquette as model for a building, it should not be too detailed. For various reasons it is widely recommended to stop listing the work, when the activities have a duration of 5 days. For instance, if your project is remodeling the backyard, 'build shed' is the right level of detail, and 'pick up screwdriver' is not. Although you might not want to forget this crucial activity of picking up the screwdriver, your schedule should not resort into a checklist or manual (you will learn more about estimating in our course Task Management).
This breakdown of the main deliverable forms the backbone of your project plan and as such it is essential to give this process the proper attention. For this reason, it was our well-considered choice to explain linking and automating the schedule in our online training about Critical Path Management (Intermediate course).
"I cannot read the Gantt Charts"
"My manager cannot read Gantt Charts" is a remark we hear quite often. We think that this manager is just not able to read this particular Gantt Chart. Since scheduling is about modeling, one of its primary purposes is being a communication means. Think of this before you start randomly typing in the products and tasks.
The correct order in your schedule
When you start planning, pay good attention to the order in which you enter the PBS elements into the plan. Ideally this is a chronological order with the first to be delivered PBS elements located higher in the schedule and the last to be delivered PBS elements lower in the schedule. This way your schedule will look like a waterfall and enhances readability drastically.
Correct naming
This is a good example:
The work breakdown structure (WBS) consists of all the activities that are needed to be able to deliver a PBS element. Whereas the PBS element is logically a summary task, the activities leading up to the delivery of this PBS element are the tasks beneath (indent/outdent) this summary task, and have a naming convention (e.g. level building site).
With this structure all activities' effort/cost/etc. will be summarized on the summary task, which makes progress tracking and learning from estimates per PBS-element extremely convenient.
The video clip below shows how to create summary tasks with underlying tasks:
Everything well structured
The purpose of this step is to create a complete overview of all needed activities to complete the deliverables within your scope. This will result in a schedule like the example below:
PBS & WBS best practices
There are several PBS and WBS best practices that we want to share with you in this course. We have translated them into a 'hands-on' list of do's and don'ts.
Do's:
Summary tasks are ideal for ‘phases’.
Make sure that 100% of the PBS elements defined in the project scope is represented in your PBS.
Make sure that 100% of the work defined in the project scope is represented in your WBS.
Each PBS element, regardless of level, should answer to the following question: ‘what needs to be delivered before we can call the project a success?’
Be specific in naming the elements (example: unit test vs perform unit test for module XYZ).
Each PBS/work element should be unique and the meaning can be interpreted without viewing the context by each team member.
Don'ts:
‘Miscellaneous’ is not a PBS element.
The PBS/WBS should not contain elements that are out of scope, such as external activities or the work of an external supplier outside the scope.
As summary tasks are not real activities which need to be performed, it is very important to ensure that summary tasks NEVER:
Have resources assigned
Have links
Are used to track progress (do this in the tasks)
Do you have more?
Which DO's and DON'Ts would you add to the list above?
Share them in the comments below.
If, for instance you consider the example of a motorcycle, the main deliverable 'engine' is further subdivided into: Transmission, Head, Battery. Head is further subdivided into Pistons and Rings. Note that you could keep doing this up to the bolts and screws level, and thereby easily overdo this breaking down.
