|
|
| Line 5: |
Line 5: |
| | [http://geilenkotten.homeunix.org/geilenkotten/nicola Old Website] | | [http://geilenkotten.homeunix.org/geilenkotten/nicola Old Website] |
| | | | |
| − | Project plan | + | Project plan [http://www.ogc.gov.uk/sdtoolkit/reference/documentation/p05_pid.html] |
| − | 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:
| + | |
| − | | + | |
| − | As a minimum the document should answer the following fundamental questions about the project:
| + | |
| − | | + | |
| − | *
| + | |
| − | | + | |
| − | What the project is aiming to achieve
| + | |
| − | *
| + | |
| − | | + | |
| − | Why it is important to achieve it
| + | |
| − | *
| + | |
| − | | + | |
| − | Who will be involved in managing the process and what are their responsibilities
| + | |
| − | *
| + | |
| − | | + | |
| − | How and when the project will be undertaken
| + | |
| − | | + | |
| − | 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:
| + | |
| − | | + | |
| − | *
| + | |
| − | | + | |
| − | Background, explaining the context of the project, and how we have arrived at the current position of requiring a project.
| + | |
| − | *
| + | |
| − | | + | |
| − | Project Definition, explaining what the project needs to achieve. Under this heading will be:
| + | |
| − | o
| + | |
| − | | + | |
| − | project objectives
| + | |
| − | o
| + | |
| − | | + | |
| − | defined method of approach
| + | |
| − | o
| + | |
| − | | + | |
| − | project scope what is included and what not
| + | |
| − | o
| + | |
| − | | + | |
| − | project deliverables and/or desired outcomes
| + | |
| − | o
| + | |
| − | | + | |
| − | exclusions
| + | |
| − | o
| + | |
| − | | + | |
| − | constraints
| + | |
| − | o
| + | |
| − | | + | |
| − | interfaces
| + | |
| − | o
| + | |
| − | | + | |
| − | assumptions
| + | |
| − | *
| + | |
| − | | + | |
| − | Project organisation structure, detailing who is going to be involved and what their responsibilities are (team management structure and job descriptions)
| + | |
| − | *
| + | |
| − | | + | |
| − | Communication plan, describes how the project stakeholders will be kept informed during the project
| + | |
| − | *
| + | |
| − | | + | |
| − | Project quality plan
| + | |
| − | | + | |
| − | Project controls, laying down how control is to be exercised within the project, and the reporting and monitoring mechanisms that will support this
| + | |
| − | | + | |
| − | *
| + | |
| − | | + | |
| − | Business case, covering the estimated costs, risks and benefits. The Business Case will require regular review throughout the project and may require updating
| + | |
| − | *
| + | |
| − | | + | |
| − | Initial project plan. The plan will be reviewed and further developed at regular intervals during the project
| + | |
| − | *
| + | |
| − | | + | |
| − | 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:
| + | |
| − | | + | |
| − | *
| + | |
| − | | + | |
| − | Any information from senior management that has an impact on the project e.g. initial projects briefs, minutes of meetings, information from corporate programmes
| + | |
| − | *
| + | |
| − | | + | |
| − | Information from other/similar projects and lessons learned reports of other projects
| + | |
| − | *
| + | |
| − | | + | |
| − | Project management standards of any development team that is contributing to the work of the project
| + | |
| − | *
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − |
| + | |
| − | Further information:
| + | |
| − | | + | |
| − | See the briefing: Project management; see also document outlines for project brief, project plan and project execution plan.
| + | |
| − | | + | |
| − | Managing Successful Projects with PRINCE 2
| + | |
