Solutions to Six Common Hurdles BAs Face

Usually in a System Development LifeCycle the requirements elicitation phase is right at the beginning — or at least should be, no matter what the methodology: Agile, Waterfall and everything in between. All Business Analysts know that it’s a crucial phase. However, since these are very focused sessions, it’s still not without its problem areas.

Jumping over HurdlesThis article will highlight six of the most common hurdles that are encountered by Business Analysts, and show how they can be solved, or at least mitigated to a certain extent.

1.   Resistance to Sharing Information

In some instances, information will not be forthcoming. There are subject matter experts (SMEs) and other users who will attend your session, but it may take a mammoth effort to get them to talk. On the other end, you may have SMEs and others who make your life difficult by bombarding you with documents.

How to Get Around the Problem

The fact that SMEs/users aren’t sharing relevant information should cause some worry. You therefore need to understand their reasons for holding back.

  • Are they resistant to change and used to a certain way of working that they don’t want to change?
  • Is it a complicated case of ego issues and office politics?
  • Perhaps they really don’t know why a certain process is being done in a particular manner, but have blindly followed it for ages. This seems to be a common theme.

The first two issues can be solved once the BA is able to gain the users’ confidence and trust. In my experience, this usually happens after a couple of sessions. After that, the information flows more easily.

The last issue is a bit tricky, since users hate to admit that they haven’t thought of the “why” and have just concentrated on the “how.” The BA has to word his or her questions skillfully here. After playing detective, it’s often clear that users don’t have the information that the BA needs, and you’ll then need to find the proper source.

2.   Irregular Attendance

  • This happens when key users attend one session and then skip a few in a row or attend only sporadically. Then they suddenly appear and start asking/changing things that were frozen during their absence. Or worse still, they want you to start from where they left off.
  • Revolving door users who are present today but may be gone tomorrow. There is inconsistency in attending the workshop.

How to Get Around the Problem:

The first instance usually happens when changes have been forced by someone and not driven by a business need. If there’s no buy-in from the business users, they’re not interested in attending the workshops. They also pose hurdles in the form of the next problem as they send their team members in turns.

Unfortunately, apart from escalation to the project manager and the project sponsor, there is nothing much that the BA can do here except 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 for whatever reason, none will volunteer to approve it. Or, there could be situations where the elicitation process may reach a dead end if certain decisions aren’t taken, causing a bottleneck in the SDLC process.

How to Get Around the Problem

The very fact that users are in consensus is a positive. Here, the only issue is accountability. If the issue under discussion can be moved into a parking lot and be considered later, then the next function can be picked up. If this isn’t possible, then along with the project manager, the BA can prepare a business case and present it to the user community.  The business case should present enough details for the decision-maker to approve it or not. The business case should clearly elaborate on the issue in question and the preferred outcome to resolve it. It should state all the relevant options.

4.   Resolving User Conflicts

This could take two forms.

First, conflict between the business analyst and the SMEs/users: This usually occurs when the BA proposes new or modified approaches to current processes and encounters resistance.

How to Get Around the Problem

To address this, the BA has to understand the resistance. Have users missed or not taken something into consideration? Or, is it again a situation where they wish to continue doing what they’ve been doing? If after the BAs determined the cause of the resistance they still feel that the recommendation needs user buy-in, they should prepare a tight business case without any loopholes and present it to the users. (see issue No. 3).

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

How to Get Around the Problem

This could be where each function would like to outdo the other. This is also an area where the BA’s facilitation skills are put to the test. You should be able to analyze and separate all the views that have been put forth and try to facilitate a healthy discussion in which all the parties are listened to. 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 a problem and not the problem itself.

How to Get Around the Problem

Real needs are the obvious ones. They’re usually the issues or the major process changes that the business requires. For the user, a perceived need seems to be very much a real need. The BA must dig deeper and probe to discover the real issue. For example, a user might request to have data updated automatically. This can be a risky requirement because it could lead to data tampering. However, the real need may be that the source data is received manually in an Excel file and there is some manual formatting or manipulation that needs to be done. In this scenario, it’s very important for the BA to identify the true problem area.

6.   Changing Needs

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

How to Get Around the Problem

This is always an issue to some degree. The best approach here is to understand the reason for the change. If it’s regulatory, for example, then the change will have to be included, even at the cost of a delay in the project implementation. If it’s not regulatory, then a dialogue with the customer is required to understand the priority, whether it can be included in the current phase or if it could be delivered in the next phase. There should be a Change Management process in place that is regularly used. Also, try a MoSCoW analysis (Must, Should, Could, Won’t).

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>