6E's for a Business Analyst

A requirement, at the very basic level, is a change.

BA is the person who drives the requirement from a conceptual stage to material form. BA always requires wearing many hats at the same time, being a functional expert (client’s person) in project team and an application expert for clients.

BA being a person to elicit, analyze and document the requirements often plays a very critical role in the project execution.

Embracing change - BA should be the person who will visualize the changes first, then convert these changes in tangible form and help business and other stakeholders to understand and bring change to reality. Thus, he/she enables stakeholders to embrace the change.

Engaging stakeholder: This is critical focus area. There should be warm and cordial relationship between different BA and stakeholders. This will be very helpful in avoid any communication gap and lack of understanding. Also, this will ensure that all the critical information flows smoothly from stakeholders to BA and implementation team. BA should ensure to make them part of implementation as much as possible. Frequent demos and prototypes will help stakeholders to understand system better and propose changes, if any, at early stage itself.

Efficient and Complete Communication – It is utmost important that all stakeholders are on the same page and have access to information/documents available. This will help to avoid misunderstandings if any and to mitigate risks on time.

Enhanced Artifacts: BA should not consider BRD, FSD are just for documenting requirements. The success of project will depend on these documents. Hence, these documents should be such that they provide meaningful insight about the application to clients. A detailed BRD serves many purposes. Users can refer to steps mentioned in BRD for usage of application. Users can refer to different technical/functional constraints mentioned while using application. 

Also, the same BRD can be used by development team to develop application and by testing team to test application.   Because of lot of details BRD can become verbose and hence, boring. So, BA should focus on making BRD more interactive and scenario driven.

Early Risk identification and elimination - The sooner the risks or potential failure areas are identified; the less will be impact on project health. BA should focus on exceptional scenarios, alternate scenarios and the scenario's which could possibly fail.

Empowerment to team members - BA/PM should make promote their contribution and welcome their suggestions. Make developers/testers feel part of project. Often they are the people who point out technical challenges/limitations in advance. Also, they can highlight the conflict and impact of different changes. Also, it would be good if they are part of clarification sessions.

Change is inevitable and at times more complex than imagined, a BA can help you to get safely.