Resolving Language Barrier on Project
I would like to share one problem which was faced by me in one of my international project. The project was launched to design a application for one international client. I was designated as project manager of this project. The coordinator/ project facilitator at client side was very poor in English. We received first document by mail. We were trying to understand this deeply but unfortunately, the English written was not at all linking the clear requirements. But we were asked to start the project.
As a project manager, I mentioned the Language barrier in my Risk register. But due to some business requirement, it was not shared with the client. The project started based on the RFP received from customer. The team started working, plans were base lined and we were following rapid spiral model of development. We used to develop something and send to client for verification. We were also getting the good response from their side.
The project was proceeding in a normal manner and there was no much schedule or effort variance. These matrices were well within the limits. We were proceeding very happily considering that we have done a great job as we have saved lot of money by avoiding the travel to client site. The system was about to complete and we were thinking to celebrate the success. But one day a mail from customer came a bomb shell on our head. He pointed out that the system GUI, Display etc are same, but the result displayed is not accurate. Probably the formulae applied are not accurate. We have done some mistake in application for formulae. Our all test cases were designed on that consideration. All designs were designed under that consideration.
The we took out the documents supplied by the customer. We found that the formulae applied by us are in same way as explained in document. There were series of mails to find out the root cause. Finally it was decided that a trip should be there at client site to find the reason. Myself and one more person visited at client site and there were series of discussions. Interpreter was used to discuss the issues. One day in one meeting, when the coordinating person was explaining something on the projector, she took the material on his language and used tool to translate the same. The results were not as we were expecting or whatever he wanted to say. I was astonished. I asked him whether he used same system to translate RFP as well. The answer was yes and we found out the reason for the same.
The tool translation done using the designated tool created problem and the formulae were made something different. Not only that even our understanding to that system was also changed when we discussed in detail. With heavy heart we came back. Started again. Though the extra cost was borne by the customer, but this incident left a good learning for us. I noted following point in bold in my lesson learnt document.
1. The language barrier must be addressed well in advance.
2. The method of countering the barrier must be made available before project starts.
3. The RFP should be questioned whether, this is written in English or tool translated.
4. Since the development model was rapid spiral, we should have questioned about the correctness of data also, because the customer thought that we just want approval on GUI etc.
therefore, please note that LANGUAGE BARRIER Must be addressed well in advance and nicely. The counter measures must be written in project plans.
It is advised to enrol a person in the project who knows that foreign language well.
I hope this happening is good learning for all of us.
As a project manager, I mentioned the Language barrier in my Risk register. But due to some business requirement, it was not shared with the client. The project started based on the RFP received from customer. The team started working, plans were base lined and we were following rapid spiral model of development. We used to develop something and send to client for verification. We were also getting the good response from their side.
The project was proceeding in a normal manner and there was no much schedule or effort variance. These matrices were well within the limits. We were proceeding very happily considering that we have done a great job as we have saved lot of money by avoiding the travel to client site. The system was about to complete and we were thinking to celebrate the success. But one day a mail from customer came a bomb shell on our head. He pointed out that the system GUI, Display etc are same, but the result displayed is not accurate. Probably the formulae applied are not accurate. We have done some mistake in application for formulae. Our all test cases were designed on that consideration. All designs were designed under that consideration.
The we took out the documents supplied by the customer. We found that the formulae applied by us are in same way as explained in document. There were series of mails to find out the root cause. Finally it was decided that a trip should be there at client site to find the reason. Myself and one more person visited at client site and there were series of discussions. Interpreter was used to discuss the issues. One day in one meeting, when the coordinating person was explaining something on the projector, she took the material on his language and used tool to translate the same. The results were not as we were expecting or whatever he wanted to say. I was astonished. I asked him whether he used same system to translate RFP as well. The answer was yes and we found out the reason for the same.
The tool translation done using the designated tool created problem and the formulae were made something different. Not only that even our understanding to that system was also changed when we discussed in detail. With heavy heart we came back. Started again. Though the extra cost was borne by the customer, but this incident left a good learning for us. I noted following point in bold in my lesson learnt document.
1. The language barrier must be addressed well in advance.
2. The method of countering the barrier must be made available before project starts.
3. The RFP should be questioned whether, this is written in English or tool translated.
4. Since the development model was rapid spiral, we should have questioned about the correctness of data also, because the customer thought that we just want approval on GUI etc.
therefore, please note that LANGUAGE BARRIER Must be addressed well in advance and nicely. The counter measures must be written in project plans.
It is advised to enrol a person in the project who knows that foreign language well.
I hope this happening is good learning for all of us.
Comments
Post a Comment