4 Business Analysis Myths We Could Do Without

As those of you that read my articles regularly will know, I occasionally like to “shake up the hornets’ nest”, in order to provoke thought and to get a healthy debate going.  With the end of the year looming, I thought it was a great time to think about BA myths that our profession could do without—and I thought this would be a great way of creating a great discussion.

My top 4 BA myths are below.  Do you agree with them? What are your top 4 BA myths?

Myth 1: Project Management is the logical career path from a Business Analyst role

A BA could become a PM—but it’s a side-step not a natural progression

A project needs a strong project manager and a strong Business Analyst.  The roles are complimentary, and whilst there is some cross-over, the roles are different.  A project manager will have a keen focus on the stated scope of the project, the timeline and the budget, and they’ll ensure that things are “done right”.  As Business Analysts, we ask probing (and sometimes awkward) questions to make sure that the organization is “doing the right thing”.   We act as a critical friend, and because of this there is a healthy and natural tension between these two roles.  When a strong BA works with a strong PM you create the virtuous circle which enables projects to do “the right things right”. 

It is perfectly possible for a BA to take a side-step into a PM role – if they so wish.  It’s also totally fine for a PM to side-step into a BA role, but it isn’t a logical or natural progression.  Career moves like this should be made consciously, rather than assuming it’s the “only way” or the “logical next step”.

Myth 2: Business Analysts need to be Developers

Technical knowledge helps, but the key is to focus on having “enough” for your project 

BAs deal with all sorts of requirements – business, user, functional, non-functional, etc.  However, our focus is on understanding the business need, and understanding what capabilities the organization has in order to meet that need, and what requirements are associated with those capabilities.

An understanding of technology helps, and as BAs we should certainly gain enough knowledge to credibly talk to technical SMEs.  However, it shouldn’t be necessary for a BA to write code.  Now—as with many things in life—rules are made to be broken.  If you are an ex-developer, you might find yourself helping to debug code when deadlines are looming.  That’s absolutely fine, and its part of being a close team, but it’s important to note that you aren’t carrying out business analysis when you do that.  Perhaps when you are doing this you are wearing a developer or systems analyst “hat”.

Myth 3: You can go on an intensive introductory 2-day “bootcamp” course and become a fully proficient Business Analyst

Training is important, but experience matters 

I see the occasional forum thread which asks, “How can I learn to be an effective BA in a weekend?”   I see this enthusiasm for learning as extremely positive, but I’m afraid to say that if you have no previous experience, a 2 day BA course isn’t going to make you an expert Business Analyst.  It is far more productive to focus on a development roadmap.  Yes, you might start with a 2 day course for awareness—so that you can get your foot in the door into a role—but then follow this up with further training, mentoring and experience.   

Myth 4: You must learn UML (or BPMN, etc.) to become a Business Analyst

Notation is important, but the logic behind it is what really matters. And elicitation can be harder than the modelling itself! 

Learning a modelling language will help you in your BA career – and many BAs swear by UML, others swear by BPMN. In fact, I use UML models myself.   However, it’s important not to get caught up in the notation – the reality is that a modelling notation can be taught much quicker if you already understand the concepts and rules behind a similar notation.  For example, if you understand data modelling using one notation, then it’s relatively easy to learn a new notation.

However—there’s something far more significant than the modelling language that you use.  That is understanding how to elicit the requirements in the first place and how to decide which models to use.  Yes, learn how to record requirements and how to use models—but don’t forget to focus on elicitation techniques too!


Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Adrian, I whole heartedly agree with you on all your points and thanks David W & David R for adding to the list.

    I would add to this list “BAs are not in a leadership role” because honestly speaking BAs are the best examples of people who embody leadership and influence without having formal titles.

    • Yes, you raise an excellent point Raisa.

      Often as BAs we lead from the side-lines. We absolutely need to influence… often without authority… in order to get things done.

      A great point, thanks for sharing!


  2. Adrian – you could just write a BA’s manifesto. We couldn’t agree more with all of these points. I like David’s addition as well.

    We’d probably add something like … “There is no need for BA’s in agile projects”. In an agile world, the business needs its interests represented on a day-to-day basis in the project and it is not realistic to expect that people who operate the business have the time required to be involved in the project daily. Additionally, a good BA brings experience and perspective from elsewhere to bear on the solution design which is a “value-add” during the process.

    • Hi David,

      I *absolutely* agree with your addition. So often there seems to be the assumption that Business Analysis isn’t important in change-driven/agile approaches. Yet, the discipline of Business Analysis is still needed! Agile project still need precise *requirements* — even if the level of *documentation* is less.

      Also, I really like the idea of writing a BA manifesto. We should get a global community together and do that 🙂

  3. Good list, and it makes people (like me) think about adding to it. Mine would be:

    “The business analyst must have experience in the domain for the projects they work on.” A variation is “The Business Analyst should also be a Subject Matter Expert.”

    A good business analyst is good because of their analysis skills, not what they previously know about the business. You cannot be clue-less, but some short prep work is usually enough to get going. In fact, too much previous domain experience can tend to influence the work a BA produces; a BA should never think they know more then the business people do.

    • Hi David,

      Thanks for your comment, and I completely agree. I think there’s a real danger of “going native” if a BA has *too much* domain experience. It becomes difficult to see the wood for the trees!


Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.