Search This Blog


29 September 2009

Another BA Competency framework

Carrying on from Ambler’s essay on Agile Business Analysts; I want to throw up Scott’s list of “Do’s and Don’ts” for business analysts as a potential for a competency framework.


There is a discussion going on at Linkedin (It's the Modern Analyst Group) about BA Competency frameworks and, well, heck, why not offer another point of view.


Take a look at the list of positive contributions and assess yourself or your BA team members on a scale of 1-5, then take a look at the negative contributions and score from 1-5 again.

This model is derived in part from Frederick Herzberg’s Hygene theory of management and Kano requirements analysis which acknowledge that there are both potential positive and negative outcomes of things such as management and features.

Positive contributions
  • Scope the system
  • Translate business needs
  • Translate technical issues
  • Model and document
  • Act as a communication broker
  • Political mentor
  • Test and validation
  • Represent stakeholders
Negative contributions
  • BAs often lack the right skills
  • BAs can have undue project influence
  • BAs can be out of date
  • BAs can act as a communication barrier
  • BAs can reduce stakeholder influence
  • BAs often over analyse
  • BAs can reduce feedback
  • BAs can reduce opportunities for developers to gain communication skills

Some of these terms need some filling in. An example; “BSAs often lack the right skills.” What are the right skills? What is their purpose? What is their context? What important outcomes will this lack of skills affect?

For Scott’s definition you can go to his article. You can also make up your own to suit your context. Remember that the context is the important think. For example, UML doesn’t matter as much as the ability to effectively get their product vision across to developers and stakeholders.