Skip to main content

Project Initiation Documentation – What’s the Point?

Have you ever written a PID (Project Initiation Document)? Did you get any value from it? Did the project?

Is the PID just a bureaucratic process, or is there any value in it? Can we do something different and get more value?

Any project initiation document, or process, will only add value if at least one of the following things is true:

  1. It strengthens the quality of thinking before the project
  2. It gets read by somebody who believes it added value to them
  3. It is used as a reference point, by everyone, and accepted as ‘the standard’ for what is to be done.

Let’s look at these, in reverse order.

1. The PID as a reference point

I have rarely seen project initiation documentation used as a reference point or to hold people to account of an approach, agreement or a deliverable. Where I have seen attempts at this (“In the PID, we said we were going to do it this way”), I have seen easy rebuttals explain the folly of the concept (“but things have changed, and you need to change your approach as a result”). Some would argue that if you keep your PID up to date as things change, it is still valid. I would argue that project teams are terrible at keeping documentation up to date. Let’s stop pretending we are going to do this and find a better way and if the PID is continually updated to reflect reality, is it an initiation document, or just the current view on what we are going to do? Having a current agreed view on where we are going to might be useful. A PID-style document might not be the best way to do this.

What are the alternatives? Personally, I like meeting minutes the most. I like sitting down with the people that might be the readers of a PID and instead, having a discussion. This meeting creates a two-way process open to cross-examination and debate (much more so than a document). Circulating minutes of the outcome keeps a record of what was agreed, and no-one needs to read a dry boring text. As things change, we discuss them again and circulate minutes again. Our documentation is up to date. However, more importantly, the people involved know what is going on rather than interpreting an understanding from a dry document. I find this approach eases understanding (the most important thing) is quicker (project managers like faster) and can be used to hold someone to account (“in the meeting on XYZ date, you said…”).

2. People who read the PID get value from it.

For this to be true, firstly, the right people have to read the PID. That means not only the sponsor or governance functions but project members and other stakeholders. This does not happen. We are kidding ourselves if we think it does. For those that do read the PID, they read the sections that they are interested in or perceive as relevant to them, often missing out important context as a result. That is not to say that some people do not read the PID. Of course, some do. However, it is not read as widely as the information should be disseminated and understood.

For the PID to deliver value, the readers have to understand its contents. The project teams that produce PIDs are often not professional technical writers, and their PIDs are full of ambiguities, contradictions and open to interpretation. It is impossible in this scenario to be certain that the few people who read it, get the value from it that you intended.

Again, that does not mean no-one gets the expected value from reading the PID. It is only fair to assume that sometimes, a percentage of the people that read the PID, get the value intended from reading it. The problem is, that on projects you need everyone on the same page. The people that have read the PID and have interpreted something else, and the people that have not read the PID and have incorrect assumptions and thoughts, are a significant problem.

I do not think the solution to the problem is writing better PIDs. I do not want my project managers to become professional technical writers. I want them to strengthen their project management skills. Given the limited utility in the PID, in adding value to its readers, maybe its time we stopped writing PIDs. Instead, use the first governance meeting to present the PID contents to the governance group, use a project kick-off meeting to do the same to the stakeholders, use the first team meeting to do the same to the project team. Now everyone has the same information. Moreover, you can do this without writing the PID.

3. Strengthening the quality of thinking

If we look at the sections in a traditional PID very few of them, have content which is a foregone conclusion. That means thought (and often discussion, group-ideation, and compromise) are needed to produce the contents. Unless a PID is produced in isolation (which it should not be), it is very hard to argue that the process of producing a PID does not improve the quality of thinking about the project. It evidently does. Hang on! Have we just re-asserted that a PID is useful after spending the last 10 minutes saying the opposite?

The process to produce the PID document is where the thinking happens. The process and discussions add value. However, you do not need to produce the document at the end. The document does not add value. Yes, we need to capture the salient points and disseminate the learning, but a document is not the best way to do that. Instead of writing, think visually. Let’s have schematics and mind maps. Instead of hoping the document is read, let’s present the document. Let’s have more judicious use of meeting minutes as documentation. Let’s stop wasting our time writing PIDs and improve the wider understanding of the project by spending more time managing our projects.

In Summary

The main problems of the PID are that it is not a good communication tool. Written communication should be low on the list on a project, it’s open to misinterpretation and misunderstanding; it takes time to produce. Time that adds little value; (iii) the PID is not read. If it is, it is not read in a way that there is a shared understanding of what the project is going to do; (iv) project teams are bad at documentation and don’t keep it up to date and (v) whilst the process of writing a PID forces some critical thinking about the project that adds value, skipping the PID, does not mean we need to skip those processes too. Instead, maybe we should have the meetings and discussions to create the PID content but present rather than a document, minute rather than read and move quicker rather than spending time writing.

Comments (12)