Dr. BA is here to answer your questions about BA-hood. You may submit your own questions which Dr. BA will answer. Dr. BA will answer all reasonable questions. An unreasonable question is one which Dr. BA cannot answer. Dr. BA will suffer alternate answers to the questions from readers and others who think they know more than the good Doctor although he may select an alternate diagnosis should he see fit. After all, this is Dr. BA’s column.
To submit a question to Dr. BA, CLICK HERE.
Click on the Current Questions for Dr. BA:
1. Just exactly what does BA stand for? – Manager (name withheld to protect the stupid) in Chicago 1. Just exactly what does BA stand for? – Manager (name withheld to protect the stupid) in Chicago
My first reaction is to say that as BAs we stand for “Truth, Justice and the American Way.” Scott Ambler has facetiously (I hope) suggested that BA stands for Band Aid. While the common understanding of BA is business analyst, many who practice the art and craft of business analysis may believe that BA stands for “Blame Attractor.”
2. How do we deal with customers who give us the solution and not the problem? – Marge, New York
There are several approaches to this situation. The easiest, conditions permitting, is to simply ask, “OK. That sounds like a good thing to do. Now, why do you want to do that?” Or something similar. In other words, ask what the problem is behind the solution without indicating any judgment of the solution itself. It might take several repetitive “why?” questions to get to the real problem. Thus you have the Six Sigma approach of “Five Whys” (you have to ask why? five times to get to the right answer). Be careful, though. If the person you are talking to has a toddler of age two or so, the person might not take kindly to being asked “why?” a number of times.
Remember, a need is also not a problem. When a stakeholder states that something is needed, the very next question, politics aside, is “Why?” as in: “Why do you need that?”
Of course, you can always slap them upside the head and remind them that it is their job to provide the problems and your job to solve them. But that might not help out in the relationship department.
When the solution-requestor is a process worker or user, you can simply accept the solution as more information, perhaps even a good idea. When the solution comes from management you have a different situation. If you accept the solution, the manager might believe that you are going to effect his or her solution without any additional analysis. While it might be the best solution, it might not. And if it isn’t, and you come up with a better solution, you now have the unenviable task of telling the manager that you won’t be using the solution he or she assumed would be implemented.
Many times when a manager tells you how to solve the problem, he or she is stating the only solution they are aware of and assume it is, in fact, the only solution. Once you can get them accepting that there are alternate solutions to the business problem, they will not expect their suggested solution, but go with whatever is best. To get to this point when confronted with a manager telling you how to solve the problem, immediately suggest alternative solutions without putting down the manager’s solution. For example, “That is a good way of solving the problem, how about…?” Or you can elaborate on their solution, “Yes, and not only that, but we could…” Your elaboration does not have to even be feasible, only different. Usually it takes two or three suggestions before the manager starts playing the game and solutionizing with you. Once that happens, you are home free to produce whatever solution is best.
Try it and let me know how it works for you. On second thought, only let me know if it works well.
4. I’m a project manager. What is the best way to relate to the business analysts?
We generally perform better when you put us on a pedestal. Bringing us coffee or bottled water on a regular basis also helps keep us in good spirits and at the top of our game. A back rub now and then goes a long way toward fostering a good relationship with us. Oh, and don’t keep bothering us with those deadlines. We have work to do.
Actually, the best relationship between project manager and business analyst is one of partnership. The business analyst focuses on the business and product aspects of the project and the project manager focuses on everything else. You can depend on the business analyst to provide honest appraisals of the effect changes to the product will have on the business community which can help you assess technical direction. You can use the business analyst’s talents for communication to negotiate or mediate in disputes with business or management (but never the solution team).
The best advice I can give you: respect the business analyst as a solver of business problems and the spokesperson on the solution team for the business community. Do not consider the business analyst as simply a recorder of requirements, and you’ll get along fine.
There are two reasons the business community starts demanding everything they can think of. First, they do not know what the real problem is so they ask for everything on the chance that something they ask for will solve the problem. Second, they do not know when they will get another chance to change things so they want to get all they can while you are cataloguing their requests.
What to do: resolve the first issue by defining the real problem so that they can focus on just what they need to solve it. The second issue can be resolved by incremental delivery. Once the business community realizes that each problem solved is another step in the overall business process improvement effort, they do not worry about not getting everything the first time. They’ll just expect to keep you around for their business lifetime as their personal problem solver.
Participants often come to information gathering sessions with hidden agendas, such as a personal bias for or against something. They answer questions in a way to further that agenda which means the answers could be purposefully misleading, incomplete, or completely false. It is difficult to tell when there are ulterior motives behind responses or actions.
What to do: observation is the best way of telling that a hidden agenda is in play. When you observe changes in body language or vocal characteristics in response to a question or new topic, usually something else is going on. It is probably not a good idea to voice your suspicion. You’ll usually get a denial or deflection. Besides, the reaction might not have anything to do with what is on the table, but might reflect some totally unrelated to the subject at hand, for example it may be incipient ADD. Simply knowing that there is some information that is undisclosed may be enough to temper your analysis of the information. Knowing a potential hidden agenda exists may increase your investigatory efforts.
7. When are requirements done? When you have a solution to the business problem and have specified everything the business needs to do to solve the problem, the business requirements are done. When you have specified everything that is necessary from a technical perspective, the system requirements are done. And when you have specified everything that needs to be completed for the project to be successful the project requirements are done. That doesn't mean frozen or unchanging - just done at this point based on the information you have at this time. 8. Is the business analyst always the advocate for the customer? One way to look at it is that the business analyst is the customer facing member of the solution team. Another way is that the business analyst is the customer representative on the solution team. The former implies that the business analyst is on the side of technology but tempering the solution with the customer's concerns. The latter implies the business analyst is more of an emissary from the business ensuring that the requested solution is delivered. In both cases the business analyst is a customer advocate. But more than that, the business analyst should always be an advocate for the solution to the business problem.
9. How does a BA identify the key stakeholders from a list of stakeholders assigned to a project by the project manager?
It may be good to distinguish between the project stakeholders who are the provenance of the project manager and product stakeholders who provide the information to the business analyst to define the solution. The key product stakeholders are those who are most affected by the problem the project is trying to solve. Those stakeholders are the ones who can give you the most information about the problem domain and the potential solution. Unfortunately they are also the ones closest to the problem so they may not have the most objective viewpoint.
I think we have two visions for everything that is developed whether it be something new and innovative or an enhancement, or even a correction. The first vision is that of the product. This vision comes from the problem owner or the sponsor or someone in business, perhaps marketing, who is able to visualize what the world looks like when the problem is solved. This vision may be a little foggy at first and clarify with time. It also may change in light of reality, especially economic reality. This vision must be promulgated among all stakeholders, business and solution team. The second vision is held by the project manager who has a vision of what the project looks like - how the team will work together, when and how resources will be added, the level of quality that will be levied over the work, what the whole thing will cost the organization and, of course, the product being delivered. This vision is voiced publicly and passed on to the project team on a continuing basis. The public vision may be housed in PMBOK-type documents such as the charter and its variations. It's all right initially for the project manager to have a slightly different vision of the product than the problem owner, and it is perfectly fine for the problem owner or sponsor to have no idea of the project vision. The product vision, however, must mesh at some point so that everyone is aiming at the same vision. Many of the problems with projects, and the cancellations thereof, are the result of unshared visions, conflicting visions, or simply no vision at all.
|
|
|
 |
Ask Dr. BA |