By: Nadya Bronstein
November 15, 2010
Table of Contents:
Why is Scope Creep a Problem? Or is it…?
How Can Scope Creep Be Controlled? Analysis and Communication Are Keys!
Introduction
Scope creep is a term that is commonly viewed in a negative light by many IT professionals and project managers. Because scope creep is fairly common and widely prevalent, it is important to analyze both its positive and negative impacts, and determine the best ways to avoid it, if necessary. Although scope creep can have detrimental effects on a project’s timeline and on its allocated budget, sometimes it is necessary and even beneficial in some cases.
A thorough change management process is very important in order to be able to track and analyze change requests. Therefore, scope creep must be examined closely in each unique situation where it may arise so that the best decision may be made.
TopWhat is Scope Creep?
In this Youtube video which was created on the subject of scope creep, scope is defined as “a measurable definition of the goals, resources, timing, and desired outcome of a project or activity.” Accordingly, scope creep is defined as “the tendency of that project to include more tasks than originally specified which leads to higher project costs and possibly missed deadlines” (Youtube).
Scope creep is a change in a project's scope after the project work has
already started. Usually, the scope increases due to the addition of
new features to an already approved feature list. Because of this, the
project drifts away from its original purpose, timeline, and budget.
A good example of scope creep is the following analogy: “It’s like
those capsules of sponges, which expand when dropped in water. They
usually expand to about ten to twenty times their original size. Why
does this happen? The boundaries (plastic capsule) dissolve. Project
scope creep also happens because boundaries disappear” (Long, K.).
Furthermore, scope creep is “the gradual introduction of requirements
that weren't part of a project's initial planning. To minimize it,
make sure there is as much clarity as possible around the scope of a
service. The contract also should include arrangements for covering
additional work, including the need for the vendor and client to agree
to the dollar-per-hour charge and the number of hours needed. It's also
a good idea to include an arrangement for an arbitrator to resolve any
disputes” (Lorber, L).
Scope creep is often gradual and not noticed immediately. This change in scope often comes about from small, seemingly insignificant change requests that the project team accepts to keep the project sponsor happy. Eventually, the change requests become numerous enough that they are significant, or one of the requests turns out to require much more work than expected.
Scope creep has the potential to be harmful to a project. According
to an article in the Daily Record, “if most of your projects with a
client lose money or barely break even, it's time for a serious
reevaluation. Analyze what went wrong and sit down with the client to
discuss win-win solutions. The culprit in these cases is usually scope
creep and is reflective of somebody's inability to effectively manage
client-initiated changes” (Tuminello, R.).
Scope creep may occur as a result of:
It is very important to define the scope of the project in its earliest stages, because “clearly defined project scope can keep team members on the same page and get them to work towards the set goal, by effectively preventing scope creep from occurring” (E-WORLD).
Projects may fail for several reasons, such as “not delivering the
complete functional scope, or being over budget or finishing the
project late. A leading cause of project failure is poor scope
definition. The point is that you can't estimate what you don't know!”
(Lukas, J). For this reason, defining project scope is critical to a
project’s success.
Two Types of Scope Creep
There are two main types of scope creep: business and technology.
First, let’s take a look at business scope creep. New technologies and
systems are designed to solve the business needs for a company. Because
the business world is very dynamic and constantly changing, it is
difficult to use older requirements, as these are often subject to
change. The common reasons for these changes are:
In an IT project, the project/business team works with the client or the customer to understand what the client wants and to document this in business requirements. This requirement definition analysis phase involves meetings, interviews, and questionnaires with the client about the current system and their future needs. In most cases, clients are unable to specify exactly what they want in the beginning until they see the product. It is also often difficult for business users to visualize how the new system will look and function until they see it.
When the users do see the new system for the first time, changes may be needed because any new applications will be initially unfamiliar to users, and they will see functionality that they do not understand or don’t like. Most of the time, the user tends to look for and focus on things that won’t work, rather than the things that do work in the system. The common approach that business users have in mind is that “we’re spending so much time and money anyway, so let’s add this during the testing phase.” This expands the scope way beyond what was originally considered and possibly more than the project can accomplish, and more than the client needs.
In order to mitigate these types of issues, the proposed solutions to business scope creep are the following:
Now, let’s take a look at technology scope creep. There are two types of technology scope creep, the first of which is a result of trying to please the customer. When a project manager tries very hard to make the customer happy, it is difficult for him or her to say no to a customer’s demand, and this results in scope creep.
There are several steps to avoid this:
First and foremost, it is the project team’s responsibility to let
the business group know that the requested change is considerably
different from the requirements that were approved during the project
scoping process. It is crucial that this is communicated clearly and
directly. The team should provide the business sponsors with different
options that are outlined below, and explain to them how these changes
could impact the budget, timelines and resources for the particular
project.
The options are:
Also, a good idea is to perform a visual walkthrough session with the client during the requirements phase, in order to define what the client wants before the system is built. This session with the client can help the team to identify the key features that the project must have, and the developers and designers can deliver a final product closer to the client’s needs, which will more likely result in project success.
The second type of technology scope creep is called “technical gold
plating,” which may occur when the programmers/developers decide to add
features and functionality that have not been specified in the approved
requirements definition. The reason for these changes could be the
business requirements are lacking important details, so the programmer
feels the need to make decisions on the fly and improvise, or if the
programmer is a perfectionist and decides that adding additional
features will make the project better, but does not consult with anyone
about these decisions. (Suresh, B.).
The solution for technical gold plating is the following:
In the division where I work, we have a very formal change request process, where each change is clearly documented (the documentation is written by a business analyst such as myself). The change requests are then sent to the project manager, who sends it to our IT team. The IT team then analyzes the changes, the impact that they will have on the project, whether they can be incorporated into the set timeframe, and how much these additions/changes will cost, and communicates this information to us on the business team very clearly. This helps us a lot with tracking changes and with understanding their impact on the project.
An example of the Change Request form that we use at the firm where I work is below. Of course, other forms and formats may be used, but this is an example of some of the important information that must be included:
Why is Scope Creep a Problem? Or is it…?
Scope Creep is often thought of in a negative light, and according to the Youtube video posted above, the conclusion is stated clearly: “scope creep is not good!” It is usually described as something to avoid at all costs. Usually, scope creep is indeed problematic. For example, the Youtube video also mentions that this quick project took much longer than it was supposed to as the number of steps increased from four to twelve, and the user stayed up late into the night trying to add on additional project features. However, there are some instances where it may actually be beneficial.
The effects of scope creep are not always negative, depending on the
situation. For consultants, scope creep can lead to creativity and
additional product features that the client could be willing to pay
more for. Furthermore, “if you work as a consultant or for a consulting
firm, ‘feature-it is’ can be great for business—as long as it’s
handled professionally. For in-house software development, additional
features could give your product the edge over your competition.”
However, this ‘edge’ is lost if you release a new product or feature a
month or two late. If the scope changes so much that it leads to a
significant delay of a release, the product may lose its novelty and may
no longer attract as much market share, which can be detrimental (Doll, S.).
Scope creep is also considered a natural occurrence by some
professionals. For example, it is often difficult to get a clear
picture of what the client envisions the end product to be. If the
client cannot effectively communicate what he/she wants, it becomes
very difficult to get the final product right on the first attempt.
In reality, what may occur is the following: “Most project managers try
their best to discover what clients want at the beginning of the
project. They use meetings, questionnaires, personal interviews – and
still, the most common experience for developers delivering a final
product is customer dissatisfaction. It may come as a slap in the face –
‘this is no good’ – or it may be couched in gentler terms – ‘you know
what would be nice’ – but the same message is being delivered: we
aren’t giving clients what they want” (Helms, H.).
Many times, customers don’t even have a clear idea about what they want,
and “clients can’t tell us what they want until they see it. That’s
why they don’t tell us what they want up front. They can’t! And if they
could, would they really need us?” This phenomenon may lead some
professionals to believe that they cannot achieve success and project
acceptance on the first try, and they must show different iterations of
the project to the client in order to give the client a chance to play
around with the software and figure out more of the details of the
final outcome (Helms, H.).
Because clients oftent cannot formulate exactly what the final product
should look like or how it should function until they have a chance to
view it, clients will not be able to give meaningful feedback until
they are working with the prototype (in the case of software) or the
pilot (in the case of a human service). A prototype is a working model
of a new product or new version of an existing product. If a client is
given a way to access a prototype and work with it, he can then
determine what is missing, and these missing pieces can be added on in
order to provide the customer with a better, more user-friendly
product.
These types of developments naturally lead to scope creep, as the
customer will likely think of more and more new additions and changes
to the existing prototype, but this can be highly beneficial because
the customer will get what he expects and the developer will have a
better picture of what the customer really needs and wants instead of
relying on his own opinions or inferences.
Why Scope Creep Can Be Bad
Despite the arguments presented above that scope creep can be
beneficial in some instances, and often inherent in projects, it can be
detrimental to a project in some cases as well. If the initial project
timeline is built with little to no flexibility, increasing scope once
the project is already underway can cause the project to be delivered
late, which leads a bad customer experience.
Therefore, it is very important to make sure that the project timeline has some flexibility built into it. If a project team is working with a fixed budget, as well as a with high amount of pressure to get the project delivered on time, scope creep can lead to devastating results. Further in this analysis, I will discuss how scope creep can be avoided, or at least controlled (Winaymarka.org).
Scope creep can occur in any type of project, both fixed price, and
variable price contracts. It can be equally frustrating in both. For
example, if there is a variable price contract with an hourly fee, then
the customer can be very unhappy if the project goes significantly
over budget, as the client is stuck paying the extra cost, which may be
more than they had budgeted for. The customer will often feel like the
vendor low-balled them on the budget. The seller of the services will
typically contend that as the project developed, the customer wanted
more than she originally requested – which is basically the definition
of scope creep.
According to an article published in Money Marketing, it is important
to include clauses in a contact with a client that deal with scope
creep. The article states that “in a good client agreement, you do have
clauses that allow for overrun when circumstances beyond your control
or your client's decision causes you to do more work, it is what we
call scope creep. It is because of this you need to establish
an hourly rate to reference that creep back. Rather than take a loss,
you should be able to go back to your client during the process,
explain why it is going to cost more and base that on an hourly rate”
(Business Strategy).
But with a fixed-price contract, the parties involved are no better off
if scope creep occurs. If scope creep is present in a fixed-price
contract, it can cause an even more difficult situation. The customer
may argue that the fixed price includes something that the other side
thinks is outside of the scope of the fixed price. Therefore, an
argument will ensue back and forth between the developer firm and the
client where the client argues that the contract included more, and the
developer counters that no, it did not. This can cause very bad client
relations and can lead to lost business in the future (Grossman, M.).
How Can Scope Creep Be Controlled? Analysis and Communication Are Keys!
In order to take control of scope creep, planning and analysis are very important, and should be conducted in the early stages of the project. In fact, “organizations can prevent scope creep by conducting the necessary project planning up front and identify requirements and the effect that the renovation project will have in all areas of the data center facility. Upfront planning and detailed project scoping can prevent a cascading impact on data center renovation projects to other areas of the data center that can increase project size, scope and spend” (Business Wire).
Additionally, it is important to analyze the project from the
beginning and try to predict which areas might end up requiring
additional work. The project manager should “be on the lookout as
early in the project as possible for small additional services not
covered under the original scope of work, so these can be discussed
with the client. Even if the PM decides not to invoice for the first
extra, it shows the client that the PM is familiar with the scope of
work and is on top of the project. The client now knows that any future
extra requests will be quickly identified by the PM as additional
services “(Ingardia, M.).
An article in Computer World stresses the importance of communication: “users get cranky when they feel have have no control over the outcome. Developers do too, of course, which is why it's so important not only to communicate in some way, but to make sure messages are understood and not simply received” (Machlis, S.). It is important to make the client feel that his/her input is important and valuable to the project’s development, and any concerns should addressed with the client as soon as they arise. Additionally, if a client’s request cannot be accepted, the project manager must openly discuss with the client the reasons for not being able to make that particular change.
Here are some pointers on how to control scope creep:
In my experience as a business analyst, scope creep can be a major problem. We often work on several large projects at the same time and sometimes we are guilty of adding on to the scope of a project unintentionally. This happens more often when we are pressed for time due to pending deadlines and do not have the time to complete a full and thorough analysis. If we come up with the business requirements too late, then we end up not having sufficient time to analyze the prototype. When we finally do get a chance to review it and test the functionality, we often find things that we missed or that could be added to make the design or functionality better, or ways to make the application more user-friendly.
These last minute changes and additions make testing more difficult,
and cause a strain on our IT resources, because the IT group is put in a
position where they have to work long hours to make these last minute
changes, and the final product may suffer because we do not have enough
time to review and to test this additional functionality before we
deliver the software to our final customers.
Why is Project Cost Important?
Regardless of the perceived effects of scope creep, both positive
and negative, cost is the bottom line. Projected costs must be analyzed
and reviewed carefully. When considering the possibility of adding on
features, review their associated costs and whether the benefits of
these features are likely to outweigh the additional spending. If not,
avoid non-essential project add-ons if possible. By controlling the
cost of development and by delivering on time, the project can be a
success, without compromising flexibility in production.
Even if the costs do not outweigh the benefits, it may be wise to avoid adding scope at the last minute because it can create a bad precedent for future projects. Last minute additions also allow less time for review and testing of the functionality of the product code and can cause a strain on IT employees, as they must often scramble to make these unplanned-for modifications.
An example of how scope creep can negatively affect the completion date
and cost of a project is illustrated in the two graphs below. The
first graph demonstrates the project as it currently stands prior to
the onset of scope creep. You can see that the red line indicates the
percentage of the project’s budget that has been used to date, and the
green line illustrates the actual percentage of the project that has
been completed thus far. The dotted line shows the planned percent
complete.
The second graph below shows the effects of scope creep on this same project.
Here it is evident that the green line, which represents the actual percent of the project completed, has moved down. As more and more items were added on to this project, the amount of work completed became a smaller percentage because the project itself became a greater endeavor.
In this example, the red line and the dotted line did not change,
because the budget was kept constant in this example. In practice,
sometimes the budget may increase to include the additional costs that
are encountered due to scope creep, or the budget may remain the same
and the project will end up running over budget.
Charts similar to the ones above are very useful in answering the two
most important questions that project managers and business executives
have, which are: is the project on time, and is the project within
budget? Clearly, in the second graph presented in the example above, the
project is likely to NOT be delivered on time, which may cause the
customer major stress and disappointment, and may tarnish the
reputation of the company that is running this project (Rusk, J.).
How to Respond to Clients
In my research, I found an article that explained how to communicate
and respond to clients when scope creep arose, which I think is very
beneficial for anyone dealing with this in the workplace. The four main
responses are:
Before providing any one of these answers to a client, “one of the most important criteria for decision making and problem solving is the need to clearly define the situation. As critical as this consideration is, it is frequently ignored or simply done poorly” (Westcutt, R.). The project manager should determine what the customer is really asking for, what the need is, and whether this can be accomplished given the established parameters of time and cost. Once the situation is fully analyzed, the project manager can provide one of the responses below.
The first response can be used to explain to the client you can make
the changes, but it will cost extra. This gives the client the option
to accept the additional costs or to decide to keep the project as is,
and not add on scope.
The second possible response demonstrates to the client that adding
on scope might not be the best idea in a situation where the client is
on a tight deadline. On the other hand, if a client is willing to make
the choice to receive the finished product a little bit later, then
adding on scope could be possible.
The third answer, “yes, but…” may be used if adding on scope will
affect both the project’s timeline and the budget. Using this phrase
can open up dialog between the client and the project manager and allow
them to come to a consensus about scope.
Project managers need to be granted the authority to make key project
decisions, and to determine which response to give to clients in a
specific situation. Project managers must also willingly take on this
responsibility and act accordingly, not only with clients but with
their internal partners as well. They must “show the right level of
authority at the beginning. They need to have a presence in how they
dress and behave in those first meetings to have the team look up and
say, ‘this person seems to know what he or she is doing. Let's give him
or her the opportunity to lead us'" (Smart, M.).
Final Thoughts
Overall, based on my research, I believe that scope creep can be a
positive influence because it allows for a project to be more tailored
to meet the clients’ needs, and modifications throughout the course of
the project may be unavoidable because the client usually doesn’t
automatically know what he or she wants from the onset. Once the client
gets a chance to review and use the product in its development stages,
he can better understand what additional factors need to be included,
which is why scope creep may arise.
On the other hand, scope creep can also be a hindrance because it can
push the project behind schedule and can increase project costs. It
can also drastically change the look and feel of a project and even its
overall purpose, in the extreme case. Luckily, there are numerous tips
that have been uncovered which can help a project manager to avoid
scope creep, or to manage it as much as possible.
Perhaps scope creep is unfairly characterized as being purely evil,
as it can be both good and bad in various situations, and can have both
positive and negative effects on a client’s satisfaction with a
project. Regardless of what your view on scope creep may be, I think
that most people will agree that having a solid process for change
management is key to a project’s success.
"Scope creep turns relatively simple requests into horribly complex and time consuming monsters."
Web-Based References:
Bram, Thursday. "4 Ways to Kill Scope Creep." FreelanceSwitch | Freelance Jobs, Freelance Forum & Directory. 2 Feb. 2010. Web. 01 Nov. 2010. http://freelanceswitch.com/clients/4-ways-to-kill-scope-creep/
Doll, Shelley. "Seven Steps for Avoiding Scope Creep." Web. 12 Oct. 2010. http://articles.techrepublic.com.com/5100-10878_11-1045555.html
Grossman, Mark. "Grossman Law Group - Scope Creep." Grossman Law Group - Home. Web. 25 Oct. 2010. http://www.ecomputerlaw.com/articles/show_article.php?article=2005_scope_creep
Helms, Hal. "In Defense of Scope Creep." A List Apart. 20 Sept. 2002. Web. 1 Oct. 2010. http://www.alistapart.com/articles/scopecreep/
"Just How Bad Is Project Scope Creep? | Winaymarka.org." 12 June 2010. Web. 01 Nov. 2010. http://www.winaymarka.org/business/just-how-bad-is-project-scope-creep/
Long, Kathy. "Scope Creep! Managing Process Improvement Project Scope." Process Renewal Group. Web. 17 Oct. 2010. http://www.processrenewal.com/files/Scope%20Creep.pdf
Rusk, John. "Earned Value for Agile Development." DoD Software Tech News. 15 Apr. 2009. Web. 03 Nov. 2010. https://softwaretechnews.thedacs.com/stn_view.php?stn_id=49&article_id=128
Starr, Joan. "Taking the Creep out of Scope Creep." California Digital Library. 22 Mar. 2010. Web. 01 Nov. 2010. http://www.cdlib.org/cdlinfo/2010/03/22/taking-the-creep-out-of-scope-creep/
Suresh, Babu. "Scope Creep Management." Project Management Software. 27 June 2005. Web. 15 Oct. 2010. http://www.projectperfect.com.au/info_scope_creep_mgmt.php
YouTube - Scope Creep Presentation." YouTube - Broadcast Yourself. 17 Feb. 2010. Web. 01 Oct. 2010. http://www.youtube.com/watch?v=HBCoMZzQ948
Non-Web Based References:
BUSINESS STRATEGY: Seconds out for hourly fees. (2010, September). Money Marketing,35. Retrieved October 31, 2010, from ABI/INFORM Trade & Industry. (Document ID: 2128191191).
E-WORLD: Why system implementation fails. (2009, February). Businessline. Retrieved October 31, 2010, from ABI/INFORM Trade & Industry. (Document ID: 1650100941).
Ingardia, M. (2008, January). 12 Steps to Protect Your Firm's Profits Against the Menace of Scope Creep. Design Firm Management & Administration Report, 08(1), 1,5-7,10. Retrieved October 31, 2010, from ABI/INFORM Trade & Industry. (Document ID: 1402656431).
Lorber, L. (2007, May 7). Small Business Link: An Expert's Do's and Don'ts For Outsourcing Technology. Wall Street Journal (Eastern Edition), p. B.8. Retrieved October 31, 2010, from ABI/INFORM Global. (Document ID: 1266233281).
Lukas, J. (2006). Bad Estimates Just Don't Happen. AACE International Transactions,ES31-ES36. Retrieved October 31, 2010, from ABI/INFORM Global. (Document ID: 1319960641).
Machlis, S. (2009, September). I've Looked at Code From Both Sides Now. Computerworld, 43(28), 40. Retrieved October 31, 2010, from ABI/INFORM Global. (Document ID: 1865425141).
Research and Markets: Renovate the Data Center. (30 July). Business Wire. Retrieved October 31, 2010, from ABI/INFORM Dateline. (Document ID: 2095606621).
Smart, M. (2010, June). AIR OF AUTHORITY. PM Network, 24(6), 46-50,8. Retrieved October 31, 2010, from ABI/INFORM Trade & Industry. (Document ID: 2081730831).
Tuminello, R. (2007, April 11). When is the right time to fire a client? Daily Record,1. Retrieved October 31, 2010, from ABI/INFORM Dateline. (Document ID: 1253421041).
Westcott, R. (2007). Have You Adequately Defined Your Situation? Quality Progress, 40(8), 80. Retrieved October 31, 2010, from ABI/INFORM Global. (Document ID: 1334726431).