Are You BA or BOT?


Do you know? If not, should you? I’m using BA as an abbreviation for Business Analyst (really, though, it’s one who performs business analysis regardless of the title) and BOT for “Business Order Taker” (also an abbreviated term for ROBOT). They are different in the way they approach business analysis.

Are you BA or BOT?Let’s give apologies to Jeff Foxworthy and examine several “You may be a BOT if…” associations:

  • your only duty in a meeting is to act as a scribe.

  • the business expects you to write down exactly what they tell you they want as a solution.

  • business stakeholders correct your grammar during a document review, rather than concentrating on the business problem to be fixed.

  • you don’t challenge the business to discover the root cause.

  • you focus on giving the business what it wants rather than understanding what it needs.

If you identified with any of the above, you might have aspects of a BOT. But fear not! There are many ways to move towards business analysis from a BOT position. Some of it may be due to the organization culture, but the organization may fail to realize what happens when BAs are treated as BOTs instead of true business analysts.

1.You fail to fix the real problem

I find parents of teenagers are almost natural BAs. How so? Take the example of my 14-year daughter saying “I need a new iPhone”. Parents will naturally question the request (because they are stakeholders paying for the phone bill and the phone). When the request is questioned, the reason the request was made is because the current phone could not load the recent updates onto the phone. Quickly we learn the real problem isn’t the phone, but the space. Now we have an additional option other than the phone – increase the storage space.

But take it once step further – why has a phone that is 4 months old run out of storage space? When you get into the analysis and investigation, you find that it’s not the music taking up a lot of space, but rather 3.5Gb of “selfies” in her camera roll. Now, you can manage storage by migrating the photos off the phone and onto the laptop, which opens up space on the phone, which allows the updates to happen, which precludes the “need” for the new iPhone. Problem solved. You fixed the real problem rather than just recording the request of the stakeholder (my daughter) and implementing it. 

Result? The business analysis rather than the order taking providing value in the form of the organization (my household) reducing costs (a business driver).

Now imagine the opposite – you just listened to the stakeholder and went out and purchased a new iPhone. The real problem would not have been solved and after the purchase of the iPhone, you’d be right back where you started – run out of space. Which leads us to the second problem of a BOT, which is…

2. You spend more money because in the end, you still have to put the real solution in place

If the BOT merely takes the “order” for the business without understanding the problem, you will spend more as a company because you have to put the original solution into production in the end.

Let’s say the business requests a Customer Relationship Management (CRM) software package for their business area. So without understanding the real problem (or pain point) they are trying to solve, the software is brought in. Then that business unit finds it doesn’t work like their old process, so they request a maintenance project to customize the software (money), training to use the new software (more money), new laptops to improve the performance of the software (even more money), and then at the end you up purchasing a sales tool because that’s what they really needed in the first place to address their sales funnel process. So all the work of putting in the CRM package and the customization was wasted because it didn’t really address their problem.

So instead of purchasing the sales tool, you purchased both the sales tool and a CRM package. And not only the CRM package, but also the cost of customization and training, and new hardware to run it. All this could have been prevented if analysis was done at the beginning to understand the objectives of the business unit, instead of merely recording what they wanted.

3. BOTs will get the blame in the end

When you simply record what the business wants, and don’t try to understand their real problem, it will eventually come back to the analyst. The business will not likely state, “Oh, we were wrong to ask for the CRM system when we really wanted a sales tool – our mistake”. It’s more likely, “Mr. CEO, our business unit lost money this year because the BA created an unusable solution for us to accomplish our job.” And there is where you get thrown under the bus.

So how do you become a BA instead of a BOT? 

While there are many ways to be a better BA, and there are lots of articles on the internet with lots of tips, here are 4 to concentrate on coming out of this article.

  1. Understand the problem the business is trying to face. If you don’t know the problem, it’s going to be hard to solve it. Like the iPhone, if the parent didn’t understand the problem, then solving it wasn’t going to work. Ask Why? What is the problem? What is the pain point you are experiencing in your business area?

  2. Solving the problem is so important, I have found it really helps to perform the work yourself alongside the business unit. This is a technique known as Observation, and it’s an active form of observation. By performing the task yourself, you will get to experience yourself the “pain” the business is experiencing. You will have a much better idea of how it affects the business user’s job and you will come up with solutions and ways to make it more efficient. Doing the task side-by-side with the business will also help establish rapport with your business stakeholders and this is so important to get them to feel as though you are there to help them and understand their problems instead of just writing down information in a document. Having someone tell you how something takes a long time versus you rolling up your sleeves and getting in there with them are two different things. Mike Rowe on Dirty Jobs does a great job of understanding the tasks required to do the job. Notice how he establishes rapport with his stakeholders on the show.

  3. Keep track of your successes and explain them to the business. Sometimes management doesn’t understand a BA is a lot more than a BOT. To be honest, sometimes the lack of value perception we have is our own fault – we don’t show the business how we have uncovered the real problem or identified alternative solutions, or saved the company $X. Make sure you keep a record of what you have identified as a BA and how you contributed to the success of the organization. If the business asks for that new, shiny iPhone for $750 and you show an alternate solution of migrating hundreds of Gb of photos off to a $5 USB drive, you have created a solution that saved the company $745. Celebrate that success.

  4. Templates or patterns can help tremendouslyto assist in asking the right questions. The purpose of a template is to have a pattern that helps you ask the right questions in order to get to “excellent” requirements. When you have a list in front of you that can help you remember what to ask, it will help you get to the analysis and be a better BA.

