What is scope creep?

Project “scope” is the baseline for a project – what has been outlined in the requirements, wireframes, and design documents. This scope is agreed upon by all parties before moving on to implementation. The project’s budget and timeline has likely been estimated based on that scope.

“Scope creep” refers to when features are added that were not included in the original documented scope. This could happen because a client realized a business requirement late in the game, a developer realized a technical issue that will not allow a requirement to be implemented as planned, or someone on the team decided that a new “cool” feature needed to be included.

How do changes creep in?

 Failure to identify changes as “outside the scope” is a major reason why many software projects exceed cost and time. Changes which seemed small at the time can add up quite quickly. This hurts the client because the delivery date inevitably gets pushed back. And this hurts a development team, because they are spending  more time implementing, testing, and fixing features that were not included in the original scope.

Here are a few reasons why scope creep may occur:

• Requirements were not accurately defined.  The requirements analyst may have written the requirement with vague terminology. The correct stakeholders may not have been involved in the planning process. The client may not have even known what they wanted during the planning process.
• Users were not involved in the planning. The system requirements may have been developed without involving the people that are actually going to use the system. Once the system is presented to the users, new desired features are identified.
• Gold plating. This refers to continuing work on a project past the point of where the extra effort is worth the value it adds. Unnecessary features are added to “wow” the client.
• No change control process. As changes are presented that are outside the scope, there is no formal way for the team to evaluate whether it should or should not be implemented. Changes that should have been deemed out of scope get lumped in with the original scope of the project, with no consideration of how it affects overall time and budget. 

How can scope be managed?

A formal change management process is key. When a change is requested, it should be evaluated by all stakeholders based on impact to the schedule, impact to the budget, priority, and risk of both making or not making the change. The client must decide whether they want to go forward with making the change and also accept the associated change to the budget and timeline.

We cannot expect that what was documented in the requirements will remain static. Assuming this will only lead to frustration by everyone involved. Software development is fluid and dynamic. Clients realize new requirements. Developers realize technical roadblocks. New design ideas are discovered. With that in mind, there must be a way to manage the natural fluidity and change as it rolls through.