Project Mandate

Triggers SU Starting up a Project

Identifies the Project Executive

content varies with the project type and size but could include:

Authority  and Objectives

Scope and constraints

Quality expectations

Identifying a Business Case

Identifying the Project Executive and Project Manager

Customer, User and ALL interested parties

SU Starting up a Project, Overview

Use the Project Mandate to:

·          confirm that the project is worthwhile

·          define responsibilities and roles

·          create the Initiation Stage Plan to enter IP Initiating a Project

·          provide information for the Project Brief

·          establish the Project Approach

·          design and appoint the Project Management Team

·          create the Stage Plan

·          help in setting up the Risk Log

This should be a short, inexpensive process

SU1 Appointing a Project Board Executive and a Project Manager

·          identify candidates for the Project Manager and Executive positions

·          verify roles with candidates and Programme Management

·          appoint the Project Executive and Project Manager

SU2 Designing a Project Management Team

·          produce Job Description(s)

·          consider the project   size  +areas of involvement

·          identify required skills and responsibilities

SU3 Appointing a Project Management Team

·          Use Job Description(s) to ensure everyone has a clear understanding of:

o         what they are responsible for

o         who they report to

·          acceptance of roles by the Team Manager

·          file the signed job descriptions

 SU4 Preparing a Project Brief

·          use the Project Mandate to produce:

o         Risk Log

o         Project Brief

o         IP1 Planning Quality

verify Business Case

 SU5 Defining Project Approach

·          produced in-house

·          produced by 3rd party

·          developed in house

·          an 'off the shelf' product

SU6 Planning an Initiation Stage

•    Create Stage Plan for DP1 Authorising Initiation

•    Update Risk Log

Project Brief

basically a mini PID - used as the basis for the PID upon approval

includes:

* Project definition (scope, objectives, constraints, deliverables)

* Business Case outline - reason for this solution

* Quality expectations  * Acceptance Criteria      * Risks

When part of a Programme it supplies the Project Brief

Developed from the Project Mandate be sure that it reflects the Project Mandate

IP Initiating a Project

·    Forms a contract between the Project Manager and the Project Board cementing the  understanding of what will be delivered, how, by when and by whom

·    First step to helping the Project Board to take ownership of the project

·    Defines how quality will be achieved

·    Creates a plan to react to a Customer's quality expectations

At each relevant point consider the Programme as a whole

IP1 Planning Quality

Once authorised by DP1 Authorising Initiation use the following documents:

·          Project Brief

·          Project Approach

•    To produce the Project Quality Plan that should outline:

·          Responsibilities

·          Criteria

·          Sign off sequence

·          Configuration Management Plan

IP2 Plan a Project

·            Produce the Project Plan by using the Project Approach, Project Brief and Project Quality Plan, in particular:

·            Identify the project's product(s)

·            Assess counter measures to all risks

·            Estimate the:

o         Effort,

o         Time and

o         Costs

IP3 Refine Business Case and Risks

·          This process's purpose is primarily to create a Business Case that can be used in the Project Initiation Document.

·          The Business Case is based on the Project Brief's outline Business Case

·          Refine question of "Why?" the project is being done

·          Evaluate Business risks

·          Ensure benefit realisation by User and Customer

·          Discuss issues with Project Board before presenting the Project Initiation Document

·          Update Risk Log

·          Identify negatives and positives

·          Update Project Plan and, if necessary, revise Project Plan

IP4 Setup Project Controls

·        Produce the Communications Plan and Project Controls (will form part of the Project Initiation Document)

·        Estimate and evaluate levels of:

o         Risk and complexity

o         Reporting required

·        Identify:

o         Stakeholders

o         Monitoring mechanisms

o         Resources required

IP5 Setup Project Files

·    Produce the Quality Log, Lessons Learned Report, Issue Log

·    Efficiently store and retrieve the projects documents and products

·    Meet appropriate requirements for:

·    The project's scale, risk and complexity

