How to manage scope creep when purchasing enterprise software

All enterprise software projects should start with a defined scope. The success of these projects depends on managing the risks associated with each project, and one of those risks is scope creep. Scope creep is defined as continually adding requirements as a project progresses. If the scope grows too large, it can even cause a project to fail. While this is a danger when developing software, it sometimes also happens when purchasing cloud or off-the-shelf software.

Gathering requirements is a journey of discovery where an organization learns more about what they need. The goal of the requirements phase of a project is to capture all relevant requirements in enough detail, including discovering unknown requirements. Any requirements missed in this phase will be uncovered in the implementation phase, where they usually cause project delays and cost increases.

In a previous article on requirements scope, we looked at adjusting the scope of an enterprise software selection project to match the features of products available on the market. In this article, we look at a slightly different problem, namely managing scope creep caused by users constantly adding requirements all the way through the project, which can put it in jeopardy.

Keep users focused

When starting a software selection project, it is important to meet with users and ask them for any requirements they have, and any potential software products they want to be considered. These initial interviews can be relatively quick, they build rapport with those users, and let the organization know the project has started.

With traditional requirements gathering, users are asked what they want, and this can lead to “unreasonable” requirements. This happens when users think this project is their one and only chance to get particular problems solved. After all, from a user perspective, what is unreasonable? Another problem with traditional requirements gathering is that it tends to rely on the users knowing what they want, which is a faulty assumption because most users know only their current pain points.

While necessary to build rapport, asking users for requirements and then capturing them is a very inefficient use of time, especially when working with user teams. A better process is to keep the initial interviews very short. Then use the technique of reverse engineering features into requirements to flesh out the list, and ensure you have all relevant requirements for the type of software being considered. Then you interview users again (usually in teams) and ask them to rate the requirements for importance.

This requirements rating process reduces scope creep by keeping users focused on what potential software products can deliver, rather than prompting them to dream up a wish list. It also keeps users focused on what they want, and not how it will be implemented. As long as the software can do what they need, how it meets those needs should not make any difference. If it does make a difference, that means some requirements were not captured.

Rate requirements for importance

An organization should always rate requirements for importance. Capturing how important a requirement is, and why it is important, is crucial to managing scope creep. When users are forced to justify why they want something, an accurate value for how important that requirement is to the organization can be assessed. Typically, requirement importance weights are decided by a team, and this tends to moderate those people who claim everything they touch is a showstopper.

Process

Although the aim is to discover as many requirements as possible in the requirements phase of the project, in reality requirements will be discovered all the way through the project. You need a process of capturing these requirements, and then rating them for importance. Even if they are captured after the software has been selected, they can still be used during the software implementation phase.

Putting it all together

A requirements profile is a list of requirements that have been rated for importance to an organization. It is the “gold standard” against which all potential products are evaluated.

Start with quick user interviews to build rapport. Employ the technique of reverse engineering to ensure you capture all relevant requirements in enough detail. Then ask users to rate the requirements for importance. This is the most effective and efficient way to develop the requirements profile.

When selecting enterprise software, Wayferry’s experience shows that keeping users focused on rating requirements for importance significantly reduces requirements scope creep.