Business Analyst

The Profession of The Business Analyst: My Day-to-Day Work

Business Analyst

Today our guest-author is Peter Lefterov – a business analyst at Bulgarian Telecommunication Company.

When I talk about Business Analysis I notice that people often have a very fuzzy idea of what I’m talking about. And the deeper I go into defining the profession from a general perspective, the fuzzier it gets.

That’s why I decided to write down the things I personally do on a day-to-day basis and I hope this will help build a better picture for the uninitiated. Other BAs might do different things but usually there is a level of similarity, otherwise there would not be a name for the profession.

1. Documentation

Most known and usually most tedious BA activity. The problem I’m trying to avoid with this is to have 5 team members and 3 major stakeholders and amongst them 15 different ideas what we are actually doing. The Business Requirements Specification is a tool for avoiding this but it is not the only one and often falls short of achieving the objective.

2. Process Analysis

I don’t do enterprise analysis at least not on my current position. What I do is more focused – when we change the systems people will change their work process. What I’m trying to describe is how things are done now (the AS-IS point of view) and how the work will be done after the change (the TO-BE process). The purpose here is to demonstrate to the team what the changes we are making will actually achieve. It also shows in details in front of the stakeholders what business results they have requested.

3. Requirements Elicitation/Analysis

A key task in my job, this is the description of what system changes we are actually going to make. The task here is to translate the general and unclear requests into detailed description of what the steakholders need and what we are going to do. I need to be at least somewhat familiar with the current system designs, since some (actually most) initial requirements are unreasonable and waiting for the developers to tell me that takes too much time.

4. Requirements change management

Extremely unpleasant topic for all involved. Means that me and the stakeholders have forgoten something or a stakeholder has simply changed their mind. So we need to reanalyze all the work done so far:

  • requirements dependencies,
  • project scope and price,
  • requirements documentation
  • and communication.

Since most of the team works on many projects at once and we have no constant communication, spreading the new information to everyone is a demanding task.

5. Priorities

All requirements matter but some matter more.  With limited resources at disposal my work includes proposing or making decisions related to what will be developed now, what will wait the next development cycle and what will be done in the bright distant future when the world becomes a perfect place and all our wishes come true. 🙂

6. Project Management

I highly value PMs for all they do – organizing meetings, taking hard decisions, negotiating deadlines, monitoring deadlines and so on. Most often, however, I have the dubious privilege to substitute for them. Since as a BA I have clear picture of requirements and keep constant contact with stakeholders I am the usual suspect for filling the role of PM for the project. If you ever need to convince someone it’s important that each project has a PM – let him substitute for a while and he/she will quickly come around. I guess that’s the reason PMs are the strongest supporters of the BA profession – for similar reasons they do our job when we are not around.

That’s all I can thing of on the spot. If you can thing of things you do as a BA (and probably me too, but can’t recall at the moment) feel free to add to the list.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email.

4 Comments

  • Craig Brown says:

    With a slioght variation that sounds like what I did when working as a BA at a telco.

    I did apply project management – at the level around the requirements management and change management, but the pm was usually well on top of the whole project, including stratgic communciations, the budget, earned value tracking etc etc.

    I think project management skills are mandatory if you wnt to be an excellent BA.

    Another skill Peter probably applies but left off his list is consulting.

  • Thanks Craig,
    I see things are similar in this kind of companies everywhere, except yours had more developed PM practice. I truly concentrate around requirements and change management, but sometimes have to sporadically intervene in more strategic considerations, when there is no one responsible on this level and the resulting chaos affects my work.

  • Ben Warsop says:

    Hi – it’s a great list Peter and bang on the button for a project-based BA. For me, I’d add “stakeholder management” or “stakeholder engagement” to the list. I know that’s the responsibility of the PM, but I’ve always spent a huge amount of time presenting powerpoints to people who can make our lives very difficult indeed and answering some bizzarely random questions!

    All the best

    Ben

  • dream says:

    Hi there to every body, it’s my first pay a quick visit of this weblog;
    this website contains awesome and actually fine material in support of visitors.

Leave a Reply

Your email address will not be published. Required fields are marked *