Mountainview ITSM

Certification

ITIL  PRINCE2  20000  27000

 

 

Venues

eLearning  Virtual  Classroom  Exam Only

 

 

Courseware

License  Corporate

 

 

References

Free downloads  Primers  Reviews  Search

Select Primer: Navigator  ITSM  ITIL  20000  27000  38500  COBIT  TOGAF  PMBoK  PRINCE2  Six Sigma

PRojects IN Controlled Environments (PRINCE) Primer

Overview

PRojects IN Controlled Environments (PRINCE) is a project management method. It covers the management, control and organisation of a project. "PRINCE2" refers to the second major version of this method and is a registered trademark of the Office of Government Commerce (OGC), an independent office of HM Treasury of the United Kingdom.  Click to download the PRINCE2 Overview.pdf

History

PRINCE2 is derived from an earlier method called PROMPTII, and from PRINCE project management method, which was initially developed in 1989 by the Central Computer and Telecommunications Agency (CCTA) as a UK Government standard for information systems (IT) project management; however, it soon became regularly applied outside the purely IT environment.  PRINCE2 was released in 1996 as a generic project management method.  The current version is PRINCE2 Edition 2009.

Structure

The PRINCE2 method addresses project management with four integrated elements: Principles, Themes, Processes and the Project Environment.

Principles

  • Continued business justification
  • Learn from experience
  • Defined roles and responsibilities
  • Manage by stages
  • Manage by exception
  • Focus on products
  • Tailor to suit the project environment

Themes

  • Business Case
  • Organization
  • Quality
  • Plans
  • Risk
  • Change
  • Progress

Processes

Starting up a project

In this process the project team is appointed and a project brief (describing, in outline, what the project is attempting to achieve and the business justification for doing so) is prepared. In addition the overall approach to be taken is decided and the next stage of the project is planned. Once this work is done, the project board is asked to authorize the next stage, that of initiating the project.

Key activities include: appointing an executive and a project manager; designing and appointing a project management team; preparing a project brief; defining the project approach; and planning the next stage (initiation).

Initiating a project

This process builds on the work of the start up process, and the project brief is augmented to form a Business case. The approach taken to ensure quality on the project is agreed together with the overall approach to controlling the project itself (project controls). Project files are also created as is an overall plan for the project. A plan for the next stage of the project is also created. The resultant information can be put before the project board for them to authorize the project itself.

Key activities include: planning quality; planning a project; refining the business case and risks; setting up project controls; setting up project files; and assembling a Project Initiation Document.

Directing a project

This process dictates how the Project Board (which comprises such roles as the executive sponsor or project sponsor) should control the overall project. As mentioned above, the project board can authorise an initiation stage and can also authorize a project. Directing a Project also dictates how the project board should authorize a stage plan, including any stage plan that replaces an existing stage plan due to slippage or other unforeseen circumstances. Also covered is the way in which the board can give ad hoc direction to a project and the way in which a project should be closed down.

Key activities include: authorising initiation; authorising a project; authorising a stage or exception plan; giving ad-hoc direction; and confirming project closure.

Controlling a stage

PRINCE2 suggests that projects should be broken down into stages and these sub-processes dictate how each individual stage should be controlled. Most fundamentally this includes the way in which work packages are authorised and received. It also specifies the way in which progress should be monitored and how the highlights of the progress should be reported to the project board. A means for capturing and assessing project issues is suggested together with the way in which corrective action should be taken. It also lays down the method by which certain project issues should be escalated to the project board.

Key activities include: authorising work package; assessing progress; capturing and examining project issues; reviewing stage status; reporting highlights; taking corrective action; escalating project issues; and receiving a completed work package.

Managing stage boundaries 

The Controlling a Stage process dictates what should be done within a stage, Managing Stage Boundaries (SB) dictates what should be done towards the end of a stage. Most obviously, the next stage should be planned and the overall project plan, risk log and business case amended as necessary. The process also covers what should be done for a stage that has gone outside its tolerance levels. Finally, the process dictates how the end of the stage should be reported.

Key activities include: planning a stage; updating a project plan; updating a project business case; updating the risk log; reporting stage end; and producing an exception plan.

Managing product delivery

The Managing product delivery process has the purpose of controlling the link between the Project Manager and the Team Manager(s) by placing formal requirements on accepting, executing and delivering project work. The Objectives of the Managing Product Delivery process are: - To ensure that work on products allocated to the team is authorised and agreed, - Team Manager(s), team members and suppliers are clear as to what is to be produced and what is the expected effort, cost and timescales, - The planned products are delivered to expectations and within tolerance, - Accurate progress information is provided to the Project Manager at an agreed frequency to ensure that expectations are managed.

The key activities are: Accept a work package, execute a work package and deliver a work package.

Closing a project

This covers the things that should be done at the end of a project. The project should be formally de-commissioned (and resources freed up for allocation to other activities), follow on actions should be identified and the project itself be formally evaluated.

Key activities include: decommissioning a project; identifying follow-on actions; and project evaluation review.

World-wide Accedited ITIL Training and Courseware

  

Contact us   Accreditation  About us   Consult & Audit  Partners   Alumni   Trainers  Careers

AXELOS Partner

TwitterGoogle +1StumbleuponFacebook LikeLinkedinPinterest

   Mountainview ITSM 1992-2018

Trademarks and Terms & Conditions of Use

No part of this website may be reproduced in any form without the written permission of both Mountainview and AXELOS Limited. Permission can be requested at Mountainview and licensing@AXELOS.com.