Based on my experience and on common sense, there are some project components which are easier to offshore than others.Requirements and Functional Design
Early phases of a project are more challenging to offshore; these phases include the requirement gathering and the functional planning of the project. Offshoring these activities can be difficult because they require a lot of interaction with stakeholders, users and subject matter experts. This type of interaction usually works much better face-to-face than over the phone.
Technical Design, Implementation and Testing
Once the architecture of the project is established, components of the technical design, implementation and testing phases are good candidates to be offshored. Interaction with project stakeholders will obviously be necessary, but the "what" of what needs to be done should be obvious.
Sales Performance Management Implementation
There are many strategies to leverage an offshore team to implement a sales performance management application. Compensation plans can be divided between on-shore and offshore teams, or both teams can collaborate on all the plans. I prefer the collaboration approach; coordination will be a bit more complicated, but many of the risks will be mitigated. As a result, the onshore team will have a clear idea on the status of the offshore team at all time, and there will be less communication issues such as misunderstandings of the requirement and functional design documents.
Here is a list of several common SPM activities which in my experience are good candidates to be offshored. If the design documents are detailed enough, there is no reason why an offshore team could not work on everything. However, there is probably less risk in offshoring well defined activities.
- ETL: A large project will use an Extract, Transfer and Load (ETL) tool to move data where it can be used by the SPM solution. With proper access, an offshore team can make a significant contribution to this process.
- Configuration Management: An implementation is usually carried in different environments; development, various testing envionments, and production. Moving the latest files from one environment to the next can be very time consuming, and often can't be performed while a team works in the environment.
- Reference Data: Loading all the reference data including participants, titles, positions, relationships, territories, etc are activities which will not impact the building of plans, until required for testing.
- Quotas, rate tables and lookup tables: Creating and updating these objects can be a very time consuming activity.
- Formulas and rules: Sometimes, several formulas and rules which are almost identical to each other are required. Not all SPM solutions have an easy "clone" feature, making this activity very tedious.
- Processing: Also called pipeline in Callidus TrueComp, with a large number of participants and of transaction (in late testing phases), processing can take up to several hours. It can be very nice for the onshore team to work on the implementation during the day and come back the next morning to find the results ready and analysis of issues that occured.
- Testing: Testing can be a tedious job. As I discussed before, test scripts should exist which will be executed again and again... and again. Some of the first testing phases such as unit testing and system testing can be almost entirely offshored, but later phases such as integration testing and user acceptance testing are often kept onshore to be able to better monitor quality.
Note: Offshoring all the boring and repetitive activities could have negative impacts on the moral and efficiency of the offshore team, just as it would on any team.
Does anyone have other examples of SPM components which can be offshored easily?
Does anyone have other examples of SPM components which can be offshored easily?
No comments:
Post a Comment