You are here: Home Articles Documents are useless
OpenID Log in


Documents are useless

by Martin Aspeli last modified Jun 29, 2009 11:12 PM

In search of something better

In my line of work, I come into contact with a lot of documents. Many a project involves a period of research and analysis, the development of insights and ideas, and the delivery of a document - usually either a Word document or a PowerPoint deck that's meant for reading rather than presenting.

A lot of work goes into these types of deliverables. A well crafted PowerPoint deliverable can be incredibly effective. I'm not talking about using the out of the box templates and putting in a few bullet points here: storyboarding techniques, graphics and illustrations can be put to great use to bring a point across.

It's just such a pity that it's all lost so quickly. Not all documents are, of course. Those that are developed for a specific purpose, e.g. to be reviewed and endorsed in a scheduled meeting, tend to work well. They have a specfic audience, are narrow in scope, and their utility is time limited. But so many reports fall into the category of documents that are full of useful insight, but end up collecting dust on someone's desk/shared drive/document management system.

The reasons are all too familiar, and yet I think people - especially the people tasked with producing these documents - all too often forget reality:

  • Most documents end up at 20 pages or more. Corporate standards for prefixes, tables of content and so on don't help. Anything that's 20 pages long ends up taking a long time to read. It's hard to keep it all in your head at once, especially if you've got other things to do, which is almost always going to be the case. Executive summaries and conclusions notwithstanding - the document ends up cannibalising its own allocation of the reader's attention span.
  • Most documents end up going to a limited audience. That audience is probably busy with lots of other things. They read it. They file it. Life goes on. Some organisations send around emails (sometimes automated) about newly completed reports etc. But no-one reads those emails, let alone the documents they link to.
  • A document that's dozens of pages long and written by one or two people is very hard for someone else to take over and evolve. A document that's completed one month and is to be used three months later is probably going to need some review and revision. All too often, that task is gargantuan. The person doing the updating needs to read the whole thing - often several times - identify changes, and proof read again. It's a task that's often measured in hours, not minutes. Most people don't even start.

The end result is that a large portion of the insight (in a brazenly made up statistic, let's say 50-80%) that may be contained in a document deliverable is forgotten and lost. It starts decaying as soon as words hit the page, and that decay is not stemmed until someone re-discovers or re-invents the same insight.

What can be done? Unfortunately, the answers are both boring and challenging, especially for an outsider trying to deliver a defined, time-limited piece of work.

Most importantly, the receiving organisation needs to be sufficiently mature in their processes to be able to receive and manage the deliverable. It's no good if the person producing the document has to invent a new way to disseminate the information each time. Of course, they often don't have a choice. But smart organisations will formalise a way to share knowledge.

People are best able to receive information if they do so as part of a predictable, repeatable process where they expect to be receiving and processing information. Ad-hoc emails are probably the worst approach. Ad-hoc meetings a little better. Ideally, the organisation should have a standard way to share information, both informally and formally.

One thing that works well is to have a weekly "brown bag" session (e.g. at breakfast or lunch) where every week something "interesting" is presented. This not only gives people a chance to share knowledge and learn, but it offers a slot for new or recently completed initiatives to showcase their results. The sessions should be open to all. The schedule can be based on a wiki or something similar, where anyone can sign up to present something. There also needs to be a moderator who both encourages interesting presentations and handles scheduling around initiatives that need to use the session to deliver something a bit more formal.

Such learn-and-share sessions are great for getting the headlines out. They need to be followed up with hard documents, and there needs to be a well-defined, predictable place to find this information. Such documents should be:

  • Visual - offer the slides used in the learn-and-share session as a prompt. Try to create no more than 5-6 slides for an hour-long session and put no more than one or two sentences on each. Diagrams and visual aids work much better. The slides are a way to generate discussion and lead into demonstrations, not a place to capture all knowledge.
  • Short - back the slides up with a written document, either a longer, more text-focused slide deck (the kind that's meant to be printed and read, not presented) or a text document. Cut out all the fluff and try to keep it to three pages (for a document) or 10 slides (for a presentation) .

In some cases, you may need yet another document that contains detailed analysis. This is mostly just for the audit trail, in case anyone questions the insights in the main deliverable. Don't make the mistake of justifying and qualifying every little detail in the "end user focused" deliverables - it just detracts from the readability and "evolvability" of the document itself. Deleagte this information to an appendix or a separate document if it's really required.

But in general, prevention is the best cure. Avoid the temptation to write three long documents when one short one will do. Work with the people who need to know the information from the beginning. The document they get at the end should be a confirmation of what they've already seen and heard, not a dump of information. Use visual aids like mind maps, rich pictures and charts to communicate relationships and key points. Stick them onto walls and talk to them in meetings. The document is the last place people will look, so it should be the last place you put that vital bit of information.

Document Actions

Great article

Posted by at Jun 30, 2009 07:07 AM
I read this post while taking a break from writing a 50 page report that I know that my client is not going to read. Instead, they will probably leaf through the slides of an executive presentation that they will not attend - sigh.
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up