The Business Analyst meets with stakeholders, but does the Business Analyst manage stakeholders? The successful BA should engage in stakeholder management to ensure the correct user provides requirements.
A stakeholder is an individual who has an interest in your application and provides requirements, processes, or other information. The Business Analyst (BA) has the sometimes difficult task of eliciting the requirements from stakeholders and gaining agreement from them on those requirements. It is not sufficient to capture requirements; one must capture the right requirements. A BA needs to manage their stakeholders by understanding the stakeholders’ roles, scope, and influence to gather valid requirements successfully. The essential question is, “How does the BA do that?”
Trouble occurs when individual boundaries are “fuzzy” or blurred. Crossing into someone’s boundary is dissonant, as it causes the individual to be uncomfortable, stressed, and can result in conflict. The stress caused by boundary invasion often can be avoided if the Business Analyst identifies the scope of each stakeholder at the beginning of the project to provide a clear demarcation of each stakeholder’s responsibility. The RACI Matrix is an excellent tool for identifying the scope and boundary of each stakeholder.
A RACI Matrix is a chart of each task or process in the application which identifies by task who is:
- R – Responsible
- A – Accountable
- C – Consulted and
- I – Informed.
The Responsible stakeholder is the individual who is performing the activity or task, they are the “Worker Bee”. The Accountable stakeholder has the authority to make a final decision and is the individual who is held responsible for approval and sign off. A Consulted stakeholder needs to provide input prior to making the decision but does not perform a task, an example would be an attorney who needs to be consulted to ensure no regulations are not violated and has no other responsibility in the project. An Informed stakeholder does not need to be engaged fully but must be told of the final decisions and requirements. An example of an Informed stakeholder would be the manager of an interfacing application, who needs to know what data is being sent and when to start receiving data.
To develop the RACI Matrix:
A stakeholder can have more than one assignment, such as someone who is both “C” Consulted and “I” Informed. If there are many cells with two or more roles, then review the tasks to ensure stakeholders are not missing or improperly identified. The RACI Matrix should not have too many cells assigned to the same person. Sometimes, stakeholders do not want to participate in requirements gathering, and this reluctance can result in over-assignment to one participant. Not having the correct stakeholders may lead to incorrect or missing requirements, rework, and worse, loss of credibility. The RACI Matrix also must be analyzed to ensure there is one and only one Accountable stakeholder for each task; this will ensure everyone knows who the decision maker is, including the decision maker!
Below is an example of one style of RACI matrix, there is no right or wrong method of display. The critical factor is having all tasks identified and the stakeholders correctly identified and assigned.
|Develop Project Plan|
|Define Process 1|
Stakeholders Are Not Equal
A perceptive Business Analyst recognizes the realities of organizational politics. Development of an application is not a democracy; the majority does not rule, and every stakeholder requirement does not receive equal consideration. Those stakeholders with authority and a vested interest in the outcome determine what is a valid requirement. Stakeholder mapping of power and influence can be extremely useful in determining the stakeholder’s impact on the project and the weight of their words. Using the stakeholder list from the RACI Matrix, determine the stakeholder priority by assigning each stakeholder to one of these areas:
- High Power, High Interest. This is a decision-maker and influencer who has the most impact and the Business Analyst must meet or exceed their expectation.
- High Power, Low Interest. This stakeholder should be closely monitored because their lack of interest could result in undesirable influence or decision.
- Low Power, High Interest. These stakeholders are often the “Responsible” parties and can be helpful, providing details and guidance.
- Low Power, Low Interest. Allow these stakeholders to talk if they want to participate, but do not spend too much time on their requests.
Every participant should be listened to and treated respectfully. However, when confronted with conflicting requirements, consider the power and interest of each source. It would be unwise to select requirements from a low power/low interest stakeholder over a high power/high interest decision-maker.
To Speak or Not to Speak
When stakeholders are arguing among each other, too often the Business Analyst gets into trouble by jumping into the conversation when it may not be appropriate for them to engage. There is less harm in listening than speaking out of turn. How does the Business Analyst determine when to get involved in the conversation? The comedian Craig Ferguson identified three questions to ask before speaking:
- Does this need to be said?
- Does this need to be said — by me?
- Does this need to be said — by me — NOW?
Thinking before speaking is good practice, regardless of the situation!
Know your stakeholders, know their scope and boundaries, know what authority they wield, and manage each accordingly. As Warren G. Bennis, scholar on leadership studies stated,
Find the appropriate balance of competing claims by various …stakeholders. All claims deserve consideration, but some are more important than others.