Tuesday, 04 October 2011 11:45

Six Common Problems Faced By A Business Analyst

Written by
Rate this item
(56 votes)

Usually in an SDLC cycle, the requirements elicitation phase is right at the beginning. As oft repeated, this is a very crucial phase that will make or break the project. This is the only time in the entire SDLC when the business users spend considerable time with the business analysts. Since these are focused sessions or workshops, it is imperative that the business analyst is able to make the most of the business users’ time and knowledge. It is important to remember that there will be no phase in future that provides the BAs with this luxury! However, it is not without its own problem areas.

In this article, I will highlight the most common problems and provide some pointers as to how we can work around them. These may not be foolproof solutions but they will work in most situations. I leave it to the reader to decide.

1.   Resistance in sharing information: In some cases, information will not be forthcoming. These users will regularly attend your workshop but it will take a mammoth effort to make them talk. At the other end of the spectrum, there are users who make your life difficult by bombarding you with loads of documents. In such a scenario, even to find the answer to a simple question, you may have to read hundreds of pages!

How to get around this problem:

The very fact that the users are not sharing relevant information should raise red flags. We need to understand the users’ reasons for doing so:

      1. Are they resistant to change and are so used to a certain way of working that they do not want to change?
      2. Is it a complicated case of ego issues and office politics that causes them to not want to share information?
      3. They really don’t know why a certain process is being done in a particular manner and they have been blindly following it for ages.

The first two issues get addressed gradually once the BA is able to gain the users’ confidence and trust. In my experience, this usually happens after a couple of sessions. Once the ice is broken, information flows more easily.

The last issue is a bit tricky as users hate to admit that they never thought of the ‘why’ and they just concentrated on the ‘how’. The BA has to word his or her questions very skillfully here. After playing detective, it is often very clear that users don’t have the information that is the BA needs. Once this is known, the BA will have to identify the proper source for this information by talking to the facilitator.

2.   Irregular attendance:

  1. This happens when key users attend one session and then skip a few in a row. Suddenly, they appear and start changing the course by asking/changing things that were frozen during their absence. Or worse still, they want you to start from where they left.
  2. A set of users keeps on rotating, and a user who is present today may be gone tomorrow. There is inconsistency in attending the workshop.

How to get around this problem:

The first problem usually happens when the changes have been proposed by IT and not driven by a business need. Since there is no buy-in from the business users, they are not interested in attending the workshops. However, as the project is be driven from the top, they attend the sessions intermittently to get the ‘attendance’ and ‘participation’ tick mark. They also pose hurdles in the form of the next problem as they send their team members in turns.

As a business analyst, apart from escalation to the project manager and the project sponsor, there is nothing much that can be done. The BA can highlight that the requirements captured during the workshops may have to be re-validated as there is no continuity of the users.

3.   Accountability for decisions:

There may be instances in which the current business process needs to be changed or modified to make it more efficient. The users may all be in consensus but none will volunteer to approve it. Or, there could be situations where the elicitation process may reach a dead end if certain decisions are not taken.

How to get around this problem:

The very fact that the users are in consensus is itself a big win. Here, the only issue is of accountability. If the issue under discussion can be moved into a parking lot and can be considered later, then the next function can be picked up. If this is not possible then along with the project manager, the BA can prepare a business case and present it to the user community. The business case document should have enough details for the decision-maker to come to a decision. It should clearly elaborate on the issue on which the decision is sought and the preferred outcome to resolve that issue.

4.   Resolving user conflicts:

This could take two forms:

a.   Conflict between the business analyst and the users: This usually happens when the business analyst tries to propose a new or a modified approach to the current process that is being followed.

How to get around this problem:

To address the first problem, the BA will have to first understand the resistance from the users. Has he/she missed or not taken something into consideration? Or, is it again a situation where the users wish to continue doing what they have been doing? The BA will first have to get clear answers for these and potentially other questions. After all this is done, if the BA still feels that the recommendation needs to get a user buy-in, then the approach followed will be similar to the one that we saw in the earlier problem area, i.e., preparing a tight business case without any loopholes and presenting it to the users.

b.   Conflict between users: If users who perform similar tasks across different organizational functions come together, there is bound to be conflict as each one feels that their approach is best.

How to get around this problem:

