I'm going to discuss common business analysis failures based on my 25 years of BA experience and also talk about some projects where we miserably failed in and the reasons for the failure of those projects.

In the first project that I am going to discuss, we were implementing ERP for a large European company. It was month-end. We had our distributor trucks in our warehouse but our system to dispatch goods failed.

This was really a pathetic time for us as the company had such a bad experience.

We were the first country to go live with the ERP system but because of our failure, there were six other countries that pushed the project by six months and that easily cost the client more than 5 million euros.

In the other project, I was working as a consultant. This client was developing an insurance management system for itself.  After nearly 3 years of developing the product, the parent company decided to shut this project which was being developed for a specific country. They wanted one system across the entire Asian region and this product could not handle the languages which the other countries spoke or wrote.

This was a very sad state of affairs as somehow the need for the project was not identified at the onset and due to this, the project got abandoned.

So why do such things happen in a project?

What are the Common Business Analysis Failures? 

It so happens that sometimes we forget to capture critical requirements during the business analysis activity. This results in a situation where the final solution is not acceptable to our stakeholders.

So, let us understand what these critical requirements are and how do we ensure that we don't forget to include them in our requirements document or product backlog.

Though some of you may question it, this kind of situation can happen very often in an Agile environment.

This is because the aim of Agile to deliver something very quickly could compromise some of the critical requirements which may not be from the end-user community.

So, what is a Critical Requirement?

A requirement, which when missed, can cause significant changes to the project including its cancellation, is a critical requirement.

There will always be some requirements that will be missed during the requirements gathering stage, but if they do not cause a significant impact on the project, they are not so critical to the project.

Some typical critical requirements that I have come across in my career are-

• Legal requirements. If you miss legal requirements then it could result in a significant change to the product or project.
• Non-functional requirements are another source of requirements that generally tend to be missed out.
• Requirements from powerful stakeholders. These stakeholders have so much influence in the company that if their requirements are not met, they may stall the project altogether.

Let us understand why non-functional requirements or NFRs are critical requirements.

Please understand that non-functional requirements typically tend to have much more impact on application architecture than functional requirements. In the first example that I've mentioned, the case of the system not being able to handle the month-end activities, we did not predict the load that happens on the system during the month-end. Usually, during the month-end, the load on the system can be 10 to 15 times higher than what is encountered during regular days.

Similar examples could be the Black Friday sale or any other such event where the load on the system can be tremendously high compared to other days. If the system is not designed to handle such a load or if you have not considered the load pattern on the system obviously the system is going to fail and it's going to put a lot of pressure on the project and the company as well. It could also lead to a serious setback in the market perception of the company.

So, to get the right NFRs, the stakeholders must take a long-term view of the application, because an application is not something that we change every 3 months. Application architectures are usually frozen for a period of time. So, increasing NFR's to a scale that is not feasible in the future will result in a system failure. And sometimes stakeholders are also afraid of proposing an NFR which will increase the system cost substantially.

Fortunately, today we have many solutions available over the cloud that allows us to scale the applications much more easily than what it was before. But at the same time, we must be cognizant of this fact that many stakeholders do not have a significant idea about NFRs because these are things that they do not encounter on a day to day basis.

So, what do we do?

We need to make our stakeholders aware of the NFR impact and discuss the need for having alternatives that will allow the flexibility to grow the system in the future.

Also, there should be a comprehensive list of NFRs. This will allow us to not forget any NFRs that can affect our solution.

For this purpose, at Adaptive, we have created a comprehensive NFR checklist. In our checklist, we have attempted to provide you with a list of about 40 commonly available NFRs that you should be aware of. There is a short explanation about the situation in which they mostly apply, whether they are applicable to the project and if applicable, if they are available and how can the NFR be tested.

This is one of the templates that we provide in our library in our product Suxeed.

Another thing that is required is a good comprehensive business requirement specification template. Although some of you may laugh at the concept, considering that agile does not talk about a business requirement specification document. Trust me if you have a reasonably well developed BRS template, especially if you are developing an application that is supposed to be used for a reasonably long period of time, it will make sure that you are not forgetting the major aspects that need to be considered. We also have a very detailed SRS specification template which can act as an extension to your user stories.

You can view & hear this blog -

https://www.youtube.com/watch?v=3KcKxV7ZMCk

Suggested Reading-

Agility vs. Analysis Foes or Companions?

9 yards of requirements elicitation

Business analysts, are you prioritizing requirements the right way?

Non-Functional Requirements - The Hidden Iceberg