In my experience, I have found application developers not very clear on roles and responsibilities of business analyst (BA) and, more importantly their need in the project. Thus, they do not pay attention to what business analysts has to say on the requirements and end up faltering on various aspects of project execution due to lack of proper understanding of the business requirements. This creates a lot of frustration to both application developer and business analysts. Below is a diagram representing a conversation with BA and an application developer.
A conversation between BA and a developer. Quite a tough one for BA.
What is the problem if business owners and application developers communicate directly without a business analyst as a bridge?
The goal of the Business Owner is to solve a problem very quickly, and the goal of the Developer is to discover all underlying needs and provide an answer as quickly as possible. And, both understand and talk using different terminologies which may be understood incorrectly by others. Also, business owners may not be able to describe various different aspects of business requirements keeping into account the strategic importance that the business wants to achieve via one or more business requirements using information technology (one or more applications). This can lead to communication gaps thus, creating changes in a vacuum, not necessarily taking the needs of all users of the system into account, depending on the organizational skills of the involved developers.
This is where business analyst bridge the gap by bringing structure to the overall requirements gathering processes including AS-IS process and TO-BE process description, taking workshops with the application developers, and giving shape to business requirements in terms of processes for business owners to validate.
Following are some of the aspects which application developers should pay attention to, in terms of their understanding and communication with business analysts:
- Belief in the role of business analyst: Believe that the role of business analysts is equally important to their role in relation with project execution and overall success of the project. Business analysts serve as the mediator or the bridge between the Technical and Business stakeholders.
- Try & understand business requirements keeping aside implementation details: It has been found that developers tend to quickly jump to design/technology aspect of the requirement while discussing the business requirements. This leads him/her to start showing resistance in terms of accepting the requirements thereby doing unnecessary arguments primarily due to the reason that they are unclear on how would they execute the requirement. This leads to lot of frustration to both the parties. Developers, on the other hand, should pay attention to understanding different use-case scenarios related with the requirements including primary, alternate and exceptional flow and all the associated business rules.
- Avoid discussing so much of technology details: It has been found that developers tend to discuss the technology specific details such as details related with programming language, database etc, and describe limitation to the implementation of business requirements. This becomes troublesome for the BA. For example, they go up to sharing that database tables and column details along with associated complex application logics which at times may sound Greek and Latin to business analysts. The developers, should rather, try and talk in terms of business requirements and associated rules, and, if only asked, should take care in describing technologies detail while keeping in mind the technology expertise of business analysts.
- Avoid going bottoms-up and discuss inability for implementation: At times, developers discuss the limitation posed by current coding and tell the BA that the feature can not be implemented for the said reason. This again brings frustration to the BA as this should have been taken care at the time of analysis and a BA has not much to do with limitation posed by existing system if not agreed at the earlier stages of project planning.
- Avoid making changes to business rules without keeping BA informed: At times, developers make changes to business rules by modifying, adding or removing rules and not informing BA. This is because for developers, it may be one or two-liner change, but for BA, this can change the behavior of the system.
- Discuss functional decomposition of requirements with BA: Quite a key is to discuss the functional decomposition of the business requirements with BA in order to make sure that all business requirements have been taken care of with modules having clear set of functionality and boundaries.
Two cents.. application developers should pay attention to what BA has to describe about the requirements and keep him/her informed at all times.
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
Great to see BA’s getting good press, especially in this age of “just start coding”. BA’s and developers need to work collaboratively on projects with business folks, bringing their individual skills and perspectives to projects. It is vital that we first identify the business need or problem that must be solved. Then we can look at candidate solutions, and ultimately a final solution that everyone can buy in to. And recognize that the solution may not always need to involve use of technology.
Thanks for sharing your comment, Andy. You are Dot On!