Scope Creep

by Stephanie Gurlen

December 2, 2003

Introduction

Many individuals and departments that provide Information Technology (I.T.) services view scope creep as something to avoid at all costs. “Scope creep threatens to undermine all our hard work, causing rewrite after rewrite of carefully crafted markup and code. In short, scope creep is evil.”¹ But is scope creep really evil? Or is it just the source of a lot of project management headaches? On the other hand, can scope creep ever be a good thing? Read on to further explore the topic of scope creep.

1.0 What is scope creep?

Looking at the words scope creep literally can provide some humor into your day. “If you take the words literally, they say that scope is creeping. Scope is creeping? What on earth does that mean? Bugs creep. In rush hour, traffic creeps. But scope? Scope is an inanimate thing. It can't creep. Not all by itself, it can't. If scope is creeping, it's because someone is creeping it.”²

Development of an information system is often seen as a life cycle, in that it is created, it goes through testing, it is sold or implemented, it will go through periods of enhancements, it will eventually go through a decline, and will eventually be replaced or terminated. The creation through implementation life stages are often performed inside a project, which is a planned effort of needed activities in order to meet a goal. Many companies will follow a project methodology when executing a project. These methodologies are standard processes for how to approach a project.

The first phase in many project methodologies is to define the scope of the project. The scope states what the objectives of the project are and what work will be done to accomplish the project. The scope describes the parameters for what is included in a project and what is excluded from a project. The scope will become more refined as a project progresses, but it will always remain within the initial parameters defined.

When through the evolution of a project, the direction of a project changes where it goes outside the initial parameters—this is a change in the scope of the project. Similarly, if there are any changes to what will be done for the project, no matter how small or how large and no matter if they were specifically requested or not, it is a change in scope of the project. Scope changes can make a project larger or smaller. Scope changes can affect the timeline of the project and the cost of the project. These changes in scope are more commonly referred by the term scope creep. In a nutshell, scope creep is the change or growth of project scope.

Scope creep more frequently occurs during the later stages of a project, such as programming and testing, than during the earlier stages, such as design. Changes may happen in the later stages as the project team gains more knowledge of the problem and solution.⁸ Scope changes can be numerous small changes or can be a fundamental design change.¹²

A project manager often tries to manage scope creep. The goal in managing scope creep is to try to minimize the impact of any changes on the project, such as on the timeline and cost. Many company methodologies have change control processes for managing scope creep. These change control processes often include filling out forms describing the requested change in scope and an approval process. Some view this form as a good method to raise awareness of the project stakeholders to what the change is and what the implications of the change are, such as an increase in the timeline and an increased cost. Others view a change control process as a way to deter potential changes in scope.³

2.0 Why does scope creep occur?

In a Computerworld survey of 160 I.T. professionals, 80% reported requirements creep either “always” or “frequently”. That is a little scary when you think about it. It is also a wake up call. The leading reason reported (by 44% of respondents) for why scope creeps so frequently was “poor initial requirements definition”. The second leading reason that “new applications were unfamiliar to users” was reported by 36% of respondents. Next, 28% reported “projects take so long that requirements generally do change”. Lastly 22% of respondents reported “poor management/failure to manage user expectations” and 19% reported “failure to involve users in early stages”.¹⁷

There are many different possibilities for why scope creep can occur. For example, scope creep can be viewed as the pressure to deliver more than what was agreed to originally. Scope creep can also occur when the business requirements were not well defined upfront, and thus the scope changes over the course of the project as requirements are solidified.⁴ Requirements may have not been well defined up front if the correct people were not involved in the definition of requirements.

As a team proceeds through the various phases of a project, frequently one or more of the team members will strive to improve or perfect the situation or product. This may result in a change of the project scope.³

Additionally, as one proceeds through a project one may become more knowledgeable about an aspect of the project than they were previously or more knowledgeable with regards to a potential solution, thus prompting a change in previously defined requirements or direction. It is also often difficult for users to visual how they would use a new system until they see it. Sometimes users do not know what they want at all in the beginning. When the users do see the new system for the first time, changes may be needed as they see what won’t work or what they do not like with the system the way it is initially designed. Again, this can result is scope creep.

Some changes in scope are caused by external entities to the organization. Changes in items such as legislation, regulatory changes, market conditions, or in the technologies being utilized can cause scope creep. All these items are out of the control of the project team or their company.⁵

Additional causes of scope creep can include: (a) underestimating the complexity of a problem in unknown territory; (b) being a perfectionist; (c) consolidation of multiple projects; and (d) misunderstandings due to a scope that was not clearly defined.⁷

Complex problems in unfamiliar territory will frequently lead to scope creep. As the team’s understanding of the situation grows, the methods needed to reach the solution will likely change. Perfectionism can also lead to scope creep, as extra work can be done that is unnecessary. A good, but not perfect, solution can be just fine.

