Last week I was re-reading the BABOK chapter on “Elicitation”. Doing a deep-dive into the BABOK is part of my professional development plan to ensure I’m making the most of each project opportunity that comes along and also part of my initial phase of CBAP-preparation. For the most part, the Elicitation knowledge area seemed like a slam dunk. I’ve used most, but not all of the techniques (never done a focus group). I’ve documented the results of elicitation informally in meeting notes and at times jumped right into analysis by using prototypes of potential requirements to validate elicitation results with stakeholders. I was actually quite surprised at how nicely my experience stacked up to the contents of the BABOK.

But one concept stuck out to me and particularly came to mind the next day as I was capturing the results of an elicitation session in some draft requirements. 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 my current (and very informal) environment, where we are using a wiki to capture requirements, I’ve been beginning to capture the stakeholder concerns as context for the requirements.

Are your stakeholder concerns organized or more like unheard writing on a bathroom wall?

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 seems better to me 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.

How do you document your stakeholder concerns? How do you use them?

Related posts:

1. Using a stakeholder requests list as part of scope definition Oftentimes a business analyst gets involved in a project with...
2. Stating requirements assumptions, not the panacea you were hoping for We all know exactly what “assumption” stands for and how...
3. Help your stakeholders discover technical possibilities to define new project concepts As business analysts, we talk a lot about gathering or...