Skip to main content

Why bother going through the trouble of creating a project initiation document (PID)? You’ve received sign-off from your client, completed project planning, and secured your resources.

Now, you’re itching to get started on your project. You could simply start assigning tasks to the team to hit the ground running and get ahead of schedule.

While you may be in a hurry to get going, you shouldn’t skip creating a project initiation document, or PID. 

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? 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.

What Is A Project Initiation Document (PID)?

A project initiation document defines the project scope, milestones, and project success criteria. It also sets the context for the project and defines team member roles and responsibilities. As a foundational project document, it 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 lifecycle to set the tone, context, expectations, and constraints for the effort. The PID is an artifact from the PRINCE2 project management methodology. It might sometimes be called a project charter or project brief.

For more, check out our "masterclass" 😉:

Project Initiation Document Vs. Project Plan

If a project initiation document is similar to a project charter, then what’s th e difference between a project initiation document and a project plan?

You can think of the project initiation document as the “what” and “why” behind a project. You document the project goals and the business case for undertaking the effort.

The project plan builds on the project charter to define how the organization intends to manage the project, including risk management, project schedule, communications, etc. 

You develop the project 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

We’ve already discussed how you might create either a project charter or a project initiation document when you’re getting started with a new effort.

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. The kickoff agenda is much more tactical. In addition to recapping the key points from the project initiation document regarding project scope and business goals, it also highlights the discussion items you’d like to review with stakeholders during the project planning phase.

Why Is A Project Initiation Document Important?

A solid start to a project is key, no matter the project’s size or complexity. A project initiation document 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.

Sign up for our emails and be the first to see helpful how-tos, insider tips and tricks, and a collection of templates and tools.

Sign up for our emails and be the first to see helpful how-tos, insider tips and tricks, and a collection of templates and tools.

  • Hidden
  • No spam, just quality content. Your inbox is safe with us. For more details, review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

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 background
  • Success criteria
  • Project budget
  • Project timeline
  • Scope, including what’s in and out of scope
  • Project requirements
  • Deliverables
  • Assumptions and constraints
  • High-level project phases
  • Stakeholder roles and responsibilities
  • Risks, assumptions, and dependencies.

Project Initiation Document Template

screenshot of project initiation document template
Here's what our project initiation document template looks like.

Here’s a simple project initiation document 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 Examples & Sample

In addition to a template, we’ve also created a filled in sample to make it easier for you to apply this format to your own projects. We’ve also included a screenshot below.

project initiation document example screenshot
Sample project initiation document.

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 the most important, so the team gets a sense of the mission and buys into the 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. It’s vital to provide the necessary details to set the team up for success.

Rather than creating a complex template, we’ll focus on the most important sections of a project initiation document, with an emphasis on digital project management applications. We’ll help you get your team and client on track without overburdening them with documentation.

1. Set 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 the purpose of the project rooted in the organizational strategy?
  • What are the business goals?
  • How does the client define—and measure—success?

Outline the strategic vision, goals, and project objectives, ideally including 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

As the project manager, you might be used to being surrounded by a team of experts. The challenge is to enable these smart people to work together effectively to deliver your project.

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 deliverables?
  • 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 up in your project initiation document—define the project specifics. Your team needs to understand exactly 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:

project breakdown structure example
Project breakdown structure example.

In my experience, it’s of great value to run the team through the rough planning and work breakdown structure, so that team members can weigh in and help you optimize. This not only highlights dependencies but also engages the team in project plan development. Team members gain an understanding of project context and 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 these dependencies. A RACI chart 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. 

screenshot of a RACI matrix
RACI chart example.

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 processes. Accompany the RACI with a communication plan that outlines how you’ll collaborate across various team roles.

6. Identify Risks, Assumptions, Issues, And Dependencies

Last but not least, make sure to 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

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. Have the client sign off on it also 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 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.

Don’t forget to subscribe to The Digital Project Manager for more on project documentation and processes.

By Sarah M. Hoban

Sarah is a project manager and strategy consultant with 15 years of experience leading cross-functional teams to execute complex multi-million dollar projects. She excels at diagnosing, prioritizing, and solving organizational challenges and cultivating strong relationships to improve how teams do business. Sarah is passionate about productivity, leadership, building community, and her home state of New Jersey.