When multiple projects are consolidated into one, such as to consolidate resources, this can increase the scope of all the projects. Effort and time will be needed to determine how the various projects fit together.

When a scope is not originally clearly defined, many misunderstandings on what is to be accomplished or how it will be accomplished can result. These misunderstandings can lead the project in unintended directions, resulting in scope creep.

Many of the individuals working on a project want to enhance the quality of the project. One individual may want to add something to the project to distinguish the result even further than originally planned. However, both of these efforts can lead to scope creep.⁹

The project team’s or an individual’s desire to please the customer and reluctance to say “no” can also lead to scope creep. The team’s or project manager’s reluctance to work with the customer to evaluate the impact of the requested change can also lead to scope creep. If the customer asks for changes, they may think the changes can all be “fit in” easily to the current schedule and cost, if the impact of the changes is not explained to them.

When considering the question of why scope creep occurs, some individuals look in the direction of whom is at fault. It may be the customer that causes the creep in scope, as they ask for more and more changes in the product being produced. It may be the programmers trying to incorporate neat, new, helpful features that were not originally planned. Or it may be the project manager who allows agreements of what will be done to creep.²

Rather than placing blame on a certain individual, one should concentrate on the process itself. The key factor on scope creep is how we manage changes in scope. Are the changes agreed upon by all stakeholders consciously and approved in writing? Is everyone aware of the consequences of the changes, such as an increase in the project timeline or an increased cost?²

3.0 What are the potential affects of scope creep?

It is common for IT projects today to be over budget or to not be implemented in the initial target timeframe. Often the cause is attributed to scope creep. Therefore, in the eyes of many in I.T. management, scope creep is a bad thing to be avoided.

In general terms, scope creep can cost up to four times as much as initial development costs. The costs of scope creep can include: (a) deferred benefits and lowered return on investment (ROI); (b) increased maintenance costs; and (c) additional expected loss, such as if the project is cancelled.¹³

If a project takes longer than anticipated to complete due to scope changes, than it will take longer before the benefits can be realized. Additional cost and delayed benefits will result in a lowered return on investment. With a system in such flux with many unanticipated changes, it can increase the ongoing maintenance costs of the system, as additional changes may be needed to bring the system where it needs to be functionally. If the project gets too out of control due to all the changes, it may be cancelled. If the project is cancelled, the company will take a loss on what it spent on the effort.

Scope creep affects not only IT projects, but ANY type of project, such as building a new home. In researching this topic, several articles discussing scope creep were found on architect, home builder, and construction web sites. While this paper’s focus is primarily on IT projects, the concepts can be expanded to many different areas.

In Kuprenas’ and Nasr’s article “Controlling Design-Phase Scope Creep”, they analyzed data from the city of Los Angeles’ Department of Public Works, Bureau of Engineering to determine the impact of scope creep on capital improvement projects for Los Angeles. Among 96 projects studied, 28 of them experienced design phase scope creep. Design phase cost performance (DCPI) was determined as the ratio between the budgeted cost of design work performed against the actual cost of the design work performed. For projects with design phase scope creep, their average DCPI was 80% higher than the average DCPI for projects without scope creep. Over two thirds of the projects with design phase scope creep attributed it to poor predesign, which then required rework during the design phase. A small percentage of projects experienced scope creep due to owner/client agency changes or emergency work. As a result of these findings, the bureau implemented steps to work toward reducing scope creep. Some of these steps included written statements of the understanding of what was to be accomplished and formal predesign procedures, guidelines, and responsibilities.¹²

4.0 When can scope creep be good/acceptable?

During a project, the I.T. project team works with the client to gather requirements. This is often done through meetings, interviews, and questionnaires. However, many times the final product results in customer dissatisfaction. Many times clients are unable to specify exactly what they want in the beginning until they see the product. One author, Hal Helms, believes that this is the natural process in which clients determine what they want – which unfortunately falls under the title of “scope creep”. The resulting iterative work and scope creep will hopefully then end up producing the product the client really wants.¹

There are many statistics on the percentage of software projects that fail. One such statistic shows only 20% of corporate software projects over the last five years have been successful.^{1 While} there could be many interpretations of what is the definition of a successful project, many believe this means delivering a project on time, within budget, and delivering a product that meets the customer’s requirements and expectations. Thus, when the delivered product is not what the user wants, the process to change the product is a necessary step. This would imply scope creep is good in these types of situations, as it results the product the user wants. Good and bad often come in pairs. The unfortunate “bad” pairing that would come with this is that this type of process could result in running over timelines and going over budget.

Prototyping can be a useful tool to work with the client upfront in the requirements phase to define what the client wants before it is built. Going through a number of iterations of the prototype with the client and changing scope at that point can help better define the final product that is needed and better result in project success. This is again when scope creep can be a good thing. The goal is for rework to not be needed when the final product is delivered.

