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,