When Business Analysts Cross Boundaries—and Why It Helps Projects Succeed

Boundaries exist, and I often cross them.

I work in a very structured environment where a defined business improvement/legislation compliance program exists. The project team consists of a project manager, a business analyst, a test manager, a set of testers, business stakeholders, personnel responsible for enforcing policy guidelines, and project sponsors. As a result, every individual has a defined role in the project from start to finish, and the project’s outputs are either a new or modified IT system.

As a business analysis professional, I often find myself crossing the role boundaries in projects. I’m conscious of not stepping on others’ toes, but you might wonder: Does anyone tell me to cross the boundaries of my role or expand it into different areas?

The answer is a strong no. The motivation behind crossing role boundaries is to achieve the best possible outcome and ensure a smooth go-live of the solution.

Why Business Analysts Sometimes Step Beyond Their Role

Boundary A: Developing the Business Test Cases

It’s a widely accepted practice that a tester is involved in most business discussions and has access to the business requirements specification as it’s being developed. However, based on my experience, testers are often spread across multiple projects simultaneously, each with distinct business requirements that differ from those of the other projects.

It’s unreasonable to expect that each tester will have an in-depth grasp of the solution's functionality being delivered for every project, all the time. A test case written in this scenario is primarily based on either a business requirements specification or a set of user stories. This carries an inherent risk of missing the business context and focusing on narrowly defined acceptance criteria, resulting in situations where a user story or requirement is incorrectly marked as “pass.”

Still, it fails to achieve the business objective that the solution was intended to address.

When Test Coverage Misses Business Context

One example of this is a business requirement that says: “A claim submitted by a client in a web-based system must be automatically approved based on a series of system logic in the background.”

The testers may write numerous test cases to validate this feature using a set of inputs, outputs, and acceptance criteria. But the fact remains that a human submits a claim to the web-based system based on various real-life situations, leading to specific parameters being input into the claim submission process that the system logic didn’t initially consider. As such, the test case is unable to account for these. 

This is precisely where I step in, crossing my role boundary to develop test cases based on my interactions with business stakeholders. As a result, I either include or exclude scenarios that testers wouldn’t be able to, because their test cases are based on either the business requirements specification or the user stories, both of which are limited in conveying multiple “what if” scenarios.

Boundary B: System Features for Stakeholders

As a business analysis professional, I begin by capturing the business needs and eliciting them into detailed business requirements for each need. Then comes a point where all this documentation is provided to the design and development resources, who are responsible for delivering the solution according to that documentation.

According to the project's formal structure, I should stop here and wait until the solution is delivered and ready for user acceptance testing. But I don’t. There’s a possibility that something could go wrong if I cease my involvement once the requirements have been completed.

I’m fortunate that the software delivery lifecycle (SDLC) framework we follow involves regular discussions between our business and delivery teams, which leads to several system-related features being discussed to meet business needs. Now, some of you may say that the delivery team must have their own set of business analysts and systems analysts to manage their side of documentation. While it’s true that the delivery teams will have their own set of technical specifications (which our business stakeholders don’t need to know), some key system-related constraints and features must be highlighted, and every business stakeholder must be made aware of them.  

Ultimately, it’s the final IT-based solution that provides a visual element of the solution to the business problem, demonstrating how a particular business requirement is addressed.

Connecting Business Needs to System Behaviour

At this stage, I transition to the other side. After discussing with the delivery team, I focus on a few key system features that will be implemented to deliver a series of business requirements. I then add them to the user story/business requirements specification so that business stakeholders can see what system behaviour they will experience as a result of meeting their requirements.

This leads to a situation where a user story or business requirement no longer remains a business requirement alone. It becomes a combination of system features, system validations, user interface requirements, and system acceptance criteria. The business requirements documentation, as the project approaches user acceptance testing, looks something like the following:

• First level: High-level business needs identified with a unique numbering series
• Second level: Business requirements for each of the business needs are identified with a unique numbering series and linked to the high-level business needs numbering series
• Third level: System modules that will be used/developed to address each of the business requirements, again with unique numbering series and linked to the business requirements numbering series
• Fourth level: System validations, user interface requirements, and acceptance criteria under each of the system modules, all linked to the third-level identification numbering series

I acknowledge that this may be too much for business stakeholders to comprehend, as they’re only interested in having their business needs addressed (as initially documented in the project's early stages). However, as the requirements are elicited and stakeholders' understanding of the business solution improves, the stakeholder pool widens beyond business stakeholders to include those from the solution delivery side as well.

By crossing boundaries here, the objective is to develop a document that serves as a reference for both business and ICT stakeholders, providing a comprehensive context for both business and system.

Why Boundary Crossing Improves Knowledge Retention Over Time

Based on my observations, the rate of personnel turnover among organizations has increased significantly. People no longer remain in their roles or jobs for five to six years, as was the case in the past.

When a person exits an organization or moves to a different role, scattered pieces of documentation are complex for the next person to understand. A comprehensive, single piece of documentation, created by crossing the boundaries as described above, helps new stakeholders long after the original stakeholders have moved on.

One Source of Truth for Business and IT

As business systems become increasingly complex, and most business requirements are delivered through business-oriented IT solutions, all necessary details must be gathered in one place.

In the era of rapidly changing roles and people, businesses must maintain their knowledge base through a smaller number of artefacts that can be referenced efficiently for future business and system improvement initiatives.

Turn knowledge into better delivery. When business analysis professionals connect context, testing, and solution behaviour, outcomes improve. Access expert “how-to” content, global standards like the BABOK Guide, and practical tools to elevate your impact. Try it free for 7 days.  

---

About the Author