How to write a Project Initiation Document - Part 2
In the first part of How to write a Project Initiation Document we described what a PID was – it’s uses and why it is an essential part of any project. In Part 2 will discuss some of the fundamental elements of the document.
What's in a Project Initiation Document
The contents of a PID may vary from Project to Project – there are however some key elements:
Layout in simple terms the goals of the project – this should include reference to the rationale behind the goal – for example – a project goal could be to reduce the risk of legacy technology by introducing a new ERP system. Notice there is a difference between Goals/Objectives and Deliverables.
What will the project Deliver? – for example is the project to deliver a written report, is it delivering a new IT system, is it delivering training – there may be multiple deliverables that need to be documented – ensure that the deliverables are measurable, so it can be proved beyond reasonable doubt that tasks have been completed
What is the scope of the project – for example is the scope “implement IT solution for Australian user base”. Note this should clearly explain who the project will be done to and anything that is excluded.
Financial Business Case
The business case should contain details of the expected costs of the Project. The Business Case should also indicate any savings that may result from the project – some business cases take a multi-year approach (e.g. 5 years) looking at the long term impact of the financial commitment.
Project Roles and responsibilities
A clear part of the PID is clearly outlining the authorities within a project. The PID should outline the Project structure e.g. sponsor, steering team, project manager, Project team and their levels of responsibilities – you may even consider drawing up job descriptions for the people within the team. The PID should define the resource requirement for running the project – for example does the Project require a team of 10? If it does explain why.
Consider any risks that may effect the Project – their likelihood of their occurrence and their possible impact. Include mitigation against the risks that you’ve identified.
Are there any assumptions or constraints that you need to make about the Project? for example an assumption of introducing a new IT system may make some assumptions about what applications the system may integrate with?
Project controls, help schedule and measure projects - think about whether the Project requires Key Performance Indicators?
Consider what information channels will be required during the project – will a monthly summary report to the Project Sponsor suffice? Or will it need something else?
PID Sign off
At sign off it is important to assess the PID and ask if it adequately represents the Project – is possible ensure that the customer of the Project signs the document as part of its release.
Constructing a thorough project initiation document is a key part of starting a project. Ensuring that key elements of a project, such as it’s goals and business case, are well understood is imperative. A PID can be referenced throughout a project and serves as a valuable route map for the Project team. Whilst their contents may vary getting down what’s important to your project can be a really valuable activity.