COMMON MISTAKES BY BUSINESS ANALYST AND HOW

TO AVOID THEM

Term Paper

By

TRIVENI SAMINENI 215116044

INDHUJA.G 215116074
SINDUJA.V 215116075
MOHAMMED IBRAHIM 215116079

Department of Management Studies

National Institute of Technology
Tiruchirappalli – 620015

October 2017
COMMON MISTAKES BY BUSINESS ANALYST AND HOW TO AVOID
THEM

Whether you are an Enterprise Business Analyst, Enterprise/Business Architect, Business

Intelligence Analyst, Data Analyst, Process Improvement Analyst, Agile BA Team Member
or IT Business Analyst, you work to bring about change within the organization. Sometimes
these are small incremental changes, and sometimes these are big changes that require an
organizational shift or cultural change. Whether small or large, most of those business analysis
roles deal with gathering requirements. One of the key activities of a Business Analyst is to
draw out and document business change requirements from stakeholders throughout the
organization. As organizations struggle with maturing their business analysis approaches, let’s
take a look at some common mistakes that practitioners commit when eliciting requirements
from stakeholders.

For better understanding, we will see the common mistakes of Business Analyst in an order
discussed in the BABOK.

Improper Stakeholder Analysis

Often times resource managers or the Project Management Office (PMO) assigns resources to
projects almost as early as the Project Manager (PM) and Business Analyst (BA) are assigned.
With these resources the project marches on and the Business Analyst never does a proper and
complete Stakeholder Analysis. Stakeholders can be missed because that early in the project
all the lines of business within the organization that are affected may not be known. Perhaps
as the project moves on, it takes a turn into a new business line; and if the Business Analyst
doesn’t recommend that a representative of that business unit be assigned to the project team,
then they are not doing their job. If you have stakeholders from one line of business answering
for another line of business, you may not have all the business or functional stakeholders
engaged in the project that should be.

One of the first activities that the Business Analyst should complete upon being assigned to a
project is a Stakeholder Analysis. This helps ensure that the proper stakeholders are engaged
in the project. However, a Stakeholder Analysis is an activity that should be considered
throughout the project’s timeframe, especially when elicitation discussions take a turn into a
new business area and there isn’t a representative from that business unit on the project team.
This is the time for the Business Analyst to raise the red flag, complete a new Stakeholder
Analysis, and recommend new resources be engaged on the project.
Not Building Trust with Stakeholders
Often times BAs move from one project to the next, have four projects going on at once, and
don’t take the time to get to know new stakeholders that they had not previously worked with.
Getting to know the new people who you are working helps you understand their viewpoint
and agenda. This will certainly help if conflict arises during elicitation. Understanding each
person’s viewpoint will help the BA resolve the conflict by helping each person to understand
the other viewpoints in the conversation. The BA cannot accomplish this if they do not
understand the viewpoints in question. Taking the time to get to know someone shows them
that you value their input and participation in the project.

Not Guiding the Conversation During Elicitation with A Group of Stakeholders

Even with a small group of stakeholders, even in a one-on-one stakeholder interview,
discussions can go off course onto tangents that are not relevant to business needs. Sometimes
the conversation can be so far off course that it is not even relevant to the present project. These
conversations tend to distract from the task at hand and waste time during requirements
discussions. It can cause stakeholders to become frustrated with the process and become
disengaged with the project, as they find better use of their time than to continually hear a
couple of people dominate the conversation with what they did over the weekend or other
irrelevant topics. Another distraction is when there are two or three conversations going on in
the room. Of course, all these issues compound as the number of stakeholders in the
conversation increases.

Part of the task of the facilitator is to keep the discussion on topic. When the conversation goes
off on a tangent, it can be difficult to find the proper time to rope it back in. The sooner the
facilitator brings the conversation back on topic, the less likely further discussions will stray
off, the less time is lost, and the more engaged your stakeholders stay in the project.

Improper Language in The Requirements

Business Analysts that work in very large organizations or with very structured teams,
especially Quality Assurance teams, have heard that your requirements have to be well
structured and testable. Many Business Analysts have been told that requirements have to be
SMART: Specific, Measureable, Attainable, Realizable and Time-bound. I worked in one
place that advocated that requirements had to be SMART-CC, adding Complete and Concise
to the SMART acronym.
Quality Assurance Teams advocate the SMART test for requirements as they want
requirements that they can test. Even though, most of the time, QA teams test the solution
against the solution (functional and non-functional) requirements, most Business Analysts will
attempt to make their business and stakeholder requirements SMART. A lot of times the BA
will fall into the trap of expressing the requirement from the technical viewpoint and in
technical terms. So they have taken a requirement for/from the business and applied technical
terms or changed the viewpoint of the requirement, which adds ambiguity and confusion for
the business stakeholders.

Remember the business requirements and stakeholder requirements are primarily from and for
the business stakeholders. Even though the technical team will use those requirements, the
business is the main consumer of those requirements. Therefore, they should be expressed in
business terms and from the business standpoint. Likewise, the solution requirements have to
be SMART for testing purposes. The technical teams are the main consumer of those
requirements, so they should be expressed in technical terms.