·    Usability, accuracy, and timely retrieval

·    Auditing requirements (i.e. Lessons Learned Report)

IP6 Assembling a PID

·          Produce a Project Initiation Document

·          Answer the questions What? Why? Who? How ? When?

·          Provide an information base for all involved with the project

·          Forward the PID to DP2 Authorising a Project

DP Directing a Project

·          Carried out by the Project Board Directing a Project is to:

·          Authorise the commitment of resources to a project

·          Ensure Risks are managed

·          Ensure objectives are being met, as laid out in the Business Case

·          Make decisions required by the Project Manager regarding the project

·          Direct, if necessary, a project into premature closure

·          Ensure a clean, orderly closure to a project

·          Responsibility lies with the Project Board

Directing a Project sub-processes are:

DP1 Authorising Initiation

DP2 Authorising a Project

DP3 Authorising a Stage or Exception Plan

DP4 Giving ad hoc Direction

DP5 Confirming Project Closure

DP1 Authorising Initiation

·        Ratify the Project Brief and Business Case

·        Approve the plan to produce the Project Initiation Document Commit resources

·        This process may be shortened when the Project Brief has been provided by the Programme

·        Use the following documents to enable the Project Board to give approval:

o         Business Case

o         Draft Initiation Stage Plan

o         Risk Log

o         Job Description(s)

o         Project Approach

o         Project Brief

DP2 Authorising a Project

·          Give final approval to the Project Initiation Document

·          This stage is combined with DP3 Authorising a Stage or Exception Plan meaning the Project Initiation Document and Stage Plan is approved together

·          Once accepted the Project Initiation Document should be frozen and stored with the Configuration Librarian

·          With the acceptance of the PID comes the Authorisation to Proceed

·          The draft PID comes from IP6 Assembling a PID

·          Authorisation to proceed then passes to CS1 Authorising a Work Package

DP3 Authorising a Stage or Exception Plan

·        An Exception Plan is a Stage Plan under "exceptional circumstances" and are treated in the same way

·        Once approved an Exception Plan becomes a Stage Plan

·        Information required:

o         Current status of the stage or project

o         Forecasts

o         Assess end dates and risk situation

·        Assess the Business Case

·        Combined with DP2 Authorising a Project when seeking Project Initiation Doc

·        Can precede SB5 Reporting Stage End & SB6 Producing an Exception Plan approved Stage Plan or Exception Plan

DP4 Giving ad hoc Direction

·          Outlines the advice and direction to the Project Manager by the Project Board

·          Things to discuss include:

o         Project Board changes

o         Risk

o         Request for Change

o         Statement of concern

o         Off-Specification requests

o         Project Issues

·          This can be useful at any point in the project

·          Highlight Reports from the Project Manager keeps the Project Board formally up-to-date

DP5 Confirming Project Closure

·        Actioned once either the last stage is completed

·        Ensures a clean, orderly closure to a project

·        Ensure an organised hand-over to the Customer

·        Establish a method for evaluating the product

·        Publish and distribute plans for the Post Project Review

·        Ensure there is Customer approval

·        Hand-over configuration management to ensure on-going control

·        Project Closure Notification

·        Often this process is resulted from CS2 Assessing Progress or CS3 Capturing Project Issues and leads to a End Project Report and Post Project Review

CS Controlling a Stage

Outlines the day-to-day responsibilities of the Project Manager including:

o Allocating work                o Checking progress  o Ensuring quality   o Managing changes

o Monitoring risks    o Reporting progress  o Watching deviations

This is an event driven process often triggered in an ad hoc manner

CS1 Authorising a Work Package

·    Enables Project Manager control over commencing and continuing work

·    Involve the Team Manager/Member with the work package creation (including quality expectations)

·    Integrated with Work Package hand-over in MP 1 Accepting a Work Package

CS2 Assessing Progress

·        The Project Manager assesses progress by looking at Checkpoint Reports, Work Packages, and the Quality Log

