The role of a business analyst is a classic example of a leader without authority. A lot depends on you, but many people higher in the chain of authority want you to report back to them. Among all those stakeholders who expect updates and ask you “when are you going to be done with requirements”, who is really your client?
Let’s be upfront about who is not your client.
A project manager is not your client. You have to collaborate with them, provide them with updates, alert them to any risks or constraints you discovered, and work together on managing stakeholder expectations. But the requirements you analyze are not the project manager’s requirements.
Your functional manager is not your client either. They will expect you to act professionally and do your job diligently, follow established practices and report on your assignments. But they may not have the time or capacity to deeply understand and get involved in the business problems you are analyzing.
The architect is not your client. They may provide the overall architecture guidelines and help you understand the impacts of the problem across the enterprise. A good architect will ensure your scope is not too narrow and will point to existing architecture patterns and strategic direction that will help guide your analysis activities. But the architect would not get into the details of a particular problem with you as long as the changes are aligned with the architectural blueprint.
The software developer is also not your client. Sometimes you may hear a flippant comment that the developers are the only people who will actually read the requirements document, but you are not writing it for them. When the code is written, tested and deployed, and the system functions according to the requirements, the developer’s job can be considered complete, but who will feel the pain if the final product is not exactly what was needed to solve a business problem?
Your real clients are those business stakeholders who have a problem you are helping to resolve. Everything you do has to be done with business needs in mind.
- When someone questions business requirements, you must be there to explain, clarify and ensure a shared understanding is achieved.
- When requirements are in danger of being reduced or taken out of scope, you have to initiate the discussion and ensure that de-scoping takes into account the priority and business value for your client.
- When solution design deviates from what was requested, your role is to engage with the design stakeholders and ensure the solution will satisfy the client’s requirements.
- When test strategy and scenarios misinterpret the requirements, expected results or behaviour, it is your job to review, provide feedback and ensure alignment with the requirements.
- Last but not the least, when your client is asking for something that is unreasonable, contradictory, risky or violates important rules and guidelines, you have to work with your client to point them in the right direction, provide reasons and ammunition to help them make the right choices, hold their hand through the challenges of business analysis, and guide them to define requirements that will be able to solve the real problem and provide value.
Want to succeed in business analysis? Apply the twelve principles of the business analyst mindset. Sign up for the Why Change newsletter for more resources and to receive your free copy of the BA mindset poster.
Explore the #ba_mindset in other formats: books, videos, or courses. Or contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
Hi thanks for ssharing this