How Are the Work Breakdown Structures and Change Control Connected?

How Are the Work Breakdown Structures and Change Control Connected?
Page content

Work Breakdown Structures and Change Control?

How are work breakdown structures and change control connected? When you think about it, these are two seemingly unconnected things. However, work breakdown structures do connect to change control in many different ways. A project’s WBS demonstrates the breakdown of all work items and how these work items relate to one another.

Change control ensures that the project is executed in the manner it is planned to be executed in. The intersection of the work breakdown structure with change control lies in the fact that any changes that must be made to the work breakdown structure then become change control projects. Any time the WBS is changed, the project’s deliverables and the project’s scope are changed.

Work Breakdown Structures Should Be Immutable?

You may have dropped your jaw a little bit when you read that last sentence “Any time the WBS is changed, the project’s deliverables and the project’s scope are changed.” Step back and think about it, though. The work breakdown structure is the skeleton of your project. Even if you think all that’s being changed is a small point, that change can ripple out and affect other components of your project.

One of the reasons you should avoid touching your WBS—and if you do touch your WBS, it requires change control—is that your WBS helps you to properly define and delineate the scope of your project. When you create a proper WBS, every element of the work associated for the project has been defined through decomposition and numbering. If you change even one item on the WBS, then you are changing the scope of the project. This is especially so if there are many task dependencies in your project.

A second reason that your WBS shouldn’t be touched unless absolutely necessary is that many aspects of your project depend upon the WBS remaining immutable. Resource allocation, budgeting, and risk management all ride on a properly broken down project. If you change something, no matter how small it seems, you could wind up creating greater costs, needing a different resource, or worse—project failure due to a risk associated with the change.

Finally, your WBS serves as a part of change control. You can easily determine whether your project is getting off course by looking at the WBS to determine whether elements that are being implemented are in fact on the list. If changes occur, it is vital to see how they impact the rest of the WBS and the project scope. Failure to do so can result in confusion or scope creep.

Implementing Change Control Using Your WBS as a Guide

Any time you need to make a change to the WBS, you should treat the change as a change control project. There are three ways that the change to the WBS can impact your project. These are:

  • Changing the scope,
  • Changing the schedule, and
  • Changing the budget.

Whenever you implement a change into your WBS, it is important that you also ensure that you check the scope, schedule, and budget of your project. Any requests for change to the WBS need to go through a formal submittal and approval process; individual team members should not take it upon themselves to implement changes. The project manager and relevant stakeholders should review the proposed request, take into account potential for scope, schedule, or budget change, and approve or deny the request as needed.

If the change to the WBS will wreak havoc upon any of these three facets of project management, or if it will impact deliverables or task dependencies, then it should be denied. Finally, if the change is required and inevitable, and it has a large impact, then a new project charter should be drawn up with the adjustments made accordingly. Take care to review the project as a whole, not just the immediately impacted items in order to avoid unwanted consequences.