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.