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?

When agile arrives move up

So management has decided to change software development processes to a more agile approach. And that means you, the business analyst, need to adopt a product owner role, or perhaps a scrum master if that's the way they go. In any case, your old rituals of gathering information, analyzing it, and producing an extensive set of requirements amidst negotiation, mediation and lots and lots of meetings are no longer going to be needed. So what do you do? Step up.
Someone has to evaluate whether the problems the product owner wants to solve are aligned with organizational strategies and goals. Someone has to verify that the solution that comes out of the iterations will not adversely impact other departments or processes. And someone has to coordinate, on the business side, with the other projects that are in process at the same time.
And that someone is the business analyst. Who better?

Has it come to this?

There is a thread on a LinkedIn business analyst group entitled "Are most BAs useless?" It is not the idea of the thread or the comments, both for and against the general concept of a business analyst's role in the organization; it's the word "useless". It is hard for me to even consider the words "business analyst" and "useless" in the same sentence referring to each other. There are business analysts who merely take orders, that is they perceive their job is to collect requirements from the user community, rewrite them into a requirements template and turn the requirements over to the solution team. No analysis. No evaluation. The customer is always right. I do not believe these types of business analyst are representative of the profession. I also do not believe they are useless. Clearly management of the organization in which they work believes they are performing a service even if all they are doing is keeping peace between the business and development communities.
Other business analysts see their job as intermediaries who call meetings, facilitate requirements sessions and generally spend their day with groups around conference tables. Again as unrepresentative as I may believe their activities are, they are still not "useless". I could go on.
I suppose there are business analysts who would be considered by any standard as "useless", especially by agile developers or pundits. But I submit that there are programmers or developers that are equally useless based on accepted standards of programming efficiency and effectiveness. I knew some. All professions have members who might be considered useless as a practitioner of that profession. It may be that they are simply in the wrong profession.
What a comment like that tells me, especially since it engenders a lot of comment in support with ample examples of "useless" business analysts, is that the advent of certification and the high demand for business analysts has produced a wave of new comers to the profession who may be here for the quick buck, or to avoid layoffs affecting whatever profession they are escaping from. People whose heart, mind, and soul are not in the career of business analyst. And that's a shame. Every profession I'm sure suffers from the same malady of hangers-on or pretenders at the profession. I just didn't think it would happen here, and so soon.

changing advice

Never think of what you are doing in terms of requirements, or systems, or software, pr even processes. Always think of what you are doing in terms of change. You are changing the organization. You are solving a business problem and bringing about a change, small or large, it’s a change. And the success of the change is not necessarily in the pizzazz of the software or the efficiency of the system, but in how the people affected by the change will accept and adopt it. Knowing this in advance and letting it infuse all you do will increase the chances of success in each of your endeavors.

What is an agile BA?

Recently there was a discussion on the Agile BA Linkedin discussion group about the difference between an agile business analyst and a traditional business analyst, if there is such a difference. One group held that all the attitudes, behaviors and activities that were attributed to an agile business analyst in the discussion are actually attitudes, behaviors and activities all business analysts should have or do agile or not. The discussion was mostly theoretical and philosophical. So here is another more pragmatic view of the difference and I am not making this differentiation as a declaration of some agile business analyst manifesto, only to perhaps clarify thinking by presenting two extremes.
When the business analyst is focused on producing a single approved requirements document at the end of a long period of structured elicitation, investigation, analysis, review and approval, and the document is passed on to the development team with or without interacting with the development team, then the business analyst is acting in a traditional business analyst role.
When the business analyst elicits and analyzes the information to produce just enough requirements for the development team to produce at least a rudimentary version of the result and then continues to revise the requirements as the business stakeholders, development team and business analyst learn more about the system delivering the final requirements document describing the system in production at the same time as the system goes into production, then the business analyst is acting in an agile business analyst role.

When are requirements done?

A question came up recently about when requirements are done. When can you say that you have completed the requirements and there is nothing left to add?
The answer is probably never. Given unlimited time and resources there will always be more information that you can obtain that will change the requirements you have specified, or add new ones, or delete old ones, up to and including changing the entire solution. Had you started a project in 1992 and planned to have the software requirements finished in a year with the target platform being a CICS 3270 terminal. You might have found yourself redoing all the requirements the following year when Windows 3.1 was announced, and then again a couple of years later for Windows 95 and the web and Java (all came into commercial use in 1995.
The bottom line is that the requirements are always complete and correct, assuming you've done proper analysis, based on the information you have gathered and confirmed up to this point in time.
However, a guideline is still demanded. So, here goes: when you have a solution to the business problem and have specified everything the business needs to do to solve the problem, the business requirements are done. When you have specified everything that is necessary from a technical perspective, the system requirements are done. And when you have specified everything that needs to be completed for the project to be successful the project requirements are done.
That doesn't mean frozen or unchanging - just done at this point based on the information you have at that time.
The real answer is that the requirements for the system or change that is implemented are done when the system or change is in production, and subsequent requirements become subsequent changes.