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. 

Listiening to the Stakeholder

I sat in on a group of business analysts discussing problems they were having with their stakeholders.  Each of the business analysts at the table had a different horror story to tell about the politics that the stakeholders seemed to be playing whenever the requirements and features of the new system were discussed in meetings or interviews. The general plaint was that stakeholders were adamant about what they wanted when they really didn’t know what they wanted.  The business analysts seemed to think that it was more important to the stakeholders to ‘win out’ over other stakeholders than to ensure that the system worked well. They looked to me to solve this problem for them.

Keep in mind one factor about human nature.  Many times stakeholders (and people in general) are not concerned about getting their way over someone else or ensuring that their requirements get included at the expense of someone else, and all the other political machinations we perceive in the dynamics of a large number of stakeholders involved in a single important project. 

Many times the stakeholders just want to know that they have been listened to. Someone cares about what they have to say, even if their position or advice is not taken.  "You are not getting my point" may not be another argument, but simply a statement that "you are not listening to us".  Therefore instead of “communicate” ( which implies talking), perhaps listen. Listen might be a better tactic while acknowledging that all points were heard and understood.  As Karl Wiegers says, "The customer may not always be right, but the customer always has a point."

I didn’t give them a solution. Not immediately, anyway. Instead I asked questions about what the stakeholders said, from the point of view of the stakeholders trying to guess what the stakeholders were thinking.  It didn’t matter whether I was right or wrong in my guesses; what mattered was that the business analysts around the table started to think about the answers to the questions and what the stakeholders might actually be saying.

In the end the business analysts determined that the stakeholders were not fighting political battles but were saying:

·         We’re not sure what the problem is, can you help us figure it out?

·         What solutions do you think will work for us?

·         Can you tell us what technology is available that might make our lives simpler for this system?

·         What is going to change and how are we going to deal with that change?

Armed with a new view of what the stakeholders might be saying and determined to listen harder and more naively, the business analysts went forth to bring about a new system.

Business System Analyst

I have noticed recently  a trend towards the role or position of “Business System Analyst”, or some other combination of the business analyst and the systems analyst, the business aspect of the problem and the technical aspect of the solution.

There are a number of reasons for this reversal of the split between business and technical roles over the past couple of decades.  Over the years the trend has been toward specialists that analyze the business problem and other specialists that describe the details of the technical solution.  The primary rationale has been the increasing complexity of the business processes requiring specialized knowledge and the eually increasing invasiveness of technology into those business processes also requiring specialized and significantly different technical knowledge and skills.

The complexity of business and the complexity of technology has not diminished, so why is there a trend towards consolidation of the business analyst and technical specialist / designer roles?

For one thing, organizations still haven’t bounced back from the Big Recession and there still is a consolidation of roles due to a reduction in staffing.  More business analysts are also project managers and more project managers are also playing the role of business analyst, and so forth.

The advent of agile software development has also impacted the role of business analyst.  “Pure” business analysts are looked at with some skepticism by the aglists who strongly support the concept of the developers dealing directly with the business community without any intermediaries.

And the increased use of off-shore developers means that the specifications provided to the off shore organization must be more technical than business analysts typically prepare so the business analysts tend to have to do systems analyst type functions to get the specifications ready for the off-shore developers while still maintaining a business relationship with the stakeholders. 

You may find yourself in a dual role, explicitly – taking the title of Business System Analyst or some such – or implicitly, by doing the work of both roles without recognition. If so the guidance to success is the same as when you have to do both a project manager and business analyst role at the same time: separate the roles as much as possible.

Why?  Because trying to do both at the same time is more likely to jeopardize the success of the product for many reasons:

·         Trying to think about the system specifications while defining the problem and refining what the business stakeholders want will likely result in many things being missed or skipped over.  For example, presenting a solution to the stakeholders before all the information has been obtained from all the stakeholders

·         There is a higher potential for solution jumping followed by confirmation bias that will focus on a specific solution which may not be the best

·         It is easier to make and not confirm assumptions about both the problem domain and the solution when both are done by the same person

·         There is a tendency to avoid details since the business analyst already knows what they are and does not have to describe the details to the systems analyst or technical specialist who is a different person

·         The combined role becomes too familiar with the problem and solution and starts overlooking issues and not addressing problems

·         There are no checks and balances that would exist if there were two different people playing each of the roles

Ideally if you have to play both roles, you will have another business analyst that can provide some feedback emphasizing one or the other role. For example, if you are focusing on the business side, the other business analyst can offer some technical commentary and review. Otherwise, if you are a lone ranger, you may have to try to split the roles in some way so that you can focus entirely on business analyst functions in one role and technical functions in the other. This decreases the problems that multiple role playing brings about,