My name is Olga Douhaya and I’m a project manager and business analyst. I’ve worked at Sphere Partners for over 3 years, overall in IT for 15+ years.
In this article, I will share common mistakes and best practices for Business Analysis. If you are not a business analyst, you might think this article isn’t for you, but not so. The common pitfalls and recommendations are a great source of knowledge for anyone involved in any phase of the product life cycle.
Team Structure
Years ago as a junior IT specialist, I used to think that the ideal team structure is where every person knows who can answer their question, and who they should go to for what.
Some teams may still operate this way. The likely reality though is the team is structured more like this:
The team is centered around the one or two people who have the knowledge, who communicate with the client, and share the vision and understanding with the team(s). In most teams, this is the Business Analyst. This person knows what need the solution is meeting, how that need will be met, and understands the bigger picture and next steps. Not all teams have such a clearly identified resource on a project, and in this case, the team structure looks more like the examples below:
However, there should always be a person on a project who communicates with the client to develop an understanding of the problem and constraints, and they are often the go-to person from the team.
In the real world, business analysis isn’t just about business analytics. A Business Analyst must be comfortable with collecting and understanding the requirements, and who can adequately speak for the customer with knowledge, confidence and accuracy of the requirements.
Let’s move on to the common mistakes of business analysis.
Requirement related issues
The most important responsibility of the Business Analyst’s job is to get the requirements right. A common issue is the requirements collected are not fully accurate, or a crucial element is misunderstood or missing entirely. This will lead to having to redevelop some functionality. How much? That all depends on many complicated factors.
So how do we avoid this? What should a BA do?
1. Be prepared to lead the meetings with the client. (the BA must have a plan)
You may think one can’t really be prepared for a kick-off meeting. But that’s not quite true. You can take basic steps to prepare by talking with the sales team to equip you with as much information as possible about the project. You can also do research into the client industry as well as initial competitor research. You want to be prepared and versed enough so you can ask the right questions of the client. For subsequent meetings, you can prepare and build on the understandings using functionality diagrams, use cases, and so on. You will iteratively collect more and more information about the client, the project, the users and the problem as you go, so you have to prepare for each meeting accordingly. And, at the end of each meeting, you should come up with more questions until everything is covered and fully understood.
2. Create post-meeting notes and ensure alignment with the client.
It may seem that after working with a client for a few months, everything is clear and post-meeting notes might feel unnecessary. However, creating post-meeting notes is really important. They not only serve as a way to capture and log the details of the information and requirements, but also provide a chance for the client to ensure you are on the same page, and get the approval on where the project solution is heading. This includes items that were talked about in the meeting, ideas, solutions and next steps. I know that sometimes it may take what seems to be a long time, but it will more likely than not save you much more time and cost in the long run.
3. Engage the input of a Team Lead or Architect in info gathering meetings.
Even if everything seems clear from the business perspective, there often are technical considerations and exception cases which must be covered. It’s sometimes difficult for a Business Analyst to identify these obstacles on their own. So, involve a technical team member if you can at the appropriate phase who can help you solicit and capture the overlooked technical requirements as early as reasonable in the process.
4. Consult with an industry subject matter expert.
At Sphere, we have a shared channel for all employees. Occasionally, we use this channel to find a subject matter expert to consult with. Often you learn something new this way and further derisk the requirements gathering process!
Narrow focus on the ‘Happy Path’
‘Happy Paths’, the ideal vision of how the system is envisioned to work, are often the first and easiest to recognise. Though this might sound obvious, or similar to the first issue, the mistake here is spending all of your time focusing on the Happy Path, and miss out on identifying the exception cases. As Murphy’s Law states, ‘If anything can go wrong, it will.’ Appropriate level of consideration and chance is crucial here to identify and classify all derived exception cases.
Oftentimes, when envisioning some functionality, the Happy Path is typically the one you think about by default. You might be so caught up thinking about the best straightforward approach a user should take, you become blind to the exception cases. But the reality is that more likely than not, there are exception cases, and the user will surely find them. You need to always be thinking about exception cases, and not just the Happy Paths.
What should the BA do?
1. Brainstorm and come up with all possible options which may occur, then review the proposed solution while applying those options.
- Communicate with the team.
- Communicate with the client.
- Look to identify all possible options and look at the solution, workflow and process from different perspectives.
2. Discuss with the client various current pain points, issues and exceptions which need to be addressed and considered within the current workflow.
Talk through to fully flesh out the various pain points the users experience. The client is the best consultant, as they seemingly deal with the problem on a daily basis.
3. Solicit input from subject matter experts.
As mentioned earlier, seek input from subject matter experts about their experience. They often have additional knowledge and pitfalls for you to consider and flesh out with the user(s).
4. Engage the QA team early.
The QA team should be engaged at project design, as they are also a great tool for identifying exception cases.
Tools and Techniques
- Brainstorming – collecting multiple ideas related to the solution.
- Interviews – talking to stakeholders directly.
- Focus Groups – bring together prequalified stakeholders and subject matter experts.
- Questionnaires and Surveys – written set of questions to quickly accumulate info from a large number of respondents.
- Benchmarking – comparing with competitors.
- Observations – job shadowing. You can also use tools that help you understand user behavior, such as HotJar for example.
- A/B testing – testing variables can show you what works better.
Poorly written tasks
After requirements have been collected, they must be broken down, organized and ultimately translated into tickets. This next issue occurs when task definitions contain too little or too much information. This results in gaps in understanding or unnecessary confusion for the team. It’s important to create tickets that are readable, easy to understand, and are organized in a way that they are easy to find.
What should the BA do?
1. Ensure the main requirement is clearly structured.
A clear and consistent ticket structure will help ensure clarity, efficiency in communication and help with consistency with details. It is a good idea to have a separate section called “Requirements:” which contains summary information about what should be done on this specific page. You want to strive to ensure that everyone who opens the ticket can read it quickly and have a complete and accurate understanding of what the ticket is requesting.
2. Specify where this requirement (specific screen, action, etc) will occur within the workflow.
It must be clear to the reader of the ticket, the context of this requirement, including where and how this requirement fits in the workflow. You know you are on the right track if anyone reads this ticket, even if they are not involved in the project, and is able to understand the intended user journey.
3. Describe specific screen elements required.
When a page has multiple uses, you need to consider if the description should go into a single ticket or not. Sometimes, screen elements need to be different depending on states, which may warrant moving the description into separate tickets.
4. Include specific system behavior based on various use cases or status(es).
A ticket must include the visual elements as well as a description of the system behavior and logic.
5. Link related tickets/tasks.
When a requirement references or triggers another endpoint or functionality, it’s good practice to link the tickets together for reference and traceability. Doing so saves the team time and reduces the likelihood of confusion around the relationships.
Give in to technical lead’s insistence
Developers prefer to build universal solutions, while the BA should keep the business’ interests first. Developers thrive on building reusable and scalable solutions, but sometimes, these solutions are not what the client needs, often needing a custom software solution instead.
What should the BA do? Communicate the following with the developer:
- Not all projects are intended to last forever – some are time-limited campaigns.
- Not all projects require full scaling – some have a limited number of users by design.
- Not all projects require perfect code – in some cases, it’s more important to do a quick-coded POC to affirm the idea.
- Not all projects need complex architecture – just as the design principle says: KISS (Keep it Simple, Stupid).
BA rarely speaks with developers
Another common mistake occurs when the BA believes the details are all captured within the ticket, so no need to discuss the requirements further with the team.
It’s common to believe that as long as all the information is written in the ticket, that you don’t need any further discussions with the team. The reality is people may have various interpretations of what is meant in a ticket, so it’s essential to speak with the team and clarify any parts which may be unclear.
What should the BA do?
1. Ticket grooming.
Review requirements routinely to ensure that each ticket is still valid. Sometimes the requirement changes, and it’s essential to ensure the accuracy of the ticket backlog and prioritization. Not doing this can result in wasted time and effort. Following best practices and for grooming helps to avoid such situations.
2. Discuss newly described functionality before development (testing) starts
As mentioned earlier, the same sentence can be interpreted differently. It’s really important to discuss all functionality with the whole team. Spend the necessary time to discuss complex functionality before development begins. This saves you time by not having to redevelop functionality which could have been avoided.
3. Be patient and ready to answer a seemingly similar question asked in numerous various ways.
Sometimes a question might be asked in various ways and multiple times. Be patient and continue to answer and clarify in various ways and as many times as necessary to be certain that everyone and everything is completely and properly understood.
4. Do not hesitate to reconsider and adjust functionality if team discussions derive additional considerations.
Don’t hesitate to reconsider and adjust functionality. You may realize that something previously described may have contradictions or may be wrong. Consider various points of view and then reassess, verify and agree on the best path forward. In some cases, it means something else needs to change. Analysis is an iterative process, building on and expanding with each iteration.
Blindly following frameworks and methodologies
Just like there is no one pill to cure all diseases, there is no one universal methodology for all projects.
What should the BA do?
1. Be flexible.
Sometimes circumstances are more suitable for scrum, other times it’s best to use the waterfall model. If an approach should work but doesn’t, try another approach, seek best practices and consult experts.
2. Reflect and adapt.
If you continue to get the same questions each and every day, it’s a sign that you may be doing something wrong. Take a step back, self-analyze, reflect, and adapt.
3. Speak to your team.
Ask your team if they are happy with the established working process. Speaking with your team as well as your client is the best way to understand which method works best.
4. Don’t be afraid to change rules.
Think about each project and each team as a living entity. Identify and adapt solutions that work best for the structure as a whole. Together, you will establish the most optimal way to be productive and enjoy your work.
This blog post has been created from a session presented to our team at Sphere Partners. You can watch our Business Analyst & Project Manager, Olga Douhaya, present this on the video at the top!
Have a technical project that requires the expertise of people in roles mentioned above? Reach out to us to request a consultation today and our team will help.
