Often, there are crunch situations in a project that need developers to stretch beyond their normal timelines. There is nothing new about it, even developers are mentally prepared for such occurrences. But, such instances, many times bring out the worst in people and can be a threat to team harmony.There are few simple steps that can be taken to mitigate such risks. The most important among these steps is the proper use of the available infrastructure and tools - instead of just falling back to emails for everything.
Photo by Florian Klauer
Founder of famous social media management system Hootsuite - Ryan Holmes - says:
“Email is familiar. It's comfortable. It's easy to use. But it might just be the biggest killer of time and productivity in the office today.”
Consider this scenario - there is a release approaching, issues / features for the release are long known and assigned to developers. But just two days before the release there is a new feature request from clients which is very important for the product. A quick meeting and the request is accepted. On the release day, it is found that the request is not yet complete. Mails start to fly around with status queries and responses. Though it is obvious that if the developer is already on the task, sending mails will only slow him down. On the other hand, sometimes the developer has not updated the status of the task which creates confusion. Whatever may be the case, but such practices waste time and effort at a very important juncture of the project.
Lets see 4 reasons which you should always consider, if ever you are tempted to fire a mail for a project management issue.
Difficult to search Emails are very difficult to search, it almost always happens that you don't remember the keywords or the sender’s name when you need to find the info in that mail. So, while sending mails can give you instant gratification, an illusion that you did something, it is highly probable that any information that you may exchange on mail will get lost. On the other hand, if you use the PM tool, the exchange will be documented and can be easily found out whenever required.
Mails need a context If you want to send a mail regarding an issue, the first you will need to do is set up a context, issue background, current requirement, and so on. You can’t simply mention the problem without any history, the recipient just won’t understand. On the other hand, PM tools have already a trail of information available, it is just required to look up the info.
Information loss Emails are meant for conversation, during the course of time, important information flows around in emails. But due to the short lived nature of conversations, important information often remains trapped in mails. Until someone recollects and puts the information at proper place. While, if the same issue gets discussed on the PM tool / issue management tool it gets documented.
Limited audience Mails reach only to a fixed number of people - the people they are addressed to. This is how emails work, but this brings another set of problems to the project. Take for example when almost many from the team are expected to face an issue, still only few know the solution - it simply makes sense to update the project wiki instead of sending mails around. Another case is when one of your colleagues leaves the company, his mails are no longer accessible to anyone - whole lot of information just