Why bother going through the trouble of creating a Project Initiation Document? You’ve received sign-off from your client, completed your planning, secured your resources and now you want to get started on your project. You could simply start assigning tasks to the team and hit the ground running, and get ahead of schedule.
But while it may seem this is a good idea, a project Initiation document, or PID is crucial to starting a project right. A successful (or unsuccessful) start to a project can determine the project’s success fairly early on.
I’ve caught myself wondering a few times in projects: where did the project go off- track? Wasn’t it clear what the client wanted? Didn’t I communicate exactly to the team what needs to be done by when? Don’t I have a ticket for everything? Why did we create this, even though it’s out of scope? The truth is: if it’s not documented, chances are people don’t know.
What Is A Project Initiation Document (PID) And Why It Is Important?
A Project Initiation Document defines the project scope, management and overall success criteria that the team can go back to during the project. It contains the basic information of the project such as context, scope, team, and collaboration. It is equally important as an internal guide and for external stakeholders
A solid start to a project is key, no matter how small or large a project is. A Project Initiation Document helps guide the team early on – to a successful project start without creating too much extra work upfront. The PID can be a living document that the team can fall back on. It also provides a safeguard if there is a change in resourcing or new team members are brought on to the team and is an ideal starting point for ramp up.
The Project Initiation Document (PID) is the first basic step to ensure your project sets off on the right foot. It sets the tone, context, expectations, and constraints. The PID specifically is derived from the Prince2 methodology, but generally all methodologies have artifacts that outline the project start. Project Initiation Documents are sometimes also called Project Charters or Project Brief.
7 Simple Steps To Create A Project Initiation Document
As a Digital Project Manager, your job is not only to manage a project to completion, but also to ensure that the team is aligned on what needs to be done, by whom and by when.
The why is just as important, so the team gets a sense of the mission and buys into the overall success criteria. Context is king and needs to be established early on. Ultimately as a DPM, you’re the coach who brings a team of experts together and it is extremely important to provide the necessary details to set the team up for success.
Rather than creating a complex template, this project initiation creation guide will focus on the most important sections of a project initiation document, with a focus on Digital Project Management. It’ll help getting your team and client on track without creating a massive PID document.
Looking for a rock-solid Project Initiation Document template?
Become a DPM Member to download it (plus get access to 50+ additional templates and samples)!
By joining our community of DPMs you will:
- Save time with 50+ expert-crafted project templates and samples.
- Get a leading edge with live and on-demand workshops led by industry experts.
- Find a tribe of support, mentorship, and networking with mastermind groups.
1. Provide The Context
Since you’ve been working with the client to scope out the project, chances are you can provide 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 it rooted in the overall organizational strategy?
- What are the business goals?
- How is success defined?
- Are there metrics defined that will measure success in the end?
Outline the strategic vision, goals & objectives and ideally include a high-level mission statement. This will help align the team on the approach and keep these goals in mind during solutioning. It will also help in defining additional work and potential project enhancements as the team keep this context in mind. (Wouldn’t it be great, if we could do…?)
2. Define The Project Parameters
Being the PM, you might be used to be surrounded by experts on your team. The challenge is to enable all these smart people to work together to deliver your project, so outlining the plan in your project initiation document to the team is just as important as outlining the scope.
Make sure to be transparent about the overall project constraints and information like:
- What is the budget for this project?
- How is the budget broken down?
- What does the timeline look like?
- How do you envision the 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 have a successful project, if every team member does their own thing. So establishing a team of experts rather than a team of individuals will go a long way and establish a sense of teamwork early on.
3. Define The Specifics
Next up in your project initiation document – define the project specifics. Your team needs to understand what exactly needs to be done and delivered for this project to be a success.
- What is in scope and out of scope?
- Are there some initial project requirements that are already defined?
- What are the project boundaries that the team shall not cross?
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. This includes potential assumptions and constraints, like the number of revisions to consider.
4. Define the Project Breakdown Structure and Resourcing Plan
To ensure it is clear to the team how the deliverables are created, it is essential to break the work into smaller chunks and create a Project Breakdown that includes the allocations. It showcases how deliverables come together and who will be working on what with whom.
High-level Project Breakdown example:
In my personal experience, it’s of great value to run the team through the overall rough planning and resourcing breakdown structure of the project, so that team members can weigh in and help you optimize. By running the team through the actual planning, dependencies will become clear and the team is part of the plan. It also helps the overall project understanding and accountability.These breakdowns can vary in detail and can map out the various activities in each phase. They can also be connected to specific dates and tie into resource planning.
5. Define Who’s Who
An important aspect of the Project Initiation Document is the overall project team structure both internally and externally. 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 before a sign off? Establishing this, will help avoid misunderstandings and give you an idea how complex sign offs are going to be.
A great way to indicate these dependencies in the project is a RACI chart. 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 start a RACI is to map out the project deliverables or activities on the left hand side and the Roles on the right hand side – both for internal and external team members and then assign the RACI status. Make sure there is only one person accountable per deliverable. If you want to learn more about creating RACI charts, read this amazing article and check this video with a great overview of RACI best practices.
Defining this is a great way to set expectations for the project communication and the overall governance. It reduces the risk of hearing sentences like “I thought that was on your plate” or “I should have reviewed that before it went out to the client”.
Make sure to outline the team structure and ensure everyone knows who is a part of the project. This includes the project manager, account manager, other team members, but also senior leadership, in case they have to sign off deliverables.
The big questions we need to be asking the client are:
- Who really knows what we’re supposed to be doing, and why?
- Who’s responsible for signing off the brief
- Who’s actually accountable or responsible for signing assets off?
- Is there a steering committee that needs to be consulted?
- Who’s going to get upset if we don’t loop them in (and remember that our clients might have their own internal politics) so we can’t just expect them to do it.
The RACI is a great way, especially when you’re new to get a handle on how things work in an agency and to get up to speed with the internal process. It can be accompanied by a communication plan that outlines things in more detail.
6. Identify Your Risks, Assumptions, Issues And Dependencies
Last but not least, make sure to include an overview of known risks and constraints into the PID. Projects can be complex for different reasons and it’s always helpful to think it through and anticipate some of the project risks and issues and come up with mitigation strategies.
Some examples are:
- Timelines that are too short or too long
- Budget constraints
- Technical unknowns
- Complex Stakeholder landscape
- Single point of failures
7. Share Your Project Initiation Document
It’s done, you’ve created a comprehensive Project Initiation Document that sets your team up for success. Make sure to share it with the entire team and to new team members that are joining later on. It’s also great for check-ins, later on, to ensure the team doesn’t lose track. Have the client sign off on it as well to formalize things like assumptions and RACI. It’ll come in handy to point to this document when new stakeholders get involved or when approval process turns out to be more complicated than anticipated.
What Do You Think?
What’s your experience with Project initiation Documents? Do you include other sections that are valuable? Are there situations where a PID is not needed or do you have experiences where a PID saved your project? Let us know in the comments.