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,

Recalcitrant stakeholders

Recently I was asked what could be done about stakeholders who refused to participate in information gathering.  They don't attend scheduled meetings or are resistant to getting together for interviews, even by phone. And they have important information about the product. Or they might suddenly appear when the product is ready to go into production with all their objections.
I offered four possibilities, as follows:

1.   1.  Make sure you have a compelling problem that will help the person when solved.  Define the product stakeholders and when asking for an appointment or a meeting start with the problem. If the problem is compelling and affects the person, they will want to provide information for solution. If not, they will not want to spend their time

2.   2/  Make sure they are affected (or impacted) by the problem or solution. If they don’t want to talk to you it may be because the person who told you to “go talk to them” gave you an erroneous name.  3. The person really doesn’t have information for you and is trying to avoid having a political situation where their boss says they have information they don’t have

3.   3.  If they are resistant to a face to face, define the information you want and let them know what information you are looking for. Sometimes people are hesitant to talk to you because they don’t think they have answers and don’t want to appear stupid.  Or they are afraid they will be asked a question they would prefer not answering, such as about how things are going in the process.  Giving them the information you want in advance may put them at ease and give them a chance to prepare a bit. It also might be beneficial if they don’t have that information. They can then tell you they don’t have it and maybe reference someone who does.

4.    4. Go back to the problem owner and ask for the information. If the problem owner refers to the person who is being resistant, tactfully relate that you cannot get with that person.  At that point one of three things will happen: 1) the problem owner will get that person to talk to you or give you the information, 2) the problem owner will refer you to someone else with the information, 3) the problem owner will get you the information him or herself. In any case, you get the information.

Stupid questions

 I know that  we are told that there are no stupid questions. And that’s good advice to follow. The idea is that we ask all our questions and not worry about whether we will appear silly or stupid in asking them. And as a business analyst, of course, our bread-and-butter is asking questions and if we analyze and concern ourselves with the quality of the question or more importantly how we are going to appear and what people are going to think about us when we ask the question, we will find that we will be stifling ourselves and limiting the number of questions we ask.

 However there are two forms of questions that might be considered to be stupid; in other words, they should not be asked.

 A question for which you know the answer or the answer is clearly obvious is a stupid question. In other words you wasted time asking it when you could have asked a more information providing question. Now this does not apply to clarification questions where you’re asking to confirm your understanding of information that you already know. But asking if the sun is shining while everyone is wearing sunglasses seems to be somewhat of a stupid question.  Or this real question asked of a medical examiner by a lawyer: “Doctor, how many autopsies have you performed on dead people?””

 The other type of stupid question is one in which the responder cannot answer. There is no way to be able to answer without for example incriminating themselves, or putting themselves in a bad light or simply the responder clearly does not have the answer to the question. For example,  “how long has it been since you stopped beating your wife?” The question itself usually generates laughter because they see the quandary the responder is in trying to answer the question. 

It is a stupid question which has no answer.