Requirements are anti-climatic

Many business analysts assume that their entire job, the end result of their efforts, is the requirements document, or in an agile context, the set of user stories or product backlog. This is not the case.  The requirements regardless of what form they take or what they are called, are really an after thought.

The real job of the business analyst is to come up with solutions to the business problem.  Optimally, the business analyst comes up with more than one solution so that the business stakeholders or management can decide which solution is the best for the organization. That doesn’t mean that the business analyst implements the solution, only devising the solution: what the business needs to do to solve the problem.  The solution is developed, or built, or purchased, or repurposed by a solution team of which the business analyst may be a part, or not.

The solutions the business analyst presents to the decision makers may be in the form of a business case, a proposal (if the business analyst works for a consulting firm, for example), a PowerPoint presentation, a formal review, or any number of other forms, but not in the form of requirements.  Why go through the exercise of developing requirements when the solution to be implemented has not been selected? 

Only after the solution has been determined are the requirements developed. 

The requirements are the details of the solution that describe to the implementers, the builders, the software development team, the quality assurance team, management, the process workers and users of the solution, and anyone else involved in or interested in the improvement being made. 

And even as detailed ‘instructions’, the requirements are still an after thought.  The business analyst should communicate the selected solution and details to the solution team and everyone else (in their own language and to the level of their understanding and need to know) before the formal requirements are committed to paper, electronic or otherwise. 

Understanding comes first, requirements simply document that understanding.

The problem is solved and everyone agrees to the solution.  All those involved in making the solution happen or evaluating the solution or using it understand what is to be done to their level and agree to it.  It’s all done and decided.

Then the requirements document what is being done.  Quite anti-climatic.

words are magic

Several years ago I was consulting to a large company in the health care business. I was somewhat of a "business analysis coach" in the role that I had. In one meeting the business analysts were complaining about their elicitation process. The complaints were fairly consistent with many others I had heard: the important people don't show up to the meetings, people who do show up don't contribute, some people high jack the meetings with their own agendas, there is conflict in meetings where there should be only information passed, people come unprepared, etc.
I made a couple of small suggestions. They called their meetings "requirements workshops" as per the IIBA's BABOK and many other sources. I suggested they call their meetings "information gathering sessions" instead.
Why? because anyone attending a "requirements workshop" would have the expectation that the meeting will end up with completed requirements. So people will come ready to make sure that their requirements get included. Others who have no particular requirements or who are afraid to commit to requirements will not show up or will show up and stay silent. Arguments will ensue among those who want their requirements included. In an "information gathering session" the only expectation is that information will be passed.
I also suggested that they change the name they gave to those coming to the meetings. In their invitations they cited "attendees". I suggested that someone coming to a meeting as an "attendee" has an expectation of just attending. If they want the people coming to the meetings to participate in the meetings they should call them "participants".
They made the changes immediately. By the next week as they returned from their meetings and reported in, they told us of the change in the way things were going. People came to meetings with documentation, prepared to answer questions and provide information. There were significantly fewer conflicts, even among those who were consistently in conflict in the past meetings. More people coming to the meetings contributed and responded to questions the business analysts asked. In general the meetings were more positive and the morale of the business analysts rose.
All as a result of simply changing a bit of vocabulary. This proves how important words are and how they affect our expectations, even subconsciously.

