Business Analyst Mindset: Twelve Principles (Part B)

Create a shared understanding

What you write may not be what I read.

What I read may not be what I understand.

And what I understand now may not be what I remember later…

The single biggest problem in communication is the illusion that it has taken place.― George Bernard Shaw

The most successful business analysts have the mindset focused on achieving a shared understanding of business problems and requirements. They know that nurturing consensus among all stakeholders is key to implementing the right solutions to the right problems.

In this article, we continue examining the principles of the business analyst mindset — with videos included for those who prefer this learning format.

Principle #5: Analysis before synthesis; information before requirements

Business analysts don’t gather requirements — that’s the biggest misconception of the profession. They gather information about the current state of business and investigate the root causes of the problems. Quality business requirements are the result of synthesis: applying business analysis techniques to the gathered information to create the vision of the future state.

There are a variety of techniques suited to the analysis and synthesis of the requirements:

If we observe how an experienced analyst organizes and facilitates requirements workshops, we will see a gradual transition from discovery to analysis and then to synthesis. The first few meetings will be centered around the “tell me about your business” or “what are you trying to achieve” questions. This initial understanding of the current state and its problems will lead to “why is this happening” questions — root cause analysis. The questions will gradually change from open-ended and exploratory to clarifying and validating.

These discussions are a prerequisite to understanding the real problem — rather than the visible pain points that the stakeholders will want to tell us about.

Requirements don’t come from business — they come from business analysis.

Principle #6: Uncover gaps — do not cover them up

Discovering gaps and inconvenient truths and is an occupational hazard of business analysis. Analysis activities may result in a discovery of unexpected hidden problems that create risks and become roadblocks to building better solutions.

These discoveries may be welcome or unwelcome, depending on the timing. Early in the project, we are more likely to acknowledge and analyze every surprise. Late discoveries are unpleasant and sometimes even shocking if they require changes to solution design.

It may be tempting to sweep the inconvenient finding under the rug. The project may already be late, or relationships already strained.

This is the time when the business analyst mindset plays a crucial role.

The role of a business analyst is to analyze the gap and help the client make an informed decision.

This will require a few steps:

This may not be the most pleasant and comfortable activity — but it is an inevitable part of the business analysis process.

Finding a gap is a success, not a failure, as it creates opportunities for improvement.

Principle #7: Simplify until nothing can be removed

Many companies are obsessed with automation projects as they are expected to help reduce the cost of running business. As business analysts get involved in these “automation initiatives”, they often struggle.

Business processes tend to get more complicated with every organizational change, redistribution of accountabilities or new business rules. These changes often go undocumented or live on sticky notes or one-page printouts taped to the walls.

The official documentation may depict a straightforward sequence of steps looking like this:

In reality, the process executed daily by the staff may look more like this:

Automating an existing process can be almost mechanical — capture what is done today and give these notes to the developer. But what would be the value? If the current process is not optimized, the sub-optimal flow will be baked into the software and will be even harder to optimize in future.

First optimize, then automate.

Principle #8: Take responsibility for shared understanding of business requirements

Business analysts invest a lot of effort into understanding the current state of business, all its processes, terminology, and business rules. They spend many hours with subject matter experts, ask them questions, and produce diagrams, user stories, documents, and tables.

They add a lot of details, cross-reference, and tag requirements with multi-level numbers and identifiers.

This work is important, and its outcomes help clarify business requirements. But it is not enough that a business analyst understands the problem and the requirements for the future solution. This understanding must be shared by all stakeholders involved in the business change, from executive sponsors to the development and testing teams.

The communication is only as good as the message received. And business requirements are only as good as the understanding of requirements by the intended audiences.

There are many techniques that a business analyst can use to communicate and validate results of the analysis and create a shared understanding of requirements, step-by-step:

• Set the context for the problem
• Use consistent terminology
• Accommodate different learning styles and present information in different formats
• Share requirements in progress
• Review, refine, reiterate and reinforce the analysis to achieve a shared understanding
• Organize and structure requirements in a way that promotes clarity and helps identify gaps
• Use clear, consistent and concise models to link requirements and relate them to the business system and its components

A shared understanding of business requirements by all stakeholders is the main outcome of business analysis.

Explore the BA mindset further in my books and courses, or subscribe to the Why Change Newsletter to stay in touch and hear about upcoming events and webinars.