Because most projects begin
with a certain amount of uncertainty in the requirements or specifications,
changes to the scope are bound to occur (Laureate Education, Inc, n.d.).
Sometimes during development, requests are made for entirely new features or functionality
(“Managing Scope Creep”, n.d.; Larson, & Larson, 2009). In either case, if
extra effort is required as a result, the project is at risk from “scope
creep”. Generally scope creep is when extra effort is added without proper
approvals, and appropriate changes to the schedule, budget, and resource plan
(“Managing Scope Creep”, n.d.; Larson, & Larson, 2009). Even when changes
are approved, dealing with the new requirements can add complexities and
challenges to your project.
Several
years ago I worked on a project team developing a web based application. The
project was run fairly formally, with a kick-off meeting, a budget, and a
schedule, but the overall requirements gathering was fairly light. I was
involved as a web developer, although I had several informal and vaguely
defined roles as a designer, technical writer, and general technology
consultant. I was also in charge of Quality Assurance (QA). At a certain point
during development I saw that the schedule was in danger, so I developed a very
rudimentary (having no formal training in this area) work breakdown structure
(WBS) to try to help the project manager revise the schedule to something more
realistic. During development a request came in to support additional
territories. As a team we had actually learned a lot about change requests,
prioritizing, and change management, during the course of this project. This
meant the project manager made sure to check that this change was a priority.
We held a team meeting to decide our course of action. Options included not
making this change, making the change and delaying the product, or trying to
add resources so we could make the change while keeping to the schedule.
We also needed budget approval for extra spending if the scope change
went ahead. Due to limited critical resources, my time for example, and the
critical path of development, it was determined that we would need to add
development resources and budget, but also extend the schedule a little in
order to accommodate the change request. Because we obtained approval for these
changes, this example may not technically be scope creep, but it is a good
example of the type of request that a less experienced team might easily have
taken on without going through a proper change request process, which would
have led to missed deadlines and budget overruns.
An example that would be considered
scope creep, on the same project, was when I took it upon myself to redesign
the interface. We had hired a freelancer to design a UI. The freelancer was
selected by one of the stakeholders who happened to be a manager with a lot of
authority, but little technical or UI experience. The freelancer did a terrible
job. Because the schedule was tight, I took it upon myself to tweak the design
to something that would actually meet the project needs. This did take up
several hours of my time that were not accounted for in the schedule. The
schedule was not particularly granular, but there were a ton of other things I
also needed to get done. My concern was it would actually take more of my time
to go through the approvals and redesign process if we tried to get the
original freelancer, or a replacement one, than just doing it myself. The path
I chose almost certainly benefited that project, the problem was I was enabling
the organization’s bad practices. If I had allowed the UI to fail, they would
have had a greater incentive to use a better vendor selection process in the
future.
Similar scope changes are a common risk. Developers,
and many people in general, like to make things great, even though the schedule
only contains enough time to make things “just good enough” (Laureate
Education, Inc, n.d.). The changes I made to the UI were fairly critical, but I
probably also spent time on other less vital improvements. Project Managers
need to be aware of the tendency for people to put the schedule at risk by
trying to make things perfect. Have the team focus on delivering something that
works, and then if there is time, let them go back and improve things. This can
be a real challenge. Programmers will probably whine about it being more
efficient to do it right the first time to avoid refactoring and so on. That
might be true, but it’s not the point. Whatever the task type, stick to the basic
requirements.
References:
Larson,
R. & Larson, E. (2009). Top five
causes of scope creep ... and what to do about them. Paper presented at
PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA:
Project Management Institute. Retrieved from https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675
Laureate
Education, Inc. (Executive Producer). (n.d.). Practitioner voices:
Overcoming ‘scope creep’ [Video file]. Retrieved from https://class.waldenu.edu
Managing
Scope Creep in Project Management (n.d.) Retrieved from https://www.villanovau.com/resources/project-management/project-management-scope-creep/#.WhiVVlWnE-U