You may have your own ways to prove your value to the business different than what I have listed here. Share your thoughts below.

Author: Paul Mulvey is Director of Business Analysis at Enfocus Solutions, author of Business Analysis for Dummies, a sought-after speaker at conferences and BA development days, and one of the top-25 business analysis influencers on Twitter. His passion is making concepts relevant to the audience. He can be reached at [email protected].

Like this article:
  59 members liked this article


Sant'Anna posted on Wednesday, October 16, 2013 2:44 PM
I'm from Brazil with a good experience in BA, but here we are so away from the top cultural information that is even hard to find some BA certification. I've done a business administration college and Strategical IT management MBA. I became BA because of all my colleagues asking for me to take care of IT issues, and then I had the first oportunite to lead a development for a web based intranet. The success of my analysis not reaching just the critical process but all the future lacks that would come when the problem is solved. Sometimes you hit the problem as a fly, but you don
Sant'Anna posted on Wednesday, October 16, 2013 2:47 PM
but you dont realize that others problems will come sistematic. I was hired by a huge software company to work in Support. After all I left the company to search for a BA certificate outside Brazil. Is incredible how is cleary to see the lack of BA in support area, the truth is that they just want to sell solutions, and not to solve customer problem.
Debbie Hachey posted on Wednesday, October 16, 2013 3:24 PM
Paul - Great article!
Jill posted on Thursday, October 17, 2013 1:33 AM
I had a good laugh when I started reading this article. I was forced kicking and screaming into a role as a BOT.I spend 6 months highlighting risks to the project that could arise at a later stage. Document review sessions had me changing 1 particular term backwards and forwards. I hated it so much and pushed back even harder. This resulted in me alienating myself and being removed before the system was built. I was so frustrated when true requirements gathering started parallel to the build.

I am now in a different department and dusting off my BA skills. I love my job and am gaining confidence again.

Remember to hang in and push back!
saraswat posted on Thursday, October 17, 2013 6:43 AM
very nice , i will always remember last four points.
Andrew posted on Thursday, October 17, 2013 7:12 AM
I think this article nails it. I used to call the BOT the "Requirements Documenter". All to often I've met clients who already have a solution in mind. I had one client who not only knew he needed a new software package but he had already chosen one. But the organization wanted a business case to prove it. Through process and requirements analysis it was clear that the source of the problem was the existing solution was not configured in a way that met his needs. As BA's we need to help our clients define the problem first as that will always lead to better solutions.
Kent McDonald posted on Thursday, October 17, 2013 7:28 AM
Good article Paul. Nice use of a real life example to bring home the importance of finding the root problem.

With suggestion #4 I'd encourage everyone to focus on the *pattern* aspect of templates. Templates are double edged swords which can, if you are not careful, drag you back into BOT land. Use with care.
Paul Mulvey posted on Thursday, October 17, 2013 8:34 AM
@LucasSanatanna - thanks for the comments

@dhachey - thanks for the compliment - hope all is well with you

@Jill - great advice. It's good to know you didn't perish during that implementation. Gain that confidence and with your questioning, sounds like you are a BA!

@saraswat - thanks

@andrewjmitchell - Yup. Sent you email about your speaking invitation. Based on the feedback I'm getting on this article, I'm thinking about turning this one concept into a preso.

@KentMcDonald - I love the real world! I've used this when I'm instructing fellow BAs, and the iPhone example requested by a teen INSTANTLY sounds an accord with those people. They "get it" quickly, including how marching down the wrong path can be less effective at best, disastrous at worst.
Robin Goldsmith posted on Saturday, October 19, 2013 3:18 PM
For more on these themes of getting the REAL problem right and actively intertwining analysis with elicitation, see my related articles

Should BABOK Include Shorthand?
Requirements Networking Group featured article
now at


BAs Will Falter Until They Learn to Discover REAL, Business Requirements
Modern Analyst featured article, January 10, 2010
Jas Kalra posted on Friday, October 25, 2013 6:53 AM
One of the most insightful articles on BA. Jotted down the last 4 points.
Richard Larson posted on Monday, November 4, 2013 6:38 PM
Hi Paul,

Nice article, Paul, and well said. I'm glad to see you are helping pick up the mantle about the BA as order taker, and why we want/need to move out of that role to be influential. Elizabeth Larson and I have spoken and written on this concept for a while and share your passion for helping to solve the right problem and not merely implement solutions as an order taker. For more on this topic, you may want to check out this article posted on Modern Analyst:
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC