What is a PID

What is a PID, and why do we need it?

The I in the PID stands for Initiation, but it can be replaced with Important, as well, and here is why. 

Project Initiation Document is an important component of project management. It is an essential starting point when the project is about to kick off, and a reference point during the entire project development, for all the stakeholders. 

In life and business, the foundation comes first. That is why there is no need to emphasize the importance of documentation - the foundation for every project, especially in the idea inception phase and early stages of the process.

Thus, for a successful project, a Project Initiation Document is a must.

If you have an idea, with proper PID it can become a project. 

A venn diagram of product manager responsibilities and the overlap of UX, technology, and business (Roadmap for developing an idea)

What is PID?

It collects all the necessary information for the very beginning of the project. Without it, the project is just an idea. An idea that could (and judged by the statistics will most certainly) go wrong if delivered without a proper specification of what is needed and how it will be achieved.

Therefore, the PID must be transparent and understandable for all the parties involved. It does not need to be written in a technical manner, on the contrary, it is desirable and recommended to use non-technical language. It will be presented to different types of audiences. Some of them may have domain knowledge or even be subject matter experts, but in completely different fields. Others may not have any expertise at all. The only thing that matters is: all of them must understand the document.

It is important to mention that PID is a “live” document until it is being signed off. Live means that it will undergo several versions and back and forth communication with the stakeholders until all the details are specified and agreed upon. With that being said, the PID represents a form of agreement. 

Participants in PID creation are the stakeholders. They are the ones who will define the most important part of the PID - the scope, based on which, the other elements will be built upon. The scope is where the key information is and the very center of the PID. But let’s leave the scope definition and importance aside for a while – there will be plenty of words on it as we go further.

Purpose of PID 

The main purpose of the PID is to define project goal, objectives, and scope. Aside from these, PID also reveals a bit about the company and project background, ensuring everyone included at any phase of the project can quickly and easily infiltrate it and get a clear vision of what is being built.

A venn diagram of product manager responsibilities and the overlap of UX, technology, and business (PID is between SET GOALS and TAKE ACTION )

Foreseeing and outlining the potential risks that could jeopardize the project execution allows finding a way of preventively mitigating them. The better we understand the risks, the better are the chances of avoiding them or finding the right solution on time.

What PID does contain?

What does the PID look like? What are its components?

In a sea of eye-pleasing designs and documents, PID must be simple. But detailed. Here is a glance over PID components and their purpose.

As already stated, this document’s purpose is to define project goals, objectives, and scope.

The goals and objectives speak for themselves - they define what is expected from the successful project realization.

Moving on to the scope. The scope represents an outcome derived from the stakeholders’ requirements. The requirements are being gathered and elicited on one or more sessions, depending on the project complexity. Once this is done, they are grouped and categorized into three general sections: must-have should have, would have, implying the importance of each group/feature. There are a few other ways to categorize the requirements, but this one is widely used for its simplicity and effectiveness.

Now that the first glimpses of scope are there, each element should be decomposed further, explaining why it is needed and its basic functionality.  

Aside from the scope, the PID also lists the Out of Scope features. This might seem a bit odd, however, it is important as the idea is to avoid any uncertainties and possibilities of misinterpretation.

How do we walk through the Scope activities once we have defined them? What is the correct order to perform the tasks?

The explanation is given in the Dependencies section, where both internal and external types of dependencies should be listed, along with the solution for the given dependencies that should help skip a series of obstacles and ensure smooth-running development.

As the project breaks to shreds, so do the Questions pop up. To avoid the zone of misunderstanding and guessing, we ask questions. And it's well known that there are no bad questions - just poor answers. The list of open questions is to be discussed and answered with the assistance of the stakeholders. Sometimes the answers are not obvious or simple and require brainstorming or outsourcing an expert to get them.

The Estimates component has been previously explained, so it is only left to mention that estimates are given based on previous experience, or again, by outsourcing an expert to help with the issue. Usually, a range is given, for both time and cost estimates, emphasizing the fact that estimates are approximate and serve for reference only.

Another PID component that can be defined based on the scope and estimates is the Planning component. It allows (again, rough) setting the key milestones and the project approach which should articulate what will be done and how it will serve the project’s goals. The way of reporting and its frequency is specified here, as well.

The risk log represents the PID component that is sometimes underestimated, which should not be the case. Risk analysis and management play an important part in project initiation. This section may include the risk description, its impact, likelihood, mitigating actions, and more. Listed risks should be specific to the project and not just a reiteration of the risks common to all projects.

Along with the risks, the Constraints that may come in the way of project delivery should be listed in the PID. These are usually things such as Government regulations, industry specifics, special certificates, standards, etc. We cannot affect the constraints, but they can affect our project. Similar to risks, we can only predict them and adapt accordingly, making sure they do not become an unsolvable obstacle for the project.

Importance of PID 

By creating the PID, you will find the answers to the questions: What? Why? Who? How? When? 

A venn diagram of product manager responsibilities and the overlap of UX, technology, and business

When we look back, it is obvious where the key importance of PID lies. What is more important than defining the project and its scope? Therefore, verifying the project and consequently securing the approval and/or funding for it.

The PID structures the roles and responsibilities of project participants. The roles are clearly defined and there are not any double divisions. This gives the team members the information they need to be productive and effective right from the start and allows   better resource planning and a clear definition of what is whose responsibility.

Knowing the importance of estimates, and the role they play in planning and decision making, the PID provides an insight into this area. Although only rough estimates are included, they are extremely beneficial to the stakeholders. The estimates are expressed in terms of cost and timelines, thus providing the ground for conducting the cost-benefit analysis and making further decisions.

And that is it. Seem like a lot, right? And what if we tell you that is not the end of the process? If you are asking yourself “What is next?”, it is time to start with the Discovery process.

The Discovery Process is the stage where we unveil unexplored project details, such as user personas, mind maps, technology recommendations, and more.

But we will leave that story for some other time.


  • PID collects the necessary information for the very beginning of the project. 
  • The purpose of PID is to make all of the information transparent and understandable for all parties involved. 
  • Describes the project goals, objectives, scope, deliverables and processes to be addressed during the project.
  • PID is being defined, referenced, and updated throughout the project to get as much value and specifications as possible. 
  • All that in the hope that the Project Initiation Document will be approved and that the project can kick-off and/or the financing for it is granted.