How Can You Control Scope Creep?

Application development projects are vulnerable to many things that can cause failure, such as underestimating resources, inaccurate time estimates, and more. One thing that can easily cause an AppDev project to fail is scope creep. You can control scope creep if you know how to recognize it, understand what causes it, and have plans for managing or avoiding it.

How to Recognize Scope Creep

Virtually every AppDev project starts out with a definition of the project goal, timing, budget, and deliverables. You can recognize scope creep when a new requirement is added to a project that wasn’t covered in the original project description.

Something that will have a big impact on scope is relatively easy to recognize, although you still need to manage it. It’s the combination of a number of seemingly harmless changes that are often the reason why projects get out of scope.

Who Causes Scope Creep?

Scope creep can be initiated in any number of ways and comes from both inside and outside of the AppDev project team.

1. People on the Team

   If your team members aren’t all on the same page, you’re leaving yourself open to scope creep. A developer who isn’t crystal clear on what the requirements are can inadvertently go in a direction that doesn’t lead to the desired deliverables as they’ve been defined. Sometimes even a small deviation can cause trouble with timing and budget.

   As developers work on a project, they start to feel invested in the outcome. If one of your developers decides that the project needs a slightly different approach, or just a small alteration in how the user interface works, you’ve got a problem.

   Coming up with a better mousetrap isn’t a bad thing, but it’s critical that your team members can identify an idea that brings the project out of scope. The team members need to discuss the idea with the team leader to identify the effect it will have before going off on a tangent. One person going out of scope can get an entire team second-guessing what is in scope and what is not.

 

2. Project Stakeholders

   If you do a good job of stakeholder management, the odds of stakeholders increasing the project’s scope is much lower. But, even when stakeholders seem to be on board, a senior stakeholder with an unspoken agenda can cause havoc.

 

3. Customers/Clients/Product Owners

   It doesn’t matter what you call them, there’s always someone you’re responsible to in terms of the overall project. Scope creep caused by this person is usually easy to spot because you’re looking for the issue to arise.

   This is the person you got approval from, the one who reviewed all of the project descriptions and should understand the scope of the project. But, it can still happen that this person will ask for revisions or changes without realizing the effect on timing and budget.

 

4. Users

   Typically, you need to test the software with your users. User feedback can be important to make sure the final product meets your customers’ requirements. But, that feedback can also be fraught with out-of-scope suggestions. You’ll need to be careful about identifying revisions that you can do and stay within scope and suggestions that are truly going outside the scope of the project.

 

5. Others

   In many situations, there are others who can affect your project. You must take input coming from or output going to another entity into account during the project definition. Any type of unrecognized dependency can cause scope creep very easily.

How to Control Scope Creep

Controlling scope creep works differently depending on the application development methodology you use.

Controlling Scope Creep Using the Waterfall Methodology

The waterfall methodology isn’t structured to be change friendly. The project is defined at the start and specific plans are laid for the life of the project. This methodology is linear and sequential, where each phase is completed and reviewed before the next phase begins. As a result, ad hoc changes are discouraged. There is just too much work to change the entire project plan in mid-stream.

If a product owner wants to make a major change, the project team can respond with alternatives such as adding the change in a future release. If it’s not possible to reach a negotiated agreement, then it’s critical that you define the impact on timing and budget and obtain agreement from the product owner to expand both.

Controlling Scope Creep Using the Agile Methodology

The agile methodology is structured to avoid scope creep wherever possible. Since agile approaches AppDev in small increments and focuses on collaboration in an iterative process, any “changes” that appear before the team has addressed how to build a particular piece of the project aren’t considered changes at all. But, that’s assuming that the change won’t create more work than was initially planned.

Agile teams typically add a 20% contingency in project plans because changes do happen as business needs change. Agile plans account for that fact by giving themselves the flexibility to adjust to changes rather than discourage them.

Some people think a project is out of scope if the final product differs from the original project definition. Using agile, that’s not an issue. Agile focuses on satisfying the customer. If the final product does that, even if it differs from the original description, the agile team has completed a successful project.

Naturally, there are times when a change can cause scope creep in an agile project. For example, if a software feature has been designed, tested, and delivered, and then someone wants to eliminate it in favor of a different feature, that’s definitely scope creep. Another example would be a change that would swap a big change for something small. You can’t add 100 hours of work and eliminate 10 hours of work without scope creep.

If a change will cause an increase in the budget or timeline, then you’re back to negotiating with the product owner to approve more resources. Scope creep is typically easier to control in an agile project. It all goes back to the communication that agile stresses with everyone associated with a project.

From the start of an agile project, anyone who might request a change should understand the difference between when the response will be, “No problem,” and when the term scope creep might waft into the discussion.

How to Avoid Scope Creep

Scope creep, as with most problems, is easier to avoid than fix. Here are some things that will help you avoid scope creep:

• Make sure you have a clear scope when the project starts
• Communicate that scope to everyone who may be affected by the project
• Establish close collaboration among the team members and everyone who may be affected by the project
• Prioritize features when the project starts—you’ll use that list when you’re trying to decide if a change should have precedence over an existing requirement
• Establish agreement on how the team will handle changes
• Strive for transparency—a new request doesn’t mean you’ve done something wrong, so be open to working with the requestor to help them understand the tradeoffs

Scope creep is just one of the issues that can cause an AppDev project to fail, but there are solutions to software development challenges. Read our recent whitepaper, “4 Reasons Why Application Development Projects Fail.” Not only will you learn more about the top four reasons why projects fail, you’ll also learn about seven solutions that can help you avoid the high cost of failed projects.