Business Analysis Pitfalls: Ungrounded in Reality

Cloudy tops of towers

I once asked a business analyst involved in a challenging system implementation that went way off the rails:

“Knowing what you know now, what would you have done differently from the start of your requirements analysis?”

The answer really hit me:

“We should have involved real business users from the very beginning, instead of hearing from them for the first time during UAT”.

All too often, there is an artificial division between “project people” and “operational users”. The most typical scenario is when one person is assigned to a project as a Subject Matter Expert (SME), user representative or business lead who is supposed to speak for all the users and their requirements. This is often done to protect operational users from being distracted by projects while there is real work to be done. The most senior and experienced business experts are usually the most vigorously protected by their managers. They are simply not available for participation in requirements analysis.

Instead, one person gets dedicated as a “project person” – like a lightning rod, he is supposed to become a single point of contact with a disrupting force – the project. That person is tasked with attending all project meetings and providing all business requirements to the analyst.

In another scenario, the scrum approach requires that one person, Product Owner, has both expertise and authority to make decisions about requirements and their priority, to maintain the pace and remove blockages that are created when larger business groups struggle with making decisions. The Product Owner is accountable for the vision of the final product, in other words, she should know best.

These models only works when this middleman, product owner or this single point of contact, has a constant and close connection to the day-to-day operational users or intended users of the system. The SME or the Product Owner needs to know intimately what happens in the trenches every day – what are the issues, the gaps, which system features are not being used as intended, which business rules are not being followed because they don’t make sense, and what undocumented workarounds get the job done. In other words, this person needs to be in constant communication with the troops and be trusted by the users.

When you as a business analyst are partnered up with a single business representative that is supposed to provide all business requirements, what happens next depends on the mindset of both the business representative and the analyst:

Scenario A.      You are perfectly happy to work with one person who “knows everything”. There is no need to look below the clouds, as the most important information will be summarized for you to capture. You no longer need to think – just document everything your SME tells you, capture the rules and the process exactly as you are told, and you are off the hook. You did your job.
Only that was not a true business analysis, it was just an exercise in scribing. This is not how the BA mindset should work.

Scenario B.      You want to understand what is happening on the ground, below the fog that shrouds the “front lines”. However, all the answers are provided by the same SME who reinforces that he is empowered to speak “for the whole business”. Every time you try to climb down from the top of the tower to the ground level, you are told that you are not permitted there, or there is no need for you to trouble yourself, or that you would not understand anyway. Depending on the strength of the personalities, seniority and experience, you may eventually give up or lose the desire to understand, or get tired of the fight. After all, it’s the problem of the business to get their requirements right. As long as the user representative signs off on the requirements (which he does), you are off the hook, again.
If this is how it ends, this is also not true business analysis. You, the analyst, do not really get to analyze the business. At best, you can analyze the information provided by one person and choose to trust it.

Scenario C.       You insist on coming down through the cloud cover and walking the streets. The SME can be your tour guide and your translator, but you want to see with your own eyes what’s going on and how it works. You want to touch the walls of the buildings and look into the shop windows. You want to peek into the alleys and check the view north and south. You want to note the movements of the inhabitants and feel the general mood. You want to get to know those people that will be the future users of the system.
With a business analyst mindset as your guide, you know you cannot go with the judgement of one person, as no one person can possibly be fully objective and omniscient. You, the analyst, want to understand the WHY behind the requirements.
If you encounter resistance, it may be a tricky political situation to navigate and will require tact, diplomacy and persuasion. You may also need to get an executive sponsor or champion on your side.  Use your skills and mindset to perform quality analysis – or you may find yourself lamenting the lack of business user involvement, as did my analyst friend from the opening of this story.

Do not fall into the trap of taking what you are given at a face value, without your own fact-checking, cross-referencing, research and analysis. Do not rely on a single source of information. Get down to the ground level and see the current state of business from your own analytical perspective. Solve the right problem.

You, the business analyst, are an investigative journalist, not a stenographer.

More posts in the Business Analysis Pitfalls category.

Find all Business Analysis Pitfalls posters in the Business Analyst Mindset Digital Toolkit. Explore the #ba_mindset in other formats: books, videos, or courses. Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.

1 comment

Please share your thoughts!

Discover more from Why Change

Subscribe now to keep reading and get access to the full archive.

Continue reading