What will KANBAN bring in to your offshore projects?

During last couple of years we have been talking a lot about agile as a whole and specifically about SCRUM, and how that help in offshore project environment to remove most the challenges introduced by the traditional waterfall environment.

While we were talking a lot about agile project concepts, engineering also has evolved a lot to support these concepts such as improved continuous integration and automated test process which eliminate most the problems of multiple team work integration and iterative releases, Cruise control's webpage which really help to get one good picture about all what's happening in multiple sites, New tools such as TFS, VS2010, and some opensource tools are also in high demand nowadays.

So obviously, We are on right track... agile is a way to go in off-shoring..the fact may hurt some of our offshore waterfall folks, but that's how it is.. one can argue that most the agile methods are good for collocated teams due to its concepts such as white board discussions, frequent meetups , open culture, transparency etc. .
After working with large offshore teams in India, Martin Fowler said "working offshore agile feel the pain much more than those using plan-driven approaches. But it's still less pain than the plan-driven methods themselves!" He said it best !

Agile is full of arguments......:-)You know that if you are a member of yahoo "Scrumdevelopment" group ;-). The latest arguments in agile world are mostly based on KANBAN.
If I explain simply, Kanban is a very lean approach to software project development. In SCRUM we said "we cut the waste". In Kanban we cut them big time. We see some agilists moving rapidly in to Kanban, but some are little conscious about the benefit it can bring in. Jeff Patton said in his blog "I'm seeing agile people behave as strangely about Kanban as traditional process folks behaved about Agile." Having said that, lets look at what Kanban will bring to all of us who are in the offshore project context. I will discuss few points here.

1. Scrum is all about time alerts – Kanban is all about event alerts.

In offshore/ distributed team context , the biggest challenge we have is to eliminate the isolation, get team members work closely with the remote teams, still have the onshore team commitment to meet up with the remote teams frequently even when they are distributed. SCRUM comes handy in this as it brings disciplines such as specific sprint planning meeting at the beginning of each sprint, daily scrum meetings (even via remote communication facilities) in every 24 hours, and retrospective after every sprint. So almost all are committed to participate these events.
But Kanban has more of a loosen up approach to it. Simply there is no time box approach, no sprint planning. They fix a limit for WIP stories. Kanban uses push and pull theory, when the WIP items becomes lesser they pull from the backlog and fill the stack.

kanban folks argue..why having daily meetings..? just raise your hand when you feel you are not in sync with your team.. lets meet up.. Why do you have to meet up daily and talk about what you have done yesterday what you will do today like a prayer. ..?
But we know in offshore context, this is not going to workout.. it will lead team mates to think.. ok .. Im having this issue.. but I may ask it later.. who knows whether my onshore mate is busy right now.. may be he is at another meeting.. this guy will pass hours, days…. And there are lots of unspoken issues stack up with the offshore guy to ask the onshore guy when the time is right..
from onshore perspective.. again we are inviting the same old problem.. lets just send him an email..or this guy keeps waiting without asking questions…At last all these tiny issues will become a big issue to the project.
About the retrospective, now we know we need to have a retrospective by end of 10 day sprint or so. But with Kanban, its again an event based thing.. if you see that you had a serious issue when testing, call the team and have a retrospective, why you need to wait till end of 10 days to have it.. hmmm..
However, most Kanban practitioners accept that this doesn't work so well even with collocated teams.. So they are also moving towards having daily meetings to talk about the bottlenecks and what they do today in front of the Kanban story display. Not based on the sprint plan.

2. Comparatively larger user stories.

When it comes to offshore – onshore engagements, requirement understanding is more challenging.. smaller user stories make the requirements more clearer and easier to elaborate upfront. But in the same time, the larger stories also has its own benefits such as easier designing, planning and to keep the product backlog in shape. But I would advise the teams to go for smaller user stories simply because that eliminates many risks in requirements especially with the challenges in distant communication.

3. Do not estimate – or at least pretend you don't estimate :-)

