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.