The Community Blog for Business Analysts

Bharat Mamtani
Bharat Mamtani

Things to know before you start your BA career

Now when I am already a successful BA since many years, I would like to share few moments with everyone.

During my first months as a business analyst, life was filled with a sort of inner turmoil. Even though I had books on how to write requirements documents, had received individual mentoring on putting together use cases, and had a trusted set of templates to follow, there was something uncertain about how the business analysis process would actually unfold.

I found myself making a lot of mistaken assumptions about what to expect, having those assumptions prove to be unfounded, and then needing to find ways to adjust and course correct. Looking back, there is nothing unexpected about my experiences, except that they were unexpected to me at the time.

Knowing that many of you are just getting started, today I am sharing 4 of the things I wish someone had told me when I was just starting out in my business analysis career.

Need to set expectations early and often, and then again and again and again…

As a business analyst, it’s not uncommon to receive too many assignments, tasks that are outside your bailiwick, or unreasonable deadlines. I was surprised to find myself constantly explaining what I was doing, why it was taking so long, and what could be expected of me over the coming weeks, even though I didn’t always know what the next week would look like!

I also found that deadlines would seem reasonable but became overly optimistic when I didn’t hear back from stakeholders in a timely manner, couldn’t get time on the calendar with a critical stakeholder for weeks at a time, or encountered unexpected issues.

I learned to continually clarify my role, communicate about what would be done when, and seek feedback to be sure I was meeting expectations.

Getting information could be a little painful

Early on in my career, I naively expected unlimited access to stakeholders and their unhindered involvement in and passion about my projects.

The reality was much different. My stakeholders had multiple projects, conflicting priorities, and too much to do. Even when my project was important to them, it could still be difficult to get the information I needed in a timely manner.

Over my career, I learned to be a bit of a squeaky wheel – a very polite, diplomatic, and conscientious one – but squeaky nonetheless. My projects started to move more smoothly and I met my deadlines with less angst.

Although being the requirements author, you aren’t the requirements owner.

I love to write and I love to write requirements. But I could get so caught up in writing and documenting and modeling that I would take on more ownership than was prudent. This would lead to a lack of buy-in from critical stakeholders, which could translate to unexpected changes late in the project.

The reality is that we absolutely need stakeholders to take ownership of the content going into the requirements document, even as we author that document on their behalf. And yes, they are likely to resist reading, reviewing, and providing feedback on requirements.

I learned that providing early, incomplete drafts that were clearly imperfect would help stakeholders see that they could add a lot of information and clarity into the requirements. I also learned to be very specific about the status of any given deliverable when sending it out, and equally specific about what I was asking of my stakeholders of this document at this time.

Dealing with issues professionally would take a new kind of finesse

I’ve always been a proactive person and a bit of a whistle-blower. When a new issue surfaced, I would signal the alarm, rally the troops, and facilitate a problem solving meeting.

However, discovering requirements is a gradual process of gaining clarity and minimizing ambiguity. At a certain point in time, every requirement was once an issue. Business analysis surfaces so many issues that you can’t possibly resolve all of them immediately.

With experience, I learned to blow the whistle more softly, keeping everyone informed about what was surfacing, but not unnecessarily alarmed. To keep the requirements process moving forward, I also learned to take ownership of the issues that surfaced inside of the requirements, and make more decisions about how to resolve issues and which options to choose or recommend.

Now that you know what to expect

Now that you know what to expect, perhaps you won’t be as caught off-guard as I was during your first days as a business analyst!

Happy Analysis !!!

This entry was published on Apr 24, 2016 / Bharat Mamtani. Posted in Business Analysis Planning (BABOK KA), Career as a Business Systems Analyst, Getting Started as a Business Systems Analyst, IIBA & BABOK, CBAP. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  28 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
12 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2018 by Modern Analyst Media LLC