Managing Stakeholder Expectations
“Do you also want …?”
“Adding that shouldn’t be a problem.”
“What if it also did …?”
These phrases all have one thing in common… We have all said them, and have lived to regret it.
As a Business Analyst, an important task is working with stakeholders to elicit solution requirements. The challenge faced by the BA is balancing the solution’s needs with stakeholder’s wants, keeping them in line with the scope of the project, and managing the stakeholder’s expectations of what what will be delivered.
Easy peasy, right?
According to A Guide to the Business Analysis Body of Knowledge v3:
“The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.”[1]
Requirements are not just what the stakeholder is asking for, they are what is needed to achieve the goal of the project, adhere to business rules and comply with regulations.
You don’t need to promise the stakeholders that you will deliver a pie-in-the-sky answer to all of their problems. You don’t even need to promise that it will have slick graphics, pop-ups, and snazzy sliding accordions (unless those are appropriate to the needs of the solution.)
You do need to promise that a solution will be delivered that will satisfy the requirements to properly address the problem. That includes things like performing calculations accurately, storing and retrieving data correctly, and functioning without errors.
Management is also counting on you to analyze the stakeholders needs, and align those needs with the scope, timeline and budget of the project.
Separation Anxiety
We’ve all heard the phrase:
“One person’s trash is another person’s treasure.”
It is often very difficult for stakeholders to understand the difference between “Needs” and “Wants”. To complicate the situation even more, different stakeholders will have different ideas of what they consider a Need. To effectively negotiate each group’s Needs and Wants, the BA needs to understand who the stakeholders are, and how the solution will impact them.
Needs and Wants can be defined in many ways, depending on the problem being worked on, but here is my general take on them.
Need:
Something that is required for the stakeholder or solution to accurately, and properly, perform or complete an action, calculation, or transaction, and cannot be accomplished through any other means. This must be satisfied for the solution to be accepted.
Want:
Something that is preferred, but is not required for the stakeholder or solution to accurately, and properly, perform or complete an action, calculation, or transaction, and could be accomplished through some other means. This does not have to be satisfied for the solution to be accepted.
In your requirements document, list and prioritize each requirement from the stakeholders. Label each requirement as “Need” or “Want”. Needs, of course, would be the highest priority items to work on. Wants, conversely, will be the lowest priority items to work on.
When you estimate the project, calculate the effort for Wants along with the Needs. Estimating both will allow you to break the effort down based on just the Needs, just the Wants, and the Needs + the Wants.
The Wants are your discretionary items that can be cut to keep the project on schedule and/or within budget. Having an estimated effort for the Wants will support your conclusions, and enabled you to shift prioritized items more easily.
Use this list as a guide so all parties can clearly see what will, may, or won’t be part of the solution.
For example:
| Requirement | Need | Want | Priority | EOW | |
| 1.1 | Ability to save both a billing address and a mailing address for a customer. | X | 1 | 2.5 | |
| 1.2 | Billing address to be required. | X | 1 | 0.5 | |
| 1.3 | Mailing address to be optional. | X | 1 | 0.5 | |
| 1.4 | Clicking a button will automatically populate the mailing address information with the billing address information. | X | 5 | 1.0 | |
This method is a simplified version of the MoSCoW technique.
MoSCoW stands for:
Must Have
Should Have
Could Have
Won’t Have
(The “o”s don’t stand for anything, but they do help to make it a catchy acronym.)
Very briefly, with the MoSCoW technique, requirements are prioritized, and worked on, in order of greatest value (Must Have) to least value (Could Have). Won’t Have items are not included in the plan at all.
The technique is designed to focus effort on delivery of all the Must Have requirements. The Should Have and Could Have requirements are the discretionary requirements to be removed if the solution is in danger of falling behind schedule.
Regardless of the method you use to define the Needs and Wants, It’s imperative to set the expectation upfront that not all items may be delivered given the time and resources allocated. When the stakeholders understand this, from the beginning, it becomes easier to prioritize each requirement, and acquire approvals.
Development can then move forward on the Needs, spending the lion’s share of time making sure they are rock solid. If time permits, some Wants can be added, provided any added testing or issues they may introduce don’t negatively impact the project schedule.
In the end, it is your responsibility to be sure that the goal of a fully functioning solution is delivered on time, within budget, and with all the stakeholders Needs met.
Understanding all of the different stakeholders, recognizing their unique needs, and effectively eliciting their requirements in order to separate Needs from Wants, will enable you to achieve your goal.
References
Hammond, A. and Hazlewood, M. (1970). Gimme Dat Ding [Recorded by The Pipkins]. On A-Side [SINGLE] UK: EMI Columbia (DB8662); US/Can: Capitol (2819).
- International Institute of Business Analysis. “Introduction.” A Guide to the Business Analysis Body of Knowledge. Vol. 3. Toronto, Canada: IIBA, 2015. p3.