BA Mindset Principle #5: Analysis Before Synthesis; Information Before Requirements

Many years ago, I took some business analysis training courses to receive an Advanced Certificate in Business Analysis (this was before IIBA).

The very first mandatory course was called “How to gather and document business requirements”. The course provided a good background of what requirements are and what they are not, what makes a good requirement, and how to document them without ambiguity. But when I think back to the name of that course I find it a little too idealistic. Do we as business analysts ever get to “gather business requirements”? Where are these requirements that are ripe for gathering?

In a couple of weeks, I’m planning to go to a local farm to gather blueberries. This week is too early, as the blueberries are not ripe yet. In one or two weeks they will ripen and will be ready for picking. Do business requirements ever reach the same stage of ripening so that they peek from under the green leaves, ready for a good business analyst to pick and gather into their basket?

This analogy will forever remain a poetic analogy. Requirements are definitely not blueberries. They will not ripen by themselves provided enough sunshine. They will not be waiting for you to pick them, if only you know when and where to pick them. If you really want a botanical analogy, think of the walnuts that fall off a tree in different stages of greenness and ripeness. You have to pick them, sort them, open their shells, break them apart and sort them further to get to their valuable cores and select those fit for what you need them for.

“Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom.” – Clifford Stoll 

Your stakeholders will not have requirements. What they have are needs, wants, problems and pain points.  So you will first gather information about the business. You will have to make an effort to discover and understand their current problems and business process (“current state”) before you can understand what they need to have to resolve existing problems or achieve the desired business outcome (“future state”). You, the business analyst, will have to collect, sort and analyze the data, look at the information you received from different perspectives, form your own understanding of what is really required to solve the business problem, and then confirm and validate that understanding with your stakeholders.

Don’t ask “What are your requirements?”

Ask “What is the business problem?” or “What are you trying to achieve?”

At the beginning of their careers, many analysts are apprehensive about the analysis part of the job. The emphasis of business analysis training for beginners is often on gathering and documenting requirements. It is much easier to train someone to document and organize information, than to “do analysis”. Analyzing the information and then selectively capturing the essence of business requirements derived from that information is much harder. It is easier to schedule meetings with stakeholders, listen to them and record what they say. It is much harder to dissect what you’ve heard with a critical eye and look for inconsistencies, contradictions and missing pieces.

In addition, you may feel uneasy about questioning or challenging someone. The hard truth is, when a business analyst does not have the courage to analyze gathered information with a critical eye or does not realize that “analysis” is also a part of their job, they will not be successful. If the gaps, contradictions, inefficiencies and missing pieces are not detected during requirements analysis, the solution will likely fail.

Here are some analysis methods and what you can get from them:

• Artifact analysis: Discovery of terminology, examples of inputs and outputs, illustrations of specific business scenarios, evidence of business problems
• Immersion: Understanding of the process, its pain points and exceptions
• Root cause analysis: Finding the real cause(s) of the business problem
• Modelling: Create models of the current state, find gaps in understanding of the current state, determine impacted processes, people and systems
• Process analysis: Identifying gaps, inefficiencies, bottlenecks and inconsistencies in the current processes; broken and abandoned process steps; redundancies and inefficient flows
• Scenario modelling: Comparing and analyzing business scenarios where different inputs and conditions result in different essential outcomes

Remember: if you are not analyzing what you have gathered, then you are not providing the value of business analysis to your stakeholders.

Want to succeed in business analysis?  Apply the twelve principles of the business analyst mindset. Sign up for the Why Change newsletter for more resources and to receive your free copy of the BA mindset poster.

Explore the #ba_mindset in other formats: books, videos, or courses. Or contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.