Several years ago I was consulting to a large company in the health care business. I was somewhat of a "business analysis coach" in the role that I had. In one meeting the business analysts were complaining about their elicitation process. The complaints were fairly consistent with many others I had heard: the important people don't show up to the meetings, people who do show up don't contribute, some people high jack the meetings with their own agendas, there is conflict in meetings where there should be only information passed, people come unprepared, etc.
I made a couple of small suggestions. They called their meetings "requirements workshops" as per the IIBA's BABOK and many other sources. I suggested they call their meetings "information gathering sessions" instead.
Why? because anyone attending a "requirements workshop" would have the expectation that the meeting will end up with completed requirements. So people will come ready to make sure that their requirements get included. Others who have no particular requirements or who are afraid to commit to requirements will not show up or will show up and stay silent. Arguments will ensue among those who want their requirements included. In an "information gathering session" the only expectation is that information will be passed.
I also suggested that they change the name they gave to those coming to the meetings. In their invitations they cited "attendees". I suggested that someone coming to a meeting as an "attendee" has an expectation of just attending. If they want the people coming to the meetings to participate in the meetings they should call them "participants".
They made the changes immediately. By the next week as they returned from their meetings and reported in, they told us of the change in the way things were going. People came to meetings with documentation, prepared to answer questions and provide information. There were significantly fewer conflicts, even among those who were consistently in conflict in the past meetings. More people coming to the meetings contributed and responded to questions the business analysts asked. In general the meetings were more positive and the morale of the business analysts rose.
All as a result of simply changing a bit of vocabulary. This proves how important words are and how they affect our expectations, even subconsciously.

Listen Naively

Generally the users or stakeholders do not tell you things that they think you know. The more you appear to know about their environment, problem, process, etc. the less they will tell you, especially about specifics.

This is a natural human reaction.  We don’t want to answer a question posed by someone with information they already know.  We don’t want to hear, “Yes, Of course. I know that. What I want to know is…”  In other words, we don’t want to appear stupid. So we will answer the question vaguely or with Monty Python’s “wink, wink, nod , nod” (I don’t have to say it because you know what I mean). 

The end result is that no new information is provided with the answer to the question.

And of course the questioner  is loath to repeat the question to get more detailed information because the questioner also does not want to appear stupid.

The answer is to ask and listen naively.

If you listen naively, as though you don't know anything, and encourage the responders to tell you more, you will get a lot of unstated expectations and implicit requirements. Use the "tell it to me like I'm six years old" approach and you may get most of those implicit requirements and hidden expectations.

Business Analsyt and X-Rays

Diagrams and models are like x-rays of the human body. They show what is beneath the skin, what is inside.  X-rays tend to be a bit more accurate since they are created by a machine and the diagrams reflecting business processes or proposed changes to the business processes are created by a human being and likely have errors of omission or assumption.  It is easy to create a X-ray.  Nowadays it is somewhat point and shoot with the computer based technology we have.  An X-ray technician has to know the equipment and how to use it effectively, and where to point for the best picture.  Similarly the modeler has to know the language of the model (such as UML) which might be considered the ‘equipment” and how much and how detailed to draw the model.  But in the end, the X-ray technician does not determine from the X-ray what is wrong with the patient, if anything.  That is the job of the doctor.  The X-ray is just a picture without the appropriate analysis.  The diagram is just a picture without the appropriate analysis by the analyst.  A business process model is a collection of boxes, lines, arrows, and other symbols arranged on a board, paper or screen.  It is meaningless unless the business analyst applies appropriate analysis to the diagram to determine what needs to be fixed, improved, or changed.

X-rays are meaningless without the explanation of the specialist, the doctor. Similarly the UML or other diagrams that the business analyst creates are meaningless cubist abstracts without a suitable explanation by the business analyst. Where the doctor explains the dark area beside the gray area which is the pancreas, the business analyst explains what the boxes represent and who the stick figures are. The skill is in the presentation which is part of creating the X-ray, or diagram, in the first place.

There was a time when the doctor did his or her own x-rays. And that is the difference between the medical x-rays and the business analyst’s.  The business analyst still does his or her own X-rays or diagrams and then analyzes them and interprets the results for the business stakeholders.  There may be a day in the future when another role creates the diagrams similar to an X-ray technician and the business analyst does the analysis and interpretation.  And unfortunately even today there are business analysts who perceive that their job is to diagram and that is all.  While they strive to produce a diagram that is simple enough for a novice to read and understand, they still do not provide any analysis or interpretation based on their experience, knowledge, insight and intuition.  They simply proffer the diagram as the outcome of their work.  This is not business analysis.