Scope Management: The Pitfalls of Steering vs. Managing Scope for Software Requirements

When defining software requirements we often have to walk the tight rope of balancing the desires of multiple business stakeholders with the budget and resource limitations of IT and support. The person managing the requirements often becomes the mediator, taking in input from all sides and using that information to guide the team to a consensus on scope.
However, just like an objective reporter shouldn’t only ask leading questions, you shouldn’t be steering the group into bad scope decisions based on some flimsy pre-conceived notions.


Here are some classic pitfalls of scope steering:

• Playing into Your Own Preconceptions – You may come into a project already having an idea of how you think the product should work or what’s important and what’s not. Perhaps you have a lot of knowledge of a pre-existing system or have worked on projects like this before. The more information you have coming into a project can really help, as long as you don’t allow it to close your mind to what stakeholders and Subject Matter Experts (SME’s) are defining as the current needs.
  
  


• The Squeaky Wheel Stakeholder – Personalities always come into play in project management and sometimes the loudest person gets the most attention. As the person facilitating requirements gathering, it’s up to you to make sure that requirements from other stakeholders and SME’s are not lost in the process.
  
  


• Defining the Solution Rather than the Need – A classic mistake of any software development project is allowing stakeholders and SME’s to define what they think the system should be, before defining the problem they are trying to solve. Any time someone is defining what the system should do, be sure that you also understand why.
  



• IT Says No – Okay, so maybe they don’t outright say “No!”, but there are times when IT resources will start rejecting ideas early-on because they are considered too big or too difficult. It is important to get sizing estimates from IT throughout a project; however, don’t abandon a feature right off the bat before understanding the requirements. Work with IT to help them understand the needs of the business and provide sizing estimates.

Effective ways to manage scope throughout requirements gathering:

• Define and Re-iterate Objectives – Working with stakeholders to define business objectives is a critical step early on in the project. As the requirements gathering process continues, each new requirement should clearly support a business objective. You should always have a clear vision in your mind of how each requirement relates to the objectives. If not, ask.




• Define the Business Value for Each Feature – This can be the most challenging aspect of any software requirements project, but it should be done to ensure that prioritization of features is base on value rather than gut decisions. How many customers will this bring to the site? How much will revenue increase as a result of this feature? How much will operational expenses be reduced? Background information such as company metrics and industry standards will help to assess the value.




• Inform Stakeholders of Impacts – As scope discussions are taking place let stakeholders know what the impacts are. Come prepared with IT sizing information so they understand the relative cost of each requirement. Identify dependencies between requirements so that the impacts of changes are understood, as well as any tradeoffs of features.
  

Managing scope will be a challenge on every project, but you can facilitate agreement among stakeholders by keeping objectives in mind and avoiding the pitfalls.

Out of Scope Out of Mind

Be wary the out of scope feature pile. Sure it is a quick and easy way to kill off an entire new project's worth of work, but did you kill it the right way? Make sure that when moving requirements to an out of scope status that the reasons for the decision are recorded and who made those decisions.

The best case will be where the feature has been mapped against a business objective that will not contribute enough to the organization's end goals. Can't argue when someone's favicon didn't make the cut since it would provide an estimated 2 cents to the yearly income from bookmark recognition.

The worst case will be a project's funder coming to you asking why his requested feature to save sales proposals in the system didn't make the cut while you stare blankly at your documentation looking for anything.

What is the Value of that Feature?

Alright. You've just identified the features that your client doesn't need going forward, the ones they can hold off on for now, and the ones that have to be implemented with the project. How did you come to that conclusion?

Were all the different group's champions in a room with you giving the thumbs up or down? Did the project funder push their features through? Maybe the cries of anguish from users as you held a feature over the out of scope bucket let you gauge how much it was needed. Are any of those a sound business case for the need of a feature?

Depending on the grandeur of your project, maybe it is. My bets are that it isn't enough. To really know what should or should not be implemented, every feature should be tied to a business objective. At the highest level you should have something along the lines of increase sales and decrease costs. From these you can have supporting objectives such as training sales, increasing client meetings, reducing cost of proposals, etc.

So did the project really need the feature to search for client information? I would imagine that kind of feature would be tied to an objective to allow for easier access to operational data, which ties to another objective to reduce costs of supporting client request. Given that, you should have a list of measurable KPIs (key performance indicators) for these objectives. This case might have a measure of the number of client requests for data per day and how long it takes to resolve the request with and without the search capability.

Now you will have to compare how strongly this feature affects the objective to reduce costs of supporting client requests. If there are a few other objectives that tie into this one, then you might imagine that the easier access to operational data could have a 20% correlation to the parent objective. From there you can take your current costs, multiply it by how important reducing costs of supporting client requests is and then multiply that against how important easier access to client data is.

So for example, let us say that our costs are $25,000. Turns out that reducing the costs of supporting client requests objectives is 30% of that cost. Now all the sub objectives are worth some part of $7,500. We said that the objective to provide easier access to client information was contributing 20% to its parent objective. This means that it is worth $1,500 of your costs.

Now you know that not having the feature costs you $1,500. You can estimate the implementation costs of the feature as well. If the implementation is higher, then arguably the feature should not be built. If the implementation cost is less than the value of having it, then you may want to build it, but at that point, you should compare the value of all the features in case you cannot build them all – choosing the ones with the largest value.

Indeed, Why Bother?

In his post Why Bother?, Mike A. used an interesting example. He questioned whether or not it was worth the effort to make a bed. He concluded it was. I disagree with one of his reasons, “it’s the right thing to do”. Here are two reasons to make the bed:

• To keep the sheets clean, when you are using the bed or bedroom for activities other than sleeping (such as a child playing on the bed).


• Because you find it sufficiently aesthetically pleasing to be worth the effort of making it.

How does this apply to requirements? We must always ask--what is the benefit of performing an action? Why are we doing this? Answers such as “because we always have” or “it’s the right thing” are insufficient. Why have we always done this? Why is it the right thing?

Controlling scope is one of the most valuable functions we provide and we must make sure there is value in everything we do. If we only use the bedroom for sleeping and don't care how it looks, it's not worth the effort to make the bed.