From Softjourn's CEO

When I first started out this discussion on the signals that let you know your company was ready for outsourcing, signal 1 was having management buy-in, i.e. they want to offshore, they already agree it is a good idea. But have they gone a step further and actually defined goals and objectives for offshoring, this is a definite signal that you are ready for offshoring. One of the most famous defined objectives which included offshoring was developed by Jack Welch at General Electric years ago: Outsource 70 percent of the back office, offshore 70 percent of that, and send 70 percent of the offshore work to India. Very clear high-level objectives. It was then up to each unit manager to determine what to outsource and how to do it.

If the management of your company or your investors have set similar goals for your firm, it is a very strong signal that you are ready to outsource because you have to make it work and you will have the support needed to get it done.

If your company has outsourced before, you will have experience in accepting the work done by others outside your company, which often does differ from internally accepted work. For example the type and frequency of status reporting may differ. If a person is working within your company; a simple check in by voice may be enough to know that the project is on track. If the project is outsourced, in order for you to feel comfortable with the work that the work is being done correctly, or that the company is doing work at all, you may require a daily written status. You may also require a deliverable every week, for example for code to be delivered every week for you to take a look and be assured that your project is progressing. Something you may not require if the work is being done in-house and you can see that people are working. 

Another aspect in which your acceptance criteria may differ is in how it should look when it is delivered. For example if you are outsourcing a software development project, and you have been trying to implement or would like to implement coding standards in to the source code for your application, but have not been able to do so to date. You may require that the outsourcing company follow-up specific coding standards for the code they are delivering, but you may not be requiring this in-house.

This signal is very standard for being ready to undertake any kind of work: Do you have a recognized need and do you have the projects defined, or how well do you have the projects defined?

Are you hearing any of this in your company today; qualified leads are slipping through the cracks because we can’t follow-up with all of them, our biggest customer needs 6 major changes to our product or we are going to lose them, we have 10 potential customers that need these two large features before we can bring them in. Do your managers consistently have these complaints? Well this is not a bad position to be in on one hand; you have the customer interest which is better than no interest, but now how do you fulfill that interest in a timely manner. 

If you do commonly hear these types of complaints, next look at how well defined these complaints are? Can they be defined in to a project? Can you ask your managers which are saying sales are slipping through the cracks the following: if you had someone to work on designing this feature tomorrow, could you give them the tools to get the job done, i.e. do you have a written definition of the needs of the client? If yes, you could be ready to outsource.

Has your company, your company’s management in the various business units been able to control the scope of their projects and deliver them on time? If so, it goes a long way towards proving that your company, or at the very least your internal managers know how to keep projects tightly controlled and on target. The biggest issue that causes projects to blow their timeframe is the increase of scope. Pressure to change the scope of a project always occurs as the various parties involved learn more about what is to be delivered or see opportunities to add something in to the project that they want and need but weren’t able to initially have included. Being able to handle this pressure and keep the focus, no matter where the team is located, is a skill. If your managers already have this skill and deliver what is needed, it will be an asset when outsourcing project work.

If this control is part of a company wide process that everyone uses, it would make outsourcing even easier. This factor could be removed from the determination of the business area where outsourcing could start.

Your project manager today manages the work of distributed teams; whether insourced (i.e. company resources sitting in a different location from where the project manager sits) or outsourced. If your project manager does this in any shape or form today, they will make the transition to managing a distributed team half way around the world. Once a team is beyond the same floor or same building the level of difficulty of working with them goes up. If your project manager works in this way today, is effective, i.e. gets things done, they can be successful with an offshore team.

With no experience managing distributed resources, you can still assess their willingness and ability to do this type of work. One of the most difficult aspects for a manager who has to begin working with a distributed team, or remote workers is wondering how they will know how things are going, how will I know that the team is working on the right tasks? 

Discussing some of the following questions with your project manager will give you good insights in to their desire and readiness to manage remote teams:

Additional questions include some of the obvious; willingness to travel as necessary, willingness to work odd hours at times.

Assess your onshore team for:  Attitude and Adaptability

Since I do not like it when these types of buzzwords are used which could mean anything, I will explain how you can use them to assess your team.

Attitude: Does your onshore software development team have the attitude that they like to work with the best and the brightest and that those people can come from anywhere? Or do they think only smart people come from the city or region where your company is located? The first attitude is going to go a long way in making an offshore team work. 

Adaptability: How well does your team adapt to change? This could be any kind of change such as change in scope of projects, change in direction, or a change in personnel. Do they see change as a good thing, a chance to prove themselves or learn something new or do they see it as a personal affront to their well laid out plans. Can they face the fact that it is a global world now not just for the sales of the product/service that they represent, but also possibly for development and operations of that product or service. Adaptability to change will certainly help the acceptance of working with a distributed team, much less with an offshore team.