“But it was in my email!” she exclaimed.
We caught each others’ eyes. Everyone seems to be in agreement not to acknowledge that last sentence, and quickly brought up other issues in order to change the topic.
Because we never, ever, read her emails. Or at least those of which she calls her “comprehensive status update.” We have all admitted it in different circumstances.
We knew we should. She was, after all, one of our project managers. And status updates are something that proponents like us depend on.
And we do try. But whenever we do, our eyes start glazing over, and we spend more time trying to understand the email rather than taking the necessary action.
First, the email in question had at least 50 recipients. Even those who are just remotely connected to the project were included. It came as no surprise that almost everyone assumed it was merely an FYI and immediately archived it.
The emails were long, unrelenting, full of jargons, and code words. They also contained a huge chunk of insignificant data – project overviews that are copied from one status update to the other, and items that are not concerned with technical development (she is a technical project manager).
There was one email where I was shocked to discover very critical action points buried in the middle. There were too many unnecessary headings and multi-colored fonts brightening up almost every section.
It gets worse: The email was entirely formatted using tables, with a multitude of merged and split columns. It was like someone tried very hard to Exel-cize the entire email.
The primary problem of her status update email is that it only served the purpose that she was able to send one. This is a common mistake of project managers — forgetting the reason for releasing a document, whether electronic or otherwise.
Documentation does not exist for the sake of existing. It needs to communicate, and must be formatted, or re-formatted, to the desired audience or environment so as to fulfill that purpose.
When I worked in a software development company, I had to do the IEEE standards for business requirements & functional specs, because that is how the engineers are used to reading them.
However, when I joined the advertising industry, any Word document I released goes unread — until I started doing them in Keynote.
Documenting for the sake of documenting is selfish. Our documents are for an audience, and must be delivered in the way that our audience will understand.
Leave a Reply