For consulting companies especially, scope change can be seen as a new opportunity to provide additional services.⁵ For the consulting company that will earn additional revenue as a result of being able to provide additional services, this can be a very good thing, indeed.

5.0 When is scope creep bad?

Scope creep is frequently viewed as one of the top reasons for project failures.⁵ Scope creep can cause projects to go over timelines and over budget. For some projects, when an excessive amount of scope creep is not be managed well, this may result in the project being completely stopped.

As a result, scope creep is often viewed as “bad” or “evil”. One source found even referred to it as a “devil”.³ This evil view of scope creep is not just held by project managers, but by I.T. and company management as well, whose additional dollars are being spent and whose projects are not being completed in a timely manner, or in some cases at all.

In Larry Murphy’s article “Using Software Project ‘Should-Cost’ Models”, he summarized findings from The Standish Group that more than $250 billion is spent each year in the US on information technology software development. Nearly 70 percent of these projects will reportedly fail in some manner. Close to 53% will cost 189% of their original estimates. Over 30% will be cancelled. Mr. Murphy also reported that other studies indicate that more than 80% of IT-related projects are over budget, late, lack functionality, or are never delivered. While scope creep can not be linked as the primary cause of all this, many believe it is one of the major contributing factors to project failures of these types.¹⁴

6.0 Ways to minimize scope creep.

Some individuals view that scope creep is something to be prevented. They see the way to prevent scope creep is to “stick to your guns” and not allow any changes in scope at all. To completely prevent any scope creep at all is a very difficult, and near impossible, task. Most project managers strive to minimize the amount and extent of scope creep.

The best way to minimize scope creep is to define the requirements up front as thoroughly as possible. Utilize different techniques such as prototyping and joint application development (JAD) sessions, to thoroughly explore and define the business and technical requirements.

There are many techniques to try to minimize scope creep or the impact of scope creep. The following list is a starting point.

Involve the customers in the earliest stages of the project possible.

The project should be a joint effort between the business unit(s) and I.T. Decisions should be shared in such areas as approach, requirements, and vendor selections.

Divide the projects into phases, with each phase resulting in a release. This enables changes to be brought into the fold on subsequent phases more easily. This also works well when time to market needs to be quick.⁶

Achievable goals should be set.

Prioritize requirements into must-haves versus nice-to-haves. Define the risk for each must-have requirement – that is the impact it will have if that requirement is not met. Utilize this information if trade offs must be made later on.⁶

Hold prototyping and JAD (joint application development) sessions between the business unit and I.T., to involve the user in a greater level of detail at an early stage.

7.0 Why it is so hard to prevent scope creep.

Scope changes can fall into two types: new requirements or modifications of existing requirements. Each request pursued requires that team members perform the necessary analysis, design, development, and implementation. Even if the project has been proceeding effectively to date, the new features will require additional time and effort, often resulting in additional cost.¹⁶

The impact a scope change request will have on the schedule can be recognized by most project managers. To determine a quantitative measure of the impact, the project manger can conduct a simple impact analysis, which can include a cost-benefit analysis. Many project managers, however, have a difficult time communicating the impact.¹⁶

If the impact is not communicated, then the customer will not have an understanding of what the impact is. If one change is accepted and to the customer there appears to be no impact, then other requests for changes will likely follow.

There is often such a desire to please or to give the customer what they want, that the project manager may not want to consider what the impact is. They try to fit the change in somehow.

Other times there may be a real business need for the change, and it doesn’t make since to proceed with the project unless the new change is incorporated. This will happen especially when legislation or regulatory changes occur.

8.0 Recommendations for Managing Scope Creep.

Preventing scope creep is an awfully tall order. My suggestion is that one should work toward managing scope creep instead of preventing it. As discussed above, in some cases scope creep can be good and in others it can be bad. But the need to deal with it, to effectively manage it, will always be there. If scope changes are poorly managed, it will lead a project down the path for disaster.

Based on my research, the following steps for managing the scope creep process are recommended as a starting point. After reviewing this list you will also find that some of these steps are equally applicable to steps for a successful project in general. This list is rather generalized, and you will need to consider if and how each item can be applied to your specific projects.

1. Have a project plan.

2. Have the business unit involved from the start of the project. The project should be a joint effort between the business unit and I.T.

3. Define and prioritize both requirements and deliverables, along with the associated risks.

Have project stakeholders approve these items in writing.

In addition to the normal benefits these items provide in laying down a good plan for the project, this information can be later utilized if requirements have to be weighed against each other for inclusion or exclusion if the scope changes.

4. Keep an open mind. Don’t just say “no”. Don’t try to avoid changes at all costs.

