The 3 Most Common Business Analyst Mistakes
We’ve all heard the quote, “What we have here is a failure to communicate.” Failure to communicate is the bane of the Business Analyst (BA). The BA has the responsibility to elicit requirements from the business and to communicate them to the development team in a way that makes it clear exactly what is needed and what must be verified.
The Business Analyst is not just the conduit between the business and the IT department, but also the translator. The BA must be able to not only communicate clearly with each, but also take information between the two in a manner that avoids confusion and misunderstanding.
By avoiding the following mistakes, a BA can establish strong communication early in the requirements process and ultimately improve project success rates.
- Making assumptions that are not quickly resolved into fact
- Ignoring stakeholders or stakeholder groups because they are so difficult to deal with or contact
- Failing to ask questions
Business Analyst Mistake #1 - Making Assumptions
Everyone makes them, but rarely are they documented or waved like a red flag in front of the whole project. Early in the project when facts are scarce, you make some assumptions. Others make their own assumptions, and everyone goes merrily along until one day the project takes a nose-dive. The reason for the problem is that bad assumptions were made, became treated as fact, and were totally ignored as risks to the project.
Control Your Own Assumptions
There are times that you must make an assumption and press on. When this happens, make sure that you have clearly documented your assumption and the consequences if the assumption is incorrect. Make sure this information is provided to all those that can help you resolve the issue and those who will be affected if the assumption is wrong. Put the assumption in an activity list with a date for resolution.
For example: IT will need to know how many simultaneous users there will be on the system being developed. You know the current system has 200 simultaneous users but can’t find out what growth is expected over the life-time of the new system. You may have seen projections for the company to increase four-fold in the area the system will support. Make an assertion that the system will need to support 800 users based on the current number of users and the expected increase. Get this assertion to the developers to see if it is a major concern or cost driver. If it is, it needs to go on your risk list. Flag the assumption so everyone knows it is just an assumption.
Identify the Assumptions of Others
You are the first person whose assumptions you want to control, but you are also at risk from everyone else’s undocumented assumptions. Here are some ways to spot assumptions.
- “But I thought…” – Pay attention when you hear someone say, “But I thought you said” or “But I thought he meant”. Statements need to be in writing so we can go back to them, reexamine them, and make sure everyone is working from the same viewpoint. Memory is insufficient in eliciting, documenting, and managing requirements. Mind reading or interpreting information without following up with the source doesn’t work either. The problem is not that someone thought, but that someone assumed. Change “but I thought” to “I assumed” and you have the gist of the problem.
- “I Wonder…” – If a person in a meeting says, “I wonder what she meant by that”, you are at risk of having a lengthy, worthless debate. Do not try to guess; no one in the group is a clairvoyant. Go ask “her” exactly what she meant.
Recognition of assumptions often occurs long after the assumption is made and it is impacting your project. It is best to uncover assumptions as soon as a project begins. As you elicit requirements, you want to understand the underlying assumptions each stakeholder is making.
Assumption-Busting Techniques
Try asking a question and listening into the silence that follows the initial answer. The stakeholder will often give you their underlying assumption after they have answered the question. For example, if a stakeholder says, “We need all the reports we are getting from the current system (pause) though I don’t know who uses them.” You can start here by asking, “Which ones do you use? Who else uses those besides you? Of the others, who do you know that is using them?”
Using the direct approach. Dig a little deeper during stakeholder conversations to uncover assumptions they may have about the system, their needs, or how their needs should be met. The following phrases might be useful.
- “Do you think it will be just like the current system or very different?”
- “Are you thinking that what you are requesting is simple and cheap or hard and complex?”
- “Have you seen or experienced something with another product that you are describing as what you want?”
As you start controlling your own assumptions, you will be setting examples for others. As you query for assumptions you will be changing the way you work and communicate.
Discovering and documenting assumptions is a challenge on any project. For a fun take on a hands-on exercise that reveals our hidden assumptions, check out this short article on the Marshmallow Challenge. Sometimes getting our stakeholders out of their routine can help shake loose the additional information we need!
Business Analyst Mistake #2 - Ignoring Stakeholders
A major reason for ignoring certain stakeholders or stakeholder groups is because the stakeholders are difficult to work with or because they are nearly impossible to contact.
If you ever took a time management course you probably learned about “unpleasant A1s.” This is an item on your task list labeled as an A because you need to do it and soon. You have also labeled it as a 1 because you have too many As and must prioritize them.
These items cause you stress and haunt you because you keep trying to avoid them, hoping they will resolve themselves. They don’t and they won’t. Most of us treat difficult people this way because they make us miserable when we have to deal with them. In the business world, when problems are ignored, they tend to just grow into bigger problems. They don’t resolve themselves. Sometimes the thought of dealing with these people is actually worse than doing it. Time management gurus will tell you that this is something you need to deal with head-on.
Dealing with Difficult People
Work with difficult people one-on-one if you can. Having them in a meeting with others brings out the worst in some people and wastes the time of others. You need to get them on-board with the scope and priorities for your project.
Don’t tell someone that they don’t need or want what they are asking for. This can exacerbate bad behavior. The fact is that because of project constraints, you aren’t going to be able to satisfy every request. The answer can be, “Yes, I can see why you want that. I’ll put that on the backlog for a future release.” Then do just that. Verify prioritization of your backlog periodically. Check in with the requester. Some will actually tell you that their need has been met or the situation has changed, and you can check that item off. The fact that you have not forgotten or ignored someone will help with future conversations.
Catching Hard-To-Reach People
Some of your stakeholders may be very hard to contact, but failure to bring them into either a scope activity or a requirement activity can result in major problems later.
Go for the short, one-on-one meetings if necessary. Asking for 15 minutes is more likely to get you onto someone’s calendar than asking for an hour of their time. Many hard-to-reach people are overwhelmed. They don’t have time to go to all the meetings they are invited to attend.
- Determine which items are really important for the person to answer or confirm for you. Go into the meeting with these items written down.
- Get as much information and confirmation as you can in 14 minutes. Then excuse yourself and thank the person for their time.
- If you need more answers, request another 15-minute slot in their schedule. If you do this well, you’ll get on their schedule almost anytime you ask for a slot. Make people want to see you – be prepared, be concise, and don’t overstay your allotted time.
Use email for those who respond to it. Some people will answer email even if you can’t get their time any other way.
- Determine the importance of your questions and address the most important item first.
- Limit each email to a single confirmation or question. You want to make it easy to answer so they will answer you right away and not put you in their to-do-later pile.
- If possible, make your first email a confirmation instead of a complex question. This is usually easier to answer and more likely to get you a fast answer.
Business Analyst Mistake #3 - Failing to Ask Questions
Being a Business Analyst means being willing to ask a lot of questions. But sometimes we hesitate to ask something of a certain person or in a certain situation. Here are some common concerns we can have about asking questions.
- I’m Afraid of Looking Dumb. – Please don’t say “I have a dumb question.” It’s okay to admit that there is something you don’t understand or that you need more information. Others have knowledge you don’t have; that is why you are talking to them!
- I Think I Should Already Know the Answer. – This is akin to being afraid of looking dumb, but it differs in that you think you should know this. You may need confirmation. You may need to dive deeper into a subject. There may be gaps in your understanding. Go ahead and ask the question. If someone says, “You should know that already,” just admit to a lapse of memory and request their help. If you think you do know but are having doubts, write down the information and ask for confirmation.
- I Don’t Have Enough Time. – “We don’t have enough time to do it right but we always have time to do it over” is a familiar quote. It’s a given you can’t know everything up front. If you have unanswered requirements questions, a list of those should be part of your status and risk management.
- I Can’t Get In Touch With the Right Person. – Ask who you should talk to if the “right person” isn’t available. There must be someone you can contact as an alternative and obtain at least a partial answer, and then follow up with the right person for confirmation.
How to Be More Effective at Getting Information
- Always Be Prepared – Some people go from meeting to meeting and just do unstructured brainstorming. While brainstorming is a great technique, it’s only one tool in the BA’s kit. Generally, you need to prepare for each meeting with an agenda, a list of questions you need answered, and supporting documentation such as visual models. If you are prepared, you can shorten meetings, and you develop a reputation for being prepared and not wasting people’s time.
- Use Visual Aids – If you are trying to confirm something that is part of something larger, then a context diagram, schematic, flowchart, process flow or other visual aid may help you get a confirmation or an answer much faster. Highlight the area you are addressing. It’s okay if the model is draft; you’re looking to complete, correct, and confirm it with your stakeholder.
- Analyze Responses – The BA’s role is not to just ask questions and document the answers, it is also to think and analyze responses. Are you getting the same answer from everyone, or is there a conflict between what different stakeholders are saying? Did the answer lead to new questions or issues? Who can help you with those problems? Are answers diverging so that the scope of the project is expanding? Are you working with the developers to determine if the answers you are receiving are achievable?
- Be a Good Listener – If you have assumed an answer, you may hear only what you think you will hear and miss some really crucial data. Once, during a deposition, I saw a lawyer divide a yellow legal pad in half, vertically. As he asked a question, he wrote answers on the left that he thought were true, and answers on the right he thought were lies. I’m not suggesting this technique, but write things you thought you already knew on the left, and information that is new or different on the right. Don’t start forming your next question until you hear the complete answer to the first one, even if what you’re hearing is popping new ideas into your brain.
For another great take on how to cultivate your BA curiosity and question-asking skills, check out How to Improve Your Curiosity, by Joy Beatty.
By avoiding these common mistakes, you (as a Business Analyst) will be able to communicate more effectively with the business and the development team. This improved communication will lead to defining a strong, clear set of requirements in a more timely manner.
In the event you’re looking for a more hands-on approach to improving your team’s ability to elicit, define, and manage requirements, be sure to check out our world-class requirements training courses.
The end-result will be improved project success rates!
