The responsibilities of the Business Analyst (a non-technical and short list)

I was reflecting on how impenetrable the role of the BA can be to a newbie when I was designing the Break through into Business Analysis programme last year.
We used to have no single definition so it was open season for anyone to decide what the BA should do (that hasn’t gone away completely!).

Have you ever felt that you are too flexible such that whenever an unsual job needs doing on the project, it comes your way because everyone else’s role is so well defined?


Now that we have one definition of the role in BABOK, the problem should be starting to disappear shouldn’t it?
Well, yes, but if you are new and you start reading BABOK, it is very easy to get confused and lose sight of what your responsibilities are. There is a very good definition of the role but it is still a little ambiguous and doesn’t give you a really solid list of responsibilities to answer the important questions such as:

Am I fulfilling my responsibilities on this project (and, therefore, being of value to the business)?


So what is your list?
That was my justification to come up with a list which is shown below and should act as that important point of reference:
i) Understand the business need
ii) Agree how to meet the business need to achieve the best results for the business
iii) Ensure requirements are understood by business stakeholders to ensure they are complete and correct
iv) Ensure requirements are suitable to ensure delivery of a solution that meets the business need
v) Ensure the business need and requirements will be met by the proposed solution
vi) Ensure any risks and issues that arise from the solution are understood and accepted by affected stakeholders

I’m sure that you are reading this and saying what does he mean by xxx and but you’ve missed out xyz.
However, I’ve found it useful to check back with this list at several points during the project to make sure I am offering all the value that I should. And if I’m not delivering that responsibility I can ask myself ‘why not?’ and do something about it.

I’d love to hear whether you think this list ‘nails’ the BA responsibilities. Does it need rewording? Are there any glaring holes?
As an aspiring BA, does it make sense? I wanted to make sure it was jargon free.

Please add your comments below.

By the way, if you would like to become a BA and would like to hear about our Break through into BA programme when we launch in June, please add your name to the list here.

It's only fair to share...
Share on Facebook4Digg thisBuffer this pageShare on LinkedIn196Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

17 Responses to “The responsibilities of the Business Analyst (a non-technical and short list)”