Jumping to Design Before Getting the Requirements

I have been in many stakeholder requirements elicitation activities where the stakeholders start
talking about design and in which system this solution will be implemented. If the BA doesn’t
squash those discussions immediately when they start too early, then they tend to multiply and
consume the actual elicitation of requirements. Soon you have a design for a solution before
you truly understand the business problem you are trying to solve before you understand the
business need.

This tends to put blinders on the entire project team, and everyone marches down the same
path toward a solution because that is the only thing the team can see. Once the solution
discussions begin, and are not halted by the BA, it tends to give everybody hearing the
discussions a single focus, even though they don’t fully understand the business need. Quite
often this leads to alternatives to the initial solution never getting considered. This also leads
into my next two mistakes BAs make during elicitation activities.

Getting Approval for The Requirements Without A Shared Understanding Of Them

With today’s tight project schedules, often times the requirements approval process is rushed
so much that ensuring that all stakeholders, business and technical, understand the requirements
in the same way is difficult. With stakeholders coming from different viewpoints, ensuring that
they all understand the requirements is a task in itself. A structured requirements walk-through
will go a long way in accomplishing this task. As everyone in the walk-through hears comments
from other stakeholders, a common understanding begins to take form. The stakeholders learn
how others view the requirements.

Feeling Requirements Must Be 100% Complete And Accurate Before Sharing With The
Stakeholders
Novice Business Analysts can fall into the trap of feeling that the requirements that they are
documenting must be 100% correct before they share them with anyone. They feel that any
corrections or changes to the requirements mean that they did not do their job correctly. So in
an effort to make sure they are correct, they go talk to more stakeholders. They make sure to
elicit from everybody in the organization. Then before you know it, the project is in analysis
paralysis.

BA Managers have to ensure that there are no performance measures on the BA’s evaluation
that measure changes to requirements. It is not a good measure of how well the BA did the job
of elicitation. The BA themselves have to remember that they are one person and they cannot
know everything. Changes to requirements are not any indication of how well the task of
elicitation was done. Using a more collaborative approach to requirements elicitation, where
the requirements are more visible throughout the process, is a better approach to ensuring the
requirements represent what the business actually needs.

Documenting Constraints as Requirements

The fact that there’s a common or preferred approach to implementing a requirement does not
imply that there aren’t other approaches. Stating constraints and desires as requirements can
happen where stakeholders are caught up in the way things work presently or have a particular
vision of how they want a solution to work, causing them to disregard other possibilities.
Requirements should be about the “what” and not the “how”. The use of prototypes in
particular, has been criticized for causing developers to overlook better solutions and leading
to incomplete specifications.

Inadequate or Non-existent Requirements Tracing

When changes happen, requirements can quickly get out of sync, leading to inconsistencies.
Tracing should happen all the way from project initiation through design and development to
maintenance. Business needs become requirements, which can be traced forward to design,
software components, tests and implementation components. Traceability shows how a
requirement relates to others and can help to identify the software components that will be
affected by certain changes. Business rules should also be linked to the use cases that affect
them so that if a business rule changes, the analyst can quickly tell which use cases will be
affected.

Blindly Using a Template

I was recently handed a Business Requirements Document (BRD) template that had several
categories of requirements including documentation, reliability, scalability and training, among
others. All of these categories are non-functional, or solution, requirements—and as I said this
was in the BRD template. Recognize the fact that these are solution requirements and do not
have any place in the BRD. If you receive a BRD like this, remove these categories or mark
“N/A” or “Will be defined during design and included in the Functional Requirements” in each
category. If you do the latter, check the Functional Requirements document template to ensure
that the category is in that template as well. If not, add it. Don’t blindly use a template just
because that is what the organization uses. Don’t try to define solution requirements during
business requirements. How do you know what your training needs are if you don’t know what
the solution is? BAs are agents of change. Challenge the template and help the decision makers
in the organization see the value of a correct template.

Too Much Reliance On Templates

A document template sets expectations about what types of requirements and requirements
artifacts are to be produced. The first problem with most templates is either that they are too
generic and broad to be of use on a specific initiative, or that they are too narrowly focused and
fail to recognize the differences between projects. Many BAs are frustrated by their current
templates because they don’t meet the needs of a specific initiative. Many templates are focused
on software requirements and ignore all of the other areas where business analysis can really
be of use, like changes to business policies and rules, job functions, relationships, capabilities
and workflows. Templates establish the focus of the BA work on documentation rather than on
discovery, collaboration and analysis. Filling out the template on time becomes the goal, rather
than understanding the requirements and recommending solutions. A template-driven
requirements document is project-centric, and the usefulness of the document diminishes as
soon as the project is completed. But, the reality is that the requirements actually live on with
the solution and could be relevant for many years. Since most project documents are seldom
referenced after the project, consider changing the focus of the BA work to produce a coherent
set of versioned requirements artifacts like process models, a data model, use cases and
storyboards that live on their own and can be base-lined and assembled into a document at any
time. You will need a requirements management tool to do this well.

