How Should the Project Manager Deal with Scope Creep?

PDF Icon Get the PDF VersionBy Kuntal Thakore

Gantt chart and graphs6 Mar
2010
Every project has (or should have) a set of deliverables, an assigned budget, and an expected closure
time. There are agreed upon requirements and tasks to complete prior to the closure of project. These
constitute the scope of the project. Any amount of variation in the scope of project can affect the
schedule, budget and in turn the success of project.
Scoping is the separation between what is included in and what is excluded from project. Scope creep
occurs when the line is moved, usually outwards. Thus what was excluded is now included, making a
project in most cases larger.
According to the PMBOK, scope creep is defined as adding features and functionality (project scope)
without addressing the effects on time, costs, and resources, or without customer approval. This
phenomenon can occur when the scope of a project is not properly defined, documented, or controlled.
It is generally considered a negative occurrence that is to be avoided.
In the past, I have participated (not as a project lead or a project manager) in a number of projects that
failed due to scope creep. I could not find any formal statistics to refer to, however, I've noted that
majority of those projects failed due some form of scope creep. Note that the PMBOK considers a
project as failed anytime it is over budget or does not meet the predetermined schedule deadline.
Scope creep can originate from:
Poor implementation of change control.
Incomplete gathering of requirements before the beginning of project execution.
Insufficient involvement of critical stakeholders (including the customer).
Lack of support from the executive sponsor.
Scope creep can be classified as:
Technical Scope Creep
Business Scope Creep
The technical scope creep can show up when the project team wants to please the customer and is not
able to reject the customer's request for a change in the requirements during project execution. Gold-
plating is another reason which can cause technical scope creep. In this case, the project team (or
development/design team) adds additional features and functionality that are not part of original
requirements in order to please the customer.
The business scope creep occurs due to external forces that may be beyond the control of project
manager. An example might be the continual changes in market trends, which makes previously defined
requirements now obsolete.
One can avoid scope creep by managing the scope of project effectively. There are a number of ways to
control or avoid scope creep:
Involve the customer and/or the end users early in the project.
Thoroughly analyse and gather requirements during the initial stages of the project.
Introduce a Change Control Board (CCB) team that would evaluate the risk of implementing the changes.
Make sure to involve critical stakeholders throughout the project phases (especially during the planning
phase).
Avoid gold-plating and gain the ability to refuse changes in requirements with proper reasons and
support.
In extreme cases, stop the project so that new additional requirements can be properly scoped and
integrated rather than tacked on.
Secondly, note that the idea of scope creep has evolved in SCRUM. The product catalogue (scope) is
dynamic and it changes throughout the software product development life cycle as long as the customer
feels that those changes add value to the project and accepts the responsibility for them. At the same
time, every attempt is made to make sure that scope within each SCRUM sprint is strictly enforced. This
evolution of scope creep in SCRUM does represent some interesting problems, which are beyond the
scope of this article.