5. Process is a help to build trust, but cannot replace trust.

Beware of project performance metrics masking problems. Here is a usual scenario:

It is written in the statement of work: "every release must be tested by the offshore team before delivery".

Western local team asks for an engineering release, just to get a feeling of what's going on.

If offshore team says "we don't want to send you an engineering release now because it is not fully tested yet, most of the time it means wait for another week before you discover that we're going to deliver poor quality".

Another danger is to work under a contract signed as a fixed bid rather than a time and materials bid. Theoretically fixed bid contracts are perfect except that you need to have a flawless requirement management technical capability.

5.1 Basic Project Management topics that should appear in the contract.

1) have a unique focal point

2) offshore team agrees to follow your development processes

3) offshore team agrees to provide as much work details as you require

4) scope and deliverables (defined by you, including test reports)

5) WBS (Work Breakdown Structure), responsibility Matrix

6) Schedule detailed enough for accurate tracking

7) offshore team and/or focal point agrees to attend regular status meetings

5.2 Quality Assurance.

In my offshoring experiences, I regret not to have to have put enough attention on the QA issues. It is as important to trust the offshore QA as it is to trust their developers. Do not have the developers test their own work. I strongly advise you to have 2 clear distinctive teams and 2 distinctive chapters in the statement of work.

Here is a good practice that I recommend following Test Driven Development (TDD) technique : ask for delivery of a test plan, before the development even actually starts. You will then have a good idea if the offshore team got the right requirements and have the same understanding.

A complementary way to build trust is to have communication.