BA Mindset Principle #8: Take Responsibility for Shared Understanding of Business Requirements

What is the most important outcome of business analysis activities?

Is it detailed and intricate process maps? Comprehensive business requirements documents? Groomed user stories? A requirements sign-off obtained within schedule?

All of the above are important. But there is something else that needs to be achieved to make business analysis deliverables useful:

Help all stakeholders have a consistent and shared understanding of the business problem and the requirements for the solution to the problem. 

A business analyst may have put a lot of effort into understanding the current state of the business, all the details of a complicated process, terminology and business rules. She or he then spent many hours with subject matter experts to understand what they need to achieve, and helped them formulate the requirements, capturing them with diligence and attention to detail.

But this is not enough. The business analyst also needs to ensure that this understanding of the requirements is shared by all stakeholders involved in the business change:

• executive sponsors
• project manager
• business subject matter experts
• operational managers
• development and QA teams
• those who will be developing end-user training and communicating the changes internally and externally

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.

All too often we focus on capturing requirements. Diagrams, user stories, documents and tables become the focus of the business analysis phase. What we sometimes forget is to validate whether what was captured is going to be understood consistently.

In our rush to complete the requirements phase as per the project schedule, pressured by stakeholders and project managers, we sometimes skimp on proper requirements validation.

Why?

Perhaps, your stakeholders groan every time when they hear “requirements walkthrough”? They may have attended a few in the past and found the experience very painful and time wasted.

Perhaps, you’ve asked everyone to review the Business Requirements Document and provide feedback, and have not received a single response by the deadline?

Do you find that as soon as you try to walk the project team through a multi-page diagram with eight swimlanes, you see eyes glazing over and chins falling down?

Are you so tired of getting conflicting responses that you just write the whole thing up the way you think makes the most sense and don’t even want to open it to further review?

Or do you perhaps truly think that you know what is best for everybody?

If these methods of forcing the walkthroughs on our stakeholders don’t work or don’t give us desired results, why do we still try to practice them?

Before suggesting a different approach, let me offer an analogy.

Think of a time when a new member joined the project team halfway through the requirements analysis phase. You may send them a pile of meeting minutes and document drafts to read and provide with a crash course on the project scope, but what happens when they start joining meetings? For the first couple of weeks, they will ask quite a few questions that have been asked and answered before. They will need time to catch up and get to the same logical point where other team members already are. They may feel uncomfortable or frustrated at first because reading meeting minutes and email exchanges is not the same as being a part of the discussions. Statements and bullet points will not give them the same level of understanding as following along, to see the reasons for reaching a particular conclusion.

The same applies to requirement walkthroughs. It may have taken a business analyst a few weeks (or months) to investigate, analyze and complete requirements while holding meetings with large and small groups and capturing the findings using a variety of techniques.

It would be very hard, and probably impossible for anyone else to read all the documents and catch up with your analysis and thinking in the few days allotted/budgeted for the review of the Business Requirements Document. Your reviewers and stakeholders would benefit from reaching the same conclusions as you reached when doing your analysis. Using a mathematical analogy, they need to follow along as you prove a theorem, to agree with the proof.

The best and perhaps the only way to reach shared understanding is to build it gradually, as the team progresses through analysis, repetition, clarification and reinforcement:

• Make sure everyone is clear about the context and the terminology
• Review and ensure you are in agreement after each significant discussion – if an agreement is not achieved, capture what needs to be revisited, assign actions and ensure the incomplete discussion does not get lost.
• Take a few minutes at the end of a requirements workshop to recap the most important points, especially those that sparked the most debate.
• Make key points visible during the meeting, facilitate continued discussions in between meetings, and confirm the outcomes frequently.
• Restate previous findings and decisions at the beginning of the next discussion.
• Follow up on sticky points with scenarios and examples that can be reviewed at the next meeting to check if what was captured last time holds water.
• Touch base with team members who missed an important discussion. It will help them catch up and be able to follow along in the next discussions. It is also a chance to probe if they might know some new information that might have changed the outcome of the previous meeting, had they been able to participate.
• Put a special effort into communicating difficult concepts, using multiple formats such as diagrams, tables, pictures, scenarios and prototypes.
• When a group of related requirements has been analyzed and captured, do a mini-walkthrough soon after (before everyone forgets) and then flag that group of requirements as reviewed. If at a later point one of the statements is invalidated, review with stakeholders whether other requirements are impacted. If you need to make changes to a reviewed requirements section – discuss it with your stakeholders first, don’t “sneak” changes in.
• Structure the requirements; use diagrams and models to help relate individual requirements to the business system or process components during requirements discussions and walkthroughs.
• Ask for agreement and understanding often and in a friendly, non-threatening manner. If your audience is afraid to admit that they don’t understand something then you are already failing.
• Do not take on the burden of carrying the information all by yourself and being the only person who knows the requirements. Everybody should have access, and you must create a climate of sharing and a constant flow of information.

You are neither the secret keeper of knowledge nor a master of dark arts. You must be the communications satellite that is constantly connecting and broadcasting. Your ultimate goal is a shared understanding of business requirements.

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.