Requirements change and expand with any project. This is a natural aspect of software development. The project manager must anticipate and plan for this, for example by including buffers in contingency plans when committing. Scope creep (also known as requirements creep), however, refers to the uncontrolled expansion of capabilities that the team is trying to cram into an already crowded project. All this does not fit.
The constant change and expansion of requirements makes it difficult to implement priority functions in a timely manner. Continuously expanding functionality leads to delays, quality problems and wasted energy. Creep is one of the most common problems in software development.
Defining a framework
The first step in combating frame sprawl is to document a clearly articulated and agreed project framework. Without defining this framework, you will not even be able to understand that you are experiencing a creep of the framework. The techniques described in my article “Defining the scope of the project”contain several detection methods. Agile projects should write a brief outline of the framework for each iteration to make sure everyone understands what will and will not be implemented during that iteration. Alternatively, you can give each iteration a short name that conveys its purpose.
The Vision and Framework Document Template that I recommend includes a Limitations and Exceptions section. Here you can list any product features or characteristics that stakeholders might expect, but that are not known to be added to a product or to a specific release. You can also list items that have been excluded from the scope of the project so that you do not forget about the decision on the given framework. This listing of known limitations helps the team make quick decisions when a request is made to change a feature on the exclusion list.
Does this fall within the scope?
The second step in managing frame sprawl is to ask, “Does this fall within the box itself?” Whenever someone proposes an additional product feature, such as a use case, user story, functional requirement, feature, or outcome, note that the scope of the project may encompass activities and outcomes in addition to the supplied software. Your customers may be asking for an online tutorial to help their users learn the new system. This does not change the software product itself, but it certainly expands the scope of the overall project work that needs to be done.
In one situation, a customer contracted with a package solution provider to migrate three sets of historical data into a new package. During the course of the project, the customer realized that six more data transformations needed to be performed. The client considered this additional work to be within the agreed scope; the supplier argued that it was outside the scope of the project and demanded additional payment.
This was one of the factors that led to the cancellation of the project, a lawsuit and a consulting task, during which I helped determine the cause of the failure of the project. A clearer definition of the scope of work at the beginning, as well as agreement on how and by whom the costs associated with the change in the scope of project work will be covered, could prevent this sad outcome.
There are three possible answers to the question “Is this within the scope of the project?” If the new opportunity is clearly within the scope of the project, then the team needs to address this issue. If it’s clearly out of bounds, the team doesn’t need to work with it, at least not right now. They can schedule new functionality for a later release or iteration.
Sometimes, however, the requested functionality is outside the scope of the project as it is currently defined, but this is such a good idea that the scope must be expanded to accommodate it. The decision to increase the scope of the project is a business decision. Key decision makers must consider cost, risk, schedule, and market implications. This requires the project manager, management sponsor, and key clients to negotiate to determine how best to deal with the change in project scope. The business requirements owner — the management sponsor — must decide whether proposed changes to user or functional requirements will become the responsibility of the project manager as a result of the expansion (Figure 1).
Working with frame spreading
Below are some possible strategies for coping with the unexpected increase in requirements:
Postpone or remove some other, lower-priority functionality that was planned for the current release.
Hire additional staff to do additional work.
Get additional funding, perhaps to pay for overtime (okay, that’s just a joke), outsource some of the work, or purchase productivity tools.
Expand the release schedule for the current release to accommodate additional functionality (no joke).
Making a compromise on quality by hastily doing work that will have to be corrected later (not the best option).
Expanding the scope always comes at a cost. The people who finance the project must make an informed decision about which strategy for managing the project scope is most appropriate in each specific situation. The goal is always to provide maximum customer value consistent with the achievement of specific business goals and project success criteria, within existing constraints.
There is no point in pretending that the project team can implement more and more functionality without paying a price. In addition, it is always wise to anticipate some expansion of the scope of work during the course of a project. An experienced project manager will include contingency buffers in the project plans so that the team can reasonably adjust to the expansion without breaking their schedule.
Properly managing the scope of a project requires meeting several conditions:
Requirements should be prioritized so that decision makers can select options to add to the next release or iteration and can evaluate change requests against the prioritization of requirements in the current underlying structure. This is the purpose of the backlog in an agile project (indeed, in any project!).
The size of the requirements must be assessed so that the team has a rough idea of how much effort it will take to implement them. For this, we need relative units of the amount of work.
A team needs to know its average performance (speed in an agile project) in order to have an idea of how many requirements, measured in units of size, it can implement and verify in a unit of time.
Change requests must undergo a change impact analysis so that the team has a good understanding of how much each will cost to implement and what the implications for the project will be.
Project decision makers and their decision-making process need to be identified so that they can effectively make decisions about changing the scope of work if necessary.
Communication is another important element for managing the scope creep. You need to educate stakeholders to understand the importance of all change requests through a defined (and effective!) Change management process. The change management process is not a barrier, but rather a gateway, a mechanism by which the right people can make the right decisions to implement the right changes at the right time. Communicate decisions on approved change requests to all relevant stakeholders so that they know how the project is progressing and how it affects them.
Don’t fall prey to frame creep and try to suppress change in vain. Instead, set a clear framework early on in the project and then follow a practical change control process to deal with the inevitable evolution of requirements. For additional ideas on how to deal with this ubiquitous project problem, see the article “How to prevent and manage project sprawl.”
Change happens: deal with it.
This article is adapted from the book by Karl Wiegers “More About Software Requirements“.
The translation of the material was prepared as part of the course “System Analyst. Basic”… If you are interested in learning more about the training format and the course program, register on Open Day online.