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 !!!