Author: Adam Alami

Throughout my career, I’ve experienced a number of situations where issues are not always apparent at first glance. Many times, superficial observations belie a fall sense of calm, while, in some cases, problems are known to exist, but still overlooked. These are some of the starting points of requirements analysis process:

1. I know what I want.
2. I know what the problem is.
3. I know the problem and the solution.
4. I do not know what I want.
5. I know there’s a problem.
6. I know there’s a problem, but I am not sure what it is.

Knowing exactly where your stakeholders stand is, in my opinion, the starting point towards eliciting and understanding requirements.

Even when the stakeholders claim that ‘I know what I want,’ to assume that these so-called ‘needs’ are valid and known would be naïve. A Business Analyst should be aware that the needs expressed by the stakeholders are not always exhaustive, valid, and will not necessarily lead to the right outcome.

What Happens When A Stakeholder is the “Know What I want” Type

A few years ago, I had an opportunity to work on a project where the client was the ‘I know what I want’ type. They were quite sure that all they needed was to modernize their IT platform, retire legacies, and introduce new capabilities to improve process efficiencies. Quite predictably, they insisted on building the project with the focus on these ideas. The entire requirements analysis were based on the idea that ‘I want to modernize the technologies I use.’ The analysis of the requirements and implementation of the solutions, from end to end, cost the company close to $50 million.

We delivered state-of-the-art solutions and implemented them successfully. However, when the company ran a benefits tracking activity to see how the modifications fared, it was found out, quite surprisingly, that the benefits were not fully realized. As for the improvements in efficiencies, there wasn’t much to speak about, either.

Related Article: Process Approach to Requirements Gathering

As analysts, we were again asked to assess this situation. This time, however, the stakeholder’s stance was ‘I am lost.’ The first instance of the project implementation was thoroughly based on the stakeholder’s suggestions, and it was assumed that the ‘requirements’ as the stakeholders saw them, were the only ones and the correct ones. In the second instance, however, we began from scratch to make the voyage from the unknown to the known. What we found had little to do with the needs that the stakeholder had insisted upon being delivered in the first instance:

1. The organization had deep-rooted cultural problems like:
   1. Dissatisfaction among staff
   2. Rifts among senior management
   3. Power struggle across the organization
2. Relations between business functions were either absent or dysfunctional.
3. Communication across multiple channels was broken and was often ineffective and insufficient.

As it turned out, modernization was indeed necessary, because the organization was carrying the risk of working with outdated legacy systems. The processes, too, were overdue for a review and possible re-engineering. However, these weren’t the only requirements. The organizational and cultural issues needed to be resolved before handling the technical issues. The root causes of inefficiencies were fundamentally cultural. The unbiased process of requirements analysis unveils the true problem.

What Was Learned

Never take for granted what stakeholders assume to be requirements. What the business user expresses is just one piece of the puzzle. There are unknowns that need to be discovered and put in front of the stakeholders.

Unfortunately, there is no single formula that would apply to every situation. However, there are requirements analysis principals that can be used to bring objectivity to the process.

1. Do not mistake what your stakeholders are telling you for the absolute truth. The truth has multiple versions. A Business Analyst has to discover every version of the truth to reach the absolute truth.
2. Be skeptical. Go above and beyond expectations, do your homework, investigate, and gather information in a structured manner to determine the accuracy of the stakeholder’s perceived requirements
3. Never leave any room for guesswork. Rely only on facts and evidence.
4. Data is of utmost importance. Try to collect information from every plausible source.
5. To counter biases, use multiple sources of information.
6. Never reason from insufficient data.
7. Every situation is different. Use your intuition.

We are called ‘analysts’ for a reason! When Sherlock Holmes walks into a crime scene, he does not solely rely on the questions ‘What has happened?’ He goes above and beyond. A Business Analyst always needs to know that the ‘needs’ expressed by the stakeholders are not always exhaustive, valid, and they will not necessarily lead to the right outcome.