Do Too Many Business Analyst Cooks Spoil the Soup?
I love attending conferences in different countries as it provides the opportunity to understand the opportunities and challenges that different business analyst (BA) communities face.
One extremely common challenge described by the attendees related to stakeholder engagement. A number of the BAs at the conference worked for companies that provide business analysis and/or software development on an outsourced basis, often to companies located in a different country. This can lead to a situation where it’s difficult to get direct and unhindered access to project stakeholders.
In fact, one attendee described a scenario where the BA role was duplicated, with one BA team in the client organization who was feeding requirements to the BAs in her organization. In situations like this there’s significant room for misunderstandings, duplication of effort, and conflict.
This raises an interesting question: How can a BA best operate when it doesn’t seem possible to get direct access to stakeholders and when there are multiple BAs from different organizations or different teams in the mix?
Clearly, duplication of roles isn’t desirable, but sometimes it’s necessary to work within the organizational constraints that are presented. As this forum thread on ModernAnalyst outlines, it is possible for BAs to co-exist in differing organizations, often with the BA on the business side focusing on the question of why a change is necessary—and by extension the BA on the delivery/supplier side would focus on detailed requirements and/or gap analysis for a specific solution.
I would extend this idea to say that a precursor to success in these situations is to clearly define and agree to the roles and responsibilities of the two BA functions. A good old-fashioned Responsible, Accountable, Consulted, and Informed (RACI) matrix should do the trick.
Once roles and responsibilities are agreed upon, it should become easier to secure stakeholder engagement—as there will be clear delineation between who is doing what. However, if there are still roadblocks, it’s important to understand why. If stakeholders don’t have sufficient availability to support the project, it is a significant warning sign that suggests the organization might not have capacity to support the project.
It is worth escalating this and also looking for other warning signs that might suggest the project is in trouble. Ultimately, if stakeholders really can’t spare the time to be involved with the project, then the organization should be asking “Should we press ‘pause’ until we can fully support and resource this project?”
Sometimes availability itself isn’t the issue—stakeholders might be reluctant to spend time with BAs because they don’t yet understand the value of the role. In this case it’s really important to understand their worldview, get to know their challenges and concerns, and show how business analysis—and good quality requirements—help them.
And to answer that earlier question: Building rapport and agreeing on roles and responsibilities are essential—and credibility comes through engagement and delivery.
