Top 10 Documentation Mistakes Committed by every Business Analyst

Business Analysts, Enterprise Architects, Data Analysts, Business Intelligence Analyst and others like them always work to bring positive change within the organization. These changes can be either incremental or enterprise-wide and revolutionary.

Regardless of the size of changes, all the Business Analysis roles mentioned above will involve consolidating requirements. One the most important roles of a Business Analyst involve to extract and document Business change needs from all Stakeholders across the Enterprise.

Most Businesses world-wide are still refining their Business Analysis methods, leading them to make a few common mistakes repeatedly along the way. Here are some such mistakes committed by BAs with regard to Documentation.

 1. Inadequate and inaccurate stakeholder analysis

It is not uncommon to see the Project Management Office (PMO) or Resource Managers assign appropriate resources to projects as soon as the Business Analyst or Project Manager are Assigned. With such resources, projects usually start taking shape, without a complete Business needs document prepared by the in-house Business Analyst. Before the project is kicked off, BAs should always do a thorough Stakeholder analysis. This is essential, since as the project gets underway, the Business lines that are touched by the project cannot be fully predicted. Also, it is a widely established fact that Stakeholder analysis isn’t one-time task and it is an on-going task that should keep going until the project is done.

2. Improper and inaccurate language in the requirements

Business Analysts are professionals who tend to work in massive organizations and highly structured teams. Business requirements are useful when they follow the acronym “SMART” which expands into Specific, Measureable, Attainable, Realizable and Time-bound. Express all Stakeholder needs in the requirements document and be clear and unambiguous about what is needed and be sure to prepare the document from a Business standpoint and always use Business terminology.

3. Leaping to design before getting the complete requirements

First step towards attaining a leak-proof Business needs document is to be clear on the Business problem that has to be solved using the product or the service at hand. If the Stakeholder begins discussions about the design requirements, then such talks have to be halted as and when they start. Always crystallize the Business requirements before going ahead with design discussions.

 4. Losing control and direction of the conversation during elicitation with Stakeholders

A very important task for a Business Analyst is to act as a moderator or facilitator in the requirements discussion. This means seeing to it that, the Business needs are addressed first and the topic is not led astray by a minority of the Stakeholders. All Stakeholders should be equally addressed in such meetings and the focus should not be on irrelevant issues and topics.

5. Getting approval for the requirements without a shared understanding among Stakeholders

As of today, project timelines and schedules are airtight, which makes the approval process as brief as possible. This is not necessarily a good thing, with Stakeholders in the project coming from different backgrounds and having different viewpoints. Therefore BAs should make a task out of making all the Stakeholders understand the Business needs in details. This will give Stakeholders the ability to view the Business needs from other Stakeholders viewpoints as well.

6. Feeling requirements must be 100% complete and accurate before sharing with the Stakeholders

Business Analysts often times will fall into the vicious loop of trying to hand over a Business requirements document that is a 100% complete. Most PRDs seem incomplete to the BA, but they should go with what their gut tells them and hand it over after a certain point. Such Business needs gathering tasks which cannot fully be gauged by the one process alone and should take on a more collaborative approach to analyse the success of the Business needs elicitations meetings and general process.

 7. Not building trust with Stakeholders

BAs need to realize that the Stakeholders are also people who need their voice to be heard, this means they have to understand their Stakeholders thoroughly. BAs have to build a great rapport and see to it that they earn trust and understanding. This will be useful when internal conflicts arise, making resolutions that much easier.

 8. Blindly using a template

Always use a template that suits a Stakeholders needs. If you have come across a Business Requirements Document (BRD) template that is appropriate to your task in every little detail then well and good. You can carry on with it, using very little or no customization. But when your project is unique, then you might have to mesh older templates or create a new one to aptly meet Business needs.

 9. State clear and concise requirements

All Business requirements need to be stated in clear and concise terms, and they have to stand out individually as much as possible, with very little exceptions. This means one Business requirement should not overlap over the other, which will confuse all the Stakeholders and de-rail the project entirely.

 10. Leaving sections blank

This one may seem rather obvious, but most BAs sometimes leaving entire sections blank thinking it is not important enough. It is most likely bound to confuse the Stakeholder, so at least put down a “None identified” or “Not Applicable” note in the place of the blank space.

Go through our Business Analysis Interview Questions to crack the Interviews.

Conclusion

If a Business Analyst follows all the steps that are mentioned above, then he/she is sure to create an effective requirements document and keep all the Stakeholders happy. Maintain a good rapport, be alert, and things will just flow! need for cybersecurity, the attractiveness of crossover skills, the data-driven nature of technical projects, etc., there will be a huge demand for business analysts in the upcoming year.

I hope that by now you have had an overview of Business Analysis. Before you enroll in ZaranTech’s certification course on Agile Business Analysis do check out this demo video: