The Business Systems Analyst (BSA) role can be a tricky one. The goal is to become the bridge to key parties. It is the role of the BSA to bridge the gap between the client’s ever-changing business needs and the feasibility of making those enhancements with the technical team. It is also the responsibility of the BSA to bridge gaps between account managers and the database/software engineers. BSAs can both sympathize with the needs and frustrations of an angry client as well as with the outcries of “minor” changes on the database turning into a three-month process. Below are the key lessons learned over the years to help any BSA overcome a burning bridge:

Question Requirements

It is not enough to take requirements from the client. You must process those requirements and push back where requirements are not consistent with the database or do not make sense. BSAs are there to consult the client and ensure that they are in good hands. Just because the client signed off on a specification, does not mean it was the right requirement to have in the first place.

Who/What/When/Where/Why

Requirement gathering is related to the ‘what’ question with an understanding of the why we need this capability. It is not the how we are going to design. Too often, the why is lost in translation and discovered too late in the development lifecycle.

BSA/Developer Relationship

BSAs are the best friends of all developers. BSAs are like the editors and proof-readers of a process prior to moving code to production. BSAs are there to help the developers discover issues prior to the deployment of their code. They are a key team when it comes to data and process quality.

QC the Right Way

It is best to assume personal fault when issues arise. If the counts do not match in your latest query, sometimes it is best to start with pointing your fingers inward. Where did you go wrong in your query or where is there a gap in your understanding? If you still cannot see personal mistake, then, and only then, would you inquire from a developer to assist in investigating the potential issue.

“That’s How We’ve Always Done It”

Wrong! Always enter your projects and enhancements with an open mind. Challenge the design and push beyond the boundaries of how things have been done. There is always a more efficient or automated way to develop a process.

Not Feasible

Most requests are feasible. Most anything can be designed and developed, but some requests take more time. Usually, the better way to design takes longer to do, but saves time in the long run. It is important that the BSA can address this with both the client and the account managers. In some tight timelines, you must do the “quick and dirty” and then implement the “right” design later, but always communicate that clearly to the stakeholders.

At the end of the day, there is no “us” versus “them”. BSAs bridge the gaps to create the “team” on every account.