How to write a Project Initiation Document A project initiation document is a reference document produced at the outset of a project.

It contains a range of information pertaining to the project including its background, deliverables and ownership. One of the most comforting things to have as a Project Manager is a full awareness of the customers requirements, the deliverables and the knowledge that the project has strong foundations with both firm ownership and sound business case. Capturing and documenting key information such as this. before a Project kicks off is an essential activity and a Project Initiation Document or PID provides a place to store it. Project Initiation Documents are nothing new and are part of many formal Project Methodologies. Too often when projects have problems, attempting to understand whats going wrong and why can be difficult. In a poor project environment things often go undocumented, and trying to unravel something that was agreed in conversation can be fraught. PIDs are good practice as they capture key information that can be used for reference throughout a project for guidance or when clarification is required. They also provide a method of communicating the benefits and business case that prove a project should be commenced in the first place. Producing the PID at the right time is essential the PID should be produced while the Project is being started. It can be authored by a mix of the customer and the Project Manager and should ultimately summarize your project in one document. As Projects can be big/small, simple/complicated the actual construction of PIDs may vary from Project to Project but there are some fundamentals that you should consider including in your PID. What's in a Project Initiation Document The contents of a PID may vary from Project to Project there are however some key elements: Project Goals Layout in simple terms the goals of the project this should include reference to the rationale behind the goal for example a project goal could be to reduce the risk of legacy technology by introducing a new ERP system. Notice there is a difference between Goals/Objectives and Deliverables. Deliverables What will the project Deliver? for example is the project to deliver a written report, is it delivering a new IT system, is it delivering training there may be multiple deliverables that need to be documented ensure that the deliverables are measurable, so it can be proved beyond reasonable doubt that tasks have been completed Scope What is the scope of the project for example is the scope implement IT solution for Australian user base. Note this should clearly explain who the project will be done to and anything that is excluded. Summary Constructing a thorough project initiation document is a key part of starting a project. Ensuring that key elements of a project, such as its goals and business case, are well

understood is imperative. A PID can be referenced throughout a project and serves as a valuable route map for the Project team. Whilst their contents may vary getting down whats important to your project can be a really valuable activity. Initiation The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the businesss needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. The initiation stage should include a cohesive plan that encompasses the following areas: Study analyzing the business needs in measurable goals. Review of the current operations. Conceptual design of the operation of the final product. Equipment requirement. Financial analysis of the costs and benefits including a budget Select stake holders, including users, and support personnel for the project. Project charter including costs, tasks, deliverables, and schedule. Planning and design After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensure that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that: Satisfies the project sponsor, end user, and business requirements. Functions as it was intended. Can be produced within quality standards. Can be produced within time and budget constraints.

Financial Business Case The business case should contain details of the expected costs of the Project. The Business Case should also indicate any savings that may result from the project some business cases take a multi-year approach (e.g. 5 years) looking at the long term impact of the financial commitment. Project Roles and responsibilities A clear part of the PID is clearly outlining the authorities within a project. The PID should outline the Project structure e.g. sponsor, steering team, project manager, Project team and their levels of responsibilities you may even consider drawing up job descriptions for the people within the team. The PID should define the resource requirement for running the project for example does the Project require a team of 15? If it does explain why.

Risks Consider any risks that may effect the Project their likelihood of their occurrence and their possible impact. Include mitigation against the risks that youve identified. Assumptions/Constraints Are there any assumptions or constraints that you need to make about the Project? for example an assumption of introducing a new IT system may make some assumptions about what applications the system may integrate with? Project Controls Project controls, help schedule and measure projects - think about whether the Project requires Key . Performance Indicators & Reporting framework Consider what information channels will be required during the project will a monthly summary report to the Project Sponsor suffice? Or will it need something else? PID Sign off At sign off it is important to assess the PID and ask if it adequately represents the Project is possible ensure that the customer of the Project signs the document as part of its release. Closing and Maintenance Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. Maintenance is an ongoing process, and it includes: Continuing support of end users Correction of errors Updates of the software over time. In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope changes. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, asbuilts. The requirement for providing them is a norm in construction contracts.