Using a stakeholder requests list as part of scope definition

Oftentimes a business analyst gets involved in a project with multiple different business stakeholders with competing views. Before jumping into the analysis of the project or even defining scope, it can be helpful to pull together all the competing requests and categorize them. This activity can help shed light on the nature of the requests. It can be critical in solidifying the project because it consciously acknowledges the input of each stakeholder.

To pull such a document together, start by listing out all the requests you’ve received. The requests may have come from a document, an interview, forwarded emails, ticket tracking systems, or from an early elicitation session. I like to use a spreadsheet or a chart in a word processing document. This is important because you will be adding columns to further categorize the requests later. Evaluate each request. Is it a business need? A requirement? Is it detailed or high level?

Then begin to look at the requests as a whole. Are there any that relate to each other? If so, how? Are there overlapping requests that could be combined? As you move through this process, you might find you want to group some requests together. You can do this by establishing a requirements hierarchy (one requirement is a subset of the other) or by adding a column to your list to capture a “category”.

Next you want to try to make this list a useful decision-making document. More than likely, your stakeholder team will need to decide which items are in scope for the project or release and which are not. Consider carefully what information would help them make the most informed decision.

I typically start by listing out the business benefit for each item. Sometimes the business benefit can be a brief category (i.e. revenue, efficiencies, etc). Sometimes it is helpful to articulate a full benefits statement and quantify it. It really depends on who is making the decision and how constrained the resources are. The more requests you’ll need to cut, the more you’ll want to understand about the potential benefits of the highest priority requests.

There are some other useful attributes to consider. Here’s a run down of the most commonly used:

• Strategic Fit — how does this request fit in with the organizations strategy or the technology strategy?
• Cost — how much will it cost us to implement this?
• Sizing — in lieu of hard cost numbers, about how big is this request?
• Current functionality — how does this request relate to what the system supports today?
• Requestor — who initiated this request? Be sure to indicate if there are multiple requestors as this can indicate a high-priority feature.
• System — in environments supported by multiple systems, indicate which system this request impacts.

As you flesh out your requests, feel free to add or remove from this list. I rarely use all of the above attributes and I often find myself using an attribute I’ve never used before to meet the needs of a specific situation.

This list of requests will quickly become what I like to call an “in/out” list. In the context of the project or release you are planning, the stakeholder group can decide if a given request is in or out of scope.

Compiling a list of stakeholder requests can yield many other benefits as well. Even when a stakeholder request is not included in the scope of the project, it will often come up again later. Oftentimes as you are getting ready to finalize requirements a stakeholder will say, but I asked for X, did you miss that? You will be able to point back to a document like this and say, yes, I know you asked for X, and we decided to defer it. Without this documented, you tend to re-evaluate scope just when you’d rather be nailing down detailing requirements.

Just as important, the request list serves as a validation tool. You give immediate feedback about what you heard in an interview or other elicitation session before asking them to sign off on scope or requirements. Even if a particular request does not make it into your project scope statement, your stakeholder gets feedback that their request was considered. This is more powerful than you might think. Sometimes people just need to know that their ideas have been heard!

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. Managing chaotic situations by building “the list”
2. Reverse Engineering Requirements: Select a Business Owner and Identify Scope
3. Defining the scope of an epic before listing user stories in an agile product backlog