How will it work? Yes it can work in the perfect world. you are going to run 100 m., you have no idea how long you will take to run.. but you will run as fast as you can. In scrum what happens is that .. you run for 10 min and see how long you could run with your maximum speed. It's a time box. Dont raise your eyes.. Projects without estimations happen in real world too. I have an example with one of our current projects at Exilesoft. The team work with this model with a very close work relationship with its onshore team in Norway. It works very well with the trust they have built with our team sitting in Sri Lanka for over an year now. But this needs very capable resources, so much trust on remote teams and lots of commitment from the customer to work with its distributed teams. Without that, this will result major issues and pain in business.

4. Burn-down charts – do we really need them?

Kanban practitioners argue about the velocity used in many other agile methods such as scrum. Velocity measured based on story points burn down rates and sprint deliveries can lead to some conflicting ideas among the stakeholders as well as within the members of the same team. So they say.. Concentrate on cycle time of a story. that's what matters.

How do they do that.. its simple. Its about noting down the entry time of the Story X, and done time of the Story X. this difference will show you the waiting and the production time of a story in the queue. What needs to be done is to reduce this cycle time as the team improves with the technology and skills by removing the bottlenecks.

What I see with burn-down charts is that burn down charts with some meaningful annotations has a real good advantage in remote team environments to communicate the progress of the current work sprint as well as overall as a product how we go with the development. It provides high degree of transparency.

Overall I see Kanban will work well with some of the current maintenance projects we have. Working on a unplanned backlog, limiting WIP number, monitoring cycle time and less focus on estimation will work well with these projects.

However, I see that Kanban together with some scrum and XP disciplines will also be a good combination. Its all about trying out these methods in offshore environment and seen the benefits, drawbacks and improving your offshore-agile practices.

No.. Im not saying that agile is the magic pill which will flush out all the problems in offshore software development. That's what Dave and I are going to discuss at Agile 2o1o on 12^th August (large scale and distributed agile. )
Our topic is simple and straight "Why you suck at off- shoring even with agile " see you guys there and lets have an interesting discussion.

Agile in Offshore- Oslo gathering (Meet-up)

It was on 20th April (Last week) at Scotsman pub, Oslo. I was so happy to be there. It was not a typical business people discussion.. It was all about meeting other agile practitioners who use agile in Outsource/Offshore context and sharing ideas, challenges in such context as an open space discussion ( Though there was no much space as the room got filled in no time). Hosting this meet-up group was a new experience to all of us at Exilesoft

The event started around 5 pm with more or less 25 participants who really experience agile way of working in their day to day offshore projects. The best of all is that there were onshore members dealing with their offshore teams in Romania, Spain, Russia, Ukraine, India and much other offshoring destinations. We were the only offshore company who was there specially to share our ideas from offshore perspectives with onshore practitioners. I think it helped onshore team members to rethink about the issues in a different angle.

Finn, the host of the group started the event by explaining the objective of “ Agile in Offshore” meet up group, and some insights to Exilesoft. I had to play more or less a facilitator/moderator role to keep the discussions going..To have a kick start, I used a real case study to explain why we moved to agile way of working in offshore projects by leaving heavy processes aside.. When finishing 2 slides.., here comes Pizza. It was kind a treat after a long workday as we all were hungry.. :-)


I started the discussions with few prioritized issues we face in offshore projects when using agile, the very first was the challenges when it comes to project initiation with an onshore customer who is not in to agile. In the same time if the onshore customer is in to agile and not the offshore team, how this conversion happens when you are not too sure that other foreign company, it's culture and management structure is ready for agile ..? I soon opened the discussions to the audience as I couldn’t wait anymore standing in front without grabbing a Pizza for myself.. ;-).

