Writing documents your stakeholders will read

“If a tree falls in a forest and no one is around to hear it, does it make a sound?” – George Berkeley

If you write a project document and no one reads it, what was the point of writing it?

You’ve spent hours crafting what you’re sure is the perfect project briefing document and you’re excited to send it to your stakeholders. But when you ask some questions at the kick-off meeting, it’s obvious no-one has read it – at least not beyond the first page. What went wrong?

Project documentation is as necessary, even if it can seem tedious. It can make the difference between success and failure. According to the PMI, poor communication is among the top five reasons that projects fail. But you are communicating – so why doesn’t anyone read it?

How can you create documentation which brings clarity and transparency to your project process, fast-tracks decisions and creates ownership within your team? Follow these tips, and you’ll hopefully never again be interrupted with the words, “Can you give me an update on the project?”

Before you begin

Gather input

How do you know which information is useful to your stakeholders? Ask them. Also find out which parts of project documents they usually skip and which they always read.

Have a plan

Your communications plan is a vital part of the overall project plan. Regular messaging will cut down on the ad-hoc requests for status updates.

Consider your medium

Avoid scattering your project communication across email, meeting agendas, chats and shared drives. Instead, bring all the pieces together into one cloud-based location. Ensure the appropriate people receive notifications when documents are added or updated.

Structure is key

Create templates

For each type of project document, ensure you always follow the same format. This makes your documents both quicker to write and easier to digest by readers. Over time it becomes easier for stakeholders to track progress when they know where to find the data that’s relevant to them.

Ideally your project management software will have a range of reporting templates ready for you to customise and use in your documentation.

Keep your documents as attractive and ‘glanceable’ as you can. Consider your fonts and line spacing, and avoid cramming in too much text at once (these tend to be the parts people skip!).

Have a strong executive summary or opening paragraph

The beginning of your document will tell the reader whether it is worth continuing to read. Include the two or three key milestones or topics you want to focus on and allude to the data you will present within in the document.

Keep it brief

 “A one-size-fits-all report does not work for all stakeholders. Too much information can overwhelm.” – Kathi Soniat, PMP, Randstad Technologies, Greer, South Carolina, USA

Avoid the temptation to include all the current information about a project in every document. Time is scarce, and your stakeholders only want to know what is essential to progress. Project status reports for example should be one page or less.

You should, of course, include any relevant context in your document, but don’t rehash the project background or keep sharing the same data. Link off to other documents as required to provide more information for those who need it.

Tips for readability

Use active voice as much as possible

Active voice emphasises the subject and makes it clear who is performing an action. If you write using active voice you will appear confident and trustworthy. Your words have more authority and are more persuasive. Hint: if your sentence includes the word ‘was’, it is probably written in passive voice. 

Here is an example of passive voice: An investigation into the overspend will be conducted. When re-written in active voice, the subject of the sentence must be included: The CFO will investigate the overspend.

Colour coding guides the eye

It may sound childish but colours really work! Whether it’s as simple as using green for actions that are on-track and red for risks, design a consistent colour code palette and use it in each status report. If you have multiple work streams in a project, you might always use the same colours when representing them in charts or graphs. Don’t overdo it though – only use colours to illustrate the most important points in your document.

Graph data wherever possible

Humans are visual creatures, and we find it much easier to interpret data when presented graphically. Again, you can link off to the full data table for those who need the detailed information. Your graphs should show your reader the conclusions they should draw, not merely present the numbers so that they gloss over them.

Annotate charts, graphs and data

To this end, annotate your visuals to illustrate what the data is showing the reader. Your title should point out the key learning of your graph, not merely describe the data. Avoid using a data legend which sits off to the side of the graph. Instead, directly label your data points (only the most relevant ones). Add any other brief pertinent annotations directly to the chart which will help the reader grasp its meaning without having to read lengthy explanatory sentences underneath. You want to avoid making the reader switch repeatedly between the graph and an explanation.

Amanda Cox, an editor at the The New York Times, says “The annotation layer is the most important thing we do…otherwise it’s a case of here it is, you go figure it out.” [source]

Psoda Plug

Do you have a project management tool which allows you to generate custom reports on the fly, allowing you to create project documents with ease? Can you manage your workflows and timelines collaboratively, keeping all of your communication in one central location? If not, Psoda can help! Sign up for a free 14 day trial today.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>