The recent post Overview of Project Initiation Document (PID) provided a high level understanding of the PID including what it is?, why it is used? and what should be included?
This post will expand on this and go into more detail on what should typically be included in the different sections of a PID.
General Principles
Before looking at the information you need to add, it is worth thinking about some general principles:
- “Less is more”. Don’t be fooled into thinking writing a 50 page document is helpful. Most stakeholders are short of time so you should aim to make the document as short and concise as possible to allow the stakeholders to understand and be able to sign-off the document. Only include information that is needed. However, if 50 pages is what is needed, this is the right answer.
- “The PID must stand on it’s own” Meaning, it needs to be able to communicate the important points just by reading the document i.e. think would the reader understand without someone explaining the document?
- “Knowledge is dangerous”. You or the writer will have acquired a lot of knowledge on the topic. This can result in important pieces of information or the PID to make sense not to being included in the document.
- “Avoid jargon”. Project’s quickly create code words and acronyms. Again the stakeholders will not be aware of what they mean so avoid using them or, at a minimum, explain what they mean when they are first used. Connected to this is avoiding “technical speak”.
Background
This is where you set the context – the reason for why the project is being proposed.
This should ensure that anyone reading the document understands the reason why the project is needed and being proposed. It articulates the high level drivers.
Need / Problem Statement
This can also be called the objectives. This is where the specific need for doing the work is explained.
For example, taking the recent regulatory changes in respect of GDPR. The need could be that the organisations website needs to be updated in order to comply with GDPR regulation. If not, the website may not be able to offer services to residents within the EU.
This clearly explains the need and reason why the project should be initiated.
Benefits
This should be a naturally progression building on the Need / Problem Statement.
This must clearly state the benefit that will be achieved by completing the project. In simple terms, it should demonstrate that doing the project will achieve the stated requirement in the Need / Problem Statement.
For the GDPR example, it may be that the website terms and conditions will be updated to clearly explain how the website complies with GDPR regulation and that the associated operating model and controls will be implemented to support the processing and control of data.
Indicative Timelines / Project Plan
In order for senior management to approve the PID, they will want a high level estimate of the timelines for the work.
This does present a dilemma to the project team as, in most cases they will not have had a chance to conduct the required analysis.
Therefore, this is where expert judgement can play a part in creating an estimate of timescale based on similar projects.
It could even be that there is a hard date that must be met, in the case of GDPR it was the 25 May 2018. Therefore, the plan might just have to show this even if you do not know if it is achievable.
The timeline should include the blocks of work you think will be required. I would suggest showing the key project activities as blocks i.e. Mobilisation, Design, Build, Test, Implement, etc. This helps the stakeholders picture how the work will be executed and assess if they think it is sensible.
I would also suggest placing a milestone early in the plan where you intend to review the indicative timeline based on the analysis that will be conducted. This allows you to clearly signal that to further develop and firm up the plan, you will be looking to conduct the required analysis and then come back to the sponsors with an updated timeline. This is important so that the expectations are managed.
Indicative Budget
This is the same principle as Timelines.
Stakeholders will want an approx.. idea of how much the work will cost. This will strongly influence if it makes sense to approve the PID or not.
If the PID advises that the cost of updating the website to support GDPR for a small business making Euro 25,000 sales in Europe is Euro 1,000,000, the stakeholders will quite rightly say that this does not make sense and decide to not offer services in Europe.
Again the project team will have to estimate based on known information and expert judgement. There should be a checkpoint in the Timeline to show that a refined budget will be presented.
Risks & Issues
Another important piece of information to help the decision process.
The PID should capture any risks and issues that will have an impact on being able to deliver the project.
For example, if the updates to the website for GDPR relies on an internal development team who are already having to complete 2 other critical projects, you should capture that there is a risk that there will be no resources to support the website changes to meet the required timeline. You can also include that a potential mitigation is getting the GDPR work prioritised over the other 2 projects.
Again it helps the stakeholder to make an informed decision as they will understand that there could be a need to prioritise and impact the other projects.
Roles & Responsibilities / Resources
The PID should state the important roles required for the project. This should at a minimum include:
- Sponsor
- Project Manager
Other roles can be included if they are known. It might be that you know the role but do not know the person who will fulfil the role.
Again having this detail helps the stakeholders understand what will be needed and if it is feasible to secure the resources.
Governance
All projects need to have the correct governance. This helps ensure the appropriate oversight and for the project to have the correct direction and support.
The stakeholders will want to know how the project will be governed as this will have a direct influence on if the project is a success.
Likewise, they may not be happy to approve if the proposed governance does not allow them to direct the work.
Summary
There is no right and wrong answer of the exact detail to include in a PID. However, the PID must include the elements listed above.
Remember the aim is to clearly communicate the need, why it is important, how it will be completed, over what time and at what cost.
This should be done in a way that is easy to understand so that an informed decision can be made.
Keeping this in mind should enable you to prepare a PID that will be well received by the sponsor and stakeholders.
