How To Create A Project Initiation Document In 7 Steps [+ Template]
Stay on Track with PIDs: The project initiation document, a critical document from the PRINCE2 methodology, helps clarify project scope, milestones, and responsibilities, so you can keep the project on track even when things go astray.
Why PIDs Matter: The importance of a PID lies in its ability to guide and streamline project initiation without overburdening the team, as well as make sure everyone stays informed and aligned throughout the project life cycle.
Template to the Rescue: Our downloadable PID template is available for DPM members, and it comes complete with a filled-in example and practical guidance on effectively structuring your PID.
Why bother creating a project initiation document (PID) once you’ve received sign-off, completed project planning, and secured your resources?
It will help keep you on track when you inevitably find yourself wondering: where did the project go off-track? Wasn’t it clear what the client wanted? Why did we create this deliverable, even though it’s out of scope?
The truth is: if it’s not documented, chances are people don’t know. Here's how document critical project information in a PID (along with a template) and keep your project on the path to success.
What Is A Project Initiation Document (PID)?
A project initiation document defines project scope, project milestones, and project success criteria. It also sets the context for the project and acts a foundational project document that is equally important both as an internal guide and for external stakeholders.
A project manager typically creates a PID during the project initiation phase of the project life cycle to set the tone, context, expectations, and constraints for the effort.
Why Is A Project Initiation Document Important?
A project initiation document is important because it helps guide the team to a successful project start without creating too much extra work upfront.
In addition to getting things rolling at the beginning of the project, the PID remains a living document that the team can reference throughout the project life cycle. It acts as a safeguard if there is a change in resourcing or new team members join, so they can get ramped up quickly.
What To Include In A Project Initiation Document
A project initiation document should include the following:
- Basic information about the project (e.g. client, project name)
- Project definition
- Project background
- Success criteria
- Project budget
- Project timeline
- Scope, including what’s in and out of scope
- Project requirements
- Deliverables
- Project controls
- Assumptions and constraints
- High-level project phases
- Stakeholder roles and responsibilities
- Risks, assumptions, and dependencies
Keep in mind that you likely won't have all the answers at this point, so think of your PID as a living document that will change as your project and its parameters become more defined.
Your PID is often a best guess based on the statement of work or the estimate that was created by the team. There’s so many things that are still up in the air. Whatever plan you put together might not pan out as it is.
Project Initiation Document Template
Here’s a simple project initiation template for you to download and adapt to your projects. It includes all the sections mentioned above. We’ve also included a filled-in sample (more on that below) so you can see exactly what to include in each section.
Project Initiation Document Example & Sample
Here's an example of what a completed project initiation document might look like. This filled-in sample is available with the template mentioned above, to make it easier for you to apply this format to your own projects.
How To Create A Project Initiation Document: 7 Steps
Here's how to make a project initiation document that contains the most important project information for your team and stakeholders.
1. Set The Context
Start by providing background on some of the business drivers of the project (if not, ask your account manager).
- Why is the client pursuing this project?
- What’s the problem to be solved?
- What’s the project about?
- Are there purely technical drivers, or is the purpose of the project rooted in the organizational strategy?
- What are the business goals?
- How does the client define—and measure—success? Which metrics do they use?
Outline the strategic vision, goals, project objectives, and, ideally, a high-level mission statement. This aligns the team on the project approach so they can keep these goals in mind throughout execution.
Having this context also helps the team when defining additional work and potential project enhancements. (Wouldn’t it be great, if we could do…?)
2. Define The Project Parameters
In the PID, be transparent about the project constraints, including information like:
- What is the budget for this project?
- How is the budget broken down by project phase or by deliverable?
- What does the timeline look like?
- How do you envision collaboration with the client?
- What is the first target that the team will work towards?
Ultimately, the team wins and loses together. It’s highly unlikely to deliver a successful project if every project team member does their own thing. Establishing a team of experts, rather than a collection of individuals, goes a long way towards establishing camaraderie and encouraging collaboration early on.
3. Define The Specifics
Next, define the project specifics in a project scope statement to give your team an understanding of what they need to deliver for this project to be a success.
For example:
- What is in scope and out of scope?
- Are there some initial project requirements that are already defined?
A crucial part of this section is the required deliverables. Since these are typically defined early on in the contract, the team needs to understand what the expectations are for these deliverables. This includes potential assumptions and constraints, like the number of revisions to consider.
4. Define The Project Breakdown Structure and Resourcing Plan
It’s important that the team is clear on how to execute project deliverables. This involves breaking the work into smaller chunks and identifying who is doing what.
Here is an example of a high-level project breakdown:
Run the team through the rough plan and work breakdown structure, so that they can weigh in. This will help highlight dependencies and engage the team in project plan development, to give them an understanding of the project context and their accountability for project outcomes.
Project breakdowns can vary in the level of detail they use to map out the various activities in each phase. They can also be connected to specific dates and align with resource planning.
5. Define Who’s Who
An important aspect of the project initiation document is the project team structure (both internal and external.)
- Who is working on the team?
- Who can approve things before they go to a client?
- Who on the client side needs to be consulted prior to sign-off?
Establishing these communication channels will help avoid misunderstandings later on. A RACI chart is a great tool to document this. It outlines who is/needs to be:
- Responsible: Who gets the job done?
- Accountable: Who is the decision maker?
- Consulted: Who needs to be asked before proceeding?
- Informed: Who needs to be kept in the loop?
The best way to develop a RACI chart is to list the project deliverables or activities and map them to project roles for both internal and external team members. Then, assign the RACI status. Make sure only one person is accountable for a project deliverable.
Defining team roles and responsibilities is a great way to set expectations for project communication and governance. It reduces the risk that you’ll hear: “I thought that was on your plate” or “I should have reviewed that before it went out to the client.”
Internal team
The internal team might include the project manager, account manager, other team members, and senior leadership, in case they have to sign off on deliverables.
External team
The big questions we need to be asking the client are:
- Who knows what we’re supposed to be doing, and why?
- Who’s responsible for signing off on the brief?
- Who’s accountable or responsible for signing off on project deliverables?
- Is there a steering committee that we need to consult?
- Who’s going to get upset if we don’t loop them in?
The RACI chart is a great way to get a handle on how things work in an agency and to get up to speed with internal workflows. Accompany the RACI with a communication plan that outlines how you’ll collaborate across various team roles.
6. Identify Risks, Assumptions, Issues, And Dependencies
Include an overview of known risks and constraints as part of the PID. Projects can be complex for different reasons, and it’s helpful to think it through, anticipate project risks and issues, and develop mitigation strategies.
Some examples are:
- Timelines that are too short or too long
- Budget constraints
- Technical unknowns
- Complex stakeholder landscape
- Single points of failure
7. Share Your Project Initiation Document
Make sure to share your project initiation document with the entire team. Have the client sign off on it to formalize assumptions and roles and responsibilities.
It’s also great to reference throughout the project life cycle so the team doesn’t lose track. This document comes in handy when new project stakeholders get involved or when the deliverable or document approval workflow turns out to be more complicated than anticipated.
For more, check out our "masterclass" 😉:
Project Initiation Document Vs. Project Plan
The project initiation document covers the “what” and “why” behind a project (i.e. the project goals and the business case), whereas the project plan builds on the project charter to define how you'll manage the project, including risk management, the project schedule, communications, etc.
You develop the project management plan after you’ve already gotten buy-in from the project sponsor to undertake the project (a step that occurs during the project initiation phase).
PIDs Vs. Other Types Of Project Initiation Documentation
While you would typically incorporate a business justification for your project as part of the project initiation document, you might also prepare a standalone business case for projects that are especially complex.
A business case includes a complete financial assessment for the project, including a cost-benefit analysis, market assessment, and competitive analysis.
A project initiation document also differs from the project kickoff agenda, which is much more tactical. In addition to recapping key points from the PID regarding project scope and business goals, it also highlights the discussion items you’d like to review with stakeholders during the project planning phase.
What's Next?
Want to connect with other digital project managers to share resources and best practices? Join our membership community and get access to 100+ templates, samples, and examples and connect with 100s of other digital project managers in Slack.
