Below are couple of sample, real and typical job descriptions of business analysts, posted on career classifieds. What strikes you about these, at a casual glance? -

1. Sr. Business Analyst in a financial publishing house - "
  • Collaborate with internal and external customers, software engineers, etc. to interview, research, analyze, and derive business, functional, and non-functional requirements for products.
  • Translate business requirements into detailed functional and non-functional specifications.
  • Contribute, as required, to the "look" and "feel" of the product including screen design, on-line text, and/or graphical user interface (GUI) consistent with company standards.
  • Participate in the design and testing phases, including design and testing of prototypes and orchestration and sign-off on acceptance test results to ensure design integrity"

2. A pure play IT Business analyst - 
  • Lead and facilitate the elaboration process for new system projects
  • Analyze and design solution recommendations for system modifications/enhancement to meet the needs of the end users.
  • Develop system requirement specifications for system projects and large strategic projects
  • Act as an liaison between end users and IT departments
  • Develop test plans and participate in system implementation of new or revised systems"

Do you see anything missing in the above? Of course, one could argue that the description is just as that particular firm wants it to be, and every firm has its own "right" role definition.  Be that as may, and in general, even if one may  say that the definition of a BA varies across the industry, are the descriptions still complete? 

Below is my mindmap of various areas that I think every Business Analyst needs to be looking at. The third level down (Brown) may be defined in context and specific to the prevalent practices, but are not the first two levels fairly generic? If a BA is not doing these, then can the resulting software product still be good? Consistently .

BA skill inventory in IT

In my little  experience and in all the books that I have read (have read most on Retrospectives), I always see retrospective as a one-time event. There are many types of these though - a sprint/iteration retro, or a release retro, program retro - you name it.  Yet, though various in scope, they seem similar in structure - recounting experience for the duration that the retro covers. One uses various means to prepare the team, poll them for their thoughts, represent them in a visible information radiator and facilitate discussion. This is truly a great exercise that I have come to admire, that forms a wonderful feedback loop for the team.
Now, I have been trying to do this a little different recently - applying Systems thinking. How about, in the usual retro that you do, after collecting the various positive and negatives, you don't see them as individual issues but a chain of cause and effect. For every positive or negative, there is, if you seek into the audience another cause attributed - and soon you'd see an entire cycle emerge (Last build was slow - (why,  because) - the CI pipeline has become large  - (why,  because) - the QA had suddely added a lot of tests  - (why,  because) - we hadn't added enough functional tests earlier  - (why,  because) etc etc.. you see then the entire retro starts to make sense.

What do you think?

What <IS> the role of a Business Analyst
Business analysis, traditionally, has included among other things the following broad objectives -
1. Ensure client requirements are all captured
2. Ensure the developer understands it

3. Ensure the code meets the aforementioned requirements

There are different schools of thought on how these are performed. In general though, traditionally,  analysis demanded these objectives be met through the following activities:
Objective: 1. Ensure client requirements are all captured
a. Elicit requirements through Questionnaire, Workshops
b. Detailed documents or Use cases/diagrams to capture requirements
c. Traceability to ensure requirements don't get dropped

Objective 2. Ensure the developer understands it
a. Capture system/data flows
b. Capture requirements as use cases/test cases

Objective: 3. Ensure the code meets the aforementioned requirementsActivities:
a. Perform and sign-off  functional tests

What <SHOULD BE> the role of a Business Analyst

As the role evolved, especially in the Agile world (coincidentally not consequently, I think) , business analysis has also acquired the following objectives/activities, and dropped some of the above as a result:

Objective 4. Ensure the requirements are right
a. User stories: Get close to the end-users, and think from their perspective and their goals - look at user value, not business value - hence ensure,  the real requirements are captured -> This has received a whole new infusion of ideas from Human Computer Interaction/Cognitive and behavioural science -> this also meant use cases, which were still partly systemic rather than completely user-centric, became user stories. And then, user stories became better defined when BAs realized "users" should be real end-users, not the system. Thus, non-functional requirements  became cross-functional requirement or just plain requirements worded differently to ensure the delivery team doesn't loose focus on how the user experiences it
b. Task Analysis/Story maps: We started looking at requirements as necessary to perform a user objective. This ensured we optimize software for the best user experience, and not just add better UI or throw better hardware to take care of it. More importantly it e
c. Get user feedback: Plan to release often, showcase and get continuous feedback

Objective 5. Maximize ROI
a. Identify MMF (Minimum marketable features) - Ensure requirements are not just prioritized, but packaged in such a way that value is realized at the earliest. And minimum time is spent on what is less valuable
b. Split stories/Release planning - create independent, negotiable, valuable, estimable, small and testable chunks of requirements that will flow through the development pipeline smoothly, and can beget immediate feedback
    View my profile on LinkedIn


    The author of this blog goes by many names in different places. But, the one that seems to have  stuck for now is... RamRam


    August 2013
    November 2012
    April 2012
    December 2011
    September 2011
    December 2010


    Business Analysis
    Cognitive Science
    Product Management
    Social Justice
    Software Consulting
    Systems Thinking