Author: Aruna Parameswaran

Six Common Problems Faced By A Business Analyst

Written by Aruna Parameswaran on October 4, 2011. Posted in Articles.

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:

Are they resistant to change and are so used to a certain way of working that they do not want to change?
Is it a complicated case of ego issues and office politics that causes them to not want to share information?
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:

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.
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.

Capturing Implicit Requirements

Written by Aruna Parameswaran on August 2, 2011. Posted in Articles. 1 Comment on Capturing Implicit Requirements

Introduction

A typical SDLC project starts with a requirements-gathering exercise followed by an analysis phase. During the requirements analysis phase, a detailed study is done in order to identify the different pain areas that would be addressed by the software that would be delivered. Often we come across situations, or more appropriately, business scenarios, wherein the requirements are not clearly documented. They are vague and do not provide any clarity as to what exactly is expected. This leads to ambiguity, and finally, a software that delivers everything except what the client asked for! Unfortunately, this discovery happens during the user acceptance phase. Defects are identified that inadvertently point to requirements that have not been clearly captured/documented. A standard reaction of the business users would be, ‘We thought that this was going to be delivered…it is an Implicit requirement!’ Once we hear this statement, a typical ‘passing the buck’ game starts between the IT department and the Business Users.

This situation could have been easily avoided if the Business Analyst had taken the efforts to identify the implicit requirements. A key responsibility of a Business Analyst is to define the Scope of the system that is going to be built, and in this process, ensure that the Explicit as well as Implicit requirements are clearly documented.

Understanding Implicit Requirements

Let us begin with understanding the difference between an Explicit and an Implicit requirement. Usually, the requirements that are stated by the business users in the different meetings and interviews are categorized as Explicit requirements. These requirements are the easiest to capture. They are usually supported by loads of Documentation, or for that matter, even a legacy system screenshot!

Implicit requirements are the hidden or ‘assumed’ requirements. Business users expect these to be delivered and hence may not feel the need to explicitly mention them in the business meetings. It could be challenging to actually define the scope as there is no clear-cut documentation or boundary available. The keyword here is ‘scope’. Let us try to understand this with a very simple example:

User requirement:

Screen to capture the following employee details:

Employee number
Employee name
Department

Implicit requirement:

Capture Designation as well

Since it is an Employee data capture screen, the business users would assume that there is a field to capture Designation as well. This would definitely be an Implicit requirement. But is it right to assume that this is the ONLY implicit requirement?

For instance, I can add a couple of other implicit requirements, such as:

Duplication check required on the ‘Employee number’ field
Should have the facility to Search for an existing Employee

Here is where the dilemma starts. Some Business Analysts would totally agree with my listing of implicit requirements, but I am sure there would be many others in the Business Analyst world who probably disagree. For instance, Search facility could be provided as a separate screen, and hence that would be a separate requirement altogether.

The key point here is to recognize that capturing the implicit requirement is more of a need than a luxury.

Another example would be in a data processing centre where the performance of a data entry operator is measured by the number of entries that have been done in the system. For example, consider a typical airlines scenario wherein millions of passengers travel daily. A data entry operator in such a scene would have to enter hundreds of passenger coupons in the system and his KRA or performance is measured on the basis of the number of coupons he enters in the system. In such a scene, the Business would need a system that would capture data quickly and in a highly efficient manner. Here, the implicit need is that the data capture form has to be designed in such a manner whereby the maximum data/information on the form can be entered using the keyboard rather than using the mouse. In other words, maximum information must be enterable using keystrokes rather than using the mouse.

If this implicit requirement is missed out, then we end up in situation where the data entry operator would never meet his KRA, and looking at the bigger picture, the airline would miss its SLA. This could lead to tarnishing the airline’s image and would ultimately impact its business.

Scope Control

If documented well, Implicit requirements can be used as an excellent tool to control the scope, which in turn will lead to lesser defects and finally a Satisfied Customer! But at the same time if the boundaries for the requirements are not clearly documented, it can be misused and will lead to Scope Creeps, huge defects and a Dissatisfied customer.

This leads us to the conclusion that the Business Analyst community would have to use certain proven methods to define and bound the scope. A cost-benefit analysis will be the ideal way to deal in this situation. There may be a scenario wherein an endless list of implicit requirements inadvertently increases the cost with no visible benefits. On the other hand, it is quite possible that by deciding to incorporate minimal implicit requirements, the client would reap huge benefits.

In a nutshell, in order to ensure that the implicit requirements are never missed out, we would need to take a step back and always try to understand what exactly the Business user is looking for and if we have really understood this need. To conclude, we Business Analysts do play a role of ‘the Truth Seeker’ and thus need to unravel what lies beneath, in our quest of understanding Business requirements!

Don’t forget to leave your comments below.

Aruna Parameswaran : A technical person with 12+ years of experience who moved into a Fucntional role by choice. Working as a Business Consultant with an IT organization and have led the Requirements phase of multiple implementation projects across geographies,primarily Asia-Pac and UK with some exposure to the US geography. Have spent the last 6 years specializing in the Life Insurance domain in the UK and Asia-Pac regions