Search This Blog

Wednesday, August 31, 2011

Gathering or eliciting requirements

If you gather requirements, you are assuming the business people or users know what the requirements are and can give them to you - that is, they can express the requirements for their system or enhancement clearly and concisely. Gathering implies that something is already there to gather. It is a rare circumstance when the users or stakeholders or anyone in the business has a clear understanding of the detailed requirements that will solve their problem. It's hard enough to find business people who can even state their problem concisely and clearly.
Eliciting is gathering information with understanding. The business analyst asks questions and more questions and analyzes the information gathered to produce the requirements - what is necessary to solve the problem. Investigation might be a better word for what business analysts do.
You gather apples or wheat.
You elicit information which you then analyze into requirements. That is the business analyst's forte. We are after all, analysts, not gatherers.

Saturday, August 13, 2011

Salute and March

"Salute and march". This is a somewhat pejorative term, even in the military from whence it originates. While on the positive side it may imply unwavering devotion to a leader and unquestioning faith in the leader's sense of direction, the phrase has come to mean failure to think for oneself and simply following orders to stay out of trouble. The epitome of this behavior was in Paris Island in the 60s when a Drill Instructor marched his troops at night into a swamp where two recruits died. Marine Corps policy was changed after that.
"Salute and march" is the negative side of being overly polite and meek. (Excessive politeness that is not assertive leads to meekness in perception if not in actuality.) Unfortunately, much of the business, especially marketing and mid-level management, who may be more concerned with their own image, career path, and reputation, expect business analysts to accept their solution and make it happen without a need to expose the business analyst to the real business problem and let the business analyst do their job (for example coming up with a better solution). The business analyst in turn faced with a senior officer in the company (someone in other words outranking them) will "follow orders" and go get the requirements. The business analyst will do so politely and conscientiously. It all works out as long as the solution implemented is in fact the best solution. When it isn't as so often happens the business manager blames the business analyst (and therefore so does everyone else). The business analyst may be perceived as being "meek" for simply following orders.
When the business analyst fails to do their job of communicating and analyzing because they are afraid of hurting someone's feelings, being impolite, crossing swords with higher authority, or they are simply afraid for their jobs, the business analyst is not doing their job. (Of course there could be other psychology at play as well. For example, some good old passive aggressive stuff: "We'll just do it their way and when it fails then they'll see how good my solution was and they'll be sorry!")
The business analyst always has the right to ask questions and more questions. The business analyst always has the right to ask what the real problem is behind any proffered solution. The business analyst has the right to challenge a solution that is flawed or doesn't go to solving the problem. And this can be done quite politely. I submit that failing to do this when the circumstances call for it might well be considered weak, ineffectual or simply "salute and march". While this may win points with the business manager who gets his or her way without challenge, it certainly is not the best for the overall organization or for the business analyst's peace of mind.