Are You an ‘Analyst’ or a ‘Facilitator’?

There seems to be a certain generality that people use, in business contexts and otherwise, to define ‘requirements’. At times, it’s conveniently forgotten that the road to achieving solutions is made short work of when these ‘requirements’ are precisely defined.

Here’s how the International Institute of Business Analysis (IIBA) defines requirements.

A requirement, according to the IIBA, is:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability, as in 1 or 2.

This is, on most accounts, a pretty solid and exhaustive definition, and I have always personally endorsed it. However, when it comes to proposing or even understanding what process or framework will work best in defining ‘Requirements Analysis’, the definition above is found wanting. Similarly, the available literature extensively documents requirements elicitation techniques but not the framework necessary to go with it.

While mentioning ‘elicitation’, I think one needs to take a look at its definition as proposed by the IIBA:

“An activity within requirements development that identifies sources for requirements and then uses elicitation techniques (e.g., interviews, prototypes, facilitated workshops, documentation studies) to gather requirements from those sources.”

The central idea here seems to be that an ‘elicitation technique’ (or a combination thereof) will lead us to the ‘condition or capability needed’, thus throwing light on ‘requirements’. My experience as a business analyst has, however, taught me that before an elicitation technique is selected, one needs to have a strategy in place for how to elicit requirements. The very assumption that the ‘condition or capability needed’ is always known by the stakeholder and all that is required is an elicitation technique to translate these into ‘requirements’ is rather unfounded and, many times, too simplistic to work.

In most cases, stakeholders aren’t aware of what they want. Even when they suggest that they ‘know what they want’, it may not necessarily be right or the only need they have. Drawing from my own experience as a professional business analyst, I have observed that the starting point is unpredictable.

The Charlie Chaplin case is one of many scenarios that the requirements analysis process faces. Throughout my career, I’ve experienced endless situations where issues are not always apparent on the first inspection. Many times, the superficial observations belie a false sense of calm and a feeling that everything is well and fine, while in some rare cases, problems are known to be existent but still not confronted.

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

Knowing exactly where your stakeholders stand is, in my opinion, the definitive base towards eliciting and understanding ‘requirements’.

Never assume the ‘knowns’ of the system!

Even when the stakeholders claim that ‘I know what I want’, to assume that these so-called ‘needs’ are valid and known would be quite naïve on the part of a business analyst. Similarly, in a case where the stakeholders are not quite sure about their problems, ‘requirements analyses’ cannot possibly be carried out with simple elicitation interviews. At the gist of it, a business analyst always needs to know that the ‘needs’ expressed by the stakeholders are not always exhaustive or valid and that they will not necessarily lead to the right outcome on their own.

The voyage from unknown to known: It might seem easy, but it isn’t!

I would like to make it clear up front that contrary to popular assumptions, the road that a business analyst needs to go down while transforming the unknown to known is not straightforward and certainly not a ‘piece of cake’.

Employing a given elicitation technique and then labelling the results, irrespective of their nature, as ‘requirements’ is nothing short of inefficient analysis. It will only tell one what is, by all accounts, already known while leaving the unknown untouched. There’s no value created by a business analyst in such cases. They are merely acting as ‘facilitators’ by asking obvious questions to the stakeholders rather than going the extra mile in order to analyse.

Running an ‘elicitation technique’ and documenting the results as real ‘needs’ or ‘requirements’ is not analysis—far from it.

It’s not always elementary!

Solving problems is detective work. From feeling your way about to reaching the root cause of an issue, the process is very similar to finding a true perpetrator of a crime. And when we talk about detectives, who better to seek out advice from than Sherlock Holmes?

“In solving a problem of this sort, the grand thing is to be able to reason backwards. That is a very useful accomplishment, and a very easy one, but people do not practice it much. In the everyday affairs of life, it is more useful to reason forwards, and so the other comes to be neglected. There are fifty who can reason synthetically for one who can reason analytically.”
–Sir Arthur Conan Doyle

I have great admiration for Sir Arthur Conan Doyle. He would have been a brilliant business analyst. He came up with character, Sherlock Holmes, who exemplifies a business analyst with two of the best qualities that a business analyst must have: ‘reason backwards’ and ‘reason analytically’.

Sir Arthur proposed a forensic reasoning to a problem. ‘Reasoning backwards’ in business analyst jargon is identifying the ‘as is’; it is gathering information and looking for clues. Problems are caused by past events, not the future ones.

In solving a problem of this sort, the best thing is to be able to ’reason backwards’. That is a very useful accomplishment and often a very easy one, but people do not practise it much. In the everyday affairs of life, it is more useful to reason forward, and so the other tends to be neglected. When elicitation techniques (i.e., interviews, workshops, etc.) are used, from my own experience, stakeholders convey future wishes. They tend to have already conceived a solution to their problem before the problem has even been validated. It’s like Sherlock Holmes walking to a crime scene and expecting a witness to tell him what really transpired so that he can return to his office and type a report out based on hearsay.

Requirement elicitation is not an exact science. However, we can develop a framework and set of principles to guide us. I have learned and developed over the years these Requirements Elicitation Principles that I have adopted throughout my career:

1. Always approach a case with an absolutely blank mind.
2. Be sceptical of what you are being told.
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.

Surely facilitation is an important part of a business analyst’s job, but it is far from the only part. Analysis in itself should always form the core of a business analyst’s responsibilities.

We are called ‘analysts’ for a reason! Facilitating information gathering and translating it to ‘requirements’ doesn’t make you an ‘analyst’. Go above and beyond, and add value by ‘reasoning backwards’ and ‘reasoning analytically’.

Author: Adam Alami, PhD Fellow, IT University of Copenhagen

Adam Alami is a PhD fellow at the IT University of Copenhagen. Adam has a wealth of experience in information technology practices. He started his career as a software developer, then moved to business analysis and project management. His 20 years’ experience revolves around major business transformation projects and process improvement. He accumulated a wealth of cross industry experience in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.