by Ivy Hooks
We’ve all heard the expression, “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 BA 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 good communication early in the requirement process and ultimately improve project success rates.
You make 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, 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.
There are times that you must make an assumption and press-on, in parallel with determining the validity of that assumption. When this happens, make absolutely 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 and hopefully someone will have “the right answer” and you can replace your assumption with that information.
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 being made or having been made.
“But I thought…” – Listen up when you hear someone say, “But I thought you said” or “But I thought he meant”. Verbal communication is not okay in the requirements world. 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. You have many contacts and multiple discussions, but often only a part of the discussion is documented and the rest is trusted to memory. 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 bad assumptions often occurs long after the assumption is made and when it is impacting your work and that of others. 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.
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 often works better than anything else. Ask the stakeholder, “Tell me what you need and any assumptions you have made that affect what you are telling me.” If you have to explain assumptions, you might use some of these statements:
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 and others in your business work, and will be reducing those late surprises due to bad assumptions.
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”. These are items on your task list labeled as an A, because you need to do then 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 and get it over with.
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 Mr. Grouch on-board and in agreement with what is in-scope and what is out-of-scope for your project. Once you have that resolved, individual issues can be addressed or discarded, depending on whether they are in or out-of-scope.
Don’t tell someone that they don’t need or want what they are saying they need or want. This can exacerbate bad behavior. The fact is that because of time, schedule, or scope of the effort, you aren’t going to provide what they are requesting. The answer to them can be, “Yes, I can see why you want that, but we cannot accommodate your need with this project, because of the schedule we have to meet. I’ll put that on my list of things to consider in a future release.” Then do just that.
Maintain a list of requests from people and revisit the list with them on some periodic basis. After a new or upgraded product is released and has been in use a while, go back to these individuals and ask them if they still need their item on your list. Some will actually tell you that their need was met and you can check it off. The fact that you have not forgotten them, and have not discounted them, will help with future conversations.
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 into someone’s office faster 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 and their calendars are always full.
Use email for those who respond to it and who avoid meetings. Some people will answer email while they are in meetings and while you can’t get to them by phone or in person.
Some people find it very hard to ask questions. Those people should not be in the role of a BA. It is essential that a BA ask questions to do her/his job effectively. Below are some reasons that people give for not asking questions and suggestions for overcoming these issues.
“I’m Afraid of Looking Dumb.” Please do not preface a question with “I have a dumb question.” It is a put-down that is not appreciated. You may want to simply admit that there is something you don’t understand or that you need more information. Others have information you don’t have; that is why you are inviting them to your meeting or going to talk to them. How you look to others is not the problem you are supposed to solve; getting information is your job. Do that and don’t worry about others’ perception.
“I Think I Should Already Know the Answer.” This is akin to afraid of looking dumb, but it differs in that you think you should know this. Moving ahead without getting what you do know confirmed, or failing to obtain the information that you really don’t already know, is going to lead to trouble. Go ahead and ask the question. If someone says, “You should know that already”, just admit to a lapse of memory and request help. If you think you do know, but are having any doubts, write down the information and ask for confirmation of that written information from one or more people.
“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 the reason for many project failures and certainly for cost and schedule overruns. See some of the other suggestions for overcoming time problems, and as a minimum, have a list of unanswered questions as part of your risk assessment before moving from scope to requirement writing and from requirement writing to design and development. Both the Project Manager and the development manager need to know exactly what questions are in limbo so they can do a good risk assessment.
“I Can’t Get In Touch With the Right Person.” Ask who you should talk to if the “right person” isn’t available. Is the company going to collapse if that right person wins the lottery and retires tomorrow? There must be someone you can contact as an alternative and obtain at least a good guess, and then follow up with the right person for confirmation.
Always Be Prepared – Some people just go from meeting to meeting and do nothing but brainstorm. While brainstorming is a great technique for some things, it cannot be the only method of elicitation in a BA’s toolbox. You need to think about the questions you need answered for a project and keep a list of those questions with names of people who might have the answers. Update your list with answers and their sources plus the new questions that are generated from these answers. If you are prepared, you can shorten meetings and interviews, you can grab the right person at the coffee pot and perhaps quickly get an answer or an appointment, 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. You can provide this visual aid to the person who hopefully has the answer. Highlight the area you are addressing. You can either show an assumed answer or alternatives from which that person can select the one that is correct.
Analyze Responses – The BA’s role is not to just think up questions and elicit 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? You may need to elicit some help from the Project Manager since you don’t have unlimited budget or schedule. 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 is your division of data, but write things you thought you already knew on the left, and information that is new or different on the right. Writing will help capture what is said and trying to sort it will help you think about what it means. Whatever you do, do not start forming your next question until you hear the answer to the first one. If you are thinking about that next question, you are not listening to the speaker.
By avoiding these common mistakes, a Business Analyst will be able to communicate more effectively with and between the business and the development team. This improved communication will lead to defining a good set of requirements in a timelier manner. The end-result will be improved project success rates.
Requirements Experts offers a 2-day seminar geared specifically to Business Analysts and the knowledge they must have to effectively define scope and requirements for a project. Visit www.reqexperts.com for the full course description of Requirement Fundamentals for the Business Analyst (2-Day Seminar).
The former CEO and a founder of Requirements Experts, Ivy Hooks is an internationally recognized expert on the subjects of requirements engineering and requirement management who has published numerous papers, trained and spoken to diverse audiences worldwide.