This could be an ego issue as each function would like to outshine the other. This is an area where the BA’s facilitation and analytical skills are put to test. The BA should be able to dissect all the views that have been put forth and try to facilitate a healthy discussion in which all the parties are listened to. It is not necessary to accept every suggestion but it is important that each user feels that he or she has been given a fair chance to present his or her case. In most situations, this approach works. If it doesn’t, the only option left is escalation to the relevant people.

5.   Real needs vs. perceived needs:

Sometimes it becomes difficult for business users to distinguish between a real need and a perceived need. A perceived need is always a little tricky as it may be a workaround/temporary solution for the problem and not the problem itself!

How to get around this problem:

Real needs are the obvious ones and can be easily identified. These are usually the issues or the major process changes that the business requires. In the eyes of the business user, a perceived need is very much a real need. The trick here is to dig deeper and probe to discover the real issue. For example, a user might ask for the functionality to update data. This can definitely be a risky requirement as it may lead to data tampering. However, the real need may be that the source data is received in an Excel file and the user probably has to do some sort of data formatting (e.g., date to be in mmddyyyy instead of ddmmyyyy) and hence the request. This can be easily achieved by asking the source to provide the data in the requisite format. Thus, it is very important for the business analyst to dig deeper and identify the true problem area.

6.   Changing needs:

Time and again, we have faced this, and there is always a dilemma as to whether a BA should accommodate or ignore the change.

How to get around this problem:

This is a perpetual problem and I am sure that there is hardly anyone in the business analyst world who has not faced this! There is no hard and fast rule to accept or reject the changes. The best way is to first understand the reason for the change. If it is regulatory then the change will most likely have to be included but at the cost of a delay in the project delivery. If it is not regulatory then a dialogue is required with the customer to understand the priority, whether it can be included in the current phase or if it could be delivered in the next phase. The best method is to do the MoSCoW analysis. This will definitely provide the business analyst the information that he or she seeks.

Don't forget to leave your comments below.


Aruna Parameswaran Mahesh is a technical person with 12+ years of experience who moved into a functional role by choice. Currently working as a business consultant and mentor with an IT organization, Aruna has led the requirements phase of multiple implementation projects across geographies while spending the last 6 years specializing in the life insurance domain in the UK and Asia-Pac regions.

Read 100452 times

Latest from Aruna Parameswaran


