As you begin eliciting information about the requirements, it’s very likely that you’ll discover information that’s not quite a requirement and not quite a business need either but is important information that has relevant project context. It’s not surprising that the BABOK provides a way of classifying this information. And that concept is stakeholder concerns.
According to the BABOK stakeholder concerns
represent the business analyst’s understanding of issues identified by the stakeholder, risk, assumptions, constraints, and other relevant information that may be used in business analysis.
Stakeholder concerns are an output of elicitation and can be used in confirming elicitation results, defining assumptions and constraints, assessing organizational readiness, and defining the business case. I would agree, stakeholder concerns are important and something that many senior BAs probably deal with intuitively.
My guess is that most of us probably jump right to documenting risks, assumptions, constraints, etc without documenting the concerns outright. In one informal environment I worked in, where we used a wiki to capture requirements, I began to capture the stakeholder concerns as context for the requirements.
Let me give you an example that has come up recently. As I was chatting with the stakeholder about some new requirements related to search engine optimization, the concern came up that some of the current pages are very well optimized for our target terms. The stakeholder made the point that we didn’t want to fix what wasn’t broken as it might actually hurt us more than help us. This concern resulted in an additional requirement or two.
I knew that when I reviewed this with the developers, they’d push back on this complexity and so I wanted to capture the rationale behind it and also ensure they had this concern in the back of their mind as they were designing the solution. I would suppose in this example, the stakeholder concern became part of the business case as well as a potential risk for the project.
In this example, we have a full wiki page of requirements broken up into sub-sections that organize requirements by feature. When documenting requirements in this way, I often write a one or two sentence intro describing the feature. In this case, I captured the relevant stakeholder concerns in this introductory sentence.
I’m liking this approach because the concerns are relevant in the context of a specific set of requirements. It also ensures that the concerns aren’t overlooked. Without formal project management, we’re not really doing formal risk management or some of the other practices that might elevate risks. Documenting this sort of information in the requirements increases the chances the concern will be seen by the right person. Some stakeholder concerns are really notes to me as the business analyst to follow-up on. Others are relevant to those designing and implementing the requirements. Some, of course, are both.
The risk in this approach is that their is opportunity for ambiguity. What exactly is a developer supposed to do with a stakeholder concern? Does this mean a requirement is missing? Ideally, I’d hope the concern initiates a conversation if the risk proves to be a reality (or a strong likelihood).
Still having the concern documented within the requirements is better than it being buried in meeting notes or in a risk list that isn’t likely to be used given our current practice. At least it’s there for all to see and act on.
>>Learn How to Ask the Right Questions
Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.