The Babel fish is small, yellow and leech-like, and probably the oddest thing in the Universe. It feeds on brainwave energy received not from its own carrier but from those around it. It absorbs all unconscious mental frequencies from this brainwave energy to nourish itself with. It then excretes into the mind of its carrier a telepathic matrix formed by combining the conscious thought frequencies with nerve signals picked up from the speech centres of the brain which has supplied them. The practical upshot of all this is that if you stick a Babel fish in your ear you can instantly understand anything said to you in any form of language.
The end of a one and half year long project is getting near, and I am thinking about all the lessons I learned from this endeavour.
The project started as an interesting one, a totally new business domain for us, in a foreign country working with a local a partner company. And it did not just start, it really is and was an interesting project, and I have learned a lot both professionally and otherwise.
Right now, I want to think, and write about the non professional lessons, which boils down to one thing mainly: communication.
As I said we’ve been working for a foreign client, where none of the involved speak English, so we had to rely on our partner company to translate and manage the communication between us, and the client. That poses several problems.
First of all, the translations were made by the employees of the company, the developers, receptionists and not by professional translators.
Second, there was no direct contact with the client – except for the requirement gathering, and some later visits to clear up some things -, and that means there were two points where e-mails could get lost, between the client and the partner, and between the partner and us. Plus the usual internal mishaps.
So, what are the most important lessons
You need a professional translator.
Whenever you go to talk with a client you either both talk the same language or you better get a professional translator. Having a co-worker, or a partner who can translate is great, but if the translator has an interest in understanding the problem then it won’t work. In our case we had a guy who also worked on the project partly as a developer/business analyst, and while it may sound good – hey he will understand what we need! – it is not.
When the translator tries to understand the problem and business domain, which would be your task, then he extrapolates, leaves out things he deems unimportant, and generally will just pass on his understanding, not what the client said.
And you have no chance to crosscheck it,you have to trust him. And it’s not a good feeling when a year later you sit down with the client to work out some problems, this time with another translator, and you find out that you implemented the wrong functionality.
Not to mention when you mess up because of a mistake in translation.
What you need, in my experience, is a “tube”, Someone who translates what is said, but does not try to understand it.
Don’t try to save on the translator. It will cost more in the long run.
E-mail is not good enough.
Or at least, it should not be your main communication channel.
It is slow. Especially when you have to send it through someone who will translate it, and vice verse – plus, the previous point applies here too, get someone who does not want to understand the problem, or you’ll never know what the original request was.
And if you use e-mail this way, insist on receiving the original from the client along with the translating party, and that the translated letter contains the original too. You won’t understand it, but you can ask about missing translations.
Hey, we got a letter in Howondalandian, and there is no English mail with the same subject! Did you translate it?
Because it will happen, the translating party forgets an e-mail, and if you are out of the loop, you won’t even realize it. And 5 months later you wonder what functionality is missing according to the client.
Use Google Documents, Zoho, Huddle. It’s a pain to keep all the excel files up to date even in house, but when it travels between different companies it turns into a nightmare. I know, they are going to get hacked, and they will steal the business secrets, but get serious, just for a moment. I bet they spend more on internet security than your company, and I really don’t see why would Google or Zoho steal your project status files. They do it once, and the news will spread on the interwebz faster than wildfire on speed. Not good for business.
Don’t track bugs and issues in an excel either. Set up an issue tracking system. I know that the internet is the unsafe, unprotected wilderness, and if we put anything out there we all will die, at least according to IT, but I think that’s a bit of an exaggeration.
For communications set up a forum, a blog, whatever, but don’t rely on people forwarding e-mails and replying to the right people all the time. You don’t want to send all the little problems and issues to the CEO, but then if six months later you need to, it is a nightmare to find it in the e-mail folder (what was the subject, who sent it, when did he sent it, did I delete it?).
And the same goes for new project members, it’s easier to send them over to a “project blog” than to find the mails, and let him find out how they fit together.
Tighter, more concentrated project management
Due to the distance it is necessary that the project manager concentrates tightly on the client, nudging him to do his part.
Being so far takes the whole project out of sight for the client. He forgets it. Really forgets it, so you have to send him reminders, questions and pester him regularly, and as you do it through a partner, it may or may not arrive to him. Send the not yet translated message to him too, so he can ask if the translation does not arrive in a sensible time.
Plus side for the website is that he will see there is a new, not translated “post”, and knows that’s something is going on.
Visit the client regularly
Simply because when you are not there, they do nothing – they got their daily job, and it will get more attention simply because that’s what they are supposed to do anyway -, and when you finally go there, they will start to look at the already deployed things and will shower you with change requests, about things that could have been noticed a long time ago if they looked at the system.
I know, it’s nothing new, people are telling the same things all over the world, there are books on this topic. I just want to see it work in the Real Life.
In Part II I will write about the next big lesson, the rugby ball and the overcoat.
And now, please, share your opinion on the above. Do you agree? If yes why? If not, why?
- Black hole project lessons – Part I: “It’s a Babelfish”
- Black hole project – Part II: “Rugby ball and overcoat”
- On Trust We Build
Ouch. Lessons learned, in the long, roundabout, drawn-out way!
<hugs> tried to reply the other day, but my work computer fought me … and i forgot to come back.
[...] it connect to a project? The second lesson I personally learned from the project I wrote about in “It’s a Babel Fish”, was the necessity of [...]
[...] conversations with some of my co-workers, and all of these made me think. I have written about how I think communication is important, I have written about how I see teamwork as a really important thing, and last week I’ve [...]