IT:PM:Methodologies:PRINCE2

• Acronym for: “PRojects IN Controlled Environments, version 2)”
• PRINCE2 is a process-driven project management methodology.
• Based on 7 principles, 7 themes and 7 processes:
  • 7 Principles:

    • Continued business justification,
    • learn from experience,
    • defined roles and responsibilities,
    • manage by stages,
    • manage by exception,
    • focus on products
    • tailored to suit the project environment;
    • 7 Themes:
    • business case,
    • organization,
    • quality,
    • plans,
    • risk,
    • change
    • progress;
    • 7 Processes:
    • SU: Starting up a project
    • IP: Initiating a project
    • DP: Directing a project
    • CS: Controlling a stage
    • MP: Managing product delivery
    • SB: Managing stage boundaries
    • CP: Closing a project
    • Deliverables:
    • Business Case
    • Project Brief
    • Risk Registar
    • Quality Registar
    • Issue Registar
    • Lesson Log
    • Daily Log

• Project Mandate:
  • When:
    • Before a Project starts
  • By:
    • Sponsor
  • Purpose:
    • Request for a project
• Business Case:

  • When:
    • Written at project start
  • By:
    • project manager, or project sponsor
  • Purpose:
    • Justify the project and outline the expected benefits – typically financial.
  • Contains:
    • Project Purpose
    • Drivers/Reasons for doing the project
    • Options explored
    • Benefits
    • Risks
    • Costs
    • Timescales
    • Cost-benefit analysis

  * Project Brief:

  • When:
    • Written at the project start
  • By:
    • PM
  • Purpose:
    • Outline the project.

      • Eventually incorporated into the project initiation document.
      • Intended to give stakeholders a picture of the project and what it will involve.
      • Contains:
      • Project background
      • The objectives of the project
      • Scope
      • Deliverables (products)
      • Constraints
      • Assumptions
      • Business case
      • Risks
      • Quality expectations
      • Acceptance criteria
      • Plan and timeline
      • Review and reporting
      • Budget

      * Project Approach

  • When:
  • By:

    • SME (Technical Lead/Product Manager) or PM
    • Purpose:
    • Outlines in detail how the team intends to complete the project.
    • Can include alternative routes considered.
    • Demonstrates that the project is feasible, and that the team have the skills, know-how and capacity to complete it.
    • Contains:
    • What does it contain?
    • Solution/product to be created
    • Description of approach
    • Alternative options explored (if necessary)
    • Type of solution(s)
    • Justification for approach
    • Who is responsible for creating it?

    * Project Initiation Document (PID)

  • When:
    • Early stages of the Project
  • By:
    • PM
  • Purpose:
    • The Initiation Document is the fully detailed document

      • Signed off by the project board before work starts.
      • One of the most important documents on a project.
      • Contains:
      • A summary of documents preceding it, such as the project approach, communication plan.
      • Project description
      • Project approach
      • Business case
      • Team/organization structure
      • Roles and responsibilities
      • Quality management plan
      • Configuration management
      • Risk management
      • Communication plan
      • Project plan
      • Project controls

      * Checkpoint Report

  • When:
  • By:
    • PM or Team lead
  • Purpose:
    • A snapshot of the status of the project at any point in time.
    • Produced at regular intervals during the project (at the project manager's request).

      • Its purpose is to ensure that everything is on track.
      • Contain:
      • Report date and reporting period
      • Work in progress
      • Work completed
      • Work planned
      • Lessons
      • Work package tolerance status
      • Issues
      • Risks
      • Who is responsible for creating it?

      * Quality Plan/Quality Management Strategy:

  • When:
  • By:
    • PM or Test Manager
  • Purpose:
  • Defines clear expectations of what quality the product will need to meet, and how this will be measured and controlled throughout the project.
  • Contains:
    • Quality management procedure (this can be an existing in-house procedure if available)
    • Tools and techniques
    • Quality records
    • Reporting
    • Timescales
    • Roles and responsibilities
• Communications Plan
  • When:
  • By:
    • PM
  • Purpose:
    • A communication strategy for the project.

      • It is intended to agree at the start how information should be communicated during the project, and who should be on the distribution list.
      • Contains:
      • Procedures
      • Tools and techniques
      • Records
      • Reporting
      • Timing
      • Roles and responsibilities
      • Stakeholder analysis

      * End Stage Report:

  • When:
  • By:
    • PM
  • Purpose:
    • A summary report for the project board covering the status of all activity that has taken place during that stage.

      • Used by the project board to decide if the project should move forward to the next stage.
      • Contains:
      • A summary report from the project manager
      • Business case review
      • Review of project objectives
      • Review of stage objectives
      • Review of team
      • Review of products
      • Lessons
      • Issues
      • Risks
      • Forecast

      * End Project Report

  • When:
  • By:
    • PM
  • Purpose:
    • Similar to the End Stage Report, but is the final report at the end of the project.

      • It also includes any lessons to come out of the project.
      • Contains:
      • Summary report from the project manager
      • Review of the business case
      • Review of the project objectives
      • Review of products
      • Team performance
      • Lessons learned
      • Who is responsible for creating it?

      * Exception Report:

  • When:
  • By:
    • PM
  • Purpose:
    • Every project has a given tolerance - slack to alter the plan without needing additional authorization.

      • Outside of this tolerance (eg: a deadline slips), then an exception report is raised and sent to the project board.
      • Contains:
      • Description of the exception(s)
      • Causes
      • Consequences
      • Options
      • Recommendations
      • Who is responsible for creating it?

      * Highlight Report

  • When:
  • By:
    • PM
  • Purpose:
    • A status summary of the project.

      • It is intended as a written communication about the project to interested parties and senior executives (mainly the project board) to help monitor progress.
      • Contains:
        • High level project status
        • Activities in progress
        • Work completed
        • Variance from plan
        • Quality review
        • Issues
        • Risks
        • Change control
        • Budget
        • Work planned next period
        • Who is responsible for creating it?

      * Work Package

  • When:
  • By:
    • PM
  • Purpose:
    • Outlines the description of each package of work that is assigned to an individual or team within a project.

      • It explains what needs to be achieved, any what end result is expected.
      • It is intended to provide a written guideline to everyone working on the project, so that work expectations are clear and carefully communicated.
      • Contains:
      • Team manager's name
      • Workpackage description
      • Procedures
      • Constraints
      • Interfaces
      • Tolerances
      • Reporting arrangements
      • Escalations
      • Approvals

      ### Questions to ask

• Who is on the Project Board?

* Key activities:

• Forming the project board;
• appointing an executive and a project manager;
• designing and appointing a project management team;
• preparing a project brief;
• defining the project approach;
• preparing an outline business case,
• consulting the Lessons Logs of previous projects;
• planning the next stage (initiation).

* Deliverable: Project Brief

• This process builds on the work of the start up process, and the project brief is used to prepare other management documents that will be needed during the project. For example, the approach taken to ensure quality throughout 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. The business case is completed. 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;
• assembling a Project Initiation Documentation.

* Deliverables:

• Project Initiation Documentation

This process dictates when the Project Board (which comprises such roles as the executive or sponsor) should control the overall project. As mentioned above, the project board must authorise the initiation stage and also authorize the project. Directing a Project also dictates how the project board should authorize a stage plan, including any exception 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 the 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.

PRINCE2 suggests that projects should be broken down into stages and this process dictates 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 packages; assessing progress; capturing and examining project issues; monitoring and controlling risks; reviewing stage status; reporting highlights; taking corrective action; escalating project issues; and receiving completed work packages.

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.[6] 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, timescales and quality, 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.

Main article: Managing stage boundaries Whereas 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 register 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 register; reporting stage end; and producing an exception plan. Best practice includes the project board, including users, reviewing progress and approving any changes to the project plan at the boundary. This review can include team managers for valid experience based opinions; and the responsibility of the project manager include to present their area of work competently to the board.

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; preparing a benefits review plan and project evaluation review. The benefits review plan indicates a time when the benefits of the end product may be measured, how and what resources will be required. Management product

• https://en.wikipedia.org/wiki/PRINCE2
• http://hubpages.com/business/Preparing-For-A-Project-Manage-Interview-Brush-Up-On-Your-PRINCE2-Documentation