How to write a Project Initiation Document by vaj64091

VIEWS: 58 PAGES: 6

									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.

								
To top