Eksempel fra Wikipedia: http://www.bizbodz.com/Management/Project-Management/how-to-write-a- Project-Initiation-Document-1.asp 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 it’s background, deliverables and ownership. One of the most comforting things to have as a Project Manager is a full awareness of the customer’s 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 what’s 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. PID’s 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 PID’s may vary from Project to Project but there are some fundamentals that you should consider including in your PID. Some of the fundamental elements of the document are listed below. What's in a Project Initiation Document The contents of a PID may vary from Project to Project – there are however some key elements: 1. 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. 2. 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 3. 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. 4. 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. 5. 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 10? If it does explain why. 6. Risks Consider any risks that may effect the Project – their likelihood of their occurrence and their possible impact. Include mitigation against the risks that you’ve identified. 7. 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? 8. Project Controls Project controls, help schedule and measure projects - think about whether the Project requires Key Performance Indicators? 9. 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? 10. 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. Summary Constructing a thorough project initiation document is a key part of starting a project. Ensuring that key elements of a project, such as it’s 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 what’s important to your project can be a really valuable activity. Eksempel taget fra OGC: http://www.ogc.gov.uk/documentation_and_templates_project_initiation_docu ment_pid.asp Project initiation document (PID) Purpose: This document defines all major aspects of the project and forms the basis for its management and the assessment of overall success. There are two primary uses of the document: To ensure that the project has a complete and sound basis before there is any major commitment to the project To act as a base document against which the project can assess progress, change management issues, and ongoing viability questions. For construction projects, the content of the Project Initiation Document is set out in the Project Execution Plan. Fitness for purpose checklist: • Does the document correctly represent the project? • Does it show a viable, achievable project that is in line with corporate strategy, or overall programme needs? • Is the project organisation structure complete, with names and titles? • Have all the roles been considered? • Does it clearly show a control, reporting and direction regime that is implementable, and appropriate to the scale, business risk and business importance of the project? • Is the project organisation structure backed up by agreed and signed job definitions? • Are the relationships and lines of authority clear? • Does the project organisation structure need to say to whom the Project Board reports? • Do the controls cover the needs of the Project Board, Project Manager and Team Managers? • Do the controls satisfy any delegated assurance requirements? • Is it clear who will administer each control? Suggested content: o As a minimum the document should answer the following fundamental questions about the project: o What the project is aiming to achieve o Why it is important to achieve it o Who will be involved in managing the process and what are their responsibilities o How and when the project will be undertaken o The PID has to answer the above questions to a sufficient level of detail to maintain control of the project. The document should cover the following areas: o Background, explaining the context of the project, and how we have arrived at the current position of requiring a project. o Project Definition, explaining what the project needs to achieve. Under this heading will be: - project objectives -defined method of approach -project scope what is included and what not -project deliverables and/or desired outcomes -exclusions -constraints - interfaces -assumptions o Project organisation structure, detailing who is going to be involved and what their responsibilities are (team management structure and job descriptions) o Communication plan, describes how the project stakeholders will be kept informed during the project o Project quality plan o Project controls, laying down how control is to be exercised within the project, and the reporting and monitoring mechanisms that will support this o Business case, covering the estimated costs, risks and benefits. The Business Case will require regular review throughout the project and may require updating o Initial project plan. The plan will be reviewed and further developed at regular intervals during the project o Risk register containing details of the identified risks so far. The Risk Register will be reviewed at regular points during the project to assess progress on managing risks and to identify new risks that may have appeared Source information: o Any information from senior management that has an impact on the project e.g. initial projects briefs, minutes of meetings, information from corporate programmes o Information from other/similar projects and lessons learned reports of other projects o Project management standards of any development team that is contributing to the work of the project o Specific control requirements of the business area or customer who the work is being done for Notes: The Project Initiation Document will need to be formally approved and signed off by the Senior Responsible Owner at the end of the initiation stage of the project. It is typically assembled by the Project Sponsor/Project Director and parts of it may be updated and refined throughout the project life cycle up to and including project closure. The Project Initiation Document is not necessarily one document, but can be a set of documents. It is likely to be developed through several reiterations. It will have stable elements and dynamics ones which will need to have new versions created as the project progresses. Ensure that the presentational aspects of the Project Initiation Document are thought through. The complete product can be large when all the detailed Product Descriptions and job definitions are included. It can be daunting to receive the whole document, and in some circumstances this could be counterproductive. Use appendices to hold the detail and only publish these when requested. In the context of OGC construction related projects the PID or its equivalent should be co-ordinated and owned by the Project Owner with much of the content being provided by the project sponsor, manager, team or external parties as required.
Pages to are hidden for
"How to write a Project Initiation Document"Please download to view full document