Content deleted Content added
No edit summary |
m Removed erroneous space and general fixes (task 1) |
||
| (14 intermediate revisions by 11 users not shown) | |||
Line 1:
{{Short description|Crucial process of a business project}}
{{Multiple issues|
{{Technical|date=April 2017}}
Line 4 ⟶ 5:
{{more citations needed|date=April 2017}}
}}
The '''project
▲The '''project initiation documentation''' ('''PID''') is one of the most significant [[Artifact (project management)|artifacts]] in [[project management]], which provides the foundation for the business project.
The project initiation documentation bundles the information, which was acquired through the [[PRINCE2#Seven Processes|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|date=April 2017}}
Line 11:
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 management)|Scope]]
Line 24:
* 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]]<ref>{{Cite web |last=Schwartz |first=Brenna |date=2023-07-26 |title=How to Create a Project Initiation Document (Template Included) |url=https://www.projectmanager.com/blog/project-initiation-document |access-date=2024-11-23 |website=ProjectManager |language=en-US}}</ref> 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 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 [[Executive sponsor|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.<ref>[http://www.pmhut.com/project-initiation-and-the-project-initiation-document-pid Project Initiation and the Project Initiation Document] - ''Retrieved on June 3, 2010''</ref>
Line 39 ⟶ 38:
=== Purpose ===
The purpose of the project initiation document is to capture and record
=== Project scope statement ===
Line 46 ⟶ 45:
=== 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
=== Assumptions, dependencies and constraints ===
Line 52 ⟶ 51:
</ref>
===
In order to complete the
</ref> The SMG (Senior Management Group) will be notified of key findings and developments.<ref>Draft Project initiation Document, https://www.rbkc.gov.uk/pdf/jsna_pid.pdf</ref>
Line 60 ⟶ 59:
=== 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'', ''[[
=== Initial project plan ===
Line 69 ⟶ 68:
=== Initial risks and issues log ===
The rule{{clarify|date=November 2021}} says the more we are about to commit, the more we will need to deliver. The [[Project|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.<ref>Project Controls in PID, http://www.my-project-management-expert.com/writing-a-project-initiation-document-project-controls.html</ref>
Boehm has identified six risk management stages: Identification, assessment, prioritisation, management planning, resolution and monitoring, which take place in project initiation document.<ref>{{Cite book|title = Software Risk Management|last = Boehm|first = B.W.|publisher = IEEE Computer Society Press|year = 1989|___location = Washington D.C.}}</ref>
=== 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
▲The last stage of writing a project initiation document is the approval, which implies the distribution to all stakeholders on the sistribution list within the project initiation document and other interested parties such as operations or [[Human resources|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.<ref>Getting a Project Initiation Document Approved, http://www.my-project-management-expert.com/project-lifecycle-project-initiation-document-approval.html</ref>
== Characteristics of project initiation document ==
Specifying the importance of the project,{{clarify|date=November 2021}} 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 diagram]]s and [[product breakdown structure]]s. The pivotal role plays the identification of responsibilities, which implies roles of project manager, [[team leader]], sponsor, [[Suppliers|supplier]], user representative, stakeholders and members of [[steering committee]].<ref name=":0" />
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 model|waterfall]], [[Agile software development|agile methodology]])? What ways of communication with stakeholders, keeping on top of risks, issues and changes.
Line 84 ⟶ 82:
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
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.
Line 90 ⟶ 88:
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 [[Estimation (project management)|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
==See also==
| |||