Blog Post

How to Get Someone to Read Your Project Initiation Document


Project Managers often produce a Project Initiation Document (PID) at the start of the project. It’s a sort of project reference document, a collection of other bits of important documentation and the starting point for anyone who wants to know what the project is about.

The PID should be useful - something that people want to read - but it can end up being too long and difficult to read. They get produced for the wrong reason - to tick a quality management box rather than to share important project information with key stakeholders.

It isn’t difficult to produce a practical, useful Project Information Document. Here are some recommendations:

  1. Make it as readable as possible. Keep it to no more than 5 pages (that can be done), break it into sections, write short paragraphs and use bullet points/numbered lists whenever you can. Remember, a reader will give you 7 seconds before they decide to lose interest. It’s probably closer to 3 seconds for a PID.

  2. Start with a section that describes the deliverable, the business case and importantly, what it is at the end of the project that represents success. That final point may not be as obvious as it seems. Success may be more than just rolling out a new management information system, it could be high levels of reported user satisfaction with the new system. Quality expectations are part of the deliverable.

  3. Includes your project plan. Consider producing a higher level, easier to read summary plan and use that in the PID. Make sure the plan shows who is responsible for the different parts of the project. Put milestones in the plan that represent real progress.

  4. Include a table - stakeholders, roles, responsibilities. Details about the Project Board and how often it meets could also go here.

  5. Include the risk register. Don’t go overboard. Start with the top 5 risks. Be really clear about the possible financial impact if things go wrong - it’s a good way to get people’s attention. Be clear about who is responsible (it might be you) for mitigating each risk.

  6. Include the top 5 issues/challenges you face at the start of the project. This is another section. Issues are not quite the same as risks. Issues are more about day to day challenges, things that need to be overcome. Again, prioritise them and don’t go overboard on the detail.

The Project Initiation Document is important but that doesn’t mean it has to be long. People want brevity and clarity, particularly in technical documents. Keep the template simple and summarize where ever you can - people can always come back ask for more detail if they need it.



Related Posts