5. Ask questions. How did we learn about this new requirement?

6. Remember it is not personal. Don’t get defensive.

7. Utilize various techniques for more thoroughly defining user requirements up front.

While defining requirements, utilize prototyping sessions and/or joint application development sessions, so that the scope changes up front at this early stage.

8. Be conscious of the type of individuals involved in requesting the change. Sometimes an individual’s personality or position may affect the request for a change, and may make the request more valid or less valid. Each request will need to be weighed on its own merits. Examples include: a constantly present team member (more valid), a topic expert business unit person (more valid), a part time or new team member (may be less valid), a perfectionist (may be less valid), a know-it-all (may be less valid).

9. Have a scope change process, which can include the following.

A form to document the requested changes in writing can be completed.

An analysis of the impact and cost-benefits can be conducted.

A review process with the project stakeholders can be held on the requested changes and the associated impacts (such as additional resources required, affects on timelines, additional costs). The business management should be the ones to make the tough decisions.

All scope changes should be approved in writing.

10. Schedule the approved changes into the project.

11. Perform constant internal review to make sure the project is on track and within scope.

12. When initially estimating or budgeting the project, put in a 10% to 20% cost contingency allowance.

13. Start a list of enhancements for subsequent releases while still in development on the initial release. This will be for items that are determined are out of the scope of this project, or that are not show-stoppers where they can wait for a later release.

9.0 Sources

9.1 Web Based Sources

1. Helms, Hal. “In Defense of Scope Creep.” A List Apart. September 20, 2002: Issue 150. http://www.alistapart.com/articles/scopecreep .

2. Emery, Dale H. “Banish the Scope Creep.” April 30, 2003. http://www.dhemery.com/journal/archives/2003-04/banish_the_scope_creep.html .

3. Veryard, Richard. “In Praise of Scope Creep.” May 2001. http://www.users.globalnet.co.uk/~rxv/projmgt/scopecreep.htm .

4. Unknown author. “Scope Creep.” Viewed November 29, 2003. http://www.yourwindow.to/information-security/gl_scopecreep.htm

5. Alev, David. “The Scope Went Through the Roof.” Viewed November 29, 2003. http://consultingacademy.com/a07.shtm .

6. Zucker, Alan I. “Manage Scope and Compete on Internet Time.” ESI Horizons. July 2000. http://www.esi-intl.com/public/publications/72000internetscope.asp

7. Brenner, Rick. “Some Causes of Scope Creep.” Point Outlook. September 4, 2002: Volume 2, Issue 36. http://www.chacocanyon.com/pointlookout/020904.shtml .

8. Unknown author. “Scope Creep.” Viewed November 30, 2003. http://www.techweb.com/encyclopedia/defineterm?term=SCOPECREEP&exact=1 .

9. Johnson, Roy W. “Scope Creep and Other Scary Things.” Seattle Daily Journal of Commerce online edition. March 28, 2002. http://www.djc.com/news/co/11131884.html .

10. Doll, Shelley. “Seven Steps for Avoiding Scope Creep.” March 13, 2001. http://builder.com.com/5100-6315-1045555.html .

9.2 Non-Web Based Sources

11. Field, Tom. “When Bad Things Happen to Good Projects.” CIO Magazine. October 15, 1997. http://www.cio.com/archive/101597/bad.html .

12. Kuprenas, John A.; Nasr, Elhami B. “Controlling Design-Phase Scope Creep.” AACE International Transactions. Morgantown. 2003. Page CS11.

13. Mielke, Deb. “Rethinking ROI.” Telecommunications Americas. Norwood. November 2002: Volume 36, Issue 12. Page 16 (2 pages).

14. Murphy, Larry. “Using Software Project ‘Should-Cost’ Models.” AACE International Transactions. Morgantown. 2001. Page IT41 (3 pages).

15. Raths, David. “Managing Your Three-Ring Circus.” InfoWorld. Framingham. March 13, 2000: Volume 22, Issue 11. Page 93 (2 pages).

16. Zimmerman, Eric. “Preventing Scope Creep.” Manage. Dayton. February 2000: Volume 51, Issue 3. Page 18 (2 pages).

17. Anthes, Gary H. “No More Creeps!” Computerworld. Framingham. May 2, 1994: Volume 28, Issue 18. Page 107 (3 pages).

18. Buchanan, Josie. “Scopes Don’t Have to Creep.” Computing Canada. October 26, 1994: Volume 20, Issue 22. Page 31.

19. Radosevich, Lynda. “Beat the Clock.” CIO Magazine. November 15, 1995. http://www.cio.com/archive/cio_11_15_95_app.html

20. Williamson, Mickey. “The Science of Software Development.” CIO Magazine. April 15, 1996. http://www.cio.com/archive/041596/devenpor.html