Business Analyst Rights and Empowerment

I was surprised again recently when a group of business analysts complained to me that the project manager was upset with them for spending extra time defining the business processes they were working on. The project manager wanted to know where the requirements were so that he could get his technical people at work on the software. The project manager wanted to know what they’d been doing for the four weeks of work since they had no requirements prepared for him.

This is not an unusual situation.  And it doesn’t only come from the IT side. Business analysts relate situations wherein the business refuses to spend time to document the business processes and define the real business problem, and instead wants the business analysts to simply record the business’s wants and needs.

My question was

“why are you complaining?”

Their answer was,

“because they are not letting us be business analysts.”

The role of the business analyst is not understood by everyone, everywhere.

Some managers still think the business analyst is a requirements recorder.  Product stakeholders want to have their every want, need, desire, and inkling inscribed into the requirements document to force the solution team to include their flights of fancy in the final software.

Many IT project managers are convinced that the business analysts are obstacles to successful delivery of a software product.  The business analysts keep bringing up the concept of what will solve the problem, and all the project manager wants is the description of what his developers have to do.

Because the business analyst “works” for the project manager or is “working on behalf of” the business, the business analyst tends to feel that their mere existence as a business analyst depends on one or the other of those constituents. And this is not true.

As Laura stated earlier, the business analyst has a manifesto to perform. The Business Analyst Manifesto states:

Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve.

That is our mission as business analysts.  And we have certain rights that are essential to completing that mission:

As a business analyst you have the right to:

  • Ask questions
  • Understand the problem and problem domain first
  • Make sure you are solving the right problem
  • Challenge the business
  • Challenge the solution team (to explain why they are choosing to solve the problem in a certain way)
  • Come up with solutions
  • Define the problem domain
  • Solve the problem

While is may be a relief to a business analyst to acknowledge those rights and realize that he or she does have those rights as part of their profession, the business analyst must also acknowledge that along with the rights, they have the responsibility to do all these things as a professional business analyst.

Granting rights might not be enough, or might not resonate with you or your management. You might say that informing your manager or the business stakeholders that you have the right to define the problem domain or to ask questions might only draw a blank stare and a comment reminding you of your place in the scheme of things – at least their concept of your place.

So, let’s talk about empowerment.  IIBA  and other organizations for and about business analysts are all about empowering the business analyst to embrace the tenets of their profession.  So what are you empowered to do?  Certainly more than to record requirements that are “gathered” from the users. Certainly more than to conduct requirements review meetings where you read the requirements to the business stakeholders in a teleconference and wait for their response.  Certainly more than to be there to take the blame when the business demands too much or when the solution team does not satisfy all the requirements.

As a business analyst, you are empowered to:

  • Ask questions
  • Challenge the norms, the “way things are done”
  • Try new techniques, methods, and processes to perform your job
  • Suggest new methods or ways of executing business processes in the organization
  • Analyze instead of accept
  • Get and understand information first before committing to a solution
  • Ask more questions
  • Do the good quality job for the organization as a whole instead of only individual organizational entities
  • Define and solve the business problem

You are empoweredYou have the rights.  And if your management starts questioning your empowerment or right to do something in a professional, business analyst way, just tell them that Steve gave you permission.  That should do the trick. (while they are figuring out who “Steve” is, you can get the job done).

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. steve blais says

    I understand your point about making sure there is a schedule to remind or force management to allocate the time for the requirements process. I believe that many business analysts do not estimate time for requirements or are at least loathe to do so is because it will prove to be limiting rather than empowering. A common BA complaint is that they never get enough time to do the requirements right.

  2. Steve ,

    This is a great post that should empower all the Business Analysts out there victimized by their Project Managers, fellow project team members, or end users.

    I would like to share my experience and sorry in advance that this is a long comment. You have inspired thoughts that I feel the urge to share in this forum and hopefully spark more conversations. This is a topic that does not get discussed often.

    The Business Analyst’s role is often misunderstood, underestimated, and challenged by those who lack experience leading projects in organizations that have project management maturity. It is only after many successes and failures that an organizations and its people “get it” and learn to value (and really appreciate) the role of the Business Analyst.

    But I think that it is worst and more painful experience, for business analysts, when their role is challenged by the Project Manager. The PM is supposed to be the Business Analyst’s ally.

    The requirement phase is one of the toughest phases to estimate in a project. A topic of many arguments between the PM and the BA is estimating the requirements gathering efforts.

    Inexperienced project managers always want to cut this phase to the minimum duration possible and jump quickly into the design or development phase. They are often pressured by their Senior Managers and sponsors to show progress. For too many PMs and project sponsors, the requirement phase feels like not much is being done. They just see meetings after meeting but no “real” deliverables. Too many of them are addicted to busy activities and efforts to really appreciate it the need to slow down to fully understand the problem that the project is supposed to solve.

    For these folks, requirement gathering just does not feel like real work. So they constantly challenge the BA’s estimates and progress. Their expectation is that requirement gathering should be just like all other activities: linear and predictable. Experienced project managers know that requirement gathering is a messy process with many twists and turns and going back and forth, just like any other creative endeavor.

    My advice to the Business Analysts is to avoid thinking from the victim mindset and instead use effective negotiation tactics to ensure they have adequate time to complete their work. Instead of constantly defending what they need to do their job, business analysts should document the estimates for their effort and make sure to communicate these estimates in writing to the Project Manager as early as possible in the project planning.

    The biggest mistake I see Business Analysts make is when they start work on projects without a schedule that shows how long they get to have to do their work. Once they start work without a schedule that clearly shows their estimates, they lose their negotiation leverage.

    Although it is tempting to start work on the project without having to provide estimates, business analysts should resist this. They should insist that the project manager produces a schedule before work starts and make sure Business Analysis estimates are reflected in the schedule.

    As long as the timeline for the requirement phase makes it in the schedule, it becomes very difficult to justify removing it without having a strong argument with which the business analyst has to agree.

    Once the BA estimates make to the schedule, any attempt by the PM to reduce them should be handled by the BA with grace and charisma. The BA should try their best to defend their estimates and educate the PM but at some point the BA needs to let go if the PM is not listening. Where I see business analysts make another mistake is when conversation about estimates and timelines becomes very emotional. The business analysts should do their best to educate.

    When logic fails, Business Analysts should document the gap between their estimates and those imposed by the PM and then move on. Should issues surface later, the BA can always refer everyone to the original estimates. Eventually, after too many failures due to missed requirements, people will start respecting business analysts.

    If the business analysis turns out to require more time than originally estimates, then business analysts should have the confidence to request more time and the PM should update the schedule, following the project change management process (insist there is one on your project). Their attitude should be “it is what it is”. If their request is not granted, then this should be documented and a risk should be added to the risk log that the requirements are not complete.

    Thank you.

    Samad Aidane

  3. Jenny Nunemacher says

    (Reposted from my LinkedIn comment)
    You were right. This is a good one. Yet, having rights is not the same as having your rights recognized. I have found that if I take baby steps to start insinuating those non-requirements contributions to the business and to IT, that it is often appreciated and gives more room to do more of it.

    Sometimes it is not feasible to solve the right problem when the immediate need is to solve the problem right now. But if we can make gradual changes by framing the problem for which we can give the right solution, we can still create improvements and progress, if not enterprise level solutions.

  4. Ravi Pardesi says

    Amazing Article, Thanks for understanding and standing by us. It gets hard to make Project Managers understand why there are no requirements even after a month. I think this answers it!!

    Thanks Again!! I am delighted…

  5. DougGtheBA says

    …and the crowd goes wild!!!!” <>

    Bravo sir. Now take a bow.




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.