Business Analyst Interview Question: Who are the key Business Analyst stakeholders, and why?
From a business analysis perspective, a stakeholder is someone with an interest or concern in the business or something that the business is doing. Key business analyst stakeholders are those individuals that are essential for the success of the BA’s work.
It’s important to first distinguish between external and internal stakeholders. External stakeholders are those that exist outside of a business organization, and which are generally beyond the business’s control. They include consumers and customers, government regulators, outside vendors, and creditors. While these external stakeholders are important, they are less directly essential to a BA’s work. And while the interests and concerns of customers are highly important to any business, their concerns are generally represented by someone within the business when it comes to business analysis work.
That leads us to internal stakeholders, who are people with interests and concerns within the business itself. Among internal staff, the following are what I consider to be the key Business Analyst stakeholders.
Executive stakeholders hold all the keys. They are ultimately responsible for the business, and often control the financial purse strings.
Executive stakeholders vary based on the project. If you are analyzing financial management issues, for example, your stakeholder might be the CFO or someone under her. Whereas if your project involves selling a new product, a sales executive might be a stakeholder.
While the list of executive stakeholders may be broad depending on the project, the executive sponsor is directly financially responsible for your project. The sponsor may also be on the hook for paying to develop the solution.
A BA needs to bring his best game when dealing with executive stakeholders. They can promote or derail your project with a simple decision. That’s why it’s essential to be highly tuned into their pain points so as to ensure your work directly addresses those pain points. And above all, be diplomatic.
Business and user stakeholders
Business stakeholders are not executives, but they are responsible for some aspect of the business. They often report to executives, so they have a high motivation to ensure project success. Even if they don’t, they are clearly responsible for ensuring that the business problem the BA is working on gets resolved.
Business stakeholders often have concerns related to cost and customer satisfaction. They indirectly represent the business’s product consumers. They want to be sure they meet the business need, at the lowest cost possible.
A sub-category of business stakeholder is the user stakeholder. A user is just what it sounds like: someone that directly uses the business solution in some way. They use the solution to meet a business need. User stakeholders usually have concerns related to the interface they are using. The interface must account for the business requirements, and do so in a way that maximizes the user’s experience (in terms of ease, accessibility, etc.) as much as possible.
Business stakeholders are the source of your business and functional requirements. They may also provide you the input for creating wireframes. Additionally, they will make you aware of legal and regulatory requirements you must follow. Sometimes they have a clear idea of what they want, and sometimes they don’t. Either way, the BA’s role with business stakeholders is to clarify what the business needs and turn that into requirements.
Technical stakeholders are primarily in the IT community. They include developers and their managers, testers, systems analysts, architects, software designers, DevOps and operations people. They are the folks responsible for creating the solution and then maintaining it on its technology platform.
The “pain points” for this group of stakeholders are diverse. For analysts, architects, and designers, the concern is ensuring that they can properly represent business requirements in the system’s architecture and design. Developers want to be sure that it’s feasible to build the solution as per the requirements in the time available. Testers want to know what criteria they should use for passing or failing the solution after its development. And operations people want to know what physical resources they will need (servers, processors, databases, etc.) to support the solution, and who will pay for them.
Technical Business Analyst stakeholders are among the most challenging for the BA. They are generally more interested in specific technical details rather than the big business picture. They may speak technical jargon. A BA will learn to handle these challenges over time. She can also call on subject matter experts to help answer technical stakeholder questions.
Cybersecurity is becoming increasingly urgent in the face of never-ending cyber attacks. Security stakeholders work in either policy or implementation. Policy stakeholders define the security standards (or controls) that a solution must implement. Implementation stakeholders, as you might expect, take responsibility for actually implementing and monitoring security controls. Their “pain points” are, of course, making sure that the business solution doesn’t get hacked–and that there is a way to recover if it does get hacked.
A Business Analyst reflects the concerns of security stakeholders by capturing security controls as non-functional requirements.
Management stakeholders are responsible for making sure their staff properly complete business analysis and solution development. Project managers are the most common example of management stakeholders. They may also be be your direct boss, the one who signs your performance review at the end of the year.
Management stakeholders care about ensuring that all work happens on time and within budget. They want to know how much time and how many people it’s going to take to finish work, and why. They also want to know why your project is exceeding budget when that happens. Essentially they want your project work to run smoothly and timely, so be ready to explain when that is not the case.
How would you answer an interview question about who the key Business Analyst stakeholders are, and why? Leave your thoughts in the comments below!