Search This Blog


21 December 2010

The five performing levels of a BA

Benjamin Bloom once again provides me with a reference model that I can apply when modelling the modern BA.  In the past I have used his model as a lens for how we view an analysts understanding of a problem.  Today I want to use it as a lens for inspecting the levels of analyst capability.

Not all projects need the same levels of capability from their business analysts, and not all individuals have the full set of cognitive and practical skills to turn in a 'masterpiece' each time they hand across some requirements.  On the other hand, we all need to do our best to build the BA capability where we work, a it's a potentially high value role that can do a lot to reduce waste, build in enterprise agility and generally maximize value from projects.

Something that helps us improve is realizing that there is a natural pathway with checkpoints along the way.  You can work on your personal capabilities (or coach your team-mates) and focus on achievable short term goals rather than just the big hairy goal to be generally amazing.

With that in mind I borrow an idea from Dr Bloom and present the five performing levels of a BA.
1. Receiving
The metaphor of the waiter is often used for this level of BA work.  This is where you, often as the junior person on a project team, go out and ask people what they want.  You write that down and dutifully hand it in as the project requirements.
This is a perfectly legitimate approach to simple projects where the stakeholders and sponsor are aligned in their views and have a clear vision of what they want to achieve.  It's also where yo begin to learn about the patterns of the enterprise; how one project can tend to look a lot like another despite some cosmetic differences.
2. Responding
As you grow your BA skills you'll start to explore the current environment and ask probing questions to help form consensual visions of the future state of the enterprise (in the context of the project.)  You are likely to develop process models that get commented and negotiated for several rounds by your project stakeholders.
You are actively participating in the discovery process, but while you may be scheduling the meetings and workshops others are leading with the ideas.  Your contribution is likely to be made via the "what if" questions around edge-case scenarios.
3. Valuing
By this stage you are adept at capturing requirements and ensuring good, consistent coverage of the business needs and wants.  Requirements are consistently traced back to project and organisational goals. Now you are starting to apply value to requirements, either at a discreet or grouped level. (See User Stories as one technique for doing this.)
4. Organizing

You are categorizing requirements by type (e.g. regulatory, financial, customer satisfaction, etc.) and mapping each requirement to a particular benefit.  You are sometimes providing specific financial or other metric driven benefits by requirement.
You are also sorting requirements into releases in consultation with the solution team and the client/stakeholders.  You work on a product road-map, anticipating what will become available for the business and when.

5. Characterizing
While I want to say level 5 is 'owning' requirements, that's not the natural role of the BA.  A BA is a facilitator that helps other people come to consensus on how the business and systems is and should be operating.
So Bloom's label of Characterizing remains the best one.  As a highly competent analyst you are able to characterize a requirement or solution as good, bad, mediocre, etc.  You can discuss it's strengths and weaknesses and offer opinions on whether there is a better alternative.  
You are likely to work to influence people to follow a particular path on a project or product.  Your vision of the product road-map inspires people to get behind you and your work with stakeholders is more akin to product management that to a consulting service delivery.
So people, that's my first draft of this model.  What do you think?  Any suggestions for where it can be improved?