Use more Business analysis techniques to step up your game.

Today I would like to talk about techniques. That is what we all know as diagrams, schemes, tables, mind maps, and more and more others.

They are always presented at conferences, meetups, and other educational activities. BAs use them to process information, elicit, specify, and manage requirements, encourage and involve stakeholders, and build effective communication and collaboration.

There are only 50 common techniques listed in BABOK and 20 else in the Agile extension to BABOK, 23 techniques in the book “Business Analysis Techniques: 123 essential tools for success” by Adrian Reed, David Beckham, Debra Paul, James Cadle, Jonathan Hunsley, Paul Turner. It is not said about other sources. They all are determined to help BAs to conduct their work and look at the need from different perspectives, and enable BAs to bring as comprehensive and full requirements as it’s possible. In contrast, the limited number of techniques in use narrows the understanding of the stakeholders’ needs as narrows the amount of information received and analyzed.

In other words, the message I would like to bring to you is that requirements definitely shouldn’t be narrowed down to a User story and Acceptance criteria written in form of bullet points only.

So, let’s delve down into this a bit.

First of all, let’s define what is a technique.

• Cambridge Dictionary defines it as a way of doing an activity that needs skills.
• Oxford Dictionary defines it as a way of carrying out a particular task or skill or ability in a particular field or a skillful or efficient way of doing or achieving something
• According to BABOK “Techniques are methods business analysts use to perform business analysis tasks”, they “provide a means to perform business analysis tasks”.

According to these definitions, techniques are something BAs are doing their work with. The BA techniques are something that is directly linked with the BA activities(work).

Then, let’s talk about the fact that each technique is supposed to be used for a specific task, or a particular activity. What’s more, they have their own purpose and allow us to look at the need or problem from a certain angle. I would like to highlight one thing: one technique — one possible view from many others. The fewer techniques used, the fewer points of view on one particular subject are discovered. Consequently, the fewer prospectives are considered, the more hidden aspects and missed requirements are left not elicited. What might end up in big trouble regarding the project needs satisfaction and deadlines.

Now let’s look at activities and connected techniques closer. There are some basic BA’s actions and tasks such as elicitation of a need and value for each stakeholder, identifying GAPs between current and desired state, analysis of the context and risks, as well as deciding what is the best solution to cover all GAPs to satisfy the need and finally modeling and specifying requirements. Each specific task requires a specific technique to perform. In contrast, there are some commonly used techniques, mentioned from the outset of this article, that boil down to the User story and Acceptance criteria. What can we conclude from that? How many tasks listed might be covered with the User story and Acceptance criteria in bullet points? I hope you see this conclusion: not all tasks, not to say half of one task from many were fulfilled. And what kind of quality of BA work might be reached in this way? Such work can be described by cliches: “There was not such a thing in the requirements” or “I expected other results, other features, they were obvious”.

So, one more time in other words:

1. Performing BA’s tasks is directly linked to using techniques.

The fewer techniques are used, the fewer tasks are performed.

The more tasks are conducted, the more techniques are applied.

2. Performing BA’s tasks in a both holistic and comprehensive way is directly linked to a number of techniques in hands.

The fewer techniques are used, the fewer aspects are considered.

The fewer techniques are used, the narrower the points of view in the requirements are.

The more perspectives are elaborated, the more techniques are exploited.

3. If you don’t use specific techniques you don’t analyze the specific aspect. If you don’t analyze…hold on our job is Business analysis.

Let’s take elicitation as an example.

Elicitation of a need is not just a noted list of what stakeholders want. It’s not a secret, that frequently people operate by symptoms of a problem or come not with a need, but with a ready solution. That’s why the main purpose here is to identify the main reason, why the need has appeared. What techniques come to mind here?

Of course, it’s Root&Cause Analysis. It may be the Fishbone diagram, 5 Whys, Cause- Effects tree (Current Reality Tree by TOC).

Certainly, it’s Problem statement. Definitely, it’s Observation and Process modeling and analysis.

If the point is in a new opportunity or a problem that most companies might face in the sphere, it’s Market Analysis, Business Model Canvas, and Business Capability Analysis.

So, we mentioned 9 techniques that help to analyze the need. If anyone is not used, this analysis is absent. As a result, the requirements are not clear and ambiguous.

To conclude, I would like to encourage you to use more techniques to analyze a need of a project and stakeholders and step up your game.