Discussion Locked

Performance Metrics for Business Analysts?

0 helpful
3 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

The company at which I'm currently employed is investigating how to apply objective performance metrics to all IT staff, including business/systems analysts. The high level tasks for the business/systems analyst at this organization are:

- Provide application subject matter expertise for one or more IT projects
- Elicit, document and validate customer technology requirements
- Analyze customer requirements and prepare functional specifications based off of them
- Prepare test requirements to ensure that delivered products perform as desired
- Verify technical specifications to ensure that they deliver product functionality

I'm hoping that some of you have been involved with implementing this type of measurement, and would appreciate it if you would share your experience and best practice recommendations.

Thanks,
Brian

3 replies

by tony hopkinson

number of boxes in all UML diagrams?

Wrong approach, been tried everywhere, and scattershot do everything number has failed everywhere.

Remember all of the numbers you choose are qualitative, any other number will prove as useful as Lines Of Code did in software development metrics, ie none.

Just to take one 'requirment'

Prepare test requirements to ensure that delivered products perform as desired

Perform as desired by who and when was that desire stated.

Test to business requirement is a notoriously flaky mapping. Even if you got there, what have you tested?

That it does do what you thought it should or in a really enlightened environment what the customer thought it should.

You haven't tested missing requirements.
you haven't tested unintended behavior.
You haven't tested exceptions
You haven't tested structurally

So you could pass the metric and still end up with a POS.

Best strategies I've seen on the metric front. Look at what when wrong last time, look at the simplest (absolute minimal manual effort) set of metrics that will either help identify and or monitor the situation.

Based on the results, do documented corrective actions and most of all follow through on them. CAR as only effective if the action gets actioned and it's corrective. Far too many forget that bit.

All else is an illusion of control, you end up counting what you can afford to count and then trying to massage that to get an 'answer'.

by wan1chang

I have been working in supply chain performance metrics areas for several years. I can see it is very challenge to measure "non-transactional" tasks because you don't have actual data/facts to determine the performance.

My suggestions are:

1. Create data for measurement.
Think about what specific data/event that you can capture from the 4 tasks you listed above. Try it, correct it and improve it over time.

2. Get subjective inputs from people who receive the work/deliverables from the analysts.
In supply chain performance management, we use survey approach to get performance data (e.g. responsiveness). You will need to come up the survey and point system.

How this helps.

by paulmee

1. Knowledge of core policies, standards and methdologies, eg CoBIT.
2. Conformance to policies, standard and methologies, including Enterprise Risk Management
3. Business requests for BA support fulfilled over total Business requests for BA support.
4. Percentage of 'chargeable' time spent on authorised projects.
5. Change planned and undertaken (over 20 man-days) with BA involvment over total Change planned and undertaken.
6. Projects with BA involvement reaching successful conclusion vs projects with BA involvement abandoned/stopped/failing.
7. Number of change requests (or issues) raised and/or rework undertaken for BA produced documentation/designs/testing
8. Quality and accuracy of documentation, eg Function definition consistent with current live systems/services
9. Satisfaction: a. of business, b. of IT, c.Compliance/Audit
10. Training: a. undertaken (in line with knowlegde skills requirements), b. given or built

This discussion is closed to new replies.