“He who fails to plan – plans to fail”
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 nails 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 which defines how the project will be executed, monitored and controlled. The project team should use this as a blueprint to broadly guide the project. Project plans are 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 (WBS)
I have been asked by clients in the past to develop a WBS, however, I learned what they really wanted was a project schedule. They are 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 does not 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 just 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-is-happening-when, and how long the project will take. It is 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 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 assigns project team members to each task. This becomes an invaluable check-list to help keep things on track.
Project schedules are often created using project management software tools such as Microsoft Project, Open Workbench or Primavera.
Cardinal's PMP® Project Managers can help you bring smarter solutions and best practices to your projects. Learn how you can get started!