Project Plan vs. WBS vs. Project Schedule
“He who fails to plan is planning to fail.” — Winston Churchill
I often hear people use project plan, Work Breakdown Structure (WBS) and project schedule interchangeably. However, each serves a different purpose, and each plays an important role in successfully getting a project to the "end zone." The project plan serves as the master blueprint, whereas the WBS and project schedule nail down the details of specific tasks within the project plan.
Let’s dig deeper into the purpose of these artifacts and their differences.
A project plan is a formal approved document that defines how the project will be executed, monitored and controlled. The project team should use this as a blueprint to broadly guide the project. A project plan is often a document created with a word processing tool.
Think of it as the culmination of all of the planning efforts compiled into a single document. Pull together all of the materials that describe what the project is about, how it will be conducted, what it will deliver, when it will take place, what it will cost and who will be involved. The content of the project plan should contain/describe the following:
- Introduction and summary
- Goals and objectives
- Problem statement and quantified business benefits
- Current state and future state
- Scope (in and out)
- Major milestones and their timelines
- Project tasks and products
- Tools and techniques to be employed
- Communication management
- Project organization, key roles
- Resource plan
- Cost plan
- Project budget
- Project risks, assumptions and dependencies
- Project standards and definitions
- Project risk management approach
- Issue management approach
- Change control procedures
- Downstream impact and considerations
- Configuration management procedures
- Quality management plan
- Detailed descriptions of tools, technology, techniques used
Work breakdown structure
I've been asked by clients in the past to develop a WBS, but I learned what they really wanted was a project schedule. They're not one and the same.
A WBS is a logical decomposition (breaking into smaller pieces) and hierarchal representation of work needed to execute a project. This decomposition of work is called a "work package." The level of decomposition is based on the extent to which the project will need to be managed. If additional visibility into the progress is needed, additional decomposition is recommended.
A WBS doesn't have a time component, predecessors or dependencies. So why bother creating a WBS when you can create a project schedule instead? By developing a WBS, one can focus on the deliverables and nothing but the deliverables. It allows an uncluttered focus on the work that often gets lost in a project schedule whose focus is time and dependencies.
The project schedule is one of my favorite tools because it really gives a clear view of what's happening when, as well as how long the project will take. It's the tool that communicates the work that needs to be performed, the resources performing the work and the time frame in which that work needs to be performed. It lists all of the tasks to complete the project and shows the dependencies between each task. Its main purpose is to show the timeline, including start and end dates for each task, and assign project team members to each task. This becomes an invaluable checklist to help keep things on track.
Project schedules are often created using project management software tools such as Microsoft Project, Open Workbench or Primavera.