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