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