Decision Making and the Business Analyst

While business analysts do have to make decisions about what they are going to do and how they are going to do it, they don't generally make decisions about the problem, the solution, or what is going to be done. Those decisions are left to those roles with authority: the project manager, the problem owner, upper-level management, and others. That being said, the business analyst is almost always intricately involved with any decisions that are made about solving the business problem.
It is good to remember the three roles that are necessary in any decision to be made. First of all there is the decision-maker, the one who has the authority to make the final decision. Then there are those who are advisors and provide advice and counsel to the decision-maker. And the third role is that of informer, the one who provides the information to the decision-maker and the advisors.
These are roles, rather than individuals, and all three roles could be played by the same person. For example you are deciding what movie to see. You are the decision-maker, making the decision on which one to choose, you are also the information gatherer checking the start time of the movies and the location they are playing, and you are the advisor checking on reviews and watching trailers.
In a business decision making context, it is highly unlikely that the business analyst will play the role of decision-maker, but in most business decisions business analysts play the roles of advisor or information gatherer or both.
The important aspect of business decision-making for the business analyst is to recognize which of the roles the business analyst is playing so that they played the appropriate role: offering advice and suggestions when playing the advisor, and offering unbiased, objective information when playing the information provider.

Introducing Doctor BA to a larger audience

For those of you who have been reading the blog here, you are probably also familiar with the column on the Website "Ask Doctor BA".  I am expanding the venue of Doctor BA's answers at the behest of Modern Analyst (modernanalyst.com).  They have published two Doctor BA articles providing a more in-depth look at some of the questions business analysts have.  The first published in March, is on BA tools (

http://modernanalyst.com/Resources/Articles/tabid/115/ID/4963/categoryId/90/Doctor-BA-and-the-Tools-of-the-Trade.aspx ).  The second which was published April 1 is on BA decision making. (

http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/4962/Doctor-BA-and-Making-Decisions-as-a-Business-Analyst.aspx).

Check them out and comment on what you like or don't like or disagree with.  Also post some more questions for Doctor BA to answer.  I'm sure he will be willing to respond.

Looking for Bad News

According to John Kotter in his seminal book “Leading Change” most organizations tend to be complacent and avoid bad news. Back in the 1980s, I was with a corporation that bought into the concept that expressing issues as “problems” was bad for organization morale and increased anxiety among employees and depressed creative solutions. The recommendation by the psychologist that proposed this issue was to substitute the words “challenges” or “opportunities” for the word “problems”. That substitution became a policy at this particular company and we were all advised to use the word “opportunity” instead of the word “problem”. I’m not sure how seriously we in IT took the edict. There certainly were a lot of jokes and sarcastic comments made about problems and opportunities, but in the end the substitution did take effect and most people were in fact using “opportunity” instead of “problem”. I don’t know whether employee morale improved, or anxiety decreased, but there certainly was an attitude that things were getting better around at the company, because we had no problems to talk about. Of course with no problems to talk about, there was also no compelling reason to make change, since change only occurs when a problem has been identified, and that led to a form of complacency. And this is the issue that John Kotter was talking about.

Change becomes very difficult if everyone is satisfied with the way things are. There seems to be a trend in many organizations to shield managers from bad news. This is especially true in IT where the engineers would rather solve a problem then bring it to management’s attention.

Business analysts confront this issue on a regular basis. A business analyst is told to find a way to improve a business process and when gathering information from the system users in the process workers finds that they have no need of improvement because everything is going fine.

While we tend to avoid seeking out the bad and try to follow the good advice for making friends and informing people which is to look for the good in everyone, as business analysts we should be looking for things that are not right, processes that could be improved, systems that are simply “bad”: not flexible enough for today’s business, too slow to keep up with the competition, to archaic or clumsy to use it efficiently (even though the users of the system may be completely satisfied with it because they have learned to overcome its idiosyncrasies), or simply not in tune with current technology.

To get the necessary changes approved and implemented we need to address the problems as problems. “Opportunities” can be skipped, delayed, subjugated to other opportunities, or simply ignored. After all, missing an opportunity does not hurt, it just does not help. A missed opportunity may fall into the category of “coulda, woulda, shoulda”. But a problem has to be addressed because failure to do so will hurt.

Of course, we as business analysts have to recognize that we will not be the most popular of people when we present the “bad news” to management. But often, as Kotter suggests, may be the only way to make effective change to the organization.

Seeing is believing or is it?

Quality is something we all want in our products. A product that delivers what was promised and what we expected, won't break when used, is consistent in use, is easy to use and pleasant to look at, and so forth.  We who are involved with product development and product delivery know that quality takes time. So, a constant plaint of those who work on the development side is that management never allocates enough time for quality. Management just wants the product delivered to beat or meet the competition, or to meet some agreed on deadline with a client or customer.  And, worst of all, management many times seems to think that a product is ready for delivery when the developers know it is not so.  Why don't they see it? 
They actually do, and that is a source of the problem in software.  Most managers today come from a non-software background.  Their familiarity with software extends to the apps and systems they use regularly.  They generally hail from a hard product background - physical cell phones, cars, computer hardware, clothing, buildings, and so forth.  When they see the product ready for delivery, a building, a car, a table, they can see the defects and if they cannot, the product is considered ready to go.
With software we can demonstrate a feature or function working well. Management sees the screen and the actions taking place and sees some results. Therefore, like the table with no scratches, it is ready for delivery.  It is difficult to convince someone who sees something working before his or her eyes that there may be issues lurking behind the screen.  That is what the cognitive behaviorists call dissonance.  Our minds must come up with a way of explaining it all.  And, since management has a vested interest in getting the product out, confirmation bias kicks in and management resolves the dissonance by ignoring the issues of lack of quality and rejects the request for additional time to fix something management cannot see.
The end result?  Products delivered with less quality that we would like.
I don't know the answer other than to make the product break in front of management's eyes, and that introduces a whole lot of other, rather unpleasant issues. But at least we can solace ourselves in knowing that there is a human explanation for the conundrum, if such solace helps at all.

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.