The Summary Paper

I’ve got a favourite new business document: I call it the summary paper and it reminds a lot of the book report format from third grade. I’ll claim to have invented my specific version but I’m sure there’s different names for this document depending on the project management/software development/business model you’ve adopted; no matter…

So what are the summary paper’s defining features, you ask? The summary paper is:

• About something really important The summary paper exists to feed into a meeting; if someone’s called a meeting hopefully the subject matter is sufficiently important to warrant having everyone in the same room not doing other work.
• Broad Include at least a brief context or history about the topic to bring readers to the same level and quickly address any knowledge gaps.
• Specific With the context out of the way, the remainder of the paper should be exactingly specific—as always, qualify and quantify wherever possible and prefer well conceived charts, diagrams, and images that can stand on their own or at least significantly augment the text. Most importantly, the summary report should be about one single thing and that subject must inform the entire report; if something isn’t relevant to the main subject, it belongs in a different summary report. Specificity in many cases equates to authoritativeness.
• Short The whole point is to create something approachable and easy to digest between tasks or on the train ride home. No one really cares about what you do but they care event less about that fifty pager no one will ever read because they don’t have the time or interest. Shortness is goodness because a short summary paper is also easy to adapt to changing information; when it comes time to discuss the paper in a meeting it’s easy to say “let’s take five minutes to read through this document.” Simply put, a short paper is more likely to get read. Assume your readers already know something about the subject. Aim for one to four pages and print it double-sided.
• Enticing Print in colour and come up with a precise title that tells the reader exactly what the document is about.
• Textual Use bullet points and tables for short lists and data. The summary paper is meant to be read so write sentences and paragraphs grouped under headings. Avoid complex tables, tables with lots of text, and bullet points in tables… Number and call out all figures in the text.
• Fast Write it quickly before you loose focus and forget key points.
• Timely Focus on the current state of play and how things are now—not how they used to be or how they might be in the future. As a snapshot in time, ensure the data presented is current to within a few days.
• Decisive State problems clearly and write in clear terms. Don’t dick around with fancy vocabulary, wordiness, and bad writing. Do use a spell checker and proofread, proofread, proofread. Use an appendix of terms and abbreviations (and even synonyms) if required. Use an appendix for references is required. Don’t bog down the first few pages with titles and logos and document controls and sign offs and and references and disclaimers; do keep it simple: include the author’s name(s), the date, and a simple version number (eg. v1.0 where the 1 is the major version and the 0 is the internal draft version). Include page numbers and numbered headings for ease of reference during discussions. Use consistent formatting to create meaning.
• Open Encourage feedback and be willing to incorporate ideas and suggestions—v1.0 should never be the final version. Incorporate feedback as early as possible.
• Owned Limit the number of authors (preferably to a single person) to encourage ownership and clearly identify the person responsible for making updates. If the paper is eventually earmarked for distribution to senior management but was initiated by a junior, allow the junior to retain ownership—especially if continual feedback looping starts to happen. Ensure whoever initiates the paper has an existing understanding of the subject and remains engaged as discussion evolves.
• Complete and Accurate TBDs should be avoided. Exclude placeholder sections containing no content. If critical information is required for completeness, find and validate that information. If existing information is unclear, clarify it by research (speak to others, do some reading, experiment).
• Actionable List possible solutions—don’t wait for that to happen at some future meeting. Identify, by name, individuals required to provide information or complete tasks.

I love these papers. My experience with this approach so far has been to say to someone arriving at my desk “here, read this” and they actually do read it (sometimes standing right there) and it results in the flow of ideas I can use to make the paper better. I’ve easily got ten to twenty individuals feeding into a single piece of work and these briefs are the fastest, most accurate way to turn discussion into action.