·        Team Managers use progress and quality information to create a Checkpoint Report for the Project Manager

·        Assess time and resources

Update Stage Plan

CS3 Capturing Project Issues

·          Usually ad hoc - Project Issue are dealt with as they arise

·          Update and categorise Project Issues in the Issue Log

Uses Change Control Approach

 CS4 Examining Project Issues

·        Examine as listed in the Issue Log and identified in CS3 Capturing Project Issues

·        Ensure the following information that effects the project is gathered including:

o         Costs

o         Time-scales

o         Benefit achievement and/or value

o         Risks

·        Update the Risk Log

·        "examining project issues" should be performed on a regular basis

·    Used to update the Risk Log and Issue Log

CS5 Reviewing Stage Status

·    This stage is central to "Controlling a Stage" sub processes

·    By checking Tolerance and the status it is the decision point to either:

o         Issue further Work Packages

o         Issue plan modifications to existing Product Descriptions

·    If the stage is within tolerances and meets the Stage Plan requirements proceed to CS6 Reporting Highlights and CS1 Authorising a Work Package

·    If the stage is outside tolerances proceed to CS8 Escalating Project Issues

Configuration Management should show the status of a stage relative to the original Stage Plan

 CS6 Reporting Highlights

·          Used to meet Communications Plan requirements

·          Create Highlight Report for the Project Board

·          Suggested length no more than 1-2 pages

CS7 Taking Corrective Action

·          Resolve any deviations from the Stage Plan

·          Often incorporated with DP4 Giving ad hoc Direction

·          Identify the cause and effect of the deviation

Update Stage Plan

CS8 Escalating Project Issues

·        Provide recommendations and options to the Project Board

·        Perform impact analysis on both The Customer's and User's Business Case

·        Possible causes:

o   Corrective action forcing the Stage Plan beyond Tolerance

o   Inaccurate estimations

Results in the creation of an Exception Report

CS9 Receiving Completed Work Package

·          To ensure the completed Work Package matches the Product Description

·          Check approvals as laid out in the Acceptance Criteria

·          The Work Package is set as a Baseline and given to Configuration Management

MP Managing Product Delivery

•    Responsibility lies with the Team Manager

•    Encompasses the following responsibilities of the Team Manager, these are to:

o   Ensure work is authorised and agreed

o   Accept and check Work Package

o   Create a Team Plan

o   Ensure work progress and forecasts are assessed

•    Basic objectives:

o   Agree the Work Package with the Project Manager

o   Get the work done

o   Hand back the completed work

•    Managing Product Delivery includes the following processes:

o   MP1 Accepting a Work Package

o   MP2 Executing a Work Package

o   MP3 Delivering a Work Package

MP1 Accepting a Work Package

·          The Team Manager should produce a Team Plan that shows how the Work Package can be completed within the constraints

·          The Team Manager should:

o   Understand reporting requirements

o   Agree tolerance margins for the work package

o   Understand what is to be delivered

o   Accept the constraints (time, cost etc.)

