Similar to logs maintained by the travelers during a voyage, offshore and onsite BA’s work is captured under various knowledge areas during project’s lifecycle. Hence in continuation of my previous articles, in this closing article about onsite vs. offshore BA, I will compare their exposure to various knowledge areas as mentioned in the BABOK.
Previous articles:
Analysis of Knowledge Areas being exposed to Onsite BA and Offshore BA
Following rating indicates chances of task being performed at onsite or offshore – 0% being no possibility to 100% indicating most certainty. Please note that this is not the division of work for onsite – offshore model. Hence 0% indicate that it is not possible to perform the respective task at onsite / offshore and 100% indicate that it is only possible to perform the respective task at onsite / offshore.
Highlights of the finding are:
- As you can see in the image, the least exposed knowledge area for offshore BA is ‘Enterprise Analysis’.
- Also, probability of tasks performed under Elicitation and BA planning and monitoring is less. Please note that elicitation tasks are related with the actual elicitation and not the documentation of requirements. And the planning and monitoring is limited to business analysis tasks and activities.
Let’s go through each knowledge
are one by one. I have mentioned my rationale behind the rating in the
comments.
1. Knowledge Area: Enterprise Analysis
Tasks Offshore
BA Onsite BA
Define Business Need 25% 100%
Assess Capability Gaps 25% 100%
Determine Solution
Approach 25% 100%
Define Solution Scope 25% 100%
Define Business Case 25% 100%
Comments: It
is very rare that enterprise analysis is done from offshore. These tasks
require high level of interaction with various business stakeholders. Only
thing that can be done from offshore in this case is secondary research,
artifact analysis and documentation of analysis shared by onsite BA. However
instead of helping, offshoring this task might waste lot of time explaining
things to offshore and reviewing their work. Hence the higher probability
rating is given to the onsite BA.
2. Knowledge Area: Business Analysis Planning & Monitoring
Tasks Offshore
BA Onsite BA
Plan Business Analysis
Approach 50% 100%
Conduct Stakeholder
Analysis 10% 100%
Plan Business Analysis
Activities 75% 100%
Plan Business Analysis
Communication 75% 100%
Plan Requirements
Management Process 100% 100%
Manage Business Analysis
Performance 100% 100%
Comments:
At onsite – this knowledge areas deals with planning of Business Analysis as a
whole (end to end). Business Analysis Planning and Monitoring activities at the
offshore, focus on the implementation side of the requirements i.e. w.r.t.
development and testing of the solution and BA tasks related with them. Chances
of conducting stakeholder analysis (majorly business stakeholders) happens only
at onsite. Offshore might get involved in case of analyzing implementation
stakeholders. There is fairly good amount of probability that an offshore
analyst gets an opportunity to work on this knowledge areas from offshore. This
is due to this knowledge areas doesn’t require high level of client
interactions
3. Knowledge Area: Elicitation
Tasks Offshore
BA Onsite BA
Prepare for Elicitation 50% 100%
Conduct Elicitation
Activity 50% 100%
Document Elicitation
Results 50% 100%
Confirm Elicitation
Results 50% 100%
Comments:
There are very few and rare occasions when the requirements are being elicited
from offshore. In those cases, offshore BA has to resort to options like
telephonic interviews or video conferencing or desktop sharing. Only in those
cases the chances of performing these activities offshore are there. In most of
the cases, tasks under this knowledge area are performed at onsite. However due
to indirect involvements, probability of this knowledge area being carried out
at offshore is less (50-50)
4. Knowledge Area: Requirements Analysis
Tasks Offshore
BA Onsite BA
Prioritize Requirements 75% 100%
Organize Requirements 75% 100%
Specify and Model
Requirements 100% 100%
Define Assumptions and
Constraints 100% 100%
Verify Requirements 100% 100%
Validate Requirements 75% 100%
Comments: Both
offshore and onsite BA's get exposure to these tasks. However advantage to the
onsite BA is that he mostly gets to work on Business requirements and
Stakeholder requirements along with Solution requirements. Offshore BA mostly
gets to work on Solution requirements. Onsite transition requirements mostly
cover process / people related transition requirements while offshore one's
might cover the technical aspects of transition requirements. At offshore the
prioritization is mostly for already selected work items / requirements. Hence
it is most of the time prioritization in terms of implementation (time and
effort-wise). Onsite prioritization
happens mostly for business value delivered as a whole. Probability of other
tasks happening at offshore is also on a higher side as the work can be carried
out internally. Since validation checks that all requirements support the
delivery of value to the business, fulfill its goals and objectives, and meet a
stakeholder need; it happens intensely at the onsite. However validation is
sort of quality check, the major focus lies at offshore.
5. Knowledge Area: Requirements Management and Communication
Tasks Offshore
BA Onsite BA
Manage Solution Scope
& Requirements 100% 100%
Manage Requirements
Traceability 100% 100%
Maintain Requirements for
Re-use 100% 100%
Prepare Requirements
Package 75% 100%
Communicate Requirements 50% 100%
Comments: Generally
tasks under this knowledge area, can be carried out both at onsite and
offshore. Tasks related to Requirement management can happen at offshore,
however communication of requirement mostly happens from onsite. The
communication package can be created onsite, however majorly the main
communication happens through onsite BA. The offshore requirement management
focuses from implementation side, where the development and testing team has
traceability matrix to link requirements with implemented features. So the main
solution scoping (from business / stakeholder requirement perspective) happens
onsite and implementation related scoping happens from offshore in
collaboration with onsite.
6. Knowledge Area: Solution Assessment and Validation
Tasks Offshore
BA Onsite BA
Assess Proposed Solution 100% 100%
Allocate Requirements 100% 100%
Assess Organizational
Readiness 25% 100%
Define Transition
Requirements 100% 100%
Validate Solution 75% 100%
Evaluate Solution
Performance 100% 100%
Comments: Except
the task of assessing organizational readiness, all the tasks can be carried
out at offshore. This is because it requires knowledge about the client
organizations, stakeholders and As-is state of the business. Other than that
many tasks of this knowledge area can happen at offshore as well. Also, the
transition requirements related with technology can be driven from offshore. Since
validation checks that solution from delivered business value perspective, it happens
intensely at the onsite.
---- END ----
Notes:
Types of Requirements:
As per BABOK 2.0, there are four types of requirements as follows:
Business Requirements- ‘Statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.’ These are very high level requirements generally originated from CEO / top management. Their triggers are external factors like competition, expansion or launch of new product etc. E.g. if a banking CEO wants to increase customer servicing channels to improve customer loyalty.
Stakeholder Requirements: ‘(They) describe the needs of stakeholders that must be met in order to achieve the business requirements.’ These are specific to stakeholders. E.g. in above case, the mobile CoE head (stakeholder) can have a requirement to launch a banking app that can provide customers with self servicing options. This becomes a stakeholder requirement
Solution Requirements: ‘Describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.’ These are basically Functional and Non-Functional requirements. E.g. in above example features of the mobile app will become functional requirements like login feature, check bank balance feature etc. Security or performance features of the mobile app will become non-functional requirements.
Transition Requirements: ‘Describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.’ These requirements mostly cover anything that to be done to make the change happen from As-is state to To-be state. E.g. in above case, data migration for mobile app or trainings for the mobile app will become transition requirements
Notes:
Types of Requirements:
As per BABOK 2.0, there are four types of requirements as follows:
Business Requirements- ‘Statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.’ These are very high level requirements generally originated from CEO / top management. Their triggers are external factors like competition, expansion or launch of new product etc. E.g. if a banking CEO wants to increase customer servicing channels to improve customer loyalty.
Stakeholder Requirements: ‘(They) describe the needs of stakeholders that must be met in order to achieve the business requirements.’ These are specific to stakeholders. E.g. in above case, the mobile CoE head (stakeholder) can have a requirement to launch a banking app that can provide customers with self servicing options. This becomes a stakeholder requirement
Solution Requirements: ‘Describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.’ These are basically Functional and Non-Functional requirements. E.g. in above example features of the mobile app will become functional requirements like login feature, check bank balance feature etc. Security or performance features of the mobile app will become non-functional requirements.
Transition Requirements: ‘Describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.’ These requirements mostly cover anything that to be done to make the change happen from As-is state to To-be state. E.g. in above case, data migration for mobile app or trainings for the mobile app will become transition requirements
No comments:
Post a Comment