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.