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.
1. Just what exactly does BA stand for? – Manager (name withheld to protect the stupid), Chicago
2. How do we deal with customers who give us the solution and not the problem? – Marge, New York
3. What is the best way to objectively define requirements after the boss has given us the solution? What do we do if the real solution isn’t his? – P. Cohen, Pittsburgh
4. I’m a project manager. What is the best way to relate to the business analysts?
5. What can you do when the users want everything regardless of what the project is about? – JV, New York
6. The requirements we got were wrong because they were influenced by personal objectives. What can we do about that? – EB, Boston
7. When are requirements done?
8. Is the business analyst always the advocate for the customer?
14. What is the role of a business analyst in an IT company? – Marilyn, Miami
15. How do business analysts handle unhappy clients? – Diksha, Hyderabad
16. Does a BA have to be from engineering background to be IT BA? – Rohit, Chennai
19. Why, when, and how should business analysts use BPMN? – Tom
1. Just what exactly does BA stand for? – Manager (name withheld to protect the stupid), 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
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.
3. What is the best way to objectively define requirements after the boss has given us the solution? What do we do if the real solution isn’t his? – P. Cohen, Pittsburgh
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.
5. What can you do when the users want everything regardless of what the project is about? – JV, New York
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.
6. The requirements we got were wrong because they were influenced by personal objectives. What can we do about that? – EB, Boston
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.
10. How does a BA identify the key stakeholders from a list of stakeholders assigned to a project by the project manager?
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.
11. What do you do when you call a specific meeting to demonstrate the prototype or product and the participants come in and take over the meeting? And they are management? – John S., Chicago
What did you do?
We told them our objectives and they said their objectives were different and asked us to leave. We did and were happy about it.
Good. What you have is two different meetings scheduled for the same time and in the same place, and you obviously were not invited to the other meeting. Exiting stage right is the correct behavior. You can resume your meeting at a different date and be more careful of who you invite.
12. We have a new vendor and we can’t seem to get together with them. We always seem to talk at cross purposes. How can we resolve the issue so that we can move on? – Reggie, New York
13. My company is suggesting that I take data modeling courses and learn about entity relationship diagrams. The DBAs do all the data modeling. We are not even allowed to get anywhere near them. Why should we learn about data modeling?
The business analyst will not generally be drawing Entity Relationship Diagrams especially nowadays. In the past I did my share of data modeling even in the role of the business analyst. But then there were no DBAs at the time, and, for that matter, no business analysts. However, having the end picture of the ERD in their minds as they collect information about the problem helps the business analysts see data In a different light and identify files (tables, entities), attributes and relationships better. They will ask questions about how the data that the product stakeholders are defining relates to other data and how it all fits together. They have a better concept of the whole system. They will be looking for connections and attributes that they would not have even considered otherwise. The business analyst informed about data modeling will identify more data more accurately than one who has never been exposed to it.
What is the role of a business analyst in an IT company? – Marilyn, Miami
The term “IT company” can mean a lot of things, as can a request for the definition of a ‘role”. In general, the role of the business analyst is to identify and resolve business problems. Most organizations have ‘IT sides” and “business sides” meaning that the IT side provides technological solutions to business problems. The BA’s role, however, is to solve the problems with or without technology. Even in an “IT company” there must be a business component: marketing, sales, accounting, billing, strategizing, managing staff and employees, etc., in other words everything in an organization other than IT. That is the focus of the business analyst regardless of the overall purpose of make-up of the organization.
15. How do business analysts handle unhappy clients? – Diksha, Hyderabad
Diksha, you have to be a bit more specific on what you mean by “unhappy clients”. Are they unhappy with the work you are doing? Are they unhappy in their current situation? Are they unhappy with the work that IT has done for them in the past? Are they unhappy with their job or position or company? Are they just unhappy people in general? Each of these can be dealt with, but require different approaches.
I am assuming the ‘clients’ you are referring to are in the business (as opposed to technology). As such, the business analyst’s first job is to understand the problem, understand why the problem exists. Then the business analyst determines the possible solutions. The problem is that the client is unhappy. The business analyst then needs to determine why and once that is determined, a solution might present itself. As for how to find out why, that is another question.
16. Does a BA have to be from engineering background to be IT BA? – Rohit, Chennai
Not at all. Many IT BAs come from the business side of things, and a growing number of companies are asking for business analysts to have MBAs instead of information technology related degrees. For the most part, it’s probably better to not have an engineering background to be a successful BA. I can say that as one who did come from an engineering and computer programming background.
17. What about when the companies won’t accept you without an engineering degree? In India we have many large and small IT companies and most of them require an engineering degree. They won’t even accept certificates from good computer teaching institutes. Can you suggest any way around?
There is not much you can do when the HR department has a set of check-boxes that must be checked before they release the resume to the BA department or to the project manager. One option is to identify the people who actually need the support and go directly to them, skipping the HR hurdle. The initiative you show in getting to the decision maker is the same initiative that a business analyst needs for success and it might impress the hiring decision maker.
There are rationales for consulting and contracting companies to require degrees and even specific degrees for all their employees. First, it looks good on their proposals to be bidding a larger number of degreed personnel and second, if the employee has a degree in software engineering, even though he is hired as a business analyst, he could be used as a programmer on some other contract. Someone who is only a business analyst would not have that flexibility. You might focus on non-contracting, non-consulting companies who may not have those concerns.
The only other suggestion is to look for companies that have just won large contracts, especially global contracts. They may have to supply a large number of staff quickly and as a result may relax their standards. It will likely require you to relocate to another country to meet the demand. However, once you have a couple of years of experience you may be able to negotiate a transfer to the location of your choice.
18. Could you give me some basic guidance on capitalizing Agile. I’ve done some brief research and it seems there is a bit of a debate on whether the word should always be capitalized or not? – Sally, Syracuse
Agile is an adjective and therefore should never be capitalized according to proper English. However, the industry has created its own language which includes agile as a noun. Usually when talking about a specific implementation of Agile or Agile as a reference (as in “Agile does this…” it is capitalized to emphasize the association with the Manifesto. Lower case is used when referencing a style of action as in “we are using an agile approach”. (Paradoxically, it would be capitalized in “Scrum is an Agile approach” .) Since the industry and the Agile Advocates seem to be making it up as they go, there are no standard guidelines. It’s every person for themselves. In other words, you can’t be wrong no matter what you do; of course you can’t be right either.
19. Why, when, and how should business analysts use BPMN? – Tom
BPMN is an excellent diagramming tool for business analysts to use to model the problem domain. Because of its emphasis on the business processes rather than the computer systems the notation helps the business analyst integrate the computer based technical solution with the overall business processes, something that is often forgotten in the rush to develop the software. Documenting the business processes feeding the computer system being changed and consuming the results of the computer system helps the business stakeholders and the solution team understand the context in which the computer system works, and better understand the scope of the business problem being solved.
20. I just got my first job as a business analyst, and I’m finding it hard to come up with a plan for what to tackle first. I’m working on a complex legacy system, and there are so many things to learn, there doesn’t seem to be enough hours in the day! What would be the best approach during this initial period, to ensure I adapt as quickly as possible and start adding value to the team? – Joe D.
Start with the problem. Get a clear definition of the problem and make sure that the team and primary stakeholders agree with that definition. You may have to actually ask the primary stakeholder because many times the standard documentation does not specify a problem to solve.
Then you can use the problem (and product vision if you can get that as well) as a filtering device to get focus from the documentation. If the information goes to solving the problem, read it; if not, ignore it.
Also you can prioritize and order the documentation. After the problem definition, gather all the information pertaining to the problem domain: how things work now. Ignore, for the time being, everything else. If you understand the problem domain well and all of the business processes in the problem domain, you will probably know more than most of the process workers working in those processes, and more than the rest of the development team.
Then, in your leisure review the solution side documentation starting with the least technical documentation first.
Stop when either you run out of time, or when the documentation becomes more technical than you can understand.