Project initiation documentation

The project initiation documentation (PID) is one of the most significant artifacts in project management, which provides the foundation for the business project.

The project initiation documentation bundles the information, which was acquired through the starting up a project (SU) and initiating a project (IP) processes in a PRINCE2 controlled project environment. PRINCE2's 2009 renaming "document" to "documentation" indicates a collection of documentation that has been collected up creating a project rather than all the information in the system.^{[ according to whom? ]}

The project initiation document provides a reference point throughout the project for both the customer and the project team.

A project initiation document often contains the following:

• Project goals
• Scope
• Project organization
• Business case
• Constraints
• Stakeholders
• Risks
• Project controls
• Reporting frameworks
• PID sign off
• Summary

A project charter could be created instead of a project initiation documentation; the two document types are highly similar. But a project charter is less detailed, which makes it more suitable for cases in which content producers are less available.

Project initiation documentation in terms of PRINCE2

The project initiation documentation is a PRINCE2 term representing the plan of approach in project management. It is assembled from a series of other documents, including the business case, the terms of reference, the communication plan, the risk register, the project tolerances, the project plan, and any specific project controls or inspections as part of a departmental quality plan or common project approach. The project initiation documentation represents a detailed version of the basic project start-up document called the project brief.

The project initiation documentation bundles together documentation to form the logical document that brings together all of the key information needed to start and run the project on a sound basis. It should be conveyed to all stakeholders and agreed and signed off by the business sponsors. In short, this is the, "who, why, and what", part of the project. It defines all major aspects of a project and forms the basis for its management and the assessment of overall success. The project initiation document builds upon the business case (if it exists) using the information and analysis data produced during initiation activities. ^[1]

A common part of formal project methodologies such as PRINCE2 ^[2] the document is a major milestone in the initiating a project (IP) process. It is the document that goes before the project board for sign off to commence a project.

The project initiation document provides a reference point throughout the project for both the customer and the project team.

Writing a project initiation document

Purpose

The purpose of the project initiation document is to capture and record basic information needed to correctly define and plan the project. The project initiation document should expand upon the project mandate and state what the project is aiming and planning to achieve and the reason for the importance of meeting these aims. It also contains the list of people who are participating in the project development from the very beginning until project closure, along with their roles and responsibilities. The project initiation document also includes the date when the project initiation documentation was approved by the project board. The project initiation document is not regularly updated during project stages. Any revisions or updates which are needed are to be done at the end of the each stage in order to incorporate detailed milestones for the next steps. The project initiation document is the basis of decisions taken for the project and it is unhelpful when the document is queried or altered at a later stage with no reference to why, by whom or when. ^[3]

Project scope statement

Project scope statement is one of the most important sections of the project initiation document. The project scope statement is divided into three parts: Project scope statement, proposed solution and in scope for project example. This is the part of the project initiation document explaining in depth what the project is delivering for stakeholders and customers. Proposed solution explains what innovations, changes and aspects the project will bring within the environment and the society and which changes and renewals it will cause. The project scope statement should include as much detail as possible, as it helps to avoid proliferating problems and questions in the project lifecycle (requirements are needed in order to succeed in in scope category). The in scope phase helps the project manager to make decisions of financial aspects and projects' expenses. ^[4]

Project background

The project background establishes why and how the project was created. Phase 1 of the project will deliver the online functionality required together with the changes to the necessary business systems impacted, whilst phase 2 will deliver the digital rights management and real-time advert insertion. The person, who has played a pivotal role in project participation should be mentioned in this section of the project initiation document. It is a rational way of make the specific project above others emphasizing the attention of participation of most active candidate of a team. It is because someone important within the company wants to see it. The result should be that the resources and equipment are made available to you to ensure your project happens. ^[5]

Assumptions, dependencies and constraints

Assumptions, dependencies and constraints detail the project initiation document. Those details are assumed ahead of the project management requirements and business requirements specification being documented. Project constraints in the project initiation document identifies the outer impact, such as unavailability of resources or a competitor (e.g. another project). ^[6]

Organization and governance

In order to complete the organization stage, the team needs to complete the organization chart. A project may be achieved by a cross-functional team with experienced representatives from multiple departments including development, interactive, test, networking, infrastructure and business systems, security and marketing. The involvement of the different areas will vary as the project progresses of the initial project. ^[7] The SMG (Senior Management Group) will be notified of key findings and developments. ^[8]

Communication plan

During the whole process of creating the project initiation document the project manager is aware that they will be attending meetings with third party project managers, lead architects and team leaders where discussions of project management reports, weekly project team meetings, fortnightly supplier meetings and weekly programme board meetings will take place. ^[9]

Quality plan

Project quality plan is usually written by the IT quality assurance (ITQA) and identifies aspects which will be delivered as part of a project (baselined project plan, business requirements (BRS), use cases , high level design (HLD), software requirements spec (SRS), test scripts, test report, post development review (PDR), stage assessments in a project quality plan). The ITQA also determines when the end stage assessment (ESA) will be taking place. These are basically checkpoints during the life of the project which ensure that a quality product is being delivered. ESA's implies the meeting where considering the baselined project plan to ensure that it is up to date and on schedule, project management reports, project workstream checkpoint reports, team meeting minutes, actions and agenda, project risk and issues log, and a quality plan tip. ^[10]

Initial project plan

Writing the initial plan for project initiation documentation implies adequate reconsideration of proposed date and detail phases accordingly. Often business stakeholders ask projects to be delivered to impossible dates, which requires highlighting of that fact. In that case most of stakeholders are flexible and about to reconsider the launch date or reducing the scope. Relaunching date or reducing the scope need to be supported with justifications, on which stakeholders making a decision of delaying the launch date. The sooner the worker starts building that sort of relationships with stakeholders, the easier it will be later on when more pressing concerns regarding the scope are raised. ^[11]

