Released more than a decade ago, research from Lamri sh owed 71% of projects were found to exceed estimated budgets or required tuning of the project’s initial scope. Even now, after many years and the development of new project management strategies, scope creep remains a headache for our industry.

According to recent research from PMI, 44% of projects finished in 2015 suffered from scope creep. Scope creep is even present in fixed-price projects, where scope and budget are considered defined and firmly set at the start of an engagement.

Why is scope creep an issue?

Scope creep is often considered a concern solely for the development team; however, it also can cause a terrible headache for business leaders if left unchecked. Breaking initial deadlines, increasing time-to-market, growth of project budgets – the effects of scope creep can easily derail a client’s ROI.

Discovery is the most powerful weapon against scope uncertainty

Imagine a situation when a release is delayed for several months in a competitive market like mobile phones. During that time competitors would be able to introduce their own devices to the marketplace and make steps toward device improvement, while the original company is still struggling with the initial release. The problem can be even more severe if we talk about products that are built for years of use, like corporate information systems.

What about software for internal use - can scope creep affect the company in this case? The answer is yes, as scope creep causes a setback in software implementation, and the company does not reap the benefits of the desired system.

How does scope creep happen?

Scope creep is defined as uncontrolled changes or continuous growth of the project’s scope. It typically occurs as a result of one or more of the following reasons:

Unclear goals and business objectives: an inability to trace each requirement to a business objective leads to the creation of a solution that combines numerous unplanned features – and it may not even address the users’ needs.
Rapid changes in customer’s business context: changes in the client’s business environment, i.e. new regulations, can cause dramatic growth in product requirements.
Rush during project initiation: have you ever heard “an ounce of planning is worth a pound of cure?” Not dedicating enough time to research and planning can create mayhem for a development team, including compatibility issues, processes that are incomplete or nonexistent, and missed input from key stakeholders.
Absence of documentation with clear initial requirements: even if there is a defined change management process, the request can’t be identified as change request without comparing it to baselines established in the initial documentation.
Misinterpretation of requirements: even a small crack in understanding at the beginning of the project can turn into the Grand Canyon separating released features from real business needs uncovered during user testing.
Using buzzwords or business terms without proper explanation: the same words can have very different meanings in different domains; as a result, using unclear language sometimes leads to a misunderstanding of the project requirements and the client’s goals.
Absence of a change management process: in an ideal world, every client wish is considered an urgent request, but scope creep can occur when fl eeting ideas are implemented without any analysis of their value or an understanding of their impact on the project timeline.
Intentional increasing of scope without increasing budget: it’s not uncommon for a client to request new features in the backlog during development; usually he or she is well-meaning and just trying to address additional problems without the bureaucracy associated with initiating a new project and gaining budget approval. Another common case involves adding features that the client genuinely believes are small, fast, and easy to develop. However, both scenarios can cause scope creep, especially when they occur multiple times for the same project.
Micro(mis)management by the client: eager stakeholders sometimes set tasks directly with one individual developer or discuss and change details without notifying the entire team.

How can we avoid it?

First of all, we need to understand that not every change in a project’s scope is “scope creep.” Changes often are useful and desirable, as they can lead to new opportunities and competitive advantages. For example, newly discovered requirements can lead to additional release or even a separate project.

However, this is possible only when changes are properly managed. There is not a single magic bullet for fighting against scope creep, but some simple steps can reduce its risk to an appropriate level:

Choose the most appropriate project type. For example, a project with a high level of uncertainty in features is definitely not a good candidate for fixed-price. To avoid the growth of unexpected features, invest in an extended discovery phase before jumping into development for open-ended projects.
Do not skimp on discovery. Speaking of which, discovery is the most powerful weapon against scope uncertainty. Carefully consider how many business analysts and how much time you will need to uncover project needs. Remember that software development is a team game, and it is not enough just to dedicate BAs to the project. For an effective discovery period, you also need to account for stakeholders’ time and involvement in the project from the very beginning.
Understand the business needs of the client. Some scope extension is dictated not by a business objective, but from a wish to make the product better looking or add a “wow” factor. But, you won’t be able to separate legitimate requests from distractions without understanding the real needs of the client. Ensure that the whole team understands the business objectives, and some change requests will naturally disappear. Indeed, sometimes even client stakeholders need to be reminded about business goals for the purposes of avoiding scope creep.
Monitor the client’s business context. Some kinds of changes can be predicted; for example, new government regulations for healthcare providers will almost surely cause changes in the software used by hospitals. Monitoring major trends allows development teams to identify potential changes in the earliest stages.
Document the initial requirements. Requirements received from the customer or elicited during the discovery period must be documented. No matter what it looks like or how it works – from a formal SRS (software requirements specification) to just a prioritized backlog – both stakeholders and the development team need to agree on baselines to use as context against additional requests.
Document what is out of scope. Not only should you document the features included in the initial scope, you should also provide a list of features that are definitely out of scope, like integration with third party tools. A predefined list of items that are out scope can help classify new requests as scope extension.
Fix and val idate your assumptions. Although assumptions can be wrong, sometimes teams must make them to provide an estimate at the start of a project. Such an approach can be acceptable if, and only if, the assumptions are fixed and communicated with the other documentation. Clients must understand that if any of the assumptions are refuted, separate features or even the whole scope might need to be reviewed and re-evaluated.
Establish and respect a change management process. When one is defined and communicated to all stakeholders, the change management process helps avoid situations when any request is immediately added to a backlog. Typical change management activities, such as impact analysis, stakeholder review, and a formal approval process, ensure that changes align with business objectives.
Traceability of business requirements to functional ones. Requirements traceability helps manage the scope and analyze the impact of each change. Tracing the requirements back to specific business objectives also ensures that the stakeholders’ business needs are met while avoiding unnecessary changes.
Prioritization. It is impossible to accomplish everything at once because of time, resources, or budget constraints; prioritization defines the most important items included in a project’s scope, and, after discovery, it is the most powerful tool against scope creep.

The truth is changes in scope will happen, and changes themselves are not something that should be feared. However, we can make the development process more efficient by avoiding them whenever possible and controlling them otherwise.

Looking for more ways to protect your software investment? Take a few minutes to watch our on-demand product security webinar with Certified Ethical Hacker and SoftServe security expert Nazar Tymoshyk.

Volodymyr’s recent stories

Scope Creep: When Development Projects Don’t Go as Planned