What makes a project successful

Code Your Dream team has been successfully working with customers all over the world since 2008. Before CYD I worked for another company who did outsourcing in IT as well (in other technologies).
I worked directly and indirectly with large companies like Xerox, adidas, Stanley Black & Decker, Teresis Media.
Now here's what I learned from 12+ years of managing and developing IT projects.

The clear, prompt and organized communications are the main key to success

Everything else can be outsourced or delegated, the communications must be handled clearly and efficiently between someone from the provider's end and the customer's end.
The clearer the communications are, the more chances for success. And vice versa: bad communications lower the chances to succeed.

The quality of specifications

If customer sends unordered pieces of information in multiple communication channels in random points in time - no one can work with that efficiently. That adds a lot of confusion and makes everything slow and risky.
It's much better to spend some time and specify the requirements clearly than quickly throw some incomplete thoughts in a bunch of emails. While sending emails with some thoughts seems to be quicker and easier, in the end it leads to much more time spent. Because when the specs are unclear and incomplete, they will raise a lot of questions, these questions will have to be answered, and so on. The better the initial spec is, the less time it takes to the final delivery of the results.

The process of collaboration

Now here's the process that does work and leads to successful collaboration.
First of all, there are 2 "roles" here - customer representative (CR) on customer's end and project manager (PM) on provider's end.
CR's main function is to explain the customers needs clearly.
PM's function is to clarify specs, provide technical expertise, suggest the best ways to implement requests, elaborate quotes and manage the implementation of tickets.
PM does NOT specify requirements and while he/she can think for the customer, this should happen only in scope of general tasks set by CR. PM doesn't have to specify what to do, he specifies how to do that.
Since these are roles, each of them stands for 1 or more people behind it. The bigger the project is, the more people "play" these roles. For small projects there's usually 1 CR and 1PM, for bigger ones - multiple CRs and one PM, for rather large ones - multiple CRs and PMs.

The process is.
1. CR posts change request, task or a bug into a tracker as a ticket in an agreed format. For example, in form of user stories (SCRUM-like). With all data required to understand the specs (like business background, page layouts, designs, links to pages, etc).
2. CR assigns the ticket requiring implementation to PM.
3. PM reviews the ticket with the team, asks questions (the ticket may bounce from CR to PM a number of times), then elaborates the estimate and assigns the ticket to CR.
4. CR reviews the estimate, and if it looks good, he/she approves it and marks the ticket as "ready for development".
5. The providers team implements the ticket. During that process there may be additional notes and questions, and the ticket may bounce between PM and CR again.
6. Once done, PM provides a quick report on what was done and assigns it to CR.
7. The ticket is reviewed by CR and customers team, tested. If some things need to be changed, they are mentioned in the tracker. During this review additional changes and fixes may be introduced, and this review repeats until everything works well for the customer.
8. The ticket is marked as resolved.

In general, both CR and PM should respond to each other within 24 hours (or less in urgent cases - this should be agreed separately).

So the main idea here is: CR should tell PM what the customer needs.
Even if customer doesn't fully know what they need. The request could be like: "the customer asks you to review the website and provide possible ways of improving it".
That's probably not the best request, but still, it's something. The request should be easy to understand and track.

The customer wants to discuss the load speed issues - that's fine, CR should create a ticket for that with all the details.
French translation should be enabled for pages - that's good, CR should create a ticket for that and let us know what needs to be translated, who is going to provide the translations, etc.
Views are not displayed the way the customer expects them - this happens and can be fixed for sure, CR should create a ticket for that and explain what exactly the problem is.

Now regarding "clear and ordered communication".
99% of communication should happen in issue tracker.
Messengers like Skype should be used in two cases:
- very urgent issues (like the website is down)
- general discussions like what's the process of work, payment terms, availability time, etc.
By the way, all general processes should be also documented.

Everything else should be posted to a tracker.
And that's not a "caprice" or just something that is nice to have - it's absolutely required to make the project successful.
If we have part of the spec in JIRA, another part in some Google doc, then another part in Skype, and yet another part in an email, it's VERY easy to get lost in that.

It's important to get organized - one of the best ways to do that is to follow the process outlined above.
And it will work well - you'll see. If you can't work as a CR, find someone who can.

There's no handshake with just one hand. There's no collaboration with just one side communicating.