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.

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.

words

The business analyst's world is about words. Words make up the requirements. Words occupy interviews and meetings to obtain information. The information itself is usually words, occasionally interspersed with pictures or diagrams. Much of our analysis is done by analyzing words. Words are variable and ambiguous and vague and many times describe the wrong things. They even lie. They are, however, what we have. We tried pictures once, and discovered that drawing pictures, while less ambiguous, was also much less efficient as a means to communicate.
With all this emphasis on words, and the corresponding frameworks of grammar, punctuation, oration, and exposition, is it any wonder that technologists trained in the black and white world of bits and bytes have difficulty navigating the verbal ocean? Technologists want clear, unambiguous, concise expressions of solutions, wants, needs, and the like so they can convert the words into software and applications. In the role of translator, that's what the business analyst does: play word games of reduction, precision, and exactitude. The business analyst takes a vague notion of a barely conceived idea and turns it into a model and a plan that will eventually become a best selling web site or an innovative medical device that saves lives. It's all in the words.

The Business Analyst as Innovator

One of the agile precepts is the build it as you go approach. Regardless of the size of the final deliverable, the product is created and delivered in small releases, each release adding some value for the customer or product owner in an iterative process. The decision of what should be developed each release is done by listing all the features and functions a customer wants and then carving out those features the solution team can implement in the next iteration.
There is an underlying assumption here which is rarely true: all the innovation and capture of new ideas for the product has already been done before the implementation effort takes place. I'm wondering where that innovation took place and who did it? The solution team innovates, but the team innovates in terms of software development process improvement (a standard mandatory element of the Scrum process, for example) and technology. But who is providing the business innovation: the new product that will eclipse the competition, the variation in service offerings that will increase the efficiency of business service delivery, the internal improvement invention that will reduce the overall cost of doing business?
While agile does not address this issue with its focus on development of working software, someone needs to do it. The product owner is focused on getting the defined features implemented to solve the immediate business problem and then getting back to work. Who addresses innovation? The business analyst. The very role the agilists have claimed should be removed from the agile equation.
Perhaps it is a better and more valuable role for the business analyst in the overall organization to be focused on innovative ways of improving the businesses processes thus directly returning value to the bottom line. A higher calling, perhaps. So when the business analyst role is summarily excised from the agile development cast of characters and product owner is not an option and scrum master doesn't seem to fit, perhaps Corporate Innovator or Business Process Improver might be the role to pursue.

the BA and the PMO

Down in Sao Paolo this week for a BA Congress I heard a lot of talk about the PMO. Since it was a BA Congress the talk centered on the role of the BA when there is a PMO. One of the interesting answers, one that is being implemented by many companies in North as well as South America, is positioning the BA as the information gatherer for the PMO decision making process. The business analyst defines the real business problem and the conditions and impacts of that problem so that the PMO can make a reasoned decision about whether the problem should be solved. Sometimes the business analyst authors the business case and sometimes the business analyst participates in the creation of the project charter, both of which may be used as decision papers. When the business analyst is assigned to support the project and assist in defining the solution, the business analyst is also keeping an eye on the business to make sure the problem still needs solving so that the organization does not get a zombie project (a project that has lost its life in terms of useful return to the organization, but still continues because no one wants to stop it).
In many of these instances, the business analyst works directly for the independent and objective Project Management Office rather than for IT or some specific business unit. I like the concept.

The Business Analyst as Producer

In the theater, both live stage and movies, there is a role called "producer". In many cases, the producer is the financial backer of the movie or play, and may be silent having no further interaction with the project other than signing checks. Most producers are actively involved with the making of the movie or staging of the play. The primary goal of the producer is to oversee and deliver a project while preserving the integrity and vision of the film or stage production.
The business analyst does not usually finance a project. However, the business analyst is responsible for the integrity of the solution and the approval of the audience, namely the business community.
The producer starts work by obtaining the rights to a work to be transferred to the screen or stage or approves a script for production. This then is the problem statement: the script is not a movie. The business analyst starts work by defining the business problem. From there the roles are fairly similar.
Wile it is the director who works with the actors, the stagehands, the cameramen, the extras, the stuntmen, the makeup and costumers and so forth to implement the production, the producer interacts with marketing and potential audiences and publicity and all those factors that influence the final result outside the sound stage. It is the project manager who performs that role with the business analyst, directing and managing the solution team of programmers, testers, data base analysts, architects and so on. The business analyst provides the feedback from the audience - the stakeholders and business community - and keeps the project aimed at the target of solving the business problem.
Perhaps in these days of agility when the business analyst who only defines requirements is considered to be superfluous, recasting ourselves as IT producers wedded to organizing the entire product from problem definition to solution in the business environment might be a valid compromise.

Why don't the customers know their own problem?

Clients and business people are typically too close to the problem to be able to really see what it is. That is why a business analyst can be so valuable. A BA can ask the right questions, step back from the symptoms, and see the real problem. Many times the client really doesn't know what the problem is, just that there is a problem. Our job as business analysts is to help the clients identity the real problem and make sure the problem is worth solving (aligned with organization strategies and goals, high priority in the scheme of things, cost beneficial to solve, etc.).
The requirements are what is necessary for the business to do both from a business perspective and technologically. Consider this: if the client knew what the problem was and the requirements - what to do to solve it - what would the client need you for?