Assuming Use Cases Are Always Sufficient

Use cases are one of the most popular means of specifying requirements. They are easy to
understand by both technical and business people and focus on system functionality from the
user’s perspective. Despite the universal-like acceptance, there are other categories of
requirements better depicted using other models. For example, data flow diagrams emphasize
the flow of data through the system while an ERD can serve as a foundation for database
design.
While use cases can be extremely useful as an identification and analysis technique, most
analysts find it difficult to express ALL their requirements as use cases, especially non-
functional requirements. Use cases should be combined with other techniques to ensure that
the desired solution is specified as completely as possible.

Inadequate Tool Support

Many requirement models are not properly documented to back up actual requirements. The
requirements management tool should enable storing of requirements metadata. The tool
should also be able to capture diagrams as well as the textual requirements that support those
diagrams.
Requirements Management tools are important because they make it easier to create
relationships and dependencies between requirements data, thus ensuring that traceability is
easier to accomplish. Simple tools like Excel and Word can easily lead to missed and
conflicting requirements. They make it hard to collaborate and accomplish versioning. When
dealing with a large number of requirements, requirements should be stored in a large database
where they are maintained to make sorting and querying easier. All the required metadata about
the requirement like the source, priority and status should be stored so that they are easier to
manage.
Trying to Make Too Many Changes At Once
It’s usually easy to spot lots of possible areas of improvement in your business analysis
practices. But culture, tradition and ceremony are likely to resist too much change at once.
Some of the changes requested by a Centre of Excellence like enhanced time and status
reporting may just be perceived as low-value overhead. So if you want to make sustained
changes, the only way to do so is to lay a solid foundation, make incremental changes, realize
and communicate the benefits and provide ongoing and substantial reinforcement to those
changes. Training is the easy part but sustaining it is difficult. Training can encourage your
BAs to consider new ways of working. Applying the theory from training is quite difficult, and
almost always requires time to recognize how to apply it in real life, to realize how to apply it
effectively and to apply constant reinforcement. Consistency in the way the BAs perform
business analysis should be a primary objective, prior to making substantial improvements.
Every one of the BAs has a group of stakeholders who must be informed and educated about
the new approaches to business analysis. Time must be allotted to allow them to make the
changes and achieve buy in from those stakeholders. Many of those same stake holders work
with other business analysts, not spotting inconsistencies very quickly. Some stakeholders will
exploit those inconsistencies because it makes it easier for them to do their own work. Focus
on incremental changes; test new techniques and tools on pilot projects and make adjustments
so that the project is successful. Communicate the successes broadly and then roll the
improvements out to other projects, providing strong support until the BAs using them indicate
that support is no longer needed. Be prepared to abandon some changes if you can’t be
successful with them.

Business Analyst Should Avoid

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.
1. Making assumptions that are not quickly resolved into fact
2. Ignoring stakeholders or stakeholder groups because they are so difficult to deal with
or contact
3. Failing to ask questions

MAKING ASSUMPTIONS
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.
Controlling your own assumptions
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.
Identifying and controlling 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 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:
- “By assumptions, I mean 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 and others in your business work, and
will be reducing those late surprises due to bad assumptions.

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”.
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.
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 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.
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 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.
- Determine which items are really important for the person to answer or confirm for
you. Go into the meeting with these items written down and a copy for all in attendance.
Give your hard–to-reach stakeholder a moment to read the items.
- Get as much information and confirmation as you can in 14 minutes. Then excuse
yourself and thank the person for his/her time.
- If you need more answers, request another 15-minute slot in his/her 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 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.
- Determine the importance of your questions or statements that need confirmation 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 he/she 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 question. This is usually
easier to answer and more likely to get you a fast answer. If you are right, the person
can easily tell you so. If you are wrong, that person is going to want to give you the
right answer in a hurry.
FAILING TO ASK QUESTIONS
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.
Common Excuses
“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.
How to Be More Effective at Getting Information
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.
CONCLUSION
The business analyst plays a critical role in representing the best interests of the organization
and justifying financial investments. As the BA navigates the sometimes complicated business
landscape, they should actively avoid each of the pitfalls discussed. To do an effective job at
requirements elicitation, avoid these traps that can get your activities off track. Be sure you
have everyone in the conversation that should be, define the business need before designing
the solution, ensure that there is a shared vision of the requirements, and document the
requirements in a collaborative approach with the project team. This will help ensure that you
do an effective job at eliciting the requirements for your organization. Critical success factors
include; Extensive stakeholder engagement, Incremental improvements built on consistent
practice, Focus on improved processes and not just templates, Ongoing coaching and
mentoring by people who truly know business analysis and the business domain and Shared
accountability for successful business outcomes. The best practices outlined in this Term Paper
not only encourage success on a specific project but, more importantly, help the business
analyst develop skills that provide a foundation for long-term success.