+4 # Bennett 2011-10-04 07:13
Nice article, well articulated. One point that could be proffered is to get to know your user on a personal level. Rather than jumping straight into business, a bit of chit-chat, humor, socializing, etc would open them up to the business at hand. Offer coffee, refreshments at meetings and watch attendance rise. Think of your user as your customer - sometimes the smallest offerings can make the biggest difference.
Reply | Reply with quote | Quote
+3 # Vijay 2011-10-04 09:18
Your are right.Very Good Article!!! We cannot always do escalation for every problem or scenario......u sually the BA is thrown to client place and company say's come after 3 months with base lined requirements. Basically we have to know the techniques of 1. How to extract information from audiences 2. How to present information to audience. 3. Soft skills required like team management, facilitation skills, conflict resolutions skills, building consensus, negotiation skills, changemenagemen t skills.....etc
Reply | Reply with quote | Quote
0 # Pankaj 2011-10-04 15:17
Hey Aruna, nice article and very well said. All these things are face by metoo during Elicitation Phase. I usually follow silence, this make the fight to freeze. And follow a speak at the right time approach. And if this also doesn't solve the purpos then you are correct in sayin, escalations also helps. Hey wuld like t know something. Can you please give me a test mail or write your id here.
Reply | Reply with quote | Quote
0 # Seo Keo 2011-10-04 16:34
The article is good, thanks. Just one comment, though. The statement "This can be easily achieved by asking the source to provide the data in the requisite format" should be taken with a caution that in practice it is not so easy to achieve. More exploration of the source is required before the answer is given to the business user.
Reply | Reply with quote | Quote
+1 # Raman Udgiri 2011-10-04 17:12
Nice Aritcle!!!! This Article touched all the problems faced by BA. Very useful suggestions made to get around the problems. Very Nice!!
Reply | Reply with quote | Quote
0 # Aruna Parameswaran Mahesh 2011-10-04 18:06
@Bennett: Thanks for your inputs. I too have tried my hand at breaking the ice by socialising/sma ll talk,etc.; but it works differently in different cultures/geogra phies.So, I did not add it in deliberately. But,yes, definitely worth a try! @Vijay: Thanks for your views. As rigtly said, soft skills are extremely important for a BA. @Pankaj:Go od to know that you like my article. It inspires us to write more & share our experience with the BA community at large. Please feel free to write to me at . @Seo Keo:Thanks for your view! Exploration & investigation are key to getting the details. @Rama n: Thanks that you liked my article! I do hope my suggestions work for you
Reply | Reply with quote | Quote
+1 # Maryam Khan 2011-10-04 18:52
Thanks Aruna. Just one question: What's the MoSCoW analysis method?
Reply | Reply with quote | Quote
0 # Colin 2011-10-05 11:27
A good article. With regard to 'Irregular attendance of workshops', I would suggest that if this is a problem, then maybe workshops are not the right requirements elicitation technique for the piece of work. Instead I would be looking at one-on-one sessions or a series of smaller meetings - while making sure that reqts raised in these sessions are circulated to all project team members. Maryam – MoSCoW is a means of assigning a priority to requirements, it consists of: M = Must have, S = Should Have, C = Could Have, W = Won’t have (this release / phase / iteration). How ever, in practice, business owners usually insist that all reqts have a priority of ‘Must Have’. How to get project members to agree on a sensible priority is probably an article in its own right. With regard to 'Irregular attendance of workshops', I would suggest that if this is a problem then maybe workshops are not the right requirements elicitation technique for the piece of work.
Reply | Reply with quote | Quote
0 # Aruna Parameswaran Mahesh 2011-10-06 00:55
@Maryam:Just saw your query now. Thanks Colin for answering the same. The use of MoSCow was first brought in by Dai Clegg of Oracle UK Consulting. It has almost become a defato standard for prioritisng requirements. @Colin:Thanks for sharing your perspective.
Reply | Reply with quote | Quote
0 # GerryM 2011-10-08 01:54
Thanks Aruna for a great topic. BA's get plenty of "what to do" advice, but need a lot of "how to do" advice, especially in new situations/proj ects. I've found that there are always business users who resist any project, and sometimes you never know their motivation. I have found that you can get to know teams in the user community and you will find the team members who not only can provide details on almost all the processes (superusers), but will also provide insights into other team members' personalities and motivations. This approach is an informal networking technique which can often be done during breaks in a requirements workshop (focus on the participants who are active contributors, and capture their contact info for offline discussions). When you encounter process gaps in requirements gathering, I always prefer setting up a one-on-one session with the key user, and reassure the reluctant user that I only want to observe the process, not interfere with their work by interviewing them. IF you can get their buy-in to this approach (note the big IF), you can then visualize each step in the process and gain insight into exactly what they are currently doing. Through multiple iterations, any remaining questions you have can be placed in a 'parking lot' for followup. The reluctant user will often feel compelled to ask if you have any questions if you haven't said much during the session. But, if they still seem resistant, I recap the remaining questions in an email and copy both the project manager and the user's manager. This is not really escalating the issue, but only making the next level aware that the issue is documented and needs to be addressed in a timely manner. The key is to avoid being confrontational or aggressive in tone (please respond by MM/DD). Thank the user for their time and participation to date and request a response at their earliest convenience.
Reply | Reply with quote | Quote
0 # Aruna Parameswaran Mahesh 2011-10-09 15:46
@Gerry: Thanks for sharing your experience. Do appreciate your response.
Reply | Reply with quote | Quote
0 # Ram 2011-10-10 22:17
Thanks Aruna for this practical and interesting article and also to others for sharing their perpectives..
Reply | Reply with quote | Quote
+1 # Ian Guénard 2011-11-18 04:43
Good article. I'll add a few more commen challenges to the list: - Pre-conceived solutions. When clients come into a requirements elicitation meeting with pre-conceived ideas on solutions. They dont want to say that they need to find a way to manage their projects more efficiently... they want to setup Project Server 2009. This makes it difficult to get to the underlying needs and requirements, and you usually dont end up looking like a "team player" by wanting to propose alternative solutions to what they have been wanting for years - that new shiny software package that doesnt really fit their needs. Difficult to break this when its settled in deep, but documenting and agreeing on needs documentation BEFORE going into requirements is a good start. A good lead question could be "Okay, so what do you plan to do with Project Server 2009? What functions will you be using? What is it going to help you with?". - Misunderstandin g of our profession. I have run into situations where (I swear!) the project manager would remove all tracability information from project charters and scope definitions. Thank god I had access to version control. Why do we need tracability and user needs when we want requirements from a BA? Document me some requirements! To avoid this, I make it clear at the start of a project, what my methodology is, what is to be expected from me as deliverables, and how I will be consuming this information for process Quality Control.
Reply | Reply with quote | Quote
+1 # Sanjay Dugar 2011-11-29 13:13
Very nice article and well articulated - problem and solution approach. One thought I had on changing needs problem faced by BA's - I think a little focus on building and a good "Vision and Scope Report" and documenting it, going on to share it with all stakeholders before the elicitation would help a lot, especially with questions around how it ties into the Vision and Scope agreed upon. The other two techniques revolving around "Appreciative Inquiry" and the "OLA Framework" would work very well, as I have tried this and found it to be very successful in managing this area of challenge.
Reply | Reply with quote | Quote
0 # Kim 2012-07-25 05:14
Just want to ask, how do you get around this problem: I'm new in a company as a business analyst. Because there is no available project yet, the manager tasked us to investigate issues and opportunities in all other departments and create/defend our own project initiation. However, without any data or documentation for us to review, we don't know where and how to start. Can you please advise on what to do?
Reply | Reply with quote | Quote
0 # Birva 2012-08-17 18:32
Hey Aruna,

