I have seen co-located teams has been proven the best for overall success of project. Colleagues just sit all together, everything runs just fastly within the same environmental, cultural, geographical and professional conditions. Over 90% of the communication pass by non-verbal channels, which includes approximately 60% by body language and 30% by tone of verbal or written communication. Co-located team has an advantage to read that 90% part of communication as well very easily.
With the growth of internet, globe has become much smaller. Business has grown far beyond the geographical limits. Now a days, when we talk about IT projects, next word come out on discussion is outsourcing, and many of those are being developed cross nations having USA-India combination on the top of such nations list. Team members are distributed at different such locations to coordinate for a common goal - the successful completion of project. Such teams deployed at different locations are better known as virtual teams. Now, communication between virtual teams has become significant factor for smooth execution of the project. I always ask a question to several forums on virtual teams, "How to read body language of members from virtual teams?" (Note: Body language provides 60% of the total communication). This is not easy to implement to cover this gap in communication between virtual teams.
Based upon my experience while working with virtual teams for many years now on all the roles from a developer, tester to lead and project manager I have learnt onsite-offshore communication is very difficult to handle without ground rules, and by having such rules in place onsite-offshore communication becomes much better than co-located teams. I'll publish separate article on "Pros and Cons of co-located team".
In this article, I'll just list down the headlines with short description of the ground rules that I always prefer to set in my teams and follow. Later, I'll definitely write detailed description for each one to explain all these:
With the growth of internet, globe has become much smaller. Business has grown far beyond the geographical limits. Now a days, when we talk about IT projects, next word come out on discussion is outsourcing, and many of those are being developed cross nations having USA-India combination on the top of such nations list. Team members are distributed at different such locations to coordinate for a common goal - the successful completion of project. Such teams deployed at different locations are better known as virtual teams. Now, communication between virtual teams has become significant factor for smooth execution of the project. I always ask a question to several forums on virtual teams, "How to read body language of members from virtual teams?" (Note: Body language provides 60% of the total communication). This is not easy to implement to cover this gap in communication between virtual teams.
Based upon my experience while working with virtual teams for many years now on all the roles from a developer, tester to lead and project manager I have learnt onsite-offshore communication is very difficult to handle without ground rules, and by having such rules in place onsite-offshore communication becomes much better than co-located teams. I'll publish separate article on "Pros and Cons of co-located team".
In this article, I'll just list down the headlines with short description of the ground rules that I always prefer to set in my teams and follow. Later, I'll definitely write detailed description for each one to explain all these:
- Have every team member to write a note on their desk that what is our main goal to achieve in the project that we are working on? Make sure that's easily visible too.
- Modes and Frequency of communications - Daily/Weekly reports by email, Status calls on Phone/VoIP, Daily workload/task allocation etc.
- Set a protocol of response - Every communication should be responded even with the shortest word like 'OK', until the thread is actually/formally closed. Even 'FYI' messages should also be responded with 'Thanks'. (Consider communication in Army personnel, call doesn't end until 'over and out' is said by officer.)
- Clearly identify actors and roles - Product owner, Project Manager/Scrum Master, Team Lead, Developers, Testers, Client representative, Who'll approve/accept the delivery etc.
- Information flow of communications/reports etc. - Email, Phone call, Who'll send to whom? Daily/Weekly etc.
- Who will distribute what information, and to whom, and in what frequency? - It appears to be clear in itself, I'll publish more on this soon.
- Velocity and Burndown charts of routine activities, with priority and challenges/risks. - How much of the work was done today/this week/10 days/month? How much of the work is pending? Any challenge, problem or roadblock to meet next deadline etc.?
- Define template and formats for every communication to circulate - That includes all the reports, charts and status metrices etc.
- Share your agenda with all the invitees at the time of scheduling the call/meeting, and give enough time to them for preparing before the meeting to avoid time wastage in the conference room/bridge. Also, fix the time slot for the meeting, and stick to that time limit. Don't discuss anything other than your agenda. Mark all discussion items with the conclusion/action items.
- Workload with every team member for the given and next days. - Create a rule in team members to shout when the are, or going to be free in next 8-16 hours time (or in whatever time limit you can define in your workflow). This helps delivery owner to assign them next tasks before they get free.
- Keep daily lessons learnt captured in your file - You should always avoid mistakes to occur again in your path, and such file can also help other project teams in your organization.
- Keep team PTOs calendar in place to help you plan your delivery for the given time period. Always have at least 10% time buffer in your plans to mitigate unknown risks.
- Remember 80/20 rule, and always have risk register on the top of your desk, and keep visiting it frequently.
I don't say, above rules can evaporate all the communication problems in your project virtual teams, but they can at least give common directions to all your colleagues working, and can also help in more sorts to formalize your work culture. Once discipline is there, productivity will improve automatically. Remember, reading body language of virtual teams' members is still not solved by these ground rules, but there are a lot of other cover ups in this framework to automate the communication flow.
In case you can share your lessons learnt with virtual teams model, and your best experience, please contribute in comments to help others to improve.
