Menu
Emails are so easy to use and so often used that we never think about them again. This article will introduce 3 dangers inherent to emails: immediacy, room for interpretation, crucial information storage.
We will present solutions to reducing these risks: delaying all sent emails, a safe email protocol agreement, thread management. This article is the part #2 of a series. The previous article in this series is available there: Keys to avoiding conflicts in an offshore software development project – Part 1.
Do you remember that email you sent fast because you were upset, angry or simply in a big rush? You know? …the one that came back in your mailbox with a big nightmare attached to it!… Well, it happened to us all and is likely to happen again. It would be nice to avoid the next one, though.
In a cross-cultural configuration like in an offshore software development project, the risks are much higher: a word badly interpreted, a tone misread, a joke not universally funny, etc. The problem is even worse as most of us are not even aware of the risk. We all believe that humans are humans and that we basically exchange the same way by emails. No, humans are not all identical and they certainly do not read emails with the same eye as yours. Interpretation is everything; we will see that in the next article of this series.
And what about that other email containing the new agreed deadline? It was …when you were talking about how to recruit a Graphic Designer. This quote must be somewhere, correct? Unfortunate that the last 3 search you made did not show what you were looking for!
When teams are remote from each other they make a great use of emails. That is natural as it is fast, reliable and as we have seen in part #1 of this series: asynchronous. The experience shows that one difficulty is to keep track of the threads and conversations exchanged. Emails contain various level of information, but it is very common to contain crucial information about the project, even if you do not want it. This goes from a precision on a requirement to a re-definition of a dead line or information about who is in charge of what. All in all, you may very well have a great software tool for your project management; it is very likely that your email will be a mine of information anyway, even against your will.
Let’s see how to achieve these 3 goals.
This will sound surprising but what we are now about to suggest is to do later what you could be doing now! In fact, have your mailer do later what it could be doing now. In short: put a delay in all the emails you send!
If your mailer allows it, automation is definitely the best option, but it can be done manually. Basically, you consider that every email is a time bomb. As such it can be defuse, but you need a couple of minutes to do so. Therefore you setup your outgoing email to always wait a few minutes before actually sending the message. I personally delay each email by 3 minutes. Outlook 2010 allows you to do that with a simple rule.
When you press the send button, your brain starts thinking about the consequences of your act. Then, you may realize how foolish or pointless your email was. And great news: you have time to change the course of events! You go back to your outbox, re-open the silly mail and modify or delete at will. You are not doomed anymore!
Some might wonder why we need to do that for all emails since most of them are innocent anyway. The answer is double:
What you can do for the real urgent answers is the following: add a code inside your email to tell the mailer that this one is an exception. I personally use the code [u] for “urgent”. You can place it anywhere and as small as you wish. The mailer will read it and act immediately. Problem sorted: the urgency is the exception, just like in real life.
This problem is a tricky one because it is for part inherent to the written nature of the email. Saying that, an email is also a tool and is used in a very special way within a software development project. Unlike a bigger document like Requirements or a Vision, emails are often shorter with one or at most a handful of points in them. They are mostly formatted informally.
Here is a protocol that can save you from the agro of a misinterpreted email:
Because emails are quite informal, people tend to just add anything that comes to mind into every email they are about to send. If this is convenient on the spot, it is a total nightmare later on. You can easily end-up asking someone to send you something you know you already have. And when you get yourself that type of message, you always wonder what on earth the other is doing with the info you send. Do they care? So, if you do not want to upset your correspondent anymore you’d rather put in place the following technique. A great discipline to have is to always create and maintain topic-threads with crystal clear titles. Here are the rules of the game:
Of course, you probably have a few tricks of your own. The points above are very easy to setup. They do not require any new tool or any training. They do not add any burden on your work. They are great time savers though!
At the beginning, our experience shows that people are reluctant to apply these rules. But they do not deserve any complain in terms of time burden. I know for a fact that they just save time and add to the quality of your project.
Although emails are part of our daily life, they can present some traps of their own, especially with the context of an Offshore Software Development Project. By following simple rules like delaying, safe email protocol agreement and Thread Management, one can make email much more friendly and reduce the risks inherent to their use.
An offshore software development project, by nature requires different countries, i.e. different cultures to collaborate. This requires some setup to work smoothly. This is what we will be covering in our next article.
Liemur provides Software Development Services within UK and with its nearshore branch in Budapest.
If you like this article, what about tweeting it or recommending it?