Scope Creep

By: Nadya Bronstein

November 15, 2010



Table of Contents:


What is Scope Creep?

Two Types of Scope Creep

Why is Scope Creep a Problem? Or is it…?

Why Scope Creep Can Be Bad

How Can Scope Creep Be Controlled? Analysis and Communication Are Keys!

Why is Project Cost Important

How to Respond to Clients

Final Thoughts

Web-Based References

Non-Web Based References



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.


What 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:

  1. Business requirements that are vague and not well defined.
  2. Underestimating the complexity of the problem in an unknown industry.
  3. Insufficient management of user expectations.
  4. Not involving the end users/clients early enough in the project.

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:

  1. Define the business requirements as “must-haves” and “nice to haves” and prioritize each of these separately. Identify the risks for each “must-have” requirement and get the stakeholders’ approval. Plan these prioritized requirements in the form of phased deliverables during the project life cycle. “Must haves” are things that are absolutely critical for the client, and “nice to haves” are items that would be nice but the client can live without and still get what is necessary out of the system.
  2. At the very beginning of the project, set project expectations with the customer stakeholders and get input and agreement from the customer.
  3. Meet with the customer to agree on project deliverables, and thoroughly document these in the Statement Of Work (SOW) document. Also note the areas that are NOT included in the Statement of Work.
  4. Document business requirements and review with the customers before any sign off.
  5. Decide and document how the users will use the system in the form of test cases during the requirement analysis phase. This will give the project managers a clearer idea of how the project should look and function, and will help with testing later on.
  6. Make a flexible project plan that has time for protyping built into it. This will allow users to participate in the design phase of the project, and incorporate their suggestions.
  7. Introduce a formal change management process and design the forms for approving changes. Follow the six steps for any changes or deviations from the initial set of requirements:
  8. When changes to a project occur, conduct an impact analysis and calculate the cost and time for the new requirements. The impact analysis should describe how these new requirements will impact other existing requirements and applications. This is effective in getting the sponsor to accept the new requirements. (Suresh, B.).

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.

This has significant implications for project planning. First, project managers need to build enough time into the project’s timeline for iterative prototyping and/or pilot phasing, and second, they need to adopt good processes for handling change requests. The change request process should include good mechanisms for capturing information about the changes requested. Tips for handling change requests were discussed earlier in this paper (Starr, J.).

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 (

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:

  1. Completely understand and analyze the project's purpose and vision. Meet with the project stakeholders and provide an overview of the project to them. Ask fortheir feedback, and document it.
  2. Understand your priorities and the priorities of the project stakeholders. Review the budget, deadline, feature delivery, customer satisfaction, and employee satisfaction. See if there is any disagreement or conflicting priorities that must be resolved, and address these as soon as possible.
  3. Define your deliverables and have them approved by the project stakeholders. Deliverables are general descriptions of functionality to be completed during the project, or what the end product that will be delivered to the customer will contain.
  4. Break down the approved deliverables into actual work requirements, which are small segments of the project. The larger the project, the more detail you should include.
  5. Further break the project down into major and minor milestones and complete a project schedule to be approved by the project stakeholders. Minor milestones should not span more than a month. Leave room for error!  Revisions may be required.
  6. Once a schedule has been created, assign resources and determine the critical path using a PERT Chart or Work Breakdown Structure which show all of the activities that must be completed and the time that each activity will take. You can use Microsoft Project for this task. The critical path is likely to change over the course of the project, so it’s important to evaluate it before development begins. Follow either the PERT Chart or Work Breakdown Sturcture to determine which deliverables must be completed on time. Review this periodically.
  7. Expect that there will be scope creep. Sometimes this is inevitable. For this reason, it is important to implement Change Order forms early and develop a process for approving and tracking the forms.  Educate the project stakeholders on your processes and make sure that the processes are followed! A Change Order form will allow you to document all changes and perform a cost-benefit analysis before scheduling the changes that are requested by the project drivers (Doll, S.).

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.

Finally, sometimes “no” is the only option. If the client is not willing to pay extra or to accept a later delivery date, sometimes no is the only possible response (Bram, T.).

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.

Doll, Shelley. "Seven Steps for Avoiding Scope Creep." Web. 12 Oct. 2010.

Grossman, Mark. "Grossman Law Group - Scope Creep." Grossman Law Group - Home. Web. 25 Oct. 2010.

Helms, Hal. "In Defense of Scope Creep." A List Apart. 20 Sept. 2002. Web. 1 Oct. 2010.

"Just How Bad Is Project Scope Creep? |" 12 June 2010. Web. 01 Nov. 2010.

Long, Kathy. "Scope Creep! Managing Process Improvement Project Scope." Process Renewal Group. Web. 17 Oct. 2010.

Rusk, John. "Earned Value for Agile Development." DoD Software Tech News. 15 Apr. 2009. Web. 03 Nov. 2010.

Starr, Joan. "Taking the Creep out of Scope Creep." California Digital Library. 22 Mar. 2010. Web. 01 Nov. 2010.

Suresh, Babu. "Scope Creep Management." Project Management Software. 27 June 2005. Web. 15 Oct. 2010.

YouTube - Scope Creep Presentation." YouTube - Broadcast Yourself. 17 Feb. 2010. Web. 01 Oct. 2010.



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).