A lot of people have the perception working as a Business Analyst is easy. Business Analysts (BAs) only need to organise meetings, listen to stakeholders, take notes, and write meeting minutes as a conclusion. BAs can often be negatively thought of as simply note takers. This might be the case for some laid back BAs. However, for excellent BAs in general the work that we do is much more complex than that. Here are some of the activities to show that BAs are not simply note takers.
1. Elicit Requirements
Going into workshops or interviewing stakeholders is not just about asking the question “Tell me what you need?” and have the mentality of “I’ll just write anything you say”. BAs don’t just “gather” the requirements, BAs need to ask the right questions to challenge what the business wants and to draw out the true business needs.
How many times have you come across situations where the business doesn’t exactly know what they need? They are just aware that there are problems and inefficiencies in what they do. This is where BAs step in and help uncover the actual business needs by getting to the root of their problems and finding out the rationale behind their needs so that accurate requirements can be elicited.
2. Facilitate Requirement Workshops
There are many elicitation techniques that BAs can use, i.e. workshops, interviews, focus groups, prototyping, surveys, observation, and brainstorming. Conducting workshops is one of the most commonly used techniques amongst the BAs.
To master workshop facilitation, it needs a vast amount of experience and skills. During the workshop, you invariably come across different types of stakeholders with different personalities, interests, and agendas. Some can be very outspoken, easy to speak their minds and ideas, and dominate the workshop. Some can be quite reserved, afraid of being judged, and therefore not participate enough. BAs need to be able to read and understand all the different personalities and provide opportunities for everyone to participate and stay focused in order to achieve the best outcomes.
If necessary, you may want to set some ground rules and re-iterate the agenda at the beginning of the workshop. “Leave titles at the door” and “Disagree with the ideas and not the people” are some of the rules that when followed can make a huge difference in creating an effective and collaborative requirements workshop.
Another key to success for getting the best out of your workshop is to come prepared. Reading background information and related documentation, gaining some understanding of the current systems and processes, and preparing a list of questions are some of the great things you can do to prepare.
3. Analyse Requirements
Why do you think our title is “Business Analyst”? Many people forget the analysis part of our job. BAs need to use their problem solving and analytical skills to analyse the elicited business needs to find out if there are any impacts and dependencies in the requirements on other aspects of the business processes and systems. Analysing and mapping the current processes and systems is crucial to understand any gaps between the current outcomes and future outcomes and to determine what must be done to arrive at the desired outcomes.
4. Document Requirements
Writing good requirement documentation is never easy. If the organisation is mature enough, you can most likely find a requirements template that you can leverage on. But be mindful that template is normally good enough to provide guidance and direction. There is no such thing as a ‘one size fits all’ template. BAs need to be creative and able to tailor the template, adjust their documentation styles, and use different methods and techniques to clearly outline the requirements that can be understood clearly and unambiguously by the audience of the document.
Good documentation is not about throwing around cool jargon and pretty diagrams. Use simple terms and techniques that suit the purpose and audience of your document, whether that means use cases, user stories, flowcharts, or prototypes, as long as they are clear, unambiguous, and easy to understand.
5. Validate Requirements
Having good documentation is useless if it does not present the true business needs. Is it enough to send out the document asking the business to review for validation purposes? How can you be sure that the business has carefully read and understood the entire document? How often have you come across situations where the business says that the new system does not meet their needs even though the system is thought to be built according to the signed off requirements document?
To avoid misunderstanding, ambiguity, and trouble down the road, walking through the document with the business is a better approach to make sure they understand and agree with what has been written in the document.
6. Communicate Requirements
Once the document is validated and signed off by the business, our work as a BA does not stop there. The requirements must be clearly communicated to solution designers/ architects, developers, and testers to ensure they completely understand the requirements and deliver the best solution that meets the business needs.
Walking through the requirements documents is always the best method to communicate the requirements to ensure that it is well understood. Don’t just leave your development team to read the documents and expect them to understand. This will open a flood gate of various interpretations that can lead to a solution being built that doesn’t meet the business needs.
7. Manage Requirements
Building a requirement traceability matrix is a technique that BAs can use to help manage requirements. Uniquely identified requirements can be traced back to the business case and forward to the design document and test cases to help manage scope, to ensure no requirements miss out on the development, and to ensure the implemented solution conforms to the requirements.
As the business can change their minds (and often do!), changes to the requirements is inevitable and can happen at any time during the project lifecycle. These changes to the requirements must be managed properly and impacts must be assessed to ensure everyone understands the changes and impacts, and works towards building an accurate solution.
In conclusion, it is a minefield out there in the Business Analysis world and without doubt Business Analysts are not simply note takers. Business Analysis activities are very diverse and Business Analysts must equip themselves with a great deal of versatility in skills and techniques in order to become a great catalyst between the business and technology. I’d really like to see any other tips anyone has out there for being a great BA.