Call it Associate Consultant, Business Analyst (BA), System Analyst, Process Consultant or anything else – job description of all these guys remain same. From the beginning of a software development life cycle, how a business analyst (BA) plays its role is known to almost everyone in an IT industry – from requirement gathering, gap analysis (as is – to be ), working on RFP/ RFI/ RFQ to attending even last mile processes of timely UAT and production sign offs.
As per performance metrics given to all during appraisal, items just meet the criteria of meeting expectations for a BA. But how do we actually access BA on a set of standard quantitative measures?
Some of the points could be found are mentioned below:
- Was the Stakeholder Map prepared to understand each owner or system that would be affected due to the new development or change in existing system? List of Single points of contact
- How many business touch points were contacted – Strategic (top management for company level strategy aligning with the project), Tactical or Day-to-day operations team who are real users?
- # of high level requirements – as per business processes and policies – per time spent
- % of use cases prepared as per the high level requirements
- % of non functional requirements missed
- % of requirements got changed post sign off due to missing elements or external influence or system defects
- % of changes in versions of Requirement Document/permissible changes pre/post sign offs?
- % correctness of requirements as per satisfaction of Technical as well as business teams?
- % of requirements conflicted with other requirements – measures consistency
- % of requirements open for discussion post sign off – measures ambiguity
- % of requirements that could be fully tested end to end – to check the verifiability
- % of requirements measured on business priority with client to know which are important/not
- % of requirements eliminated during consulting phase as they were of least importance and more resource consumables/total requirements? – adds productivity to the BA output
- % of requirements changed due to changes by strategic management of the team – top management through an interview session?
- % of use cases modified or deleted during business interactions or new requirements?
- % of requirements debated with what is in scope and what not?
- # of times scope changed
- % deviation in the project timeline due to changes in requirements?
- # of times delay in the customer sign off on UI, UAT, requirements, etc
- # of sessions taken for how long/overall project timeline to make team understand the requirements due to ambiguity in requirements or on open points which is not clear to the technical leads/solution team
- Performance Rating point given by customers on touch points or meetings conducted by BA – formally or informally for overall performance – on a scale
- Performance Rating given by the team members on a scale
Judging on such quantitative measures would obviously improve the performance of a business analyst.Any comment on the enhancement of list is also welcome as the list of not that long! :)
Some of the points could be found are mentioned below:
- Was the Stakeholder Map prepared to understand each owner or system that would be affected due to the new development or change in existing system? List of Single points of contact
- How many business touch points were contacted – Strategic (top management for company level strategy aligning with the project), Tactical or Day-to-day operations team who are real users?
- # of high level requirements – as per business processes and policies – per time spent
- % of use cases prepared as per the high level requirements
- % of non functional requirements missed
- % of requirements got changed post sign off due to missing elements or external influence or system defects
- % of changes in versions of Requirement Document/permissible changes pre/post sign offs?
- % correctness of requirements as per satisfaction of Technical as well as business teams?
- % of requirements conflicted with other requirements – measures consistency
- % of requirements open for discussion post sign off – measures ambiguity
- % of requirements that could be fully tested end to end – to check the verifiability
- % of requirements measured on business priority with client to know which are important/not
- % of requirements eliminated during consulting phase as they were of least importance and more resource consumables/total requirements? – adds productivity to the BA output
- % of requirements changed due to changes by strategic management of the team – top management through an interview session?
- % of use cases modified or deleted during business interactions or new requirements?
- % of requirements debated with what is in scope and what not?
- # of times scope changed
- % deviation in the project timeline due to changes in requirements?
- # of times delay in the customer sign off on UI, UAT, requirements, etc
- Performance Rating point given by customers on touch points or meetings conducted by BA – formally or informally for overall performance – on a scale
- Performance Rating given by the team members on a scale
Judging on such quantitative measures would obviously improve the performance of a business analyst.Any comment on the enhancement of list is also welcome as the list of not that long! :)