Very very informative article. Article contains lot about how to come up with the solution rather than going in deeper confilction.
Thanks for sharing!
Reply | Reply with quote | Quote
0 # GOOD WORK 2012-10-04 02:47
Reply | Reply with quote | Quote
0 # Dave Nails 2013-04-22 04:58
Thanks for the At, Im still growing in the world of BA and With great pleasure I found it easy to study n master challenges bfore tackling'
Reply | Reply with quote | Quote
0 # Ngozi Adiuku 2013-04-24 22:24
Great topic! These are real issues in the BA world. Thanks for the insight on how to deal with these challenges.
Reply | Reply with quote | Quote
0 # Shipra 2013-08-09 00:45
best piece available online on this topic
Reply | Reply with quote | Quote
0 # Temmy 2013-08-25 08:22
Thank u for writing this article. It's been very helpful. Am new in the BA world and am reading every available article I can get.
Reply | Reply with quote | Quote
0 # Anjali 2013-10-25 00:45
This is really helpful for BA
Reply | Reply with quote | Quote
0 # Prabhu 2014-02-03 19:38
Very nice article, Aruna. For ages these have been the issues And these will be the issues for the rest of the humanity as well! Networking always help. It's just that we need to know their culture, we need to then adapt to their's as much as possible to socialize. We need to remember that different people have different perceptions, problems, approaches and philosophy. If we can count in all of them and if we are genuinely interested in them and the work, I am sure we can break any ice. Anyway appropriate humour and a good hot coffee works for me!
Reply | Reply with quote | Quote
0 # Prabhu 2014-02-03 19:40
Oops sorry, I forgot, Aruna! I mainly intended to thank you. Thanks for the nice write-up.
Reply | Reply with quote | Quote
0 # Vik 2014-02-04 06:26
Good Article. These are indeed very common challenges and mostly likely a project will have all of them. I believe the solutions of each challenges could be various and are topics of more details, the solutions you have provided are "must do" or starting points. So before i employ some innovative tactic I would ensure if I have tried all effective solutions in here.
Reply | Reply with quote | Quote
0 # Mohan 2014-02-04 10:35
good one and very informative
Reply | Reply with quote | Quote
0 # Neha 2014-02-04 13:08
Very nice read....lists beautifully the various problems of a BA during elicitation.
Reply | Reply with quote | Quote
-1 # Ravi 2014-06-30 05:30
Very nicely articulated! Thanks Aruna
Reply | Reply with quote | Quote
0 # Prachi 2014-08-08 22:25
Great article Aruna !! :)
Reply | Reply with quote | Quote
0 # NN 2016-07-29 12:30
Reply | Reply with quote | Quote

Add comment

Security code

search Articles

© BA Times.com 2016

DBC canada 250