The Community Blog for Business Analysts

Adrian M.
Adrian M.

You Must Question Requests from the Business

A while back, I was reading a Computerworld - Singapore article on Business Intelligence and embedded in it was a small, but significant, truth about the business analyst role. 

The article points out that a common mistake made by many organizations is to treat the business analyst as a request taker. That is - if the business division asks for a change in the process (or requirements, for that matter) the business analyst is supposed to just do it. In other words, they expect the business analyst to be a "yes man" (or woman). 

Many folks tend to forget that the word "analyst" is actually part of the titles of the "Business Analyst" and "Systems Analyst" roles. One of they key responsibilities of the business analyst is to analyze the information received and question that information if it does not make sense. 

There can be nothing worse than an organization paying top dollar for qualified business and systems analyst only to treat them as note takers or technical writers. 

One of the key values that a business analyst brings to the table is the ability to innovate... the ability to ask "Why?" 

The other day - I was reviewing a new set of requirements from the business side and noticed one of them which did not make any business sense. 

So I dared to question it... 

When I question requests from the business I tend to use a very simple approach: 

Why? 
Why? 
Why? 

In this particular case, the answer I got was "Because Mr. X said so!

What? Because one person said so, it doesn't make it so! 

Along with every new requirement and change in business process there must be a justification and clear rationale for the request. If it is not clear that the effort will improve the bottom line - then question it, question it, question it! 

As a business analyst you need to make sure that somebody (it doesn’t always have to be you) has analyzed the situation and determined that a change in process or system is needed for one of the following reasons:

  • it reduced operating costs,
  • it increases productivity (makes money),
  • it meets regulatory requirements.

I realize that there are other, more subjective, reasons to make modifications such as increased usability of a product, look and feel requirements, etc. Those types of reasons need to be treated with caution because it is hard to objectively quantify their impact to the bottom line. 

What are my motives? 

... if you question requirements: What are your motives? 

After years and years in this profession - this is something I do without even thinking about it - a matter of habit. But after a little bit of introspection here are some of the reasons why I question business requests:

  • From a pure business perspective, I want to make sure that the change in process or system improves the bottom line. From a sense of preservation I want the organization I work for to be in business for a long, long time.
  • Because they hired me to do so... I am being paid for my ability to think and solve problems not for my request taking skills. If that was my goal - I would have become a waiter (no disrespect for waiters intended).
  • Because deep down in my gut I can't stand designing or asking the developers to implement a change in the system which does not make business sense. Such features are bound to be changed again in the future and are a waist of everybody’s money, time, and effort.

Please note that I am not advocating that you overtly question every single request from the business. If you do that, you'll find your way out the door very quickly. 

But you should analyze in your mind every requirement to make sure it makes business sense (at least from your perspective). 

Use your better judgment and focus on the requirements with the biggest problems.

If you manage and lead business analysts then you must ensure that you get commitment from upper management on the role, responsibility, and authority your analysts must have. Then turn around and empower your team. Make sure they understand that they are allowed to and must question those business requirements (with tact - of course) which are suspect. 

Do you question requirements? When? How?

Adrian

This entry was published on Jan 07, 2015 / Adrian M.. Posted in Business Analysis Planning (BABOK KA), Elicitation (BABOK KA). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  4 members liked this article

Related Articles

COMMENTS

Mindy Knuffman posted on Monday, February 16, 2015 11:33 AM
This is something I am trying to instill in myself at my new job. I find that if I explain why I'm asking why, they will look at the questioning as a benefit and not a problem.
Mindy Knuffman
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC