When I started outsourcing back in 2003-2004, I had this research in hand about the challenges of outsourcing.
I can now, after 12 years of practical experience summarize it in one sentence: distance creates distortions.
Any relationship. Be it personal or professional is hard to keep healthy and positive. If you add long distance to that formula, the result is a disaster.
I read many articles about the importance of open and continuous communications. It is true. It’s absolutely needed.
But the best advice came from my mentor Martin. He had a saying: put yourself in their shoes. Understand THEIR world.
Then it hit me. The best way to avoid misunderstandings is to just try to understand what the other party is going through!
Being in my unique position where I travel between LA and Kiev several times a year, I get to experience the feelings on Both sides of the pond.
When I’m in LA, I’m thinking: what’s my team working on? I trust them. They are good people. I don’t think they are working on someone’s else project. But WHAT exactly are they working on? Is it something needed or are they side-tracked by some unimportant detail?
I’ve asked them to send me reports. Daily stand ups. End of day summary. Plan for tomorrow. Etc. I tried it all.
But that feeling is always there!
On the flip side, when I’m in the Kiev office with the programmers, I start to be with them on one wave length. I start to question the client’s decision on some aspects. And even worse, I understand that there is ALWAYS a concern that the client (any client) would take the code and go. It happens.
I actually sat my team through the very old movie: 12 o’clock high. It’s a great movie about WW2, but it has an amazing amount of lessons about team work and leadership.
Still ..there is always a concern: what did the client mean by this request? What’s going on with the projects that sense of uncertainty?
My solution is: think outside the code!
In order to avoid having the miscommunication between the PMs and the clients, the first thing I do is to make sure that the PM and the programming team is fully aware of what is the problem that the client is trying to solve.
Once that’s identified, the rest just falls into place nicely.
We had a client, debtor soft, that wanted to build a full debt settlement platform. Sales. Support. Client portal. Debt settlement automated work flow, etc.
That concept didn’t even exist in Ukraine.
How could I have expected my team to produce something awesome if they don’t know what it is?
So, I educated them. Explained what debt is. How the economy in the USA was growing and people took lots of credit on low rate variable etc.
That approach took the product from a one-page sample static HTML site, to multi app framework.
I can confidently say that to build such a system one would need tens, if not few hundred, pages of requirement and spec.
We had none.
How?
I have a process that depends heavily on client engagement in the beginning and in the end.
I have recently formalized that process as a service offering: Mockup Guys.
As a client, you have few Skype calls with us. Then we produce wireframes, requirements and eventually designs.
All you have to do it just be available during the skype calls and to provide timely feedback when needed.
It’s easy. Try it!