That was a cool debate.. When we felt we have discussed a point to an extend, in agreement we moved to the next point.. Likewise we discussed and debated about many concerns from onshore as well as from offshore perspective such as the challenges in highly integrated scrum models, Scrum master role in integrated teams, Isolated scrum team models, Product owner and use of Proxies , how effective is the use of offshore PO proxies, culture issues , language issues when it comes to casual communication, the extend of actual usage of the collaborative tools in such context etc.

It was very nice that 3 other Exile colleagues Buddhima, Shiran and Adipa who were in Oslo also joined the event, they were good contributors to various practical issues we discussed on engineering , and source controlling in distributed environments.

Ofcourse the event was time boxed. :-) In 2 hours we had to end the event, Still we received lots of comments from some of the participants who waited little longer. It was a great experience and there were many requests to continue this group. Currently there are 61 members there, so that now we put our thoughts together on how to progress with the group with some new ideas for the upcoming events.

Offshore Project management - Interview with Dave Prior

Click to play

Offshore project management and use of Agile. – Part 2 – Tiers of Outsourcing

The part 1 of this article has already received industry attention than I have expected. I’ve seen it has been referred in some discussions, forums and even in twitter and FB many times. Now it has been published in ICPM where it meant to be.

This is the 2nd article of the series. In this article I’m going to discuss the tiers of outsourcing.


When you initiate an outsourced project as the outsourcee, or when making the decision to outsource a project as the outsourcer it’s very important to understand which tier of outsourcing you are in to. This will give you some intelligence in advance about these extra issues you may face in outsourced projects compared to collocated projects. I can think of many dimensions of outsourcing when I define the tiers..
But following categorization based on geography – distance and time zones simply help me to understand many common positive and negative risks of such projects in each context.





'Outsourcing is outsourcing' either you outsource the project to your next door software company or to a company in the other side of the globe. Because in either case you need to manage external contracts, requirements, risks, security and knowledge transferring. However as I have shown in this diagram, the challenges in outsource project management increases when we move up in the tires mainly due to the communication issues and secondly due to cultural issues which I will be discussing in some of the future articles.

First, lets look at the bottom tier. The main advantage of outsourcing to a company with less travel distance is that it could facilitate more of face to face discussions whenever required. This will cut off a big portion of distant communication risks. The other point is that having same language speaking people working for you may provide you the luxury of using your native language in business discussions. Mostly the business and personal cultures will not have much difference with both the company professionals who work together for the projects and that will result much quicker relationship building among project teams. However this tier of outsourcing mostly delivers only the benefits described in the 1st and 2nd points which I discussed in the 1st part of this article.

Nearsourcing , the 2nd tier of outsourcing is more commonly seen among Western and Eastern Europe countries. Countries such as Poland, the Czech Republic, Slovakia and Hungary are stabilizing as software outsourcing destinations for Western Europe markets. As I see the software businesses attracts near sourcing mainly due to reducing the risks of cultural difficulties, legalization issues for onsite work and contractual/ financial terms. Further they benefit with minimized time zone differences. But if someone think Nearsorcing is the solution to avoid all the critical risk factors of outsourcing, it’s a big myth. Sometimes I see Nearsourcing bring more communication problems to the table.
Imagine a company in Norway outsource a project to a development company in Greece. I don’t see many Norwegions fluent in Greek or Many Greeks speak Norwegion. Neither parties don’t use English as their main business language. So these two teams trying to use English as a common language for communication can deliver more risks in Nearsouring than a Norwegion team communicate with a team in South East Asia where English is the main business language to do day to day work.
Nearsorcing seems very attractive for some of the industries such as manufacturing. If you look at the cost factor, Nearsorcing can bring you cost saving specially when it comes to manufacturing simply due to less transportation costs of goods. Hefty ocean fuel surcharges are involved when transportation happens from China to USA compared to Nearsorcing operation from Mexico to USA.
However based on available options in the global outsourcing market its still an argument to decide how much benefit Nearsorucing can bring in to software business which is totally different from manufacturing especially with relatively high labor costs of software professionals of Eastern Europe countries compared to most the SEA countries.

