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.

More on your future in business analysis

I was asked how long a business analyst should be a business analyst before he moves on to a “real” profession like project manager.   Here is my response:

I will mark my 50th anniversary in the IT business in September.  I am still a business analyst and as it turns out have probably been a BA for the whole time. I don't intend to "change " jobs.  Why?  Because business analysis is a role, not a position.  The CEO and CIO of major companies still perform business analysis activities; they still play the business analysis role.  There is always a demand for someone to determine the real problem, analyze the situation, and define alternate solutions to the problem.  there will always be a need for someone to analyze other businesses for acquisition or merger or analyze the competition and marketplace to help management decide on strategic direction for the organization.  You may choose to leave the position of business analyst, but likely once you are working in business analysis you will always work in business analysis.