{"id":66,"date":"2015-01-18T22:05:19","date_gmt":"2015-01-18T22:05:19","guid":{"rendered":"http:\/\/essenceoftheba.com\/home\/?page_id=66"},"modified":"2018-07-19T11:18:15","modified_gmt":"2018-07-19T11:18:15","slug":"ask-dr-ba","status":"publish","type":"page","link":"https:\/\/essenceoftheba.com\/?page_id=66","title":{"rendered":"Ask Dr. BA"},"content":{"rendered":"

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\u00a0may select an alternate diagnosis should he see fit.\u00a0After all, this is Dr. BA\u2019s column. \u00a0<\/span><\/p>\n

To submit a question to Dr. BA,<\/span> CLICK HERE<\/a><\/span>.<\/span><\/span><\/p>\n

1.<\/span><\/a><\/span> Just what exactly does BA stand for? \u2013 Manager (name withheld to protect the stupid), Chicago<\/span><\/a>
\n<\/span>
\n<\/span>2. How do we deal with customers who give us the solution and not the problem? \u2013 Marge, New York<\/span><\/a>
\n<\/span>
\n<\/span>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\u2019t his? \u2013 P. Cohen, Pittsburgh<\/span><\/a>
\n<\/span>
\n<\/span>4. I\u2019m a project manager. What is the best way to relate to the business analysts?<\/span><\/a>
\n<\/span>
\n<\/span>5. What can you do when the users want everything regardless of what the project is about? \u2013 JV, New York<\/span><\/a>
\n<\/span>
\n<\/span>6. The requirements we got were wrong because they were influenced by personal objectives. What can we do about that? \u2013 EB, Boston<\/a><\/span><\/span><\/span><\/p>\n

7. When are requirements done?<\/a><\/span><\/p>\n

8.\u00a0Is the business analyst always the advocate for the customer?<\/a><\/span><\/p>\n

9.\u00a0How does a BA identify the key stakeholders from a list of stakeholders assigned\u00a0<\/span>to a project by the project manager<\/span><\/a><\/span><\/span><\/p>\n

10.\u00a0How does a BA identify the key stakeholders from a list of stakeholders assigned\u00a0<\/span>to a project by the project manager<\/span><\/a><\/span><\/span><\/p>\n

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? \u00a0And they are management? – John S., Chicag<\/a>o<\/span><\/span><\/span><\/p>\n

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<\/a><\/span><\/span><\/span><\/p>\n

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<\/span>?<\/span><\/a><\/span><\/p>\n

14. What is the role of a business analyst in an IT company? – Marilyn, Miami<\/a><\/span><\/p>\n

15. <\/span>How do business analysts handle unhappy clients? – Diksha, Hyderabad<\/span><\/span><\/a><\/span><\/p>\n

16.\u00a0<\/span>Does a BA have to be from engineering background to be IT BA? – Rohit, Chennai<\/span><\/span><\/a><\/span><\/p>\n

17.\u00a0<\/span>What about when the companies won\u2019t accept you without an engineering degree? \u00a0In India we\u00a0<\/span><\/span>have many large and small IT companies and most of them require an engineering degree. They\u00a0<\/span>won\u2019t even accept certificates from good computer teaching institutes. Can you suggest any way\u00a0<\/span>around?<\/span><\/a><\/span><\/p>\n

18. <\/span>Could you give me some basic guidance on capitalizing Agile. I\u2019ve done some brief research and it seems there is a bit of a debate on whether the word should always be capitalized or not? \u00a0– Sally,\u00a0Syracuse<\/span><\/span><\/a><\/span><\/p>\n

19. Why, when, and how should business analysts use BPMN? –\u00a0Tom<\/span><\/span><\/span><\/a><\/span><\/p>\n

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!\u00a0What would be the best approach during this initial period, to ensure I adapt as quickly as possible and start adding value to the team? –\u00a0Joe D.<\/span><\/span><\/span><\/a><\/span><\/p>\n

 <\/p>\n

\n

<\/a>1. Just what exactly does BA stand for? \u2013 Manager (name withheld to protect the stupid), Chicago<\/b><\/span><\/b><\/i><\/span><\/h4>\n
\n

My first reaction is to say that as BAs we stand for \u201cTruth, Justice and the American Way.\u201d\u00a0 Scott Ambler has facetiously (I hope) suggested that BA stands for Band Aid.\u00a0 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 \u201cBlame Attractor.\u201d<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>2. How do we deal with customers who give us the solution and not the problem? \u2013 Marge, New York\u00a0<\/span><\/b><\/i><\/span><\/p>\n

\n
There are several approaches to this situation.\u00a0 The easiest, conditions permitting, is to simply ask, \u201cOK. That sounds like a good thing to do.\u00a0 Now, why do you want to do that?\u201d\u00a0 Or something similar.\u00a0 In other words, ask what the problem is behind the solution without indicating any judgment of the solution itself.\u00a0 It might take several repetitive \u201cwhy?\u201d questions to get to the real problem. Thus you have the Six Sigma approach of \u201cFive Whys\u201d (you have to ask why? five times to get to the right answer).\u00a0 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 \u201cwhy?\u201d a number of times.<\/span><\/div>\n<\/div>\n
\n
\u00a0<\/span><\/div>\n<\/div>\n
\n
Remember, a need is also not a problem.\u00a0 When a stakeholder states that something is needed, the very next question, politics aside, is \u201cWhy?\u201d as in: \u201cWhy do you need that?\u201d<\/span><\/div>\n

 <\/p>\n<\/div>\n

\n

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.\u00a0 But that might not help out in the relationship department.\u00a0<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>3. What is the best way to objectively define requirements after the boss has given us the solution?\u00a0 What do we do if the real solution isn\u2019t his? \u2013 P. Cohen, Pittsburgh<\/span><\/b><\/i><\/span><\/p>\n

\n

When the solution-requestor is a process worker or user, you can simply accept the solution as more information, perhaps even a good idea.\u00a0 When the solution comes from management you have a different situation.\u00a0 If you accept the solution, the manager might believe that you are going to effect his or her solution without any additional analysis.\u00a0 While it might be the best solution, it might not.\u00a0 And if it isn\u2019t, and you come up with a better solution, you now have the unenviable task of telling the manager that you won\u2019t be using the solution he or she assumed would be implemented. \u00a0<\/span><\/p>\n<\/div>\n

\n

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.\u00a0 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\u2019s solution.\u00a0 For example, \u201cThat is a good way of solving the problem, how about\u2026?\u201d\u00a0 Or you can elaborate on their solution, \u201cYes, and not only that, but we could\u2026\u201d\u00a0 Your elaboration does not have to even be feasible, only different.\u00a0 Usually it takes two or three suggestions before the manager starts playing the game and solutionizing with you.\u00a0 Once that happens, you are home free to produce whatever solution is best.\u00a0<\/span><\/p>\n<\/div>\n

\n

Try it and let me know how it works for you.\u00a0 On second thought, only let me know if it works well.\u00a0<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>4. I\u2019m a project manager.\u00a0 What is the best way to relate to the business analysts?<\/span><\/b><\/i><\/span><\/p>\n

\n

We generally perform better when you put us on a pedestal.\u00a0 Bringing us coffee or bottled water on a regular basis also helps keep us in good spirits and at the top of our game.\u00a0 A back rub now and then goes a long way toward fostering a good relationship with us.\u00a0 Oh, and don\u2019t keep bothering us with those deadlines. We have work to do.\u00a0<\/span><\/p>\n<\/div>\n

\n

Actually, the best relationship between project manager and business analyst is one of partnership.\u00a0 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.\u00a0 You can use the business analyst\u2019s talents for communication to negotiate or mediate in disputes with business or management (but never the solution team).\u00a0<\/span><\/p>\n<\/div>\n

\n

The best advice I can give you:\u00a0 respect the business analyst as a solver of business problems and the spokesperson on the solution team for the business community.\u00a0 Do not consider the business analyst as simply a recorder of requirements, and you\u2019ll get along fine.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>5. What can you do when the users want everything regardless of what the project is about? \u2013 JV, New York<\/span><\/b><\/i><\/span><\/p>\n

\n

There are two reasons the business community starts demanding everything\u00a0they can think of. First, they do not know what the real problem is so they ask\u00a0for everything on the chance that something they ask for will solve the problem.\u00a0Second, they do not know when they will get another chance to change things so\u00a0they want to get all they can while you are cataloguing their requests.<\/span><\/p>\n<\/div>\n

\n

What to do: resolve the first issue by defining the real problem so that they can\u00a0focus on just what they need to solve it. The second issue can be resolved by\u00a0incremental delivery. Once the business community realizes that each problem\u00a0solved is another step in the overall business process improvement effort, they\u00a0do not worry about not getting everything the first time. They\u2019ll just expect to keep\u00a0you around for their business lifetime as their personal problem solver.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>6. The requirements we got were wrong because they were influenced by personal objectives. What can we do about that? \u2013 EB, Boston<\/span><\/b><\/i><\/span><\/p>\n

\n

Participants often come to information gathering sessions with hidden agendas,\u00a0such as a personal bias for or against something. They answer questions in\u00a0a way to further that agenda which means the answers could be purposefully\u00a0misleading, incomplete, or completely false. It is difficult to tell when there are\u00a0ulterior motives behind responses or actions.<\/span><\/p>\n<\/div>\n

\n

What to do: observation is the best way of telling that a hidden agenda is in\u00a0play. When you observe changes in body language or vocal characteristics\u00a0in response to a question or new topic, usually something else is going on. It\u00a0is probably not a good idea to voice your suspicion. You\u2019ll usually get a denial\u00a0or deflection. Besides, the reaction might not have anything to do with what is\u00a0on the table, but might reflect some totally unrelated to the subject at hand, for\u00a0example it may be incipient ADD. Simply knowing that there is some information\u00a0that is undisclosed may be enough to temper your analysis of the information.\u00a0Knowing a potential hidden agenda exists may increase your investigatory\u00a0efforts.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>7. When are requirements done?<\/b><\/i><\/span><\/span><\/p>\n

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.<\/span><\/p>\n

\n

That doesn’t mean frozen or unchanging – just done at this point based on the information you have at this time.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>8.\u00a0Is the business analyst always the advocate for the customer?<\/b><\/i><\/span><\/span><\/p>\n

One way to look at it is that the business analyst is the customer facing member of the solution team.\u00a0 Another way is that the business analyst is the customer representative on the solution team.\u00a0 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.\u00a0 But more than that, the business analyst should always be an advocate for the solution to the business problem.<\/span><\/p>\n

 <\/p>\n

<\/a>9.\u00a0How does a BA identify the key stakeholders from a list of stakeholders assigned\u00a0<\/span>to a project by the project manager?<\/span><\/span><\/b><\/i><\/span><\/p>\n

\n

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. \u00a0The key product stakeholders are those who are most affected by the problem the project is trying to solve. \u00a0Those stakeholders are the ones who can give you the most information about the problem domain and the potential solution. \u00a0Unfortunately they are also the ones closest to the problem so they may not have the most objective viewpoint.\u00a0<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>10.\u00a0How does a BA identify the key stakeholders from a list of stakeholders assigned\u00a0<\/span>to a project by the project manager?<\/span><\/b><\/i><\/span><\/span><\/p>\n

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.\u00a0 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.\u00a0 This vision may be a little foggy at first and clarify with time. It also may change in light of reality, especially economic reality.\u00a0 This vision must be promulgated among all stakeholders, business and solution team.<\/span><\/p>\n

\n

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.\u00a0 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.<\/span><\/p>\n<\/div>\n

\n

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.\u00a0 The product vision, however, must mesh at some point so that everyone is aiming at the same vision.<\/span><\/p>\n<\/div>\n

\n

Many of the problems with projects, and the cancellations thereof, are the result of unshared visions, conflicting visions, or simply no vision at all.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>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? \u00a0And they are management? – John S., Chicago<\/i><\/b><\/span><\/span><\/p>\n

\n

What did you do?<\/span><\/p>\n<\/div>\n

\n

We told them our objectives and they said their objectives were different and asked us to leave. We did and were happy about it.<\/span><\/p>\n<\/div>\n

\n

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.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>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<\/b><\/i><\/span><\/span><\/span><\/p>\n

Never think of what you are doing in terms of requirements, or systems, or software, pr even processes.\u00a0 Always think of what you are doing in terms of change.\u00a0 You are changing the organization.\u00a0 You are solving a business problem and bringing about a change, small or large, it\u2019s a change.\u00a0 And the success of the change is not necessarily in the pizzazz of the software or the efficiency of the system, but in how the people affected by the change will accept and adopt it.\u00a0 Knowing this in advance and letting it infuse all you do will increase the chances of success in each of your endeavors.\u00a0<\/span><\/div>\n

 <\/p>\n

<\/div>\n

<\/a>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?<\/span><\/b><\/i><\/span><\/span><\/p>\n

\n

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.\u00a0 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.\u00a0 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.<\/a> The business analyst informed about data modeling will identify more data more accurately than one who has never been exposed to it.<\/span><\/p>\n

 <\/p>\n<\/div>\n

<\/a>What is the role of a business analyst in an IT company? – Marilyn, Miami<\/span><\/b><\/i><\/span><\/p>\n

The term “IT company” can mean a lot of things, as can a request for the definition of a ‘role”. \u00a0In general,\u00a0<\/span>the role of the business analyst is to identify and resolve business problems. Most organizations have ‘IT\u00a0sides” and “business sides” meaning that the IT side provides technological solutions to business\u00a0problems. The BA’s role, however, is to solve the problems with or without technology. Even in an “IT\u00a0company” there must be a business component: marketing, sales, accounting, billing, strategizing,\u00a0managing staff and employees, etc., in other words everything in an organization other than IT. That is\u00a0the focus of the business analyst regardless of the overall purpose of make-up of the organization.<\/span><\/p>\n

 <\/p>\n

<\/a>15.\u00a0<\/span>How do business analysts handle unhappy clients? – Diksha, Hyderabad<\/span><\/span><\/b><\/i><\/span><\/p>\n

Diksha, you have to be a bit more specific on what you mean by “unhappy clients”. \u00a0Are they unhappy\u00a0<\/span>with the work you are doing? \u00a0Are they unhappy in their current situation? \u00a0Are they unhappy with the\u00a0work that IT has done for them in the past? \u00a0Are they unhappy with their job or position or company? \u00a0Are\u00a0they just unhappy people in general? \u00a0Each of these can be dealt with, but require different approaches.<\/span><\/p>\n

I am assuming the \u2018clients\u2019 you are referring to are in the business (as opposed to technology). \u00a0As such,\u00a0the business analyst\u2019s first job is to understand the problem, understand why the problem exists. Then\u00a0the business analyst determines the possible solutions. The problem is that the client is unhappy. The\u00a0business analyst then needs to determine why and once that is determined, a solution might present\u00a0itself. As for how to find out why, that is another question.<\/span><\/p>\n

 <\/p>\n

<\/a>16.\u00a0<\/span>Does a BA have to be from engineering background to be IT BA? – Rohit, Chennai<\/span><\/span><\/i><\/b><\/span><\/p>\n

Not at all. \u00a0Many IT BAs come from the business side of things, and a growing number of companies are\u00a0<\/span>asking for business analysts to have MBAs instead of information technology related degrees. For the\u00a0most part, it’s probably better to not have an engineering background to be a successful BA. I can say\u00a0that as one who did come from an engineering and computer programming background.<\/span><\/p>\n

 <\/p>\n

<\/a>17.\u00a0<\/span>What about when the companies won\u2019t accept you without an engineering degree? \u00a0In India we\u00a0<\/span><\/span>have many large and small IT companies and most of them require an engineering degree. They\u00a0<\/span>won\u2019t even accept certificates from good computer teaching institutes. Can you suggest any way\u00a0<\/span>around?<\/span><\/span><\/b><\/i><\/span><\/p>\n

There is not much you can do when the HR department has a set of\u00a0check-boxes\u00a0that must be\u00a0checked before they release the resume to the BA department or to the project manager. One option is\u00a0to identify the people who actually need the support and go directly to them, skipping the HR hurdle. \u00a0The\u00a0initiative you show in getting to the decision maker is the same initiative that a business analyst needs for\u00a0success and it might impress the hiring decision maker.<\/span><\/p>\n

There are rationales for consulting and contracting companies to require degrees and even specific\u00a0degrees for all their employees. First, it looks good on their proposals to be bidding a larger number of\u00a0degreed personnel and second, if the employee has a degree in software engineering, even though he\u00a0is hired as a business analyst, he could be used as a programmer on some other contract. Someone\u00a0who is only a business analyst would not have that flexibility. \u00a0You might focus on non-contracting, non-consulting companies who may not have those concerns.<\/span><\/p>\n

The only other suggestion is to look for companies that have just won large contracts, especially global\u00a0contracts. They may have to supply a large number of staff quickly and as a result may relax their\u00a0standards. It will likely require you to relocate to another country to meet the demand. However, once\u00a0you have a couple of years of experience you may be able to negotiate a transfer to the location of your\u00a0choice.<\/span><\/p>\n

 <\/p>\n

<\/a>18.\u00a0Could you give me some basic guidance on capitalizing Agile. I\u2019ve done some brief research and it seems there is a bit of a debate on whether the word should always be capitalized or not? \u00a0– Sally,\u00a0Syracuse<\/span><\/span><\/span><\/span><\/b><\/i><\/span><\/p>\n

Agile is an adjective and therefore should never be capitalized according to proper English.\u00a0 However, the industry has created its own language which includes agile as a noun.\u00a0 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.\u00a0 Lower case is used when referencing a style of action as in “we are using an agile approach”.\u00a0 (Paradoxically, it would be capitalized in “Scrum is an Agile approach” .)\u00a0 Since the industry and the Agile Advocates seem to be making it up as they go, there are no standard guidelines.\u00a0 It’s every person for themselves.\u00a0 In other words, you can’t be wrong no matter what you do; of course you can’t be right either.<\/span><\/p>\n

 <\/p>\n

<\/a>19. Why, when, and how should business analysts use BPMN? –\u00a0Tom<\/span><\/span><\/b><\/i><\/span><\/p>\n

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.\u00a0 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.<\/span><\/p>\n

 <\/p>\n

<\/a>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!\u00a0What would be the best approach during this initial period, to ensure I adapt as quickly as possible and start adding value to the team? –\u00a0Joe D.<\/span><\/span><\/b><\/i><\/span><\/p>\n

Start with the problem.\u00a0 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.<\/span><\/p>\n

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.<\/span><\/p>\n

Also you can prioritize and order the documentation.\u00a0 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.<\/span><\/p>\n

Then, in your leisure review the solution side documentation starting with the least technical documentation first.<\/span><\/p>\n

Stop when either you run out of time, or when the documentation becomes more technical than you can understand.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

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… <\/p>\n

Read more<\/i><\/a><\/div>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"open","template":"page-templates\/full-width.php","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","footnotes":""},"class_list":["post-66","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=\/wp\/v2\/pages\/66","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=66"}],"version-history":[{"count":87,"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=\/wp\/v2\/pages\/66\/revisions"}],"predecessor-version":[{"id":475,"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=\/wp\/v2\/pages\/66\/revisions\/475"}],"wp:attachment":[{"href":"https:\/\/essenceoftheba.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=66"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}