Much of our communication is in writing. We write plans, requirements, specifications, reports, code, tests, etc. For a major IT project, the volume of paper can be enormous, but is it valuable?
In today’s fast-paced, high-stress, businesses, no one has the time to read volumes of information no matter how nicely formatted and presented. Yet, many organizations continue to turn out the equivalent of a multi-volume encyclopedia on project after project.
Why do we continue this archaic practice?
It’s the thinking process that goes into creating documents that is really important, not the documents themselves. Unfortunately, documentation often serves as a vehicle for showing off what a good job we’re doing rather than simply conveying information.
Elaborate and fancy documents require a lot of effort but rarely provide equivalent value. They tend to contain large amounts of boilerplate and little original content.
Such lengthy documents tend to discourage readers. They are too lengthy to absorb electronically and too bulky to print out and thumb through. Readers tend to go for the executive summary, which while conveying a few major points, is short on specifics.
There’s a better way. Apply the principles of agile development and lean programming to produce documents your teams can really use.
1. Focus on content not form.
Before writing any document, there a few questions you need to answer. What is the purpose of the document? Who is the intended audience? How long will the information be needed?
If the document’s purpose is to impress someone such as a customer or business partner, appearance is important and the extra effort is justified. If the document is strictly for internal team use, appearance shouldn’t matter.
Reverse your thinking and follow an agile approach. Rather than beginning with a lengthy formal template and looking for ways to simplify it, begin with a short informal outline. Increase length and formality as needed. To save time, send out an informal document to get everyone moving and add formality later, if needed.
2. Keep it brief.
We like to create lengthy documents that cover all aspects of the problem and corresponding solution. Yet, in most companies, people are specialized. Most of the document contents don’t apply to particular individuals who ask themselves if it’s worth the time to wade through a tome to extract the few points of interest to them.
Think lean. Break up long rambling documents into a few short ones where each is tightly focused. Your goal is collaboration not just communication. Big documents communicate but they do little to enhance thought-provoking discussion.
3. Minimize the work effort.
Seek out ways to minimize the work to be done. Many problems are solved on a whiteboard. Often, someone takes the time to type up what’s on the whiteboard, re-draw the diagram, and send an email to the team. Yet often, the information is needed but the formality is not. Why not just take picture or two of the whiteboard using a cell phone camera and email it?
Lastly, avoid duplicating information. Rather than copy content from one document to another, simply refer to the original. Not only does this keep the new document shorter, it makes maintaining and updating document sets easier.
Recognize that the most efficient way to convey information is face to face. Documentation should encourage and facilitate discussion. Too often, it has the opposite effect. Agile documentation keeps teams focused on meaningful insights not fancy layouts. Do you have any other suggestions?