Archive for the ‘IT outsourcing’ Category

Offshore Outsourcing – Humor of the Week

July 19, 2008

Here is one of my favorite Dilbert strip:


A friend also sent me this funny conversation between a consultant and an offshore resource:

Consultant: So, today is the checkpoint for the designs, status should be on 90% completed, meaning everything’s done and waiting for final review. Are you finished?
Inder: Yes, I put the status on 90% completed
Consultant: Ok, let’s have a quick look at the document. Well… the document is basically empty? How can you put it on 90% completed?
Inder: Yes, document is empty – but it’s all in my head!

In Summary:

  • The communication infrastructure in some countries can be unreliable.
  • Risks associated to offshoring should be identified early.
  • Expectations need to be set and communicated clearly.

Offshoring Sales Performance Management Implementation Components

July 16, 2008

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.
  1. 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.
  2. 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.
  3. 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.
  4. Quotas, rate tables and lookup tables: Creating and updating these objects can be a very time consuming activity.
  5. 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.
  6. 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.
  7. 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?

Outsourcing and Offshoring your SPM Implementation

July 6, 2008

I’m planning to write several articles related to sales performance management outsourcing and offshoring. Let me first define what outsourcing and offshoring means.

Outsourcing: This is when you subcontract the design and implementation of your compensation plans.
Offshoring: This is when you subcontract (typically parts of the implementation) to another country. India and China are well known IT offshoring destinations, but there are many others.

One of my first post on the blog was about in-house development versus outsourcing. Most SPM implementations I see follow one of these patterns:

Pattern 1:
An implementation partner is selected – this can be a vendor agnostic implementer, or the product vendor. As part of their submission, they propose the use of an offshore team to reduce the cost of their bid, or to be able to “go-live” more quickly.

Pattern 2:
An implementation partner is also selected. There are no upfront discussions about offshoring any work. The concept of an offshore team is brought up if the project falls behind schedule.

Upcoming Topics
The reality is that most vendors and consulting companies use offshore teams. I will write about the pros and cons of offshoring, the associated risks, the challenges it will add, the importance of communication strategies, and a few personal stories of managing offshore teams.

I will also write about which aspects of the implementation can be “offshored” more easily. The good news is that with an SPM implementation, once the design phase is completed, there are different way to “break-out” work in different components which are not on a critical-path to each other.

Finally I will answer several questions I have received on this topic. If you have any questions, please don’t hesitate to send them to me.