o   Agree on the reasonable requirements for:

    Reporting (including to whom)

    Frequency and detail of Checkpoint Reports (defined in the Stage Plan)

    Quality (as mentioned in the Product Description)

    Procedures (such as updating the Risk Log, Quality Log and

    Risk analysis, planning and resources

MP2 Executing a Work Package

•    The Team Manager is responsible for:

o   Determining the status of the Work Package

o   Controlling risks/and effort

o   Evaluating remaining effort required

o   Creating Status and Progress Reports

o   Ensuring quality checks are carried out

o   Advising the Project Manager of problems

•    It is possible that the organisation carrying out this stage does not use PRINCE2

MP3 Delivering a Work Package

•    During this process the Team Manager has 3 main objectives:       

o   Obtain quality and acceptance sign-off

o   Hand over the products (to Configuration Management)

o   Advise the Project Manager upon completion

·    It is the responsibility of the Team Manager to ensure that the Work Package is handed over correctly

·    The delivery is controlled by Configuration Management

SB Managing Stage Boundaries

•    Responsibility of the Project Manager

•    Basic process:

o   Gather results

o   Plan next stage

o   Update Project Plan and Risk Log if required o   Seek stage approval

•    Key points:

o   Ensure that any changes to the Project Plan still support the Business Case

o   Check the Project Approach and Configuration Management for improvements

o   Options at the end of each stage include redirecting the project or stopping the project

SB Managing Stage Boundaries (cont)

•    Key objectives:

o   Assure the Project Board that products have been completed

o   Provide information about the on going viability of the project

o   Obtain next stage authorisation and Tolerances (cost and time)

o   Update Lessons Learned Log

•    Sub processes include:

o   SB1 Planning a Stage                         o   SB2 Updating a Project Plan

o   SB3 Updating a Project Business Case  o   SB4 Updating the Risk Log

o   SB5 Reporting Stage End                    o   SB6 Producing an Exception Plan

SB1 Planning a Stage

•    Prepare the next Stage Plan from the Project Plan

•    Be sure to include management products (ie PRINCE2 reports and plans)

•    Consult with Project Assurance to check expectations are being met

•    Review the Project Management Team structure for possible changes

SB2 Updating a Project Plan

•    Update from Stage Plan or Exception Plan namely the:

o   Project Quality Plan

o   Project Approach

SB3 Updating a Project Business Case

•    This is an essential process that maintains the project's viability

•    Within the process revise costs, timings and benefits

•    Update Risk Log and Issue Log

•    Changes to the Business Case must be approved by the Project Board

•    Changes can be for the better or worse

SB4 Updating the Risk Log

•    Analysed and updated when a risk has increased, decreased, occured or stayed the same.

•    Each Risk should have an "owner"

SB5 Reporting Stage End

•    Occurs when a stage is nearing an end or an Exception Plan is created

•    Present to the Project Board with the original Stage Plan and a summary of the Issue Log the execution of this stage should have been forecast during CS

SB6 Producing an Exception Plan

•    Undertaken once an Exception Report has been presented to the Project Board and approval has been given to produce an Exception Plan

•    Is due to a stage or the project exceeding Tolerances

•    The execution of this stage should have been forecast during CS Controlling a Stage

CP Closing a Project

·    Produces an End Project Report and Lessons Learned Report

·    Confirms operational and maintenance acceptance of products

·    Ensures a clear end to a project

·    Required because all projects are (and should be) finite

·    Majority of the work is in gaining Project Board approval

·    Closing a Project processes are done in parallel - they do not depend on each other

·    Without a clear project closure there is a tendency to drift into operational management

·    Provides an opportunity to take stock of achievements

·    Sub processes in CP Closing a Project are:

            o   CP1 Decommissioning a Project

            o   CP2 Identifying Follow-on Actions

            o   CP3 Project Evaluation Review

CP1 Decommissioning a Project

·        The Project Manager is responsible for this process

·        Both the Customer and Supplier should be in agreement that the project has come to an end

·        Notify everyone involved about the project closure (Project Closure Notification)

·        Products should be officially handed over

·        Ensure maintenance is in place

·        Create Status Account (using Configuration Management)

CP2 Identifying Follow-on Actions

·          The Project Manager is responsible

·          Document Follow-on Action Recommendations

·          Recommend date for Post Project Review (evaluate the benefits as outlined in the Business Case)

·          Produce plan for Post Project Review

CP3 Project Evaluation Review

•    Assess the project's

o   Results

o   Quality of management

o   Quality of Risks and quality management

•    Identify the lessons learned from the Lessons Learned Report

PL Planning

·          As PRINCE2 is a product based methodology 'what' is to be produced is defined first along with its product description

·          Ensure that the plan includes time and resources for project and quality management

·          The principles are What (e.g. Description and quality), Why and How (e.g. By whom, what sequence)

·          Basic steps (once the what, why and how have been answered):

o   When, by whom

o   Amount of effort that will be required o   Determine how long it will take

o   Determine quality control

o   Calculate costs

o   Decide on budget

o   Assess risks

o   Determine control points

PL1 Designing a Plan

·          The detail level of the plan is determined by the planning approach

·          Identify the maximum length of time and how to measure the quality of the product

·          To achieve required estimations the following my be employed:

o   Computer tools

o   Experienced planners in this area

o   Either top-down or bottom-up estimation

o   Discussions with others

·          Allowances to consider:

o   Change Budget

o   Contingency Plans

·          Responsibility lies with the Project Board

PL2 Defining and Analysing Products

·          Uses Product Based Planning

·          Outline the management of all (Specialist and Management) products and their quality requirements

·          Ensure all the product specifications are approved

·          Sequence these products in order of their creation

PL3 Identifying Activities and Dependencies

•    Completes the Product Flow Diagram

•    Identify activities required by the project from external contractors

•    Estimate interdependencies that may exist between these activities

•    Deal with any dependencies by ensuring they are sequenced appropriately

•    Resource availability is dealt with in PL5 Scheduling

PL4 Estimating

•    The two major steps in estimating are:

o   Identify resources required

o   Estimate effort required for each activity

•    Identify resources and time required for each activity. Be sure to include:

o   Specific skills

o   Degree of confidence and margin of error

o   Assumptions made

o   Level of product and activity understanding

PL5 Scheduling

•    Will be changed and updated to ensure agreement between all parties

•    Steps are:

1.    Create planning network

2.    Assess resource availability

3.    Produce draft schedule and assign responsibilities

4.    Reassess the level of resource usage after reassigning activities

5.    Confirm control points with the Project Board

6.    Calculate resources and costs to produce the plan budget

PL6 Analysing Risks

•    Ensure the cost of avoiding the risk does not exceed the cost of risk itself

•    If there is something not under the control of the Project Manager there IS a risk

•    Evaluate each resource in the project for risk

PL7 Completing a Plan

·        Project descriptions, risk analysis, the schedule and estimations should be consolidated and           presented to the Project Board

·        Product Checklist should have start and end dates

·        Tolerance Margins should be set by the Project Board

·        A GANTT Chart or bar diagram of the Schedule should be included

·        Once approved the Project Board 'freezes' the plan, thereby setting a Baseline

·        Project Manager is responsible

Component 1, Business Case

The business case is the description for the reasons of the project and the justification. Covers the entire scope of change

The most important set of info for the project.

What should it contain?

•    Reasons •    Options •    Benefits Expected •    Risks

•    Cost and Timescale •    Investment appraisal •    Evaluation

Developing the business case

·    Executive is the owner

·    Project mandate is used to develop the information required for the business case.

·    During project start up the BC is updated to provide more detailed information on the benefits, risks, options, and costs. PP gives a clearer view of this.

·    Formal approval of the business case is required by the executive

·    During each stage of the project the BC is reviewed

·    BC provides all stakeholders with basic info on the project. CP covers when BC info is communicated to stakeholders.

·    At project close the BC confirms project has delivered

At project close the BC is the basis for the post project review plan.

Component 2, Organisation

Four layers

•    Corporate or programme management

•    Direction (PB)

•    Day to day management (PM)

•    Team management and product delivery ( TM)

Three project interests

•    Business - Should meet a business need

•    User - use, achieve objective, benefits, impact •    Supplier - skill supplier  

Senior Supplier

•    Needs to achieve results required by senior user

•    Within timescale and costs

Project Assurance (Optional)

•    All appointments independent of the PM and made by the PB

Project Support  (Optional)

PM may need admin help

Role can include configuration librarian

Organisation, Project Executive

ultimately responsible for the project supported in the Project Board by the Senior User and Senior Supplier owns the Business Case balances the demands of the User, Supplier and Business responsibilities include:

·          approve Project Board

·          ensuring tolerance is set in the Project Brief

·          approving End Project Report and Lessons Learned Report