The third tier is what I’m experiencing right now with our current business at Exilesoft development in Sri Lanka and customers located in Norway. The same experience I have had for many years with some companies located in Australia, UK, Germany, Greece and New Zealand. Teams falling to this tier may face almost all the challenges in outsource business but still there is overlapping business hours within the same day where distributed teams can use for collaboration.
By looking at most the SEA software engagements with western countries, its proven that If well managed and well modeled, this tier delivers most the benefits of outsourcing business for the outsourcer as well as the outsourcee due to many reasons. The only difference in the top most tier compared to this tier is that, distributed teams in outsourcing business who are falling to the top most tier has no overlapping business time for collaboration. This increases risk of communication and becomes quite difficult to practice some of the agile methods which need closer and casual communication for projects specially the “Daily scrum” in scrum teams. There are alternatives we may use in such context (But not the Scrum mail :) period!!!) which we will be discussing in the future.

I have used Waterfall and Agile management concepts on such outsourcing projects in almost all these tiers. Compared to all the frameworks and models I have used, I find agile management concepts help to reduce the risks of outsourcing software projects drastically if used wisely.

In the 3rd part of this article we will have a closer look at dealing with culture differences in the project management falling to 3rd and 4th tiers of outsourcing and in the 4th part onward we will have a detailed discussion on other common difficulties and risks we face in outsourcing compared to collocated development while discussing how Agile can be used in each case to reduce the risks by taking Scrum as an example.

Offshore project management and use of Agile. – Part 1

Its again Winter in North.. So we are busy here at Exilesoft, Sri Lanka with most the customers who visit us. That's one nice thing in offshore business, as much as we enjoy travelling Europe, it seems our customers have found a second home to come when the winter starts in their countries. This is an ideal time we get to work together again as collocated teams. For them its quite exiting to work with us as well as to extend their business trip for one week or so to have little relax time in this exotic Island, explore the culture and have a better understanding and stronger bonding between the customer and development teams. Altogether it’s an awesome experience for both the parties. I too enjoy such visits of our customers a lot.

In the same time, being in software offshore business is not easy. Unless you have the right relationship between the outsourcer and outsourcee, the offshore business can become really painful to both the parties.Software development itself is quite challenging even in collocated development environment. When it comes to offshore software development, we are adding some more complexities to it, simple reason is that an offshore development team faces the same complexities which an in-house team faces + much more . So the Project management in this environment by balancing this distant relationship is quite a challenging endeavor.

This series of articles which Im writing to ICPM, will be focused on the challenges in such offshore business and how we use Scrum (One of the Agile methods) at my current organization to overcome these mostly seen challenges in Offshore business. I hear you.. It’s a trade off. When we overcome some of the main issues., there will be other issues which we may face.. Its understood. Its all about how to overcome the most serious issues in such environment and deliver the right value to the customer without scraping the organization’s bottom line.

To manage these offshore/outsourced projects with distributed teams successfully, We first need to understand why Organizations outsource their software projects. By working twelve years in this industry I have seen the same reasons with most my customers who decided on outsourcing their projects to us irrespective of the size of their projects.

1. Skilled Resources
In Some of the countries , its quite hard to recruit skilled resources compared to others. May be its all about the availability of such skilled resources, the market competition as well as the difficulty of hiring such experienced resources only for one or two projects (Shorter time period).

2. Business Focus.
Even if they have these resources available to hire, if the organization’s main focus is not the IT business, it may not be always wiser to hire such resources and expand the IT departments which is not their primary business focus. As an example, a company in travel industry needs to be focused on travel business instead being focused on expanding its software development. So in this context, outsourcing its software development to an organization which focuses on software business can be a wiser move.

3. Protecting the Intellectual Capital
If an organization develop one of its core software products which will give them their competitive edge in the market, the last thing this organization may need is to have its developers who worked on this product to join its competitors with all the knowledge about the business. Some times when an organization hire people from the same country or state, there is quite a risk factor that the developers who work for this product may join their competitors when the assignment is over. But outsourcing this product to a country far away which doesn’t have such closer relationship with the other organizations in the same market may reduce the risk factor.

4. Cost
Most the organizations carry their cost benefit analysis before outsourcing its software projects to other companies. Its quite important that the cost difference to be a visible factor. However there is hidden costs in software outsourcing which I will discuss in a latter article under this series.

5. Round the clock / Extended hours of production
As an Example, if there are 2 distributed teams in an Organization in Norway and Sri Lanka, and if both team work their 8 working hours, the total production time expands to 12 hours as Norway is 4 hours behind Sri Lanka. This helps in some of the product development and software support work.

Its important that as the outsourcee we understand the key factors which enable the outsourcing business of the customer and deliver the expectations throughout development.

In the next part of the article, I will discuss the tiers of such software outsourcing and how the challenges increases in each tier. >>

P2P Conference 2009 - Agile Stream.

Monday :
Most the speakers who reached Cairo before the conference had a visit to Giza Pyramids and the museum on Monday which was quite fascinating , specially to get to know each other as some of us have never met before and in the same time to explore Cairo, History etc. We all had lots of fun together. What I mostly enjoyed was the camel ride !




Picture : Me and Giza Pyramids


When we reached the hotel it was bit late, Before I went to the room, I met Dave Prior (Immediate past chair of PMI IT & Telecom Sig), It was so exiting to see him as we have been knowing each other through articles , blogs and emails for quite a time. He was amazing.
At night Emad ( the host of P2P and the CEO of Brisk Consulting wanted to meet all the speakers in order to give an overview of the conference. Except me all the others were from eitther USA or Canada. After the meeting , others proceeded to the Dinner but I was tired and full with late lunch so I went to bed.



Tuesday
The conference started officially on 3rd Tuesday with Keynote speeches by some of the ministers of Egypt Government and some industry experts. It was quite interesting to see how Egypt government has understood the importance of proper project management expertise in the region. The afternoon sessions were more focused on PMOs and Maturity of PMOs in General.
There we met Ricardo Viana Vargas (PMI Board of Directors Chair) Dave introduced me to him and gave him a reminder about one of my articles which they have referred before with regard to Agile and PMBOK. Jesse who was with us didn’t forget to tease me about the PMI April issue and me being the cover girl ( oh I'm blushed ) in front of him. And we had a little chat. I was so impressed to hear how open he is to Agile and Scrum while heading PMI, It was very impressive. I thought to bring this up in the Colombo chapter discussion next time.
Dave proposed that we should grab a coffee and do a practice run of my first presentation with himself and Jim as I was little nervous about the presentations among all the very experienced speakers.. But they were quite happy with the practice run so their comments gave me lots of confidence before presenting to the audience.
Dave gave me more info on Transition of the PM in Agile which he thought would be the questions from the Audience.

We started the Scrum sessions by 4th November. This segment was conducted by James Cundiff- Jim( Managing Director Scrum Alliance, Dave Prior, Jesse Fewell, Bob Tarne and me. It was an amazing experience to work with such people and we were a great Cross functional Scrum team. we conducted most the sessions with some discussions ,questions and answers.







The Amazing thing in this sessions were that, we , speakers had arguments about certain concepts openly in front of the audience. It was never a stiff speeches we see in normal conferences. As a team we turned it around. As a team we made it very agile , open and direct. Jim mentioned his opinion on daily scrum which Dave and Myself disagreed openly, Jesse had a conflicting idea about initiating an organization with Scrum against my opinion. We all had certain arguments on how to position a PM in this transition .. Very upfront.. This was amazing and most the audience gave lots of encouraging comments about the way we handled it . There you go....They got the idea of Scrum not being a very prescriptive method.. In RUP you never argue on how to write a use case or a PFD.. So that was an eye opening for the audience. Thanks Jim for starting this conversations.

Jim and Dave opened the session by explaining the basics of scrum. they got some volunteers from the audience to play a game for the attendees to understand the effectiveness of initial one time planning Vs Iterative planning. Then the next session was mine. I had to present the Organizations moving from waterfall to Agile , the challenges they may face in this transition. I touched main areas in the presentation such as Why Moving to Agile, (there I had a great story to convince the audience with real pictures to support the story)Which Agile methods to be selected , In Which layer of the Organization to be aproached first, (there I explained the core cultures of organistions and how to spot the right layer based on the specific culture ) then the most important part, how to handle the people in this transition, such as customer, Technical staff, Management and specially the project manager. Phew !!! You know what.. I got a blue screen.. Why MEEEEE!!!!!!!!!!!! But somehow I managed to not to click "my Panic button". so all were ok and I got some good comments about the presentation.
lessons Leaned : Have story cards in your hand , when ever you go to a presentation.. If your computer make troubles, still you can continue without an issue.

After the coffee break, Dave presented about "Reluctant Agilest" quite an interesting presentation about a story how painful agile can be when not embraced in right way.
There after, Jesse took over and he explained "Agile PMO" how agile a PMO could be. Very informative presentation on that aspect and he showed his maturity in managing PMO through out the presentation with live examples.
Then the Audience was lesser for the second session after the lunch break and Bobs presentation was to address the knowledge management for Agile projects. Im sure which has been a very interesting presentation , But I missed it as I went out of the room to get ready for my next presentation on the same day which is Outsourced Project management and challenges in Agile.
I think that was the best presentation I ever made in my life. It all came from my heart as this is what I have been doing for past 12 years. I discussed about outsourcing issues openly in 5 key areas and how we have used Agile to overcome these issues in my current company. Which was the presentation that I have got most the positive feedback so far. ( Most the delegates commented to me at the next day coffee break that they have never known Sri Lanka as such a software offshore destination.. Hmm I was happy..)We closed the day with my presentation.

We had an awesome night that day .. With all the speakers and some of the other people , we had lots of fun. The night was too long .. Me and Jesse who had to take the next day morning sessions were half dead when we reached the hotel around early morning the next day.

3rd day started with Jesse’s presentation on Agile vs PMBOK, which audience had many questions which they needed to clarify. Again I missed most the parts of this presentation as next I had to present my last presentation on Effective communication in Agile. I explained the difference between agile communication and the traditional project communication. In the same time I got some real project examples to show how Agile communication can go wrong with such informal methods. According the audience they had a good presentation from me.. But to be honest I think I was not with my full energy for this presentation compared to others. The next session was a very interesting one by Bob about the user stories and the last session was by Jesse about the Agile contracts. There he explained how fix price works in Agile contracts which is the case in most the real world projects. Interesting !!!

We had the round table discussion afterwards, all 5 of us together.. it was very nice...

Picture : closing dicussion by all the Agile speakers (from left to righit ) Jesse Fewell, PMP, CST, Dave Prior (CST, PMP, Immediate past chair of PMI IT & Telecom Sig ), me, Bob Tarne PMP and James Cundiff( Managing Director Scrum Alliance )

At night some of the speakers went for a dinner in Nile cruise while me , Dave, Jim, Andrew and Bob conducted a retrospective about the Agile stream of the conference. It was time well spent.
After the retrospective again we had a late night.. Not that late as previous night as Jim had to catch his flight back home , Emad and Nora (the hosts ) invited us to taste a real Egyptian Dinner at a real nice exotic Egyptian restaurant.. It was really a nice experience..
After that we said Good bye to each other.. It was such a sad thing to leave such wonderful people whom we worked together for few days as a team.
My flight is today evening.. Only Dave and myself were left in the hotel with the hosts as all the other speakers have left. We both had a small breakfast meeting at Marriot to discuss what we can do in the future together, specialy my interest to become a CST and upcomming PM conference in colombo which will be really good.

Project Communication in Outsourced Project Management

We all know that, in average a project manager spend more or less 90% of his or her project management time for communication. Proper and effective communication is one of the most challenging areas in project management.. How about communication in outsourced project management..? that is any PM’s nightmare unless they manage it properly from day one.
This issue is not about language, either you do nearsoursing or outsourcing, nowadays most the professionals will speak good English. But poorly managed remote communication may increase the risk of project failures drastically. All aspects of remote communication should be carefully quality managed by a project manager who is in to outsourced project management. Unfortunately this needs quite lot of experience.
Over the years I’ve seen most the PM methodologies have matured, and processes has been introduced for project management.. New tools have come to the market., but still the challenge of remote communication remains the same.. How do we overcome it ?
Recently I had a chat with one of my project managers. He told me a story about a project he has managed while working in his previous company. It’s a very small sized project developed for one of the European countries. So him being the project manager sitting in the development company in Sri Lanka has communicated with customer via 600 emails. It gave me a fright.. Are we really doing something right here?
Have you heard about “Mad email Syndrome” which is very common in outsourcing operation. These are the symptoms;.
Project Manger from Venders company writes a mail to the customer about his questions regarding some requirement.. A nice email. Customer reads the mail., thinking why these people can’t even guess some simple thing like that …then he writes a reply in Blue color as comments for each question. ( yes we need to clearly separate the answer from the question)
Now that the Vendor's project manager who waited impatiently till he get all the answers to his questions receives the mail and he goes through the blue color comments made by the customer.. after reading that he find its disapointing and the customer has not answered half the things as he expected., most the points are not elaborated., so it creates much more questions for him now. Then what he does.. ? he uses another color., mostly seen is green , write comments in green color again under each blue color comments.. send this to the customer and CC to his whole hierarchy to save his back :-) and show them that he has still not got the answers right.
Customer receives the long email which is flashing in many color comments now.. He get really worked up.. certain symbols can give him a totally a different tone to the email. He write the comments in red color now.. and send it to the vendors PM again..

This doesn’t stop here… Is this situation new to you ? Im sure if you are in to outsourcing business you may have gone through this situation many times. This chain of email communication is a very strong risk trigger of project and relationship failure between outsourcer and outsourcee.. Why such a useful tool such as email can create this much of damage?
1. When communicating through emails , the other party doesn’t see your body language. They read exactly the meaning of word to word which may sound totally different to what you meant.
2. The other party don’t hear your tone of the voice. or your giggling . Recently I saw a customer commenting something like “Remove this field! “ with “!” what is that additional “!” is for ? these may create some unnecessary issues
3. Its very common that both parties think the other party is the idiot. They put less effort to understand each other. This may totally be different if you had a face to face discussion.

So how do you quality manage this remote communication? My advice for project managers are as follows;

1. Do not have email communication over 2 loops., if it goes over always try to use Voice via skype or telephone line. Or even use some tools such as Webex. Which is really good.(video con would be the best but unfortunately most of us do not have that facility )… Hmm How about Cisco TelePresence.???. I love to experience that !! :-)
2. Always read and re read your emails before sending.. do they mean something wrong to the reader.. make sure you communicate very clearly
3. Do not send too many emails. Try to summarize possible information in one email. Have your subject lines very clear.
4. If you need only 1 question mark have one .. But not three.. When you ask “can I have these replies by before end of business today? “ has a major difference between “can I have these replied before end of business today???????????”
5. Be very clear and elaborate on required points.. try to use tables as much as possible
6. Be warned when communication is not going right.. always ask help from your supervisors before it becomes too late.
7. Have the right attitude to respect the other party . if you read the mail in negative mind., you will end up with negative results.
8. Send customer status reports frequently., leave very little room for questions. Reports should be completed.
9. Always have project budgets to meet the customer face to face at least once in your project life. That will make your project communication much easier.
10. Understand that the time customer can spend for you is limited. That’s one reason why he or she outsource the project to you. Respect the fact and always think twice before you raising the question .Because you need to get the question right at the first time .