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.
Click here to learn more about the Requirements Discovery Checklist Pack
Hi Laura,
I’m wondering whether beneath every ‘stakeholder concern’ lies an underpinning ‘Risk’ or ‘Issue’….for every project I’ve worked on we’ve always had a ‘Risk Log’ and an ‘Issues Log’, which are typically just Excel spreadsheets. Even for projects that don’t require as much so-called formal project mgmt rigour we always have these logs, the rationale being that for any project no matter how big or small, there are always going to be Risks and Issues that come up and these need to be captured somewhere.
In the past, we’ve actually used a single spreadsheet to capture both – we simply have one of the columns in the spreadsheet set as ‘Type’ from which either “R”(isk) or “I”(ssue) must be chosen for each record that is entered. In the specific example you used, this could be reframed and stated as a risk. I suppose for something that is not deemed as being either a ‘Risk’ or an ‘I’ssue – you could set up a third “Type” that being “C”(oncerns).
Like most things, there’s more than one way to skin a cat. The important thing is that as long as it is being captured and is visible then that information can be used.
Adam
Adam, I think you are definitely right as there are many ways to manage this information. A project risk list or issues log may not be specific to requirements-related risks, so on a large project it can be a difficult tool to use as a requirements checklist of sorts as you’ll end up wading through many irrelevant risks and issues relate to the project as a whole and not just the requirements.
What I found when I started thinking about stakeholder concerns is that it broadened my perspective of what information to capture. Typically I try to keep risk and issues lists relatively short and actionable. They need to be reviewed and updated often. Issues are driven to closure. Risks are actively managed. Stakeholder concerns, on the other hand, can include risks and issues, but they can also include other pieces of information or individual perspectives that might not make it into an action-oriented list.
In this particular informal environment I was also using stakeholder concerns as a way to communicate valuable requirements-related information to the development lead who was filling a systems/technical analyst role. This helped eliminate redundant conversations with the stakeholder group and put some context around the business requirements.
Hi David,
When I started writing this post, I was capturing them as you are — all on a single page. I think this can still work well for small, well-defined projects.
For larger projects, I’m considering a separate page. We use a wiki, so each project has an overview page which is organized much like a traditional scope document. I’ve added a new section to this project overview page to capture concerns.
They do come up in multiple stages as stakeholders can have concerns about the need, about a specific requirement, a specific implementation decision, etc. I’m now leaning towards the fact that embedding them in the requirements documents, though it promotes visibility, makes them harder to manage. Like risks, issues, and other miscellaneous information pieces for a project, I need to own the list and own that the items on the list are addressed.
Laura
Hi David, if I can add my two cents in, I use a tab in excel to capture stakeholder concerns and then another tab to capture project issues outstanding.
Michelle
Hi Laura,
Do you capture your stakeholder concerns on one page and then capture your requirements on another set of hierarchical pages?
At the moment, I’ve been placing all of these on a single page to avoid burying the concerns under too many layers of clicks. I’m trying to keep them more visible, so readers are reminded of them.
Are these coming together all at once or at different stages in your elicitation?
Stages. While I wish all concerns would come out all at once, it never works out that way.
You could also use SharePoint in a similar fashion as a wiki.
Hi Michelle,
That seems like a great approach as well. I’m experimenting with a list in my latest project. I will see what the stakeholders think. So far, I like that it has given me the freedom to capture items that might not be “risks”, “issues”, or such yet. They are just concerns and so they don’t have to fit into any specific piece of the plan, but I won’t lose track of them in meeting notes or other less structured ways of capturing the information.
Laura, great topic and post. I document stakeholder issues/concerns in Excel. It is easier for me to follow up and review as well as determine whether they have been reviewed and worked through or have not been addressed. The biggest problem I see is that some companies do not listen or value the stakeholder concerns and that is where the project will fail. We are delivering a solution to the business (business reengineering or IT solution) and the business needs to be heard. This is one of the first things I work on when I begin to gether business requirements and then add to it throughout the project. I also review it regularly with the business so that they know that their views count.
Michelle
Hi David,
Thanks for your comment. We are using a wiki as well and I find the same thing happens. Over time things need to be reorganized and what worked at the beginning of a project does not work as well later in the project. I’d be curious to hear a bit more about how you keep this organized this way on a wiki. Do you capture your stakeholder concerns on one page and then capture your requirements on another set of hierarchical pages? Are these coming together all at once or at different stages in your elicitation?
Great timing on the post! I’ve actually just started to document stakeholder requirements on our company’s development wiki (we use Trac) and I’m really finding this discussion helpful.
I’ve currently been keeping all of the stakeholder concerns on the same wiki page, as I find for me this requires less navigation/linking and makes (me at least) more organized, but I’m early in developing the process for this. Ofcourse, ‘what works for me’ will change between people/organizing etc. I suppose the key is trying something new and seeing if it works for you!
First post from a long time reader! Thanks Laura
Hi Dave — So that’s two votes for a separate deliverable with stakeholder concerns. I think I must make an attempt at it in a project sometime soon!
Connie — Very interesting insight about stakeholders wanting their concerns swept under a rug. I have experienced this and it can mean that the ROI on the project is off. If we don’t want to face the real risks of the project, then there might be a reason not to do the project at all. Concerns swept under the rug can be opportunities for the business analyst or other project leader to step up. If a concern is raised, I do feel compelled to follow it through and ensure we’ve addressed it through requirements or planning. Perhaps by helping the stakeholders build mitigation plans you can position your company to deal with valid concerns proactively rather than in a reactive way.
As far as the wikis, you are not going to find a better discussion than the one Adriana led us through in a previous post. I have listed a few pros and cons in the comments as well: https://www.bridging-the-gap.com/wiki-requirements-management-benefits/
I do agree, it’s not about the tool, it’s about the process or not even about the process but what you bring to the process. But sometimes the tool throws your typical process upside down, which can be a great learning experience as it forces you to rethink “why” behind your documentation.
Best,
Laura
Hi, Laura,
Very interesting approach. Sometimes I have sponsors who want to stifle concerns and risks, because raising them without a specific mitigation strategy or resolution can cause inordinate swirl in the upper ranks. Have you encountered that?
Also, I’m very much interested in how you like using the Wiki approach. Can you give the pros and cons? I’m used to process (many processes and tools) and to me the tool is never the issue. It’s committed, smart people working together as a team that make the project work and prevent problems.
Thanks for an interesting discussion!
Connie
Great post! Every BA should think about and address stakeholder concerns.
We often use an approach similar to Jennifer’s. The stakeholder concerns are documented in a separate log … sometimes we call it a risk log or a parking lot or whatever. We address them similar to the way that a PM would address risks. We have additional discussions with the stakeholder to determine the impact and probability of the risk occurring and then develop a mitigation plan. In some cases, it is determined that the concern can be ignored. But, if it is decided to avoid it or attempt to reduce the impact or probability, then we determine what the system must do for that to occur and document additional requirements.
Hi Jennifer,
I like that idea and might try it in a future project. It seems like it would be a great checklist to refer to during various project phases, such as starting design, starting development, testing, and transition. Each time making sure the concerns are addressed appropriately.
Laura
Hi Tola,
That’s a great question and one that would merit a whole set of posts in and of itself. I will add it to the list of posts to write as it is a good topic!
In the meantime, you might want to consider a bit of research on personas, which is essentially developing a profile of your target customer. This can help guide the elicitation and prioritization processes.
Focus groups and surveys are also common techniques used.
Laura
Laura,
You are right about the situation. And thanks for the tip.
I was just wondering if there was a special way to go about eliciting the requirements in that situation.
Thank you.
Tola.
Hi Tola,
If I understand your question correctly, the stakeholders you are working with are not direct users of the application. Instead, you are working with a sponsor who is building a product to be used by a collection of people you hope will buy your product?
I have often been in this situation and it does impact the requirements process you use significantly. As far as stakeholder concerns, your business owner or sponsor is still the person from whom you would elicit these concerns and document them. He might be concerned, for example, about not knowing much about a specific user behavior. This concern could become a requirements risk that you mitigate through a focus group or a survey.
I hope that helps.
Laura
Laura,
Great topic! I agree with your assessment that stakeholder risks or concerns should be documented. Working from the assumption that there is no formal project management involvement, I agree that a BA is in the best position to capture these details. I particularly love the idea of a Wiki approach as I think the entire project team should shoulder some accountability for documenting and resolving these concerns which could tie to risks.
I do believe that the concerns should be documented separately (but traced to, if appropriate) the requirements. Concerns from a stakeholder can be directly impacted (positively or negatively) by the requirements and how they are fulfilled but other times they could be completely not related to the requirements. I would propose that by having a matrix outside of the requirements to track the concerns, you can still have global visibility to the concerns.
Good luck with your efforts! And keep the great conversations going!
Great post Laura. I am actually new to the BA professional although i have about 3 years IT experience.
My concern when reading about stakeholder goals is that, given a situation where you are working as a BA outside a formal organizational context. Actually, an IT project which is just a idea of a person (say something like twitter or facebook). The situation i find myself is that i have helped identify and expand the ‘primary’ requirements based on the idea the person has and my understanding of the idea. However, because it is not a formal setup (a possible start-up actually) , am just playing a BA role to help gather and document requirements and communicate them to the developers. Is there a particular approach i am meant to take? considering the fact that the stakeholders are primarily the guy that has the idea, the developers and myself.
I hope you understand the situation am in and can provide some tip.
Thanks
Tola Anjorin MBCS
Pingback: Tweets that mention How do you capture stakeholder concerns? -- Topsy.com