Read below or add a comment...

  1. A guide will make certain that you have a life vest and gives you some
    pointers on how one can handle the paddle during certain components of the New River white water
    rafting trip.

  2. When a feminine Norwegian Viking died some time through the 9th
    century, she was buried carrying a standing symbol: a ravishing
    piece of bronze jewelry worn on her traditional Norse gown.

  3. Suraj A. Joel says:

    Hi Alex,

    Very good summary. Is it correct to say that a BA must be a solution provider? Is it necessary for a BA to have a very good knowledge about his domain like BFSI, Airlines, Retail, etc? In my country, people straight from their MBAs land up in BA roles. We cant expect them to be experts in domain. How do we get solutions from a BA?

    Sorry for all the bombardment of questions. Seeking your help. Thank you.

    Regards,
    Suraj

    • Alex Papworth says:

      Thanks Suraj. I don’t think I said that the business analyst needs to be a solution provider.

      The simple answer is, you don’t need to be an expert in IT or in a domain as long as you know someone n the team who is!

      When I stated…

      Ensure the business need and requirements will be met by the proposed solution

      All you need to be able to do is ask the solution provider (e.g. IT designer) to prove that their design meets the requirement. It can be more complicated in practice (!) but you don’t need to be an expert in the domain.

  4. Rachel Price says:

    Thanks Alex. A very succinct list for those who know the trade.

    For the uninitiated I would prefer to see Requirements being put into the context of ‘Change’ and to understand the difference between Business Want and Business Need. A BA needs to add value to the change process.

    Thanks
    Rachel

    • Alex Papworth says:

      Thanks Rachel. I agree strongly with your point about separating want from need. This is one of the areas where we can be of the most help to the business – stepping back to make sure the need is fully understood before identifyng a solution or ‘want’.

  5. Jyolsana Varma says:

    Hi Alex,

    Thanks for the above list.

    If I am right, BA has some kind of involvement in UAT phase (ofcourse it may vary job to job or company to company). Basically, BA help with co-ordinating acceptance of the solution with business, solving problems or impediments during the phase and even producing UAT scripts.

    Jyolsana

    • Alex Papworth says:

      You are right both that they are involved but also that it varies between companies. My only involvement in the past has been to review the scripts. But that’s just my experience…
      There is a real fuzzy area around broader acceptance whether that’s coordinating the go live, investigating how the new system will be ‘landed’ or addressing issues as and when they arrive.
      Some of this may well fall to the BA. But is it the BA’s job?
      Someone has got to do it…

  6. Hi Alex,

    Your post challenged me to go back to my own list. I think we are relatively aligned, which doesn’t surprise me at all.

    There are a couple of items I include on my list, that aren’t explicit on yours. (Although you may include them inside one of your responsibilities.)

    1) Getting Oriented – learning about the project, domain, and role to be sure we’re in a position to contribute effectively.
    2) Help the Business Implement the Solution – This would be the work the business analyst does to create future state business processes, train end users on the new solutions, or otherwise be sure the business is prepared to embrace the new solution fully.
    3) Assess the Value Created by the Solution – This is when we determine if and to what extent we were able to deliver on our business objectives, and can often be the impetuous for kick-starting additional projects.

    You can find my list here:
    http://www.bridging-the-gap.com/business-analysis-process/

    Cheers,
    Laura

    • Alex Papworth says:

      Thanks Laura. I like the getting oriented – how can we help assess the business need until we are at least someway familiar with the business area. We have got to be able to speak the lingo even if we are not experts.
      I’ve quoted your number 3 in my latest email as this is a clear and big gap. We have to make sure we have delivered the benefits that were planned. In my experience this can be overlooked and is not helped by the fact that benefits don’t suddenly appear on the day the project goes live.

      • Thanks for the comment Alex. I feel that #2 and #3 go together. I agree with what you said in your email that these are not always BA responsibilities. But, the more I’ve done in this area, even if it’s to oversee and support others who are fulfilling these responsibilities, the more positive the results. This is where we as BAs really get to be sure our projects deliver the value that’s expected. I think we’ll see this part of the role grow and expand as leadership demands more results from projects.

        Laura

  7. ShravanTiwari says:

    I think that the list is good but still there is scope to include few more points.

    These points are highly required while implementation phase…

    a) Involve in problem-solving meeting to discover how a particular business need can be met considering technology constraints.
    b) Proactively involve if issues come up during implementation that cause some new requirements to be addressed.
    c) Help business stakeholders to accept the solution that’s being implemented.
    d) Analyze how the business stakeholders will use the new solution.
    e) Find out new needs and requirements during implementation which might create new projects to initiate.

    • Alex Papworth says:

      Thanks Shravan for taking the time. These are some wel considered additions.

      I’d like to respond to your suggestions in turn:

      a) Involve in problem-solving meeting to discover how a particular business need can be met considering technology constraints.
      Is this not the same as v) Ensure the business need and requirements will be met by the proposed solution

      b) Proactively involve if issues come up during implementation that cause some new requirements to be addressed.
      What do you mean by addressed in this context?

      c) Help business stakeholders to accept the solution that’s being implemented.
      That’s certainly important. I don’t think I really call this one out although you could argue it forms part of (v) if I was being generous! Are you referring to user acceptance testing when you say accept? Or are you referring to the need to ensure the business is ready to accept the new system?

      d) Analyze how the business stakeholders will use the new solution.
      Not sure what you mean by this. Can you expand or provide an example?

      e) Find out new needs and requirements during implementation which might create new projects to initiate.
      This sounds like a useful value add activity but the value in my list is keeping it concise but still useful. This sounds like a useful activity but not part of the critical list.

      These are just my views – I’d be happy to discuss further.

      • Shravan says:

        Hi Alex,

        Thanks for your comments,

        a) You are right Alex that is the same but i wanted to include technology constraints term because in many projects this also plays an important role.

        b) This is some that while implementation if there is an issue which could be converted to another requirement. So need to review each issues found while implementation.

        c) I am referring to the need to ensure the business is ready to accept the new system.

        d) planning before providing the system to the business stakeholders, like training, demonstration etc.

        e) Yes your comment is absolutely correct, i would say this beneficial for the organisation you are working:).

  8. HClindinin says:

    I think most list will be essentially the same. My focus is keeping everyone on the same page.

    Get consensus on the business need
    Ensure the cost/risk of the most reasonable options are understood
    Get agreement on what the resolution will (and will not) be
    Ensure all actions remain in line with the agreed upon resolution
    Ensure the impact and cost of any chance is a) understood b) acknowledged c) communicated to all involved parties
    Get acknowledgement that the delivered solution met the defined solution (and why if it doesn’t)
    Document as appropriate.

    • Alex Papworth says:

      Thanks HC

      The power of coming up with a new list is that you have a fresh perspective which gives new insights.

      I like the mention of consensus – it calls out the fact that new BAs might expect the business to have a clear single view but that isn’t always the case.

      Shravan’s mention of a problem solving meeting and HC’s mention of the reasonable options highlights the fact that reaching a solution often involves consideration of several options before selecting one. I’m going to think about how this could be included in the list. I think this is covered by item (ii) but my version doesn’t highlight the importance of communicatins the costs/risks to ensure a good decision is made…

      The other items do seem to be covered but the references to get acknowledgement and achieving understainf and communication is a key part of the role which isn’t really highlighted.

      Thanks for the food for thought HC…

Trackbacks

  1. […] few weeks ago, I wrote about the responsibilities of the business analyst (in my […]



Leave A Comment...

*