Every day, Business Analysts need to work with a variety of stakeholders to elicit, define and verify requirements. There are a number of challenges associated with this. This article highlights some of those challenges and suggests what can be done to address them.
Stakeholder challenge 1: Stakeholders resistance to share information
Unfortunately, a Business Analyst may encounter a stakeholder/s who’s not forthcoming in providing information. The stakeholder might attend your workshop, but it takes a huge amount of effort to get any information from them or they won’t commit to meeting after several attempts which causes delays.
There could be a number of reasons why a stakeholder isn’t forthcoming with information:
- Resistance to change: they prefer the way they’re working and don’t see the value in changing
- Issues in office politics the Business Analyst may be unaware of
- Experience of previous projects failing resulting in stakeholders not wanting to spend more effort on another project that may also fail
- Fear of being made redundant or replaced
A Business Analyst needs to prepare ahead of a workshop by undertaking a stakeholder analysis and communicating a clear plan for the workshop, outlining the purpose, desired outcomes and the value behind what’s being done. A good technique to use for a workshop is the ‘POWER’ start technique (Purpose, Outcomes, What’s in it for them, Engagement, Responsibilities). Consider changing your usual approach with difficult stakeholders. Gain their trust by pointing to something you have in common, show the value of the project or share success stories from previous projects.
Stakeholder challenge 2: Stakeholders have the urge to design the end system/solution
If a stakeholder is very close to a process or how a system operates, they’ve probably identified inefficiencies and created workarounds to the problem. When a Business Analyst tries to elicit requirements from these stakeholders, these stakeholders will tell them about solution(s) rather than real needs. In most cases, the solution they provide is the perceived problem, but not the root cause of the problem. A Business Analyst has the responsibility to solve the right problem.
A Business Analyst wants to ensure that the right problem is solved and not the perceived problem. They can use the ‘The 5 'W's technique – Who, What, Where, When and Why?’ to identify the root problem. Once the problem is identified, create a problem statement.
A good problem statement will:
- Identify the problem, opportunity or challenge
- Identify who is affected by the problem and what the impacts are
- Define what a successful solution would be, do or enable
Stakeholder challenge 3: Stakeholders mis-define their real needs
Stakeholders mis-defining their real needs is one of the biggest challenges a Business Analyst faces. If the BA cannot successfully translate and define requirements on behalf of stakeholders, then any poorly specified requirements may lead to projects failing. Some scenarios where stakeholders may mis-define their requirements are:
- Stakeholders use the project as an opportunity to define their ‘wish list’. This may lead to requirements being missed or poorly prioritised
- Stakeholders with a technical background define the requirements as a technical specification to resolve the problem
- Stakeholders provide requirements on areas they’re not experts in
Business Analysts have to actively assess requirements received from stakeholders and ensure that quality requirements are documented and proper stakeholder analysis has been done. Define the ‘as-is’ and the ‘to-be’ models to understand the features to be delivered. A good method to assess the quality of a requirement is to use the acronym ‘SMART’ (Specific, Measurable, Achievable, Relevant, Time-boxed).
If using user stories, good criteria is to use the acronym ‘INVEST’ (Independent, Negotiable, Valuable, Estimable, Small, and Testable).
Stakeholder challenge 4: Accept or ignore requirements when more than one stakeholder is involved with different views
Another challenge faced by Business Analysts is when conflicting requirements are received from different stakeholders. The challenge for the Business Analyst is to identify what requirements need to be accepted without creating conflict between the stakeholders. A decision has to be reached where both parties agree on what needs to be delivered.
The Business Analyst can arrange a face-to-face meeting with both stakeholders to understand the perspective underpinning each requirement. It’s useful to make the process as visual as possible for transparency and also so that complex requirements can be more easily understood. The best outcome will be mutual agreement on how to go forward on the conflicting requirements.
If an agreement can’t be reached, the Business Analyst should approach the nominated decision maker identified by the stakeholder analysis exercise. A technique like the ‘RACI’ model (Responsible, Accountable, Consulted and Informed) can be used to identify the roles and responsibilities of the stakeholder on the project.
The common theme with most stakeholders’ challenges is that a Business Analyst must be able to communicate effectively and manage people. This is also not a topic that can be studied and be an expert in. Continuous effort by the Business Analyst is required to improve communication and management of stakeholders.