In project management world, here is typically how communication about tasks takes place.

A team member completes a task assigned to her, and then makes an additional and distinct effort to communicate that she is done with it. She can do so by email, updating a project management tool or by simply shouting out loud in the team hall.

While the shouting-out-loud may not be fun, what is worse is that she can potentially skip the shouting (or sending the email).

The stage of working on the task assigned to her, and her communication about its completion, are treated as two completely independent and distinct items. The communication requires proactive and explicit effort – sometimes very much an after-thought event!

This has the obvious failing of missing out on the communication part. After all, it’s the task that is more important, right? And you are doing a favor by additionally letting others know about it.

So imagine the day when she forgets to shout out in the hall that she is done. While you may not miss the shouting, you will certainly miss out on the communication. You would never know that you can now start something which was based on she being done. Even more, she may be wondering why you are not starting what you were supposed to. After all, she is done!

Interesting!

The problem is that communicating about something we are responsible for has always been kept separate – and worst even secondary and less important – than the actual work being done. Project managers consider it their responsibility going around actively asking for statuses. Team members consider updating the project management tool an unnecessary chore – better left for end of the day or when pounded on by the project manager. Software programmers simply ‘check-in’ their completed code but don’t intimate others they are done. And the list goes on.

This has the obvious failings of everybody in the team being at different levels of understandings. You may be waiting for something which is already done – which is obviously a productivity loss. There may be duplication of effort. There can be chaos and confusion. There can be a lot of shouting – but all for the wrong reason.

Common sense, right? We all know these problems. Unfortunately, this is how we fix it. We motivate more active communication. We keep enforcing it as a distinct post-work activity.

We need to merge the ‘working’ and ‘communicating’ parts.

Communicating to relevant people about what you are doing needs to be part of the task itself – not separate from it. The task is not done until it is completed and communicated to whomever it needs to be communicated to. It is not a post-activity, afterthought or favor. It is the final step of what you are doing.

Updating your project tracking tool needs be part of the work – not separate from it. Sending an email intimation should be done before you can say you are done. Telling your fellow programmers that you have checked in the code, and they can proceed, is part of your work – not a bonus item you add.

There is no such thing as no communication – you are always communicating. If you are not shouting out in the hall – all you are saying is that you are not done!