Project controls

There are specific number of sections, which needed to be completed in terms of controlling the whole project: project controls, project stages and exception process. Those could include budget actuals and forecasts produced for each financial period, exceptions to be escalated to the corporate programme manager, product reviews from the quality plan, project tolerance, risk mitigation plan, identifying project risks and plans for their mitigation, an issues log, existing change control processes, weekly highlight report for corporate program board, weekly supplier meetings, weekly project teams meetings, etc.

Initial risks and issues log

The rule^{[ clarification needed ]} says the more we are about to commit, the more we will need to deliver. The project stages are initiation, requirements, design, development, test, project launch and close with the exception process stage. The last stage is the most unstable, as covers how much the budget, time and project scope could increase without the project being forced to go into exception. In a situation when stakeholders decide to relocate project into exception, a detailed exception plan is needed to be introduced which will replace the versions of the project/stage plans which were in use before the exception. And on top of all this additional paperwork, the project manager will also have to keep the project moving forward and ensure their team is motivated. Once the project initiation document is formally approved, it means that there is an additional contingency to utilize before having to move into exception. This can make all the difference to the successful delivery of a project in much the same way as good cash flow is key to the success of any growing business. ^[12]

Boehm has identified six risk management stages: Identification, assessment, prioritisation, management planning, resolution and monitoring, which take place in project initiation document. ^[13]

Getting a project initiation document approved

The last stage of writing a project initiation document is the approval, which implies the distribution to all stakeholders on the distribution list within the project initiation document and other interested parties such as operations or HR for resources by e-mails with the request of comments. Then the lead of the team will amass the comments, and then it will be followed by the final meeting where stakeholders and interested parties are about to discuss the project initiation document in further detail. It is only after these stages are complete that your project initiation document will be of a sufficient standard to be approved and passed onto the programme board for funding. Depending on the complexity and the size of the project the stages are about to be completed in five informal and four formal reviews. Some problems could appear such as shortage or resources and lack of finance. It is pivotally important to identify how prioritized is your project before starting the project initiation document, which will help to avoid huge expenses if the project is about to appear in an exception stage. ^[14]

Characteristics of project initiation document

Specifying the importance of the project,^{[ clarification needed ]} the project initiation documentation identifies that it is the contract between the project management and sponsor. The aim of the project initiation documentation is understanding the premises of the project. The correct format of project initiation documentation represents the understanding of the background, objectives and benefits. A good project manager is not only interested in delivering an output or a capability to their customer, but interested in the wider context and the benefits that this capability will ultimately bring about. The project initiation documentation identifies what is in scope within the project with the use of flow diagrams and product breakdown structures. The pivotal role plays the identification of responsibilities, which implies roles of project manager, team leader, sponsor, supplier, user representative, stakeholders and members of steering committee. ^[15]

There are key aspects which need consideration before starting a project and creating a project initiation document, such as: how will the project be delivered? What type of approach: variegates techniques (e.g. waterfall, agile methodology)? What ways of communication with stakeholders, keeping on top of risks, issues and changes.

For a project initiation document it is sufficient to include the place, which emphasize on main phases and activities of the project.

The success of the project initiation document and the whole project can build up on visual aspects such as graphics, as a way of galvanizing better visual memorizing of the project.

Risks are needed to be identified before they appear as a problem within the whole project. The problem could be resolved by creating the list of top projects' risks and what precautionary measures have to be taken.

The financial side of the project is needed to be considered. The project initiation documentation scheme needs to be included along any budgetary constrains and provided the assumptions the team used when they estimate as well as details about how often the review will be estimates. The important aspect should avoid isolations, as it might cause mistakes such as spelling or jargon.

In order to improve the project initiation documentation, a presentation could be created, identifying and emphasizing on main points. ^[15]

See also

• Business case
• PRINCE2
• Project management
• Project planning

References

1. Project Initiation and the Project Initiation Document - Retrieved on June 3, 2010
2. Prince 2: A Practical Handbook By Colin Bentley, ISBN   978-0-7506-5330-5
3. Purpose of PID and Related documents, .http://www.my-project-management-expert.com/writing-a-project-initiation-document-intro.html
4. Project Scope Statement in PID, http://www.my-project-management-expert.com/writing-a-project-scope-statement-in-a-project-initiation-document.html
5. Project Backgrounds in Terms of PID, http://www.my-project-management-expert.com/writing-a-project-initiation-document-background.html
6. Assumptions, Dependencies and Constraints of PID, http://www.my-project-management-expert.com/writing-a-project-initiation-document-assumptions.html
7. Project Organization and Governance, http://www.my-project-management-expert.com/writing-a-project-initiation-document-governance.html
8. Draft Project initiation Document, https://www.rbkc.gov.uk/pdf/jsna_pid.pdf
9. Communication Plan, http://www.my-project-management-expert.com/writing-a-project-initiation-document-communications-plan.html
10. Project Quality Plan, http://www.my-project-management-expert.com/writing-a-project-initiation-document-quality-plan.html
11. Project Initial Plan, http://www.my-project-management-expert.com/writing-a-project-initiation-document-initial-plan.html
12. Project Controls in PID, http://www.my-project-management-expert.com/writing-a-project-initiation-document-project-controls.html
13. Boehm, B.W. (1989). Software Risk Management. Washington D.C.: IEEE Computer Society Press.
14. Getting a Project Initiation Document Approved, http://www.my-project-management-expert.com/project-lifecycle-project-initiation-document-approval.html
15. What makes a perfect Project Initiation Document (PID)?, http://www.susannemadsen.co.uk/blog/what-makes-a-perfect-project-initiation-document-pid