Managing Scope Creep in Project Management
Managing Scope Creep in Project Management
o Not Involving the Users Early Enough: Thinking you know what the users want or need is a
serious mistake. It is important to involve them in both the requirements analysis and design
phases.
o Underestimating the Complexity of the Project: Many projects run into problems because
they are new in an industry and have never been done before. Nobody knows what to expect,
there are no lessons learned and no one to ask.
o Lack of Change Control: You can expect there to be a degree of scope creep in most projects,
therefore it is important to design a process to manage these changes. A simple process of
document, consider, approve and resource can be implemented.
o Gold Plating: This term is given to the practice of exceeding the scope of a project in the belief
that a value is being added. These changes inevitably consume time and budget and are not
guaranteed to increase customer satisfaction.
o Lack of proper initial identification of what is required to bring about the project objectives
o 44% were challenged; these projects were late, over budget, and/or with less than the required
features and functions
o 24% failed which was denoted by those projects that were canceled prior to completion or
delivered and never used
"These numbers represent a downtick in the success rates of the
previous study, as well as a significant increase in the number of
failures," says Jim Crear, Standish Group CIO. "They are the low point in
the last five study periods. This year's results represent the highest
failure rate in over a decade."
2. Understand your priorities and the priorities of the project drivers. Make an ordered list that you
can refer to throughout the project duration. Items should include budget, deadline, feature
delivery, customer satisfaction and employee satisfaction. You’ll use this list to justify your
scheduling decisions once the project has commenced.
3. Define your deliverables and have them approved by the project drivers. Deliverables should be
general descriptions of functionality to be outlined during the project.
4. Break the approved deliverables into actual work requirements. The requirements should be as
detailed as necessary and can be completed using a simple spreadsheet. The larger your
project, the more detail you should include. If your project spans more than a month or two,
don’t forget to include time for software upgrades during development and always include time
for ample documentation.
5. Break the project down into major and minor milestones and complete a generous project
schedule to be approved by the project drivers. Minor milestones should not span more than a
month. Whatever your method for determining task duration, leave room for error. When
working with an unknown staff, I generally schedule 140% to 160% of the duration as expected
to be delivered. If your schedule is tight, reevaluate your deliverables. Coming in under budget
and ahead of schedule leaves room for additional enhancements.
6. Once a schedule has been created, assign resources and determine your critical path using a
project evaluation and review technique (PERT) chart or work breakdown structure. Your critical
path will change over the course of your project, so it’s important to evaluate it before
development begins. Follow this map to determine which deliverables must be completed on
time. In very large projects, try not to define phase specifics too early, but even a general plan
will give you the backbone you need for successful delivery.
7. Expect that there will be scope creep. Implement change order forms early and educate the
project drivers on your processes. A change order form will allow you to perform a cost-benefit
analysis before scheduling changes requested by the project drivers.