When people think about project management tools, the tool that most frequently springs to mind is the project schedule, usually created using Microsoft Project. The project schedule normally comprises a colorful Gantt chart showing a visual representation of project tasks over time. But before project managers start work on the formal project schedule, there is another important tool that should be completed and verified… the project Work Breakdown Structure, or WBS.
What is a Work Breakdown Structure (WBS)?
A Work Breakdown Structure is a document that illustrates the work involved in a project, and shows how that work relates to other work on the project. By viewing a WBS, project stakeholders can visualize and understand the individual work packages that must be completed in order to finish the project and achieve project closure. These packages comprise the totality of the project scope.
The Work Breakdown Structure is important to complete before starting work on the project schedule because it is critical that project managers understand the work involved with a project before attempting to schedule it. A WBS helps project managers and project team members break down the work into estimable tasks. Once those tasks are subsequently understood and estimated properly by members of the project team (the people who will be doing the work), work on the project schedule can begin in earnest. It is a frequent mistake for project managers to jump into project scheduling without first achieving a proper understanding of the project work. This usually leads to scope creep and inflation of the project budget down the line.
The WBS on the PMP exam
The Project Management Institute (PMI) likes the WBS to take the form of a graphical representation, with a flowchart-like display of boxes containing the various work packages to be completed in a project. The boxes at the top of the chart contain the higher-level work to be completed; below these boxes the work is broken down into the individual work packages. These work packages are broken down to a level of granularity where project work packages can be properly understood and estimated. It is this format of WBS that project managers will find if they choose to become Project Management Professional (PMP) certified by taking the PMP exam.
A spreadsheet-based WBS
While I appreciate PMI’s version of the WBS, I find I need to gather and understand more information about a project before I start work on the project schedule. It is for this reason that I often employ a spreadsheet-based WBS for the projects that I manage. The same information you would find on the graphical WBS can also be found on the spreadsheet version, but on a spreadsheet you also have the option of adding more information relevant to the project resources, time, and cost. This spreadsheet-based WBS can accompany a graphical WBS for maximum effect; however, you might also choose to stick with one version or the other if you don’t want to have to edit two separate documents if the project scope happens to change once the project is underway.
Creating the WBS
Creating the WBS will require work by the project manager, project stakeholders including client representatives, and members of the project team. The goal is to break down the work on the project into estimable chunks, or work packages. I find I like to be more granular rather than less granular when it comes to breaking the project into chunks, because more granularity makes project team members (for example, the software developers or business consultants who will be doing the actual work on the project) think more carefully about how long it will take to complete individual tasks. I, and most other project managers, find that work is most frequently underestimated rather than overestimated, and as such projects frequently face time crunches. By working with smaller-sized work packages, the risk of this can be mitigated.
Once these work packages are created, information about each package should be gathered. For my own WBS spreadsheet, this information includes:
- Project task: what the project task is, and the work it comprises.
- Time estimates: the time it will take for a developer or business consultant to complete the task. Testing may or may not be included.
- Resource constraints: what type of resource can do the work. I like to indicate a minimum level of competency for this task. For example, some tasks can be completed by a junior developer… someone straight out of college or new to the company. Other tasks will require a senior developer or a practiced systems architect to handle. By indicating the minimum level of skill required to take on a task, you can assign resources depending on your project team, and can also take into account changes to the project roster should they occur in the future.
- Resources: which resource or resources will do the work. This takes into account who is currently on the project team. This field may change in the future, which is why it is important to also know your resource constraints. Should your resource change in the future, you will be able to pick a new resource based on skill level found in the resource constraints. Remember to consult your project team before assigning work. I like to discuss upcoming project tasks with the team members who will eventually be completing them before finalizing an official WBS or project schedule.
- Project area: the high level box you would find on a graphical WBS. For example, infrastructure, or the name of the component or module the task belongs to.
- Predecessors: what work needs to be completed before work on this specific task can begin.
- Critical path: whether this work is or is not on the project’s critical path, meaning that if this task slips, the entire project runs a risk of slipping.
- Priority: it is handy to know what parts of a project are of greater priority than others. If changes need to be made to scope down the line, it is good to know which parts of the project are most likely to be pushed.
- Client involvement: to what degree will the client be involved with the task? This may require some added scope or time management, and these tasks may also be harder to move in the future should changes to the project schedule occur due to client resource constraints.
- Cost: I’ve left this last, but for most stakeholders, this is the most important information… how much is the project going to cost? Once you know what resources will be completing the project tasks and how long it will take them to complete these tasks, you can find out how much that individual task will cost (cost per day * days per task). With a completed WBS, you can add up the costs of the individual tasks to find the total cost for all of the tasks in the project. That plus any additional overhead will be the cost of the project, at least from a work perspective. You can also find a way to work any materials costs or other costs into the WBS if you choose.
Remember to make sure that your WBS comprises the entirety of the project scope according to the project plan. Anything that is not found in this WBS should be treated as scope creep once the project is underway.
Benefits of a comprehensive WBS
Once I’ve created my WBS spreadsheet, I receive two important benefits. The first is that I give myself a comprehensive view of the project. All of the important information (for the project manager or project directors, at least) about project tasks, resources, time estimates, and costs according to the project budget can be found in a single document. The second is that if you do this work right, another project manager can take your document and create a schedule out of it. Even with no knowledge of the project, another project manager should be able to step in and create a project schedule for your project, because your spreadsheet-based WBS has all the information needed about resources, predecessors, and the critical path to be able to create at least an initial schedule.
Using a resource modifier
As you become a more experienced project manager, you will start to notice some important things about your projects that most stakeholders don’t seem to think about. One of the most important things you will learn is that all resources are not created equal. Some people can complete tasks very quickly, and with great quality. Others are not as quick to complete tasks, need extra time to go over the work they’ve done once they’ve finished it, or need to be allocated more time to learn how to complete tasks as they work on them.
This is important because when you create a project schedule, you can’t simply swap out resources and expect the same result. For example, if you create a task for one of your senior architects to complete in five days, and during the project you find out that because that architect is going on maternity leave you have been assigned a new consultant from a different consulting company who does not have experience with your project, you can’t expect the new consultant to also be able to complete that task in five days! It might happen… but it likely won’t.
It is for this reason that I like to add modifiers to my resources. These modifiers take into account whether a project team member is quick, average, or slow, or if the team member is being mentored on the job or learning to complete tasks as they go. In this manner, when you assign a team member to a task, that modifier is taken into account… so for some people, a five day task may become a seven day task. You should also add a field that indicates whether or not you choose to use the modifier for that task, as some tasks will take a certain fixed amount of time to complete regardless of skill level.
Using modifiers like this can also help you to run scenarios on possible project team configurations. You can switch resources around and see if your changes will cause the project to take longer to complete or inflate the project budget.
Using the WBS on your project
Once the WBS is completed you can use it to complete the project schedule. You will have a tremendous understanding of the project scope, the tasks to be completed, and who can best complete them. You will know how long it will take to finish the project and how much it will cost. Furthermore, once the WBS is created, the project manager will no longer need to ask project team members for information about project tasks or how long they will take to complete… that information will be available to the project manager on the WBS so that the project manager can make decisions based on schedule and schedule impacts while leaving the project team members to themselves to complete their tasks. No project team member wants a project manager constantly hounding them with questions about the schedule while they’re being held to a deadline to finish their tasks. This is not to say that you shouldn’t ask project team members important questions when they arise; however, if you can, find out all this information before the actual project work begins so that you can minimize the amount of time you require from your project team members for administrative tasks.
As changes occur to the project scope, you can indicate these changes on the WBS, and work with the time estimates and available resources to see what impacts these changes will have. These changes can then be moved over to the project schedule. It is important to keep your WBS updated throughout the project; be sure to keep previous versions of the WBS handy so that you can look back and see how changes have impacted the project over time.
I hope that this has been a helpful introduction to Work Breakdown Structures. If you are a project manager with your own views to share about Work Breakdown Structures, I’d be happy to hear them, even if they contradict with my own views. It is by sharing our views and discussing our own experiences that we can learn and grow as professionals. Be sure to leave any questions or comments below. I appreciate it!