We are based in India and for the past several years have been working with project managers in USA, UK, Spain, Italy, France, Australia, Chile and Germany apart from India for repeat business.
Please allow me to present the views from my side of the table. I know that my utterances will not earn me any brownie points for getting new clients but we have our set of clients who are very happy with the way we are.
You have mentioned three (four actually) very vital ingredients for a successful outsourcing process.
Lack of trust:
From my personal experience, trust building activity is a two way street. It is equally important for the PM to invest sufficient time and effort to instill that trust in their chosen team. If you as the PM proceed with a positive thought process that your chosen team is trustworthy, more often than not, it will prove to be trustworthy. There are rotten apples everywhere, so be it in this domain as well. One has to learn to move on in a bad situation.
Lack of authenticity (often times it's just a name behind an email, hard to build trust w/o more info):
Just like in any other business, due diligence is mandatory before getting into a relationship, so it is here as well, and for both sides.
In our formative years, we got burnt because we did not do the necessary due diligence and delivered (or deployed the resources) for the project. Mid-way, the PM just disappeared without a trace and we were left holding the baby.
We learnt it the hard way and now proceed with utmost caution, keeping our financial exposure to the minimum in a manner that it is a viable proposition for both of us.
Lack of transparency (difficult to know what's being worked on and where you are in your dev schedule):
There are a plethora of tools available to monitor the status of the project. I don’t think this should be an issue at all to know where you are in the development schedule.
Though this comes with a caveat - the data being input by the developers is correct. I guess, any good PM should be able to spot fake status data very early in the cycle.
Poor communication skills (not just language barriers but issues with concepts and terminology):
This again is a two way street. Some PMs we have worked with have caused us immense grief.
I present my point through a very classic example of a driving instructor (read PM) sitting facing backwards and instructs the driver to take a left turn at an intersection. Having traveled a considerable distance after the left turn, the instructor says he meant his left and not our left!! Hence the candidate is failed in the driving test because he/she could not understand simple instructions.
In case the development team cannot understand the concepts and terminologies essential for the project, I think the blame lies equally with the PM who chose an inadequate team on the basis of cost alone. The power to choose a development team lies solely with the PM. One very good method to weed out the fake teams is to throw an odd ball requirement at a very lucrative offer during the discussions and if the team can refuse this offer by saying that they do not have the skill sets to deliver on this requirement, in all probabilities, that is the team that can deliver when they say that they can.
In my opinion, it is equally important for the PM too to see to it that each stakeholder is on the same page at the start of the project.
And that will be a major challenge.
If this can be ensured, half the battle is already won.
This well-known cartoon shows it all http://www.sardiumservices.com/HowProjectsWork.jpg - most projects looks this way. You wait ages, pay a lot and at the end get something completely different than what you need.
Why it happens over and over again? Most companies never succeeded so they simply don't know how to build software. They'll hire anyone, just to fill the racks. Some nearly have to use electric shocks to drag their developers to their daily stand-ups ;) Very few have a recruitment process and hire only quality people.
There is a huge difference between an average consultant and a real software engineer. It's a mind-set difference. Software engineer thinks about building the SUCCESSFUL product that works. Consultant thinks about hacking something and then dumping it to the client, so it's not his problem anymore. In my experience easily 80% of people in software development falls into "hack it - dump it" category, which plays nicely with the statistics that show that 60% of Software Development projects fail.
How to solve it? You need a good development process, hire quality engineers and be eager to provide quality solutions.
If you'd like more information on that topic, we've addressed those issues in our report "Why software projects fail. Symptoms. Causes. Solutions.". Let me know if you'd like a copy - the website on which it will be available for download is not ready so I can't provide the URL yet.
We've also started publishing a series of posts on LinkedIn covering the topic: linkedin.com/pulse/you-part-failing-project-cezary-repecki?trk=prof-post and linkedin.com/pulse/you-part-failing-project-2-cezary-repecki?trk=prof-post