There’s More to Outsourcing than Just Cutting Costs

January 21st, 2008 |   Send this article to a friend!

These days it’s standard practice for American based companies implementing software systems to send technical development overseas to countries like India, Singapore, and China. If you walk around the corner of your office, you may find a small offshore team crammed into a cubical gathering and reviewing technical requirements to be distributed to resources located on the other side of the world. In almost all cases, the outsourcing model is adopted in an effort to cut down on development costs. On the surface it makes sense - why pay a US based contractor the high salary when an offshore resource can perform the same work for a fraction of the cost? Several years ago, many IT executives considered this question to be a no-brainer and would have immediately adopted the offshore model. But while all their concentration was focused on cutting costs, project managers neglected other important variables in the offshore equation, and

as a result there have been few successes and far too many failures in adopting the outsourcing model within the IT industry. If you’re an executive evaluating the cost benefits of the offshore model, there are other factors to take into consideration.

For starters, you must evaluate the skills and expertise that is required from the technical resources that are needed. Generally speaking, most offshore developers I’ve worked with have an outstanding technical background. They know and understand database architecture, coding standards and syntax, and have an expertise in the many software tools that are necessary to get the job done. Irrespective of citizenship or other factors, these skill sets alone are great for development work on small, independent software systems where there are minimal dependencies. Some examples of an independent software environment could be:

• A small to mid-size business running a custom-built, homegrown system.
• A standalone software system used to collect and report on transactions specific to a department and/or sub-division.

If your software system fits this profile, than an offshore resource could most certainly meet your needs.

Where additional precaution is needed is in the implementation of a company-wide ERP system. When doing any kind of customizing to an enterprise software application, it’s critical that the technical resources you seek not only have sound technical skill sets, but also a strong functional understanding of the application. The technical resource at minimum should know:

• How the application module was designed to work out-of-the-box.
• The inter-dependencies of the modules. In other words, how a particular module fits into the entire application framework.
• The adverse affects of changing module design based on these inter-dependencies.

Now I’m willing to admit that it’s unrealistic to expect a technical guru to write complex code all while he or she is reciting the user documentation, but general functional knowledge is a definite requirement to ensure that you’re project staff and offshore resources can communicate on the same wavelength.

I’ve observed that the services provided by an offshore outfit are usually sound from a technical standpoint. However, from a functional standpoint, the level of expertise is up for debate. When first introduced to the model, many experts (including myself) had the expectation that the technical resources provided would have some degree of functional knowledge of the respective system. This expectation often led to a major misunderstanding of what an offshore outfit is able to offer. What was thought to be a team of techno-functional resources turned out to be a team of highly skilled coders with less than desirable knowledge of the application.

Anyone who has worked in the ERP world knows that communication is key to running an effective software implementation project. If this line of communication breaks, a rippling effect is sent throughout the entire team - placing the quality of work and the success of the project at risk. If the project staff and the outsourcing group do not have the same collective understanding of the functional requirements, a severe breakdown in communication between these groups occurs and results in technical objects not being delivered according to the communicated (or understood) specification. I like to call this the Techno-Functional Gap, and without a doubt, it is the main reason why the outsourcing model has failed.

Before making the decision to go offshore, it’s extremely import to consider how the techno-functional gap will be bridged among your project staff and the offshore resources. Ultimately what you want to avoid is a purely functional consultant with no technical background writing design specifications for an offshore programmer without any functional knowledge of the application. Both resources may have their respective strengths, but if a common understanding cannot be met, there’s an increased risk of the requirements being poorly communicated by your staff or misunderstood by the outsourcing group.

An easy way to measure this risk is to first evaluate the skill sets of your current staff. Depending on how weak or strong the technical background of your staff is determines the kind of functional background that’s needed from your offshore resources. By building a skill set matrix which rates your staff’s functional and technical strengths, your organizational needs become more clear. So for example:

	Module	Functional Rating	Technical Rating
Resource #1	Finance	9 – Strong	7 – Above Average
Resource #2	Sales	10 – Strong	1 – Poor

 

In the above chart I took two example project resources: one from the sales team and one from the finance team. I then attempted to rate each of their functional and technical skill sets on a scale of 1 to 10, where 10 indicates strong knowledge and 1 represents little to none.

Looking at this chart, we see our finance resource has a very strong functional background with above-average technical skills. Therefore, we may be able to settle for an offshore resource with minimal functional skill sets. On the other hand, we see that our sales consultant has a strong functional background, but has no technical experience. With no technical background, we must be cautious in our choice of offshore developers to pair up with our sales resource. For this resource, it would be wise to find a developer that has average to strong functional knowledge of the system.

This is a very basic example, but it shows how effective this technique can be in ensuring that the project staff is paired up with the appropriate outsourcing resources.

For complicated or critical custom components that will be vital to your business process, I would suggest pairing up resources that have overlapping techno-functional skills. Matching resources with overlapping skill sets will ensure a seamless communication of requirements and effective coordination in testing the complexities of the customization. Simply put, for high-risk technical objects, it’s better to over-communicate than to under-communicate.

In addition to skill set pairing, I would also make sure that a collaborative work environment is put in place so that the project team and outsourcing groups can seamlessly share, distribute, and organize project deliverables amongst each other.

In the past, I’ve seen many clients allow the outsourcing partner to take full responsibility in managing and versioning all deliverables, from documentation to technical objects, as way a way to reduce overhead and take advantage of the cost effective labor. However, like the skill set gap, the collaboration gap creates another disconnect between the developers and the project staff. This led to the internal team having several issues with:

Assessing documentation and other deliverables. 

• Identifying the state of the test environments and knowing which instance had the code ready for testing.
• Identifying code versions and knowing which version of the code they were testing.

These uncertainties usually led to the project team managing their own versions of the documentation and code. Then, as you would suspect, this led to confusion among both groups as to who had the latest version.

Remember, having an offshore group isn’t just about assigning technical development to a separate group sitting at a 14 hour plan ride away; it’s about assigning the project team and the outsourcing group joint responsibility to meet the requirements outlined by the business. It’s a collaborative effort - and being this is a collaborative effort, it’s important to provide the work environment necessary for both groups to work as a single, integrated unit.

It’s important to ensure that some kind of tool or shared network space is in place so that all information associated with the offshore efforts is easily accessible to your staff and the outsourcing partner. There are many tools out there to help streamline the collaborative process. From my past experience, Microsoft SharePoint has proven to be a great tool that allows you to organize your deliverables by team, milestone, etc. through an easy to use web interface. The application allows you to grant access to members of the project so that documents are controlled both from a rights and versioning standpoint. Now I’m only using SharePoint as an example and I’m not trying to sell you the application. However, whatever tool you choose to implement, it’s important that everyone from the team has access to this collaborative workspace and follows all organizational and versioning policies instituted within the team.

So far I’ve discussed the importance of establishing open communication and a collaborative work environment between your staff and the outsourcing partner to minimize the immediate risks, which are misinterpreted requirements and poorly designed custom objects leading to failures within the project and exposed risks to the business if implemented. But in addition to the immediate risks, the long term (or post project) risks also need to be evaluated. Remember, in most cases, the point of bringing on an outsourcing partner is to utilize their resources for the short-term. Once the implementation project is completed, the idea is to relieve the offshore resources and allow your internal project staff to continue supporting the system.

However, if clear communication and group collaboration is not in place, then you may want to extend that contract with your outsourcing partner for much longer than you originally anticipated. If you’re internal staff is not up-to-speed with the work performed by the offshore team, than your group will not be able to effectively support any customizations to the system without the involvement of the outsourcing partner. Too many times in my career have I seen outsourcing contracts extended not because delays to the project schedule, but because the client was not prepared to take on the responsibilities of supporting and maintaining the system.

So in addition to communication and collaboration, a knowledge transfer plan needs to be in place to ensure that your staff is given the information and tools necessary to continue supporting the work delivered by your offshore resources. Do not make this effort secondary to all other activities that may appear to take higher priority. This should be a dedicated phase within your project schedule and should be accounted for in the budget. The less time you set aside for knowledge transfer, the more time you will most likely need to sign up for offshore support. Also keep in mind that the more integrated your project team and the outsourcing partner become, the less time it should take to transfer knowledge. On the flip side, if the work of the outsourcing group was performed independently with no interaction with your staff, then knowledge transfer will most likely be a nightmare.

Like anything in business, it’s not just about cutting costs, but being able to cut costs without sacrificing the quality of work or exposing your organization to potential risk. Outsourcing can be a working, efficient component of your ERP project team so long as the appropriate offshore resources are paired with your staff, the lines of communication are open, and an environment is provided to promote group collaboration. When evaluating your offshore options, make sure to take all these factors into consideration. You may find that the cost risk or the overhead in building an integrated environment may far exceed hiring some permanent hands. Most importantly, it’s important that your IT organization practices what you preach. In other words, do not expect to bring your business into an integrated EPR system environment if your project organization cannot operate as an integrated entity itself.

---

Mr. Thompson is a Senior Oracle Applications Consultant with Lexerd Group Consulting. Visit www.LexerdGroup.com to find out more about our firm.

Interested in hosting your own blog? Lexerd Group’s Internet Services division provides specialized blog hosting services that utilizes the Wordpress blogging platform. Visit http://www.lexerdgroup.com/blog-yourself/ for more details.

Entry Filed under: General, Technical, Outsourcing, Insourcing