How well is the Business Analyst’s role defined in your organization?
The Organization Needs a BA Role
At a recent Business Analyst World conference in Toronto, it was not a surprise to hear many of the speakers lamenting about projects that continue to roll in late and over-budget. To have those expert speakers continue to lay the blame on inadequate and/or incorrect requirements reinforces the message that improvement in this area is vital. And therefore, as a key component to improving the requirements aspect, that the clear definition of and understanding of the role of the Business Analyst (BA) is more important today than it has ever been. As a practicing Business Architect and Requirements Consultant, I have been crusading about this for many years.
For a professional football team, winning a game consists of scoring enough touchdowns. The delivery of a solution, on-time and on-budget is akin to winning the game. Getting that requirements list properly is one touchdown that must be scored. Effectively communicating the requirements to management is another. Translating those requirements so the developers can build from them is another. In order to accomplish this, it takes many players on the team, each performing their individual roles well, collaborating tightly as a group, adjusting quickly to internal and external influences, so they can reach that goal line over and over again. Winning football teams, have learned that to be continually successful, the roles and responsibilities must be very well defined and fully aligned to the team’s strategy.
The Multiple Roles (Personalities) of the Business Analyst
Herein lies the problem in the daily life of a BA. I continually go into client sites and see that there is confusion as to what role the BA (and their organization) is supposed to play. I see BAs positioned within the lines of business (LOB), as part of the Project Management Office (PMO), centered in IT, peripherally attached via special projects, and within BA departments themselves. Is there one right or wrong place for the BA to be located? My opinion is no. It’s not where they sit; it’s what they do and how effectively they do it.
The confusion begins when organizations are unclear about the objectives the BA should have, the tasks they should be responsible for, and the methods they should use. Furthermore, there are unclear lines between how they should interact with the LOB, management/stakeholders, PMO, Solutions Architects, IT, Development and QA/Testing groups. All of this lack of clarity leads to weak results. This has the BA working in an environment where they have to define and manage business requirements in a very unstructured and ambiguous environment. Obviously an impossible task.
Each organization must evaluate how they operate and what they expect of their BAs. Do they perform business analysis work, develop requirements, do systems analysis, design business architecture, or all of the above? Without getting into all the varying positions, skills, and competencies of a BA (which we’ll cover in other articles), we are finding that the common and primary responsibilities of the BA of the 21st century fall into three main categories; 1) Business Architecture, 2) Business Analysis and, 3) Requirements Definition and Management. While these three areas are closely intertwined, it is too broad of a topic for discussion in this short article. Since business requirements is at the center of each of these areas, let’s first focus on that aspect.
The BA Role Needs Organization
One of the first priorities of an organization is to figure out their standard processes, policies and business rules for requirements definition and management. I recognize this is easier said than done – especially in a world of multiple and hybrid methodologies like agile, lean, iterative and waterfall development. I have gone into many organizations where BAs recognize and are trying to fix the problem but just can’t seem to get the rest of the organization on board. In these cases, it’s usually more the issue of the organization’s resistance to change.
A successful team employs a solid game plan, good playbooks supported by strong coaching to build that winning team. An organization needs to put in good management to build this environment with players who can execute. They should also consider bringing in experts to initiate this kind of transformation, especially if the right people are not already in place or it’s transitioning from other types of organizational structure and leadership.
It makes sense for a BA group to help champion this because coincidentally, enabling this transformation utilizes many of the same skills the BA must employ to get good requirements from the rest of the organization. Ultimately, it’s simply the defining of the business architecture and business requirements for the solutions delivery group:
- Definition/collaboration/alignment of vision and objectives amongst the stakeholders (Enterprise analysis),
- Discovery of the scope and analysis of the desired state solutions delivery business processes, with the right subject matter experts (SME),
- Elicitation of the processes to map the business requirements,
- Identification of the risks, issues and rules,
- Analysis and extrapolation of the functional requirements,
- Delivery and transformation.
This is the basic roadmap; however, just as there are thirty-three professional football teams in the NFL, there are the same number of variations and more, on how to run a game plan. There is no one right way. The BA team must understand the organization’s development and project environment needs, and then apply the right analysis and approach (i.e., practices) built on strong fundamentals.
To build this roadmap, the organization must first remove any confusion about a BA’s role and responsibilities. Am I a SME or a BA? Do I simply follow orders or do I help coach the stakeholders in order to get the right requirements? Am I a Solution Architect or Business Architect? Am I a Product Owner or Scrum Master? Am I a developer or do I help translate the business requirements into solution specifications? Am I a tester or a facilitator of helping get right test scripts built? Do I deliver the solution or am I the definer of the requirements to properly deliver the solution? Hopefully the latter in all of the above questions was your answer. Unfortunately, we see organizations who continue to get it wrong all of the time.
Why the confusion? That is a good question. I have seen the role evolve over the past 25 years. Some of it comes from the history and how the IT world has matured. Some comes from the demands that organizations have to become quicker and more nimble at delivering solutions. Others come from the myriad of development methodologies that have come and gone over the years which continually change the perception of the BA’s role.
The Agile BA
Let’s talk about Agile. It is an approach whose goal is to build a culture and organization where everyone should be able to do all jobs collaboratively, iteratively and effectively. I understand and like the approach. Heck, I was an entrepreneur in the 90’s and built software in this kind of environment. However, how to practically and pragmatically achieve that in the real world is the challenge — especially when mid-size and large companies find it hard to execute in an entrepreneurial fashion? But the push is in that direction and because of this, I see BAs who are scared that they don’t see their role clearly defined in that process. It’s there, it’s just buried in as part of the Agile methodology and not clearly delineated (follow us for more articles and webinars on this subject).
Wrong Assumptions Lead to Wrong Roles
Additionally, I have been in organizations where the BAs think their main role is to be the main SME. The assumption that the super SME will make a super BA is more often than not, an incorrect one. It’s the BA’s role to facilitate the discovery of the requirements from the SMEs in the business — then manage those requirements to properly align with the architecture and building of the correct solution. This is why it is hard to be a super SME turned BA. It’s very difficult, if not virtually impossible, to do both jobs at the same time and get results in a timely manner.
I’ve seen others who think their main role is as the QA/Tester. However, with no one leading the creation of good requirements, weak requirements tend to be produced, resulting —obviously— in a weak solution. Testing of a solution built from weak requirements may ultimately lead to the discovery of the right requirements but unfortunately at the wrong time: in testing. But we see it happen over and over again.
One thing is fairly consistent though. In all of the situations above, if the product does not deliver, then much of the blame is put on the shoulders of the BA.
Developing the BA Role
How do we begin to fix this problem? I suggest a two-prong approach. The first is personal development in order to improve our individual skills. The second is to improve how the BA and BA organization interacts with the organization as a whole. I will go into the personal development side in future articles but if I was to identify one key component of why projects fail, it comes when the requirements must be communicated to other groups.
The BA’s Role as Organizational Intermediary
Breaking down the barriers between departments and silos is one of the key functions of the BA. In each of the six key steps outlined above, there are many places where the BA plays a critical role in interacting with the various stakeholders:
- Ensuring the vision/objectives are aligned with the solution (management’s needs)
- Ensuring the requirements align with the business’ desired state process (business needs
- Ensuring that the solution architects understand the requirements (solution delivery needs
- Ensuring that development understands the requirements and the context from which they were derived (development needs
- Assisting QA/Test in building out proper unit and user acceptance test scripts (delivery needs
- Ensuring the organization understands the requirements to properly roll out the solution (delivery/transformational needs)
Many BAs, and the departments they work in, are often unclear about how to collaborate with the other groups involved. This can be a result of a number of challenges: turf issues, a lack of the organization’s confidence in IT to deliver the right solution, or the lack of strong, consistent solution delivery life cycle processes.
The BA as Communicator
This, in my opinion, has become the central role of today’s BA. They have to ask the right questions, then listen carefully and understand the responses. They need to identify needs, wants, rules, requirements, constraints, assumptions, issues and risks — and be able to differentiate between them. , They need to negotiate and facilitate compromises when there are differences of opinion. And they need to clearly communicate the outcomes and ensure that all the key stakeholders understand them. This is a two-way street that the effective BA must know how to navigate. Ineffective solution development and delivery can almost always be tied to ineffective communication.
As stated above, this is even more key with the huge paradigm shift occurring in today’s development process moving to an Agile culture. While many BAs feel threatened, this is actually an opportunity. Why? Agile’s manifesto is centered around fostering more effective communication and collaboration. No one is better positioned to play an integral role in this than a person with the skills of a BA.
The BA as a Leader
Another theme I heard at the conference is that the BA needs to become less afraid and take more chances. For me, this means a BA needs to take on more of a leadership role in the development process – leveraging their knowledge and strength in how to improve their requirements processes and practices. BAs need to focus their energy to support where their organization is weak in its requirements ability by applying methodical best practice approaches while helping to keep the strong areas stable. It’s cliché but it is true that we are ‘only as strong as the weakest link’. The solution only gets properly built through a strong team effort.
BA organizations need to continually analyze how their company stacks up with its ability to help the organization understand and communicate the requirements collaboration process amongst the various groups involved. In a recent requirements maturity assessment done by IAG Consulting, it was determined that most organizations are still very immature in this area. If that’s the case, then it will take education, negotiation, facilitation and collaboration with the other groups in the organization to get everyone working from the same requirements playbook. But that’s a lot of what BAs are supposed to do in the first place. If these skills don’t exist, find help and training: Training in requirements best practices, and in other critical BA competencies such as facilitation, communication and team building.
This also dispels another frequent misperception that the primary trait a good BA must have is technical skills. Yes, it’s good to have a working knowledge but more importantly it’s these soft skills that a BA must possess in order to effectively help an organization to be successful in delivering solutions.
Conclusion
I believe it’s time we stop redefining the BA’s role whenever a new development methodology appears. The same core principles of business architecture, analysis and requirements have existed since we first started applying bytes to business processes. Organizations lose more traction by letting this area continue to be amorphous and unclear. By paying more credence to the actual coding life cycle than to the creation of proper requirements in the first place, they continue to put the proverbial cart before the horse.
Strong requirements practices, analysis and collaboration skills have always been the foundation for effective delivery of solutions. Whether you’re called a systems engineer, product manager, program manager, project manager, systems analyst or scrum master, these capabilities must exist – and must be a priority – in any organization that values and treats seriously its product, systems and solution delivery.
– Trent Wong