Do you have problems with people not reading your project documents? It's really frustrating when you send out documents for comment and then find that the people you sent them to don't read them. Or have any recollection of receiving them.

One of the best ways that I have found to avoid this happening is to make sure people know what is expected of them when they receive an email from you with a document attached. If you don't spell out what you are waiting for then it's really unlikely that you'll get it, so you have to make it clear for stakeholders.

There are 4 statuses that I use when issuing project documents to the rest of the team.

For information

This is exactly as it says-a document that you are issuing for information purposes only. It could be the detailed project plan to the project sponsor (you'd never expect them to read it all but they asked to see it). It could be the risk log to the full project team (they don't all have actions but you are sending them the most recent version so they know what is happening). It could be a communication about the latest project status to the marketing team (they could use it in another internal communication but they don't need to do anything with it if they don't want to).

For action

Again, the status 'for action' is very clear. If you are the recipient it tells you that you are expected to do something as a result of receiving this document. It could be a work package description that you and your team are now going to work on. It could be an invoice to approve or a quote to review. In fact, it could be anything that you create or forward on to someone else that needs them to do the next action.

For approval

This status is a straightforward one, and I use it when I don't need an executive decision but I do need formal confirmation about what I plan to do next. For example, I might prepare a budget forecast for my project. I don't expect my sponsor to decide if I've done it right but I will need him to approve the latest figures. You can also use this when you have had verbal agreement on a course of action, such as changing dates on the plan, and are now issuing the associated project documents for formal sign off.

Decision required

This sort of document is the kind of thing that you would send to your project sponsor or project board, and you probably won't use this status as frequently as you would use the other two. You could be sending a paper recommending the actions to be taken as part of an issue management plan, or a document detailing a project change and asking for direction on whether to implement it or not. It could be something to do with project scope-whether the website background should be blue or white, for example, or what images to use in the brochure.

Whatever it is, the status 'decision required' tells the recipient that they need to make a decision and let you know what they have decided before anything else will happen on this task.

How to do it

The easiest way to flag your documents is to put the status in the email subject line (assuming you are sending it by email). The email subject line ‘Decision required: Risk of delay action plan’ tells your recipient exactly what they are getting and why they should open the email and the attachment.

It is better to do this in the email subject line or the body of the email than on the document itself. That's because you will probably be sending the same document to several different people, and they all have different roles to play. If you mark your project PID 'For approval' in the text of the document itself (using the watermark feature, for example) then when you send it to your project team members or the PMO they will also get that message. Leave your documents status-free and then use your covering email to let the recipient know what is expected of them.

This is a really simple technique but I've found it is incredibly effective. Make it easy for people to understand what you want them to do and they are far more likely to do it-it saves them time and you get the result you want.