What You Should Know about Scope Creep versus Scope Change for the PMP Certification Exam
For the PMP Certification Exam, you should know that the difference between scope creep and scope change is addressing the impact of the scope change on the schedule, cost, and other aspects of the project.
Start by looking at some of the common causes of scope changes:
External event: Changes in the competitive environment or a new regulation can cause the team or the customer to reconsider the product scope.
Error in defining product scope: If a requirement was left out in defining the scope originally, the scope will have to be changed to include the new requirement.
Error in defining project scope: An error in defining the project scope, such as needed to employ specific procedures or processes, could entail changing the project scope.
Value-adding change: Sometimes a team member finds a better way of accomplishing the work or determines how to improve quality by doing things differently.
Implementing a contingency plan or workaround: If a risk event occurs and you need to take actions to respond to it, the actions could cause a change to either the project or product scope.
Customer sees the product and wants changes: Some product development projects employ a life cycle that allows for iterative development as the customer and end users see interim deliverables. This is still a scope change, but the project team is planning for the design and the deliverables to evolve with each iteration.
Here’s how each of these types of changes could be applied to the childcare center.
External event: There are new regulations regarding water pressure and flow rate.
Error in defining the product: The architect didn’t lay out the HVAC system correctly to match the floor plan.
Error in defining the project: The project manager didn’t include the contractor in the weekly team meetings or include the weekly report templates the contractor will need to submit.
Value-adding change: The general contractor comes by one morning and tells you he knows of a kitchen supply wholesaler that’s going out of business, with appliances for less than wholesale and higher grade than the appliances you planned for the childcare center. This change improves performance and reduces cost.
Implementing a contingency plan or workaround: Consider the following risk: The city might not approve the plans, thus causing a schedule delay. If this risk did occur, the response was to mitigate the risk by following up weekly. If the risk occurred anyway, the contingency plan was to immediately start drawing up plans to resubmit. This is additional scope that would need to be incorporated into the project.
Customer seeing the product and wanting changes: Assume that the parents come to the childcare center after the frame is completed but before any of the electric, plumbing, and HVAC work has been done. Some of the parents think it would be a good idea to increase the size of the playroom and decrease the size of the eating area.
The contractor is on-site and says that could be done — and that he can give you an estimate for cost and schedule implications by the end of the week.
Now look at the other side of the equation: scope creep. No project is immune to the perils of scope creep. You have to be strong, have good scope definition, and have a good change control process to avoid it. Here are some common causes of scope creep:
Lack of change control: If you don’t have a well-defined change control system, you can’t effectively control the project. It isn’t enough to have a change control system, though. Stakeholders have to know about it, it can’t be overly prohibitive to use, and you have to enforce it.
Not understanding the work needed to meet project objectives: If you start working on a project before you understand all the work needed to meet the project objectives, you are likely to miss deliverables or miss the amount of work it takes to meet those deliverables.
Lack of communication: Stakeholders can say what they want — and in their heads, that message is very clear. However, in the decoding process, the receiver might have a completely different interpretation of what the stakeholder wants. By not using multiple modes of communication, using jargon, or assuming that you understand what the customer wants, you are leaving yourself open to misinterpretation of scope to deliver what the stakeholder wants.
Not saying no: This applies to the project manager, sponsor, and team members. It can be scary and unpleasant to tell someone she can’t have what she wants. Sometimes it seems easier to just give people what they want. You must enforce the change control system. You don’t have to be rude about it, but you must make sure it is followed!
To prevent scope creep, follow these rules:
Fully define and document your scope.
Meet with your stakeholders and customers often to confirm that you all have the same understanding of scope.
Establish a change control system that includes
A change request form
A process to analyze the impacts of change requests
A change control board to discuss and determine the outcome of the change request
A method to communicate change request status (approved, denied, pended)
A procedure to update plans to incorporate approved changes
Document the scope using requirements, a scope statement, a WBS, and a WBS dictionary.
Get sign-off on the scope and baseline it.
Enforce the change control system.
Keep project documents up to date.