All of Kubernetes’ work involves virtual teams and these are virtual both in the organisational sense i.e. drawn from across the clients’ operation and in the physical sense i.e. in many locations. This means that, by default, we have gained a lot of experience in managing projects “remotely”.
A couple of recent experiences have shown us how much we have learnt without actually realising it! Without going into details this includes:-
- Communicate continuously and clearly. Do not assume that everyone that needs to know has heard you or read the email / text / website. Even if they have heard you, they may not have the same understanding! Our rule of thumb is that if you think (as a project manager) you are communicating too much you are probably only just doing enough!!
- Use technology appropriately. Email, discussion forums, text, voice and video conferencing can all make communication easier and quicker. They can also get in the way of effective communication e.g. an email discussion of a key requirement can take a long time and cause friction when diplomacy is needed. In general we use:-
- Voice conferencing for status updates and general project management discussions (i.e. who is doing what by when). It can also be used for closed discussions. It can’t be used for brainstorming and open discussions
- Web based project libraries for having a single depositary for all project documentation with version control. This is essential to make sure that all excuses are removed for not being up to date! At the moment we are trialling Project Spaces which seems to be very good, if a little North American biased as these things tend to be.
- Email for confirmation of telephone conversations, meeting arrangements etc i.e. anything that is transient with a short half life of relevance.
- Face to Face communication for anything where an “open” conversation is needed e.g. requirements brainstorming and prioritisation. I often have complaints that getting all the right people in a room is expensive and time consuming, however in my experience NOT getting the right people in a room (and facilitating them properly) is a recipe for delay and waste.
- Both the day job and project work have to be done. This means respecting the fact that individuals are rarely measured or rewarded on their project work, but on their “day job”. However it also means removing “business as usual” as an excuse for people failing to deliver their project tasks. Speak it quietly; it is rare that a “day job”, if properly prioritised, actually takes up all a person’s working time.
- Be as transparent as possible. With a remote team in either sense of the word there is always the temptation / possibility for cliques and pools of information that get dammed up. This is nearly always corrosive. As far as possible, let everyone on the project team know everything, not only does it enable systemic issues to be spotted earlier it also makes people feel included and respected, a vital foundation for building a high performing team.
This is not an exhaustive list but we have found that applying these principles helps projects delivered by virtual teams perform better.
One of the next things we will be trying is video conferencing to see whether this bridges the open discussion gap where they only be done by face to face currently