Managing Level 2 Projects

Authorisation

Action

Information

Technique

Template

1. Introduction

This guide has been created to assist with the effective management of Level 2 projects. Level 2 projects will typically be:

Cost/Value: £100,000 - £5,000,000
Effort: 75+ days
Timescale: 6 to 24 months
Risk Level: Low, Medium and High levels of risk
Nature: Complex / Formal
Approach: Internal/external approved suppliers development; Cross department delivery

Managing this work as a project will help to:

Increase the understanding of what is expected
Provide a common understanding of constraints
Reduce the need for re-work
Improve the communication between the teams
Establish a system for when things may go wrong

1.1 Authorisation Points

Level 2 projects require a minimum of five End Stage Assessments (ESAs). These can be either formal meetings or informal discussions between the Project Board and the Project Manager (or a mixture of both). The ESAs for Level 2 projects are:

Prior to Start-Up in the form of a Project Mandate
At the end of Start-Up to officially start the project.
At the end of the Initiation Stage to approve the PID.
At the end of each Management Stage. There may be many of these.
At the end of the project for final closure.

The process diagram below relates these authorisation points to the Gateway Review Process. All authorisation should be recorded and filed in the Project File.

1.2 People

As a minimum Level 2 projects require a full Project Board and a Project Manager. The Project Board will make decisions on the project, and the Project Manager will manage the project under the direction of the Project Board.

2. Level 2 Projects

The table below gives information on who will be operating in which Process, and lists the Management Products that should be created for Level 2 Projects

Processes/Stages	Management Products	Who’s Responsible?
Before Start-Up	Project Mandate	Project Board
Directing A Project	End Stage Assessment A	Project Board
Start-Up	Daily Log Lessons Log Business Case Project Product Description Project Approach Project Brief Organisation Initiataion Stage Plan	Project Manager
Directing A Project	End Stage Assessment A2	Project Board
Initiating a Project	Configuration Management Strategy Issue Register Quality Management Strategy Quality Register Communication Management Strategy Risk Management Strategy Risk Register Project Plan Business Case Benefits Review Plan Project Controls Project Initiation Documentation Stage Plan	Project Manager & Project Board
Directing A Project	End Stage Assessment B	Project Board
Controlling a Stage	Work Package Quality Register Checkpoint Report Highlight Report Risk Register Issue Report Issue Register Exception Report Exception Plan Lessons Report End Stage Report Stage Plan	Project Manager
Directing A Project	End Stage Assessment C	Project Board
Closing a Project	Customer Acceptance End Project Report Lessons Report Follow-on Actions Benefits Review Plan Business Case	Project Manager
Directing A Project	End Stage Assessment D	Project Board

Level 2 Projects - Process Diagram

3. Project Start-Up

Before starting a project, there must be a Project Mandate. Issued to the Project Board Executive by the Corporate/Programme Management, it should provide sufficient information for Start-Up to be completed. The decision to begin the Startup of a project will be taken at a meeting called "End Stage Assessment A".

When starting projects there could be a number of triggers that combine to perform the function of a Project Mandate. These triggers can be synonymous with decisions and information used within the Gateway Review Processes 0, 1 and 2. This Information is used by the Project Board Executive and the Project Manager to complete the Start-Up stage.

The objective of Project Start-Up is to establish whether the proposed project is worth officially starting. To support this decision there needs to be a number of Management Products created to provide a “terms of reference” for the project.. The minimum requirement is the Project Mandate, Project Brief and Business Case. Other Management Products such as the Project Product Description, Project Approach and Organisation should be considered, but may be generated during Initiation.

Much of the information needed for completing Start-Up may already have been created in the Gateway Review Processes 0, 1 and 2 and therefore needs collating into a Project Brief forming the Level 2 projects terms of reference for the Project Board.

For Level 2 projects that are at the top-end of the project level indicator, consideration should be given to managing this “front end” as a separate project. This will be applicable to larger complex projects that require significant input to establish the information required to satisfy this process. This period of work is usually known as a Feasibility Study. When running a Feasibility Study, the controls described in the “Managing Level 2 Projects” guide should be applied.

The following table lists the Management Products that should be considered during Start-Up and Initiation..

Management Product	Information Provided
Daily Log	Captures information on events and issues
Lessons Log	Captures good and bad use of the process
Business Case (Start-Up)	Why are we doing this?
Project Product Description	What needs to be delivered? What quality needs to be achieved?
Project Approach	How can we deliver it?
Project Brief (Start-Up)	Summary - Assembled information from Startup
Organisation Structure	Who should be involved?
Initiation Stage Plan	How much will it cost to set up the project? How long will it take to set up the project?

3.1 Daily Log

The Daily Log is used to record events and discussions that would not need to be recorded and dealt with formally. You should think about the Daily Log and what format this might take during Start-up and Initiation. Examples would be a physical book, a Word file on your desktop, or the use of a structured Outlook folder.

3.2 Lessons Log

The Lessons Log is used to capture good and bad use of the processes and techniques. You should review any related lessons from previous projects during Start-up so that these can be incorporated into your project plans. A mechanism for capturing new lessons using a Lessons Log should be established during Initiation.

A Template for the Lessons Log can be found in the Templates Guide.

3.3 Business Case

All projects must have a Business Case to justify its start and continuation. An Outline Business Case must be created during Startup. This might be a document in its own right, or it may be part of the assembled Project Brief. There may be a Business Case within the Project Mandate, but if not, then one will have to be created prior to the project starting.

At this point there may not be enough information available for detailed timescales and costs, meaning that refined benefits would not be known. As a minimum, the reasons for the project should be documented, as well as the primary expected benefits. Essentially, the Business Case must justify the official start of the project, and if benefits cannot be identified, then the Project Board needs to think carefully about whether to start the project or not.

A Template for the Business Case is in the Templates Guide, and provides advice and guidance for each of the sections. The full information for completing the Business Case will not be available at this early point, so just details of the Reasons for the project, along with expected costs and benefits will suffice. In this context we refer to it as the ‘Outline Business Case’.

If the project is authorised to start following this process, then the Business case will be refined during the Initiation Stage when more informaiton is available.

Further information on the way Business Case is used across Company Name projects can be found in the Techniques Guide.

3.4 Project Product Description

All Level 2 projects must have a Project Product Description written to define the project’s final deliverable. The Project Product Description will include details of Acceptance Criteria for the project which will be used to assess the project’s completion during project closure. It will also include details of the projects major products that are required to be delivered. Ideally be created during Start-up to help understand the final deliverable, the Project Product Description may be created during Initiation when more information is available.

A Template for the Project Product Description is in the Templates Guide, and provides advice and guidance for each of the sections. All sections of the Project Product Description should be completed for Level 2 projects.

3.5 Project Approach

The Project Approach identifies the preferred way to manage and deliver the project. Examples of approaches are to outsource the key development work, buy in a product, or develop something from scratch.

Once decided on the preferred approach, details of any alternative considerations should be included, along with reasons for the chosen approach. A statement for the standards that need observing will give useful information for when you plan the project.

Due to the nature of the work involved with creating the Project Approach, and the decisions that need to be made, you will find that Startup and Initiation will both be used during this activity.

A Template for the Project Approach is in the Templates Guide, and provides advice and guidance for each of the sections. All sections of the Project Approach should be completed for Level 2 projects.

3.6 Project Brief

To establish key information for the proposed project, you should create a Project Brief during Start-up. This will essentially form the terms-of-reference for the project and will provide the base information for the Project Initiation Documentation (PID). The Project Brief should include:

the projects objectives
what will be included within the scope of the project
what needs to be delivered for the project to be accepted
the benefits of undertaking the project

A Template for the Project Brief is in the Templates Guide, and provides advice and guidance for each of the sections. All sections of the Project Brief should be completed for Level 2 projects.

3.7 Organisation

The success of any project relies on the skills and commitment of the people involved. Considerations need to be made during Startup (in particular to the Project Board and Project Manager roles), with refinement of this information being completed during Initiation.

The key mandatory roles for Level 2 projects are described in the following table.

Project Role	Role Description
Project Board	Decision making body and owners of the project. The Project Board gives authorisation and direction to the Project members.
Executive (Project Board)	Ultimate authority for the project and chairperson of the Project Board.
Senior User (Project Board)	Represents the end users and those who will be affected by the project's outcome. Responsible for specifying requirements and accepting products.
Senior Supplier (Project Board)	Represents the specialist interests and commits the technical resources to the project. Assures the integrity of development work.
Project Manager	Day to day management of each stage of the project. Manages the project for the Project Board.
Project Management Office (PMO)	A Support function providing support and guidance primarily to the Project Manager, and also to the rest of the project management team.

3.7.1 Project Board

It is likely that more than one person will be required to assist the decision making and represent service areas such as personnel, finance or technical. To represent these interests a Project Board should be formed.

The Project Board must represent the following interests at all times, represented by the following roles.

Business Interests represented by the Project Board Executive
User Interests represented by the Project Board Senior User
Specialist Interests represented by the Project Board Senior Supplier

The responsibility for the appointments to the Project Board is that of the Executive. A Level 2 Project Board should be made up of a minimum of 2 people and a maximum of 5 people who will represent the three interests above. In all cases the Executive remains the ultimate authority for the project.

Project Assurance must exist in all levels of project. For Level 2 projects, the Project Board should consider delegating some Project Assurance to an additional resource. Any such resource must be independent of the Project Manager. See Techniques section of Guide for more detail.

Decisions also need to be made with regard changes, and whether the Project Board will delegate decisions on changes to a Change Authority, or undertake this role themselves. See Techniques section of Guide for more detail.

3.7.2 Project Manager

The Project Manager’s responsibility is to manage the project for the Project Board. This will include creating and managing the plans, authorising work to the teams, managing issues and risks, working with other resources to ensure the timely delivery of products, and keeping the relevant people involved.

3.7.3 Team Manager

Team Managers should be included on Level 2 projects if there is a need for such appointments. Examples may include managing different locations, managing specific technical work or teams or managing key work streams for the Project Manager.

3.7.4 Project Management Office

All Level 2 projects will require administrative functions to complete. Examples include taking assisting with board meetings, managing and circulating information, managing and tracking changes and issues, managing the filing structure and configuration management system, assistance with the project plans. In the absence of dedicated project support, the Project Manager will pick up these responsibilities.

A full list of organisational roles and responsibilities are in the Techniques Guide. Details of who will be responsible for each role will need to be documented, along with details of their associated responsibilities.

Use the Organisation Structure Template to document who will be involved in the project, and include any modifications to the Responsibilities that are relevant to each role.

3.8 Initiation Stage Plan

All Level 2 projects must have an Initiation Stage to plan and setup the project. Depending on the project, this might be a short Initiation Stage or a long one. Either way, resource will be used, and the use of this resource should be planned and managed to cover the time, effort and resource needed to develop the project understanding to PID level.

The Initiation Stage Plan should be created during Project Start-Up to demonstrate the time, cost and other resources needed to effectively set up the project and create the PID with all its supporting narrative. This plan is then presented to the Project Board; along with the other information generated in this process for authorization and commitment should the project officially start.

A Initiation Stage Plan template is in the Templates Guide and includes a number of sections that should be included for Level 2 projects.

The Techniques Guide has a section of the Company Name recommended steps of planning.

3.9 Preparing for Authorisation

You should now have all the information that the Project Board needs in order to move through Authorisation point B. You should assemble the information so that is easy to view and understand. The Project Brief will essentially provide the vehicle for this information. The information will assist the Executive to decide on whether or not to officially start the project. You should consider creating a short presentation for when you meet with the Executive.

3.10 What next?

The Executive, along with other members of the Project Board will review the information and make a decision on whether to authorise the project to officially start and proceed to the Initiation Stage. This decision is taken in Level 2 projects at a meeting known as “End Stage Assessment A2”.

If the decision is to proceed you will receive authorisation to progress with the Initiation Stage Plan. If the decision is not to proceed, then the information gathered should be archived and made accessible for use with future project requests.

3.11 Information Checklist – Project Start-Up

The following form should be used to monitor and track the information gathered during Project Start-Up and Initiation..

Information Checklist - Project Start-Up & Initiation. Project Name: ………………………………...
Information	v	Completed By	Date	Authorised	Date
Project Start-Up
Daily Log
Lessons Log
Business Case
Project Product Description
Project Approach
Project Brief
Organisation Structure
Initiation Stage Plan

4. Project Initiation

Before the Initiation Stage can start you should have received authorisation from the Project Board. Gateways Review Process 3 helps to provide prerequisite information for Initiation. Details of the authorisation should be recorded and filed in the Project File or Daily Log.

The objective of Project Initiation is to plan the project and set up a management environment that is appropriate to the project. Most of the information that is generated in the Initiation Stage will be assembled into the Project Initiation Documentation (PID).

The following Management Products may have been created during Project Start-Up & Initiation. Any of the following that have not been previously created must be created during Project Initiation.

Daily Log
Lessons Log
Project Product Description
Project Approach
Organisation Structure

You should refer to the section "Project Start-Up" in this Guide for more information on the above Management Products.

The following table lists the Management Products that will be created in this process, and the information each will provide.

Management Product	Information Provided
Configuration Management Strategy	A description of how and by whom the project’s products will be controlled and protected.
Issue Register	A record of all issues that are raised, including the impact of each issue and the actions taken
Quality Management Strategy	A description of the quality management standards and approaches that will be applied to the project.
Quality Register	A record of the checks performed on a product to ensure it meets standards
Communication Management Strategy	A description of the means and frequency of communication between the project and the project’s stakeholders.
Risk Management Strategy	A description of the risk management approaches that will be applied to the project, including analysis metrics and responsibilities.
Risk Register	A list of risks identified, with information on how likely the risk is to happen, and the consequences if it does.
Project Plan	Detailed information that describes the work needed for to be undertaken.
Business Case	The justification for the undertaking and continuation of any project.
Benefits Review Plan	A schedule of when post-project reviews will be carried out to assess whether the expected benefits are being achieved.
Project Controls	A statement of how communication, authorization and control will be managed during the project.
Project Initiation Document	A full set of project information needed to start the project on a sound basis and convey the information to all concerned with the project throughout its life cycle.
Stage Plan	A detailed schedule of what will be done, when and whom.

4.1 Configuration Management Strategy

When managing a project, each product needs to be tracked and managed. The Configuration Management Strategy needs to be created to define how the products will be recorded or named, what version control will be used, what storage and retrieval systems will be used, and who is responsible for undertaking this task.

4.1.1 Setting up the Project Files

To keep track of the management information (i.e. the plans, reports, minutes, etc.) you will need to use an effective filing structure. This structure should be defined in the Configuration Management Strategy. The high-level recommended structure is:

Project File
Stage File (for each stage of the project)
Quality File

The Techniques Guide has a chapter explaining the recommended approach to project filing.

4.1.2 Specialist Products and Change Control

Details should also be laid out referencing the Change Control procedure that will be used during the project. As development progresses, there may be changes requested by the customer, or errors with specialist products by the supplier. All these issues need to be dealt with using the change control procedures. Reference to such procedures, and details of responsibility for this should be defined in the Configuration Management Strategy.

A Template for the Configuration Management Strategy can be found in the Templates Guide.

4.2 Issue Register

An Issue Register must be created during Initiation, usually when preparing the Configuration Management Strategy. This will provide a repository of all Issues that are being handled on a formal basis.

A Template for the Issue Register can be found in the Templates Guide. The format of the Issue Register may be a spreadsheet, as per the template, or a database approach.

Further details on the Issue management approach can be found in the Techniques Guide. This also describes the process and procedures for handling exception situations.

4.3 Quality Management Strategy

A Quality Management Strategy must be created during the Initiation Stage to define and refer to all standards that should be observed throughout the project’s life. This could include industry regulations, policy, legislation and quality procedures. It is not required to copy all standards into the Quality Management Strategy, but rather reference them. Details of tools and techniques, responsibilities, control and reporting should be included.

A Template for the Quality Management Strategy is in the Templates Guide.

4.4 Quality Register

The Quality Register will maintain details of all quality checking. You should create the Quality Register during project initiation, and then populate it with the planned quality activity. As quality checking is carried out, the Quality Register should be updated with the results. This should be done at project level, and during each stage.

A Template for the Quality Register can be found in the Templates Guide.

Details of the Quality Review Technique can be found in the Techniques Guide.

4.5 Communication Management Strategy

A Communication Management Strategy should be created during the Initiation Stage to establish the methods and frequency of communication to people within the project and those external to the project. All communication from the project must be controlled and approved by the Project Board, and the Communication Management Strategy will provide this information.

A Template for the Communication Management Strategy is in the Templates Guide.

4.6 Risk Management Strategy

There needs to be a definition of the project’s approach to identifying, assessing and managing Risk. The Risk Management Strategy needs to be created for this, and should refer to any standard procedures and tools that the organization has in respect of risk.

Included in the Risk Management Strategy should be details of the types of risks that are being identified (e.g. strategic, legislative, technical, operational, environmental, political, economic); how the risks will be assessed (i.e. low, medium and high, or 1-10 score card); and the standard response types that can be used to mitigate the risk (e.g. avoid, fallback, accept).

A Template for the Risk Management Strategy is in the Templates Guide.

4.7 Risk Register

All projects will have an element of uncertainty. Prior to starting any project the risks should be considered. The Risk Register should be created, and all known risks should be entered onto it. The Risk Management Strategy will have defined the processes and procedures for identifying and measuring risks, and this information should be reflected in the format of the Risk Register.

A Template for the Risk Register is in the Templates Guide. All sections of the Project Brief should be completed for Level 2 projects.

More information on how to identify and analyse risks is in the Techniques Guide. You should also draw on the experiences of others when considering risk.

4.8. Project Planning and Stage Planning

You are required to produce a Project Plan during the Initiation Stage. For Level 2 projects is important not to become too detailed when planning the project. The approach taken should be of a high-level approach in order to identify the overall project timescales, costs, dependencies and resources. Depending on the work to be carried out, some parts of the project plan will need to be a little more detailed than others.

When the Project Plan has been created (using the guidance from the Techniques Guide), the key decision points on the plan can be identified, and used to assist in identifying the management stages of the project.

Towards the end of each stage, the subsequent management stage can be planned in more detail (as described in section 4.13). The benefits of this stage-by-stage planning approach include:

Reduction of risk to the firm commitment of the Project Board
Control of the commitment of the funds and resources to each stage
Greater focus on products, resulting in fewer change requests
Greater information of the stage being planned due to more knowledge
More manageable size pieces of work for the Project Manager to plan
Estimate can be based on the experience from previous stages

When defining the management stages on the Project Plan, the Project Board should be consulted for direction on where the key decision points should be. This planning step should be carried out with the project controls in mind. Thought should be given to how increased controls (e.g. communication, work authorisation, etc) can help with planning longer horizons.

4.9 Business Case

All projects must have a Business Case to justify the start and continuation. An Outline Business Case should have been created during the Startup process. Now that the Project Plan has been created and there are more details of timescales and costs, the Business Case needs to be refined. Expected benefits need to be measurable, with a clear indication of how each of the benefits will be measured. There should also be a financial summary of the project that shows the project’s costs, and ongoing maintenance costs for supporting the product. Mapped against this should be the expected benefit so that the net benefits can be assessed. This detailed Business case then provides the ‘Project level’ or ‘Initial’ Business Case for use as the base line for the project.

A Template for the Business Case is in the Templates Guide, and provides advice and guidance for each of the sections

While it is the Project Manager’s responsibility to manage the Business Case, the Project Board Executive ‘owns’ it and is responsible for the benefits being achieved.

Further information on the Business Case can be found in the Techniques Guide.

4.10 Benefits Review Plan

It is necessary to plan for a benefits review to establish whether benefits that were originally identified for the project are indeed being achieved. This is known as a Benefits Review Plan. The Benefits Review Plan should be created during Initiation, and updated at the end of each stage. The actual review itself will happen sometime after the project has finished.

Depending on the project, the review might be planned for 3-12 months after the project has closed. For longer periods of time, a series of review meetings should be planned. You should seek the advice of the Executive when preparing this information.

A Template for the Benefits Review Plan is in the Templates Guide. The Project Manager is responsible for creating the Benefits Review Plan. The Project Board Executive is responsible for conducting the review meetings.

4.11 Project Controls

As the planning is being progressed, details of risks, quality, people, and decision points will become more apparent. Throughout project initiation you should be giving thought to the controls that will be applied to the project. This includes:

How will everyone be kept informed?
How will the decisions be made?
How will work be handled with suppliers?
How will the plans be handled?
How will the products be maintained?
Who is responsible for all of this?

These questions need answering, and should be documented in the PID.

Communication - Verbal, emailed, message-board, or face-to-face?
Reports - Emailed, printed and signed, or presented?
Decisions - All members of Project Board to be present, representatives attending, or tele/web conference?
Work Packages – Formal sign-off, or informal authorisation/handover?
Plans and Produts – Formal configuration management logging all products?

While there is no template for the project controls, there is a section in the PID that requires the controls to be clearly defined. The template for the PID can be found in the Templates Guide

There are many techniques applicable to controls, including Change Control and Quality Review. Techniques Guide has details of these techniques. You will also find more information on other controls such as reports and Work Packages in the ‘Progress’ section of the Techniques Guide.

4.12 Project Initiation Document (PID)

When the PID has been assembled with the project information, it needs to be authorised by the Project Board. The authorised PID will ten be ‘baselined’ – meaning that the baseline version must not be discarded. It should be recognised however that all parts of the PID should be reviewed throughout the project, with changes applied when required (using the change control procedure).

Some parts of the PID will be more volatile that others, and it’s these parts that should be monitored closely (at least at the end of each stage). The three most volatile elements of the PID are the Project Plan, Business Case and Risk Register. Other dynamic content that could change from one stage of the project to the next include the Organisation Structure; Quality Management Strategy; and Communication Management Strategy.

The stable content on the other hand mainly refers to the Project Definition which is be derived from the Project Brief (i.e. objectives, scope, constraints, interfaces, etc.).

When creating the PID, you would expect to involve the Project Board and team members to assist with the Planning, Risk Analysis and Business Case. These components are explained in the Techniques Guide.

When the information is gathered and ready for assembling, it is useful to hold a PID Workshop which pulls the Project Team together while assembling the PID.

A template for the Project Initiation Document is in the Templates Guide.

4.13 Stage Plan

To obtain authorisation and firm commitment of resource to the next stage of the project, a Stage Plan for the next stage needs to be created. To create this plan, you should use the planning steps described in the Techniques Guide.

The Stage level plan will be more detailed that the Project Plan as it is the Stage Plan that contains the detailed activities, dependencies, and criteria for the management and specialist work that should be undertaken.

The Stage Plan is not just be a graphical plan. Other elements should include Product Descriptions, stage organisation structure, details of the stage controls, and a resource summary. A template for the Stage Plan is in the Templates Guide.

4.14 Preparing for Authorisation

You should now have all the information that the Project Board needs in order to consider Gateway Review 3.1 and make decisions during End Stage Assessment B. You should prepare the information so that is easy to view and understand, then ensure its timely circulation to the relevant people. It is important the individuals have time to review this information prior to the End Stage Assessment.

The assembled information will assist the Project Board to decide on whether or not to approve the PID and commit resources to the next stage. You should consider creating a short presentation for when you meet with the Executive.

4.15 What Next?

The Executive, along with other members of the Project Board will review the PID and the Next Stage Plan and make a decision on whether to approve the PID and authorise the project to progress to the next Management Stage. This decision is taken in Level 2 projects at a meeting known as “End Stage Assessment B”. Details of the authorisation should be recorded and filed in the Project File.

Once you have authorisation, you can move onto Controlling A Stage, which is explained in Section 5 of this guide.

4.16 Information Checklist – Project Initiation

The following form should be used to monitor and track the information gathered during Project Initiation.

Information Checklist – Project Initiation Project Name: ………………………………...
Information	v	Completed By	Date	Authorised	Date
Start-Up
Daily Log
Lessons Log
Project Product Description
Project Approach
Organisation Structure
Initiation
Quality Management Strategy
Communication Management Strategy
Risk Management Strategy
Project Plan
Business Case
Benefits Review Plan
Project Controls
Project Initiation Document (PID)
Next Stage Plan
Project Files Issue Register Quality Register Risk Register

5. Controlling a Stage

Before progressing to a management stage, you must have received authorisation of the Stage Plan from the Project Board. You should have presented the Stage Plan for the forthcoming stage at an End Stage Assessment Authorisation B and have had a firm commitment from the Project Board of the required resources. Gateways 3.1 and 3.2 will have been completed as necessary

Controlling a Stage is the process which drives you through each stage of the project. Controlling a stage will be performed more that once as the project is deemed to have more than one management delivery stage. Therefore Authorisation B will occur many times too. This section explains how to:

Manage the stage & report progress
Handle issues and escalate problems when necessary
Handle and manage risks
Delegate work to the project teams
Keep the project plan up to date
Check the quality of products
Prepare for the End Stage Assessment

The following table lists the Management Products that will be created in this process, and the information each will provide.

Management Product	Information Provided
Work Package	Detailed information on the work that needs to be done to develop one or more products
Quality Register	A record of the checks performed on a product to ensure it meets standards
Checkpoint Report	A summary report of work completed by the teams (sent to the Project Manager).
Highlight Report	A summary of progress of the stage to the Project Board
Risk Register	A list of risks identified, with information on how likely the risk is to happen, and the consequences if it does.
Issue Report	A form to capture details of an Issue that is to be handled formally.
Issue Register	A record of all issues that are raised, including the impact of each issue and the actions taken
Exception Report	An alert to the Project Board explaining the details and impacts of a deviation from an agreed plan.
Exception Plan	A detailed schedule that is used to recover a plan which has (or will) exceed its tolerances.
Lesssons Report	Information on what went well, what didn’t go well, and what you recommend for future projects.
End Stage Report	A report that summarises the stage, explaining the products that have been completed and the current situation of project statistics.
Stage Plan	A detailed schedule of what will be done, when and whom.

5.1 Managing the Stage Plan

As work progresses and products are developed, you need to reflect progress on the Stage Plan. The Stage Plan will have been created and authorised prior to starting the stage. Information on creating the Stage Plan is in the Techniques Guide.

Updates to the plan should be carried out when work is authorised to teams; when Checkpoint Reports are received from the teams; when Risks are identified and require attention; and when work is returned from the teams.

Also, as Issues are raised and require action to be taken, it is likely that the plan will need to be modified. Any re-work will need to be planned with consideration to the timescales and resources available to you. You will also need to refer to the plan when reporting progress to the Project Board.

Basically your plan is the backbone to your project. You should keep a close eye on it and ensure that it is kept up to date at all time. Be sure to use the escalation procedure described later in this Section if the plan exceeds the tolerance that has been agreed with the Project Board.

5.2 Work Packages - Getting the work done

The information in this section refers to the “Managing Product Delivery” process in the PRINCE2 Manual and this accommodates the lower levels of working.

All work that is delegated to Team Managers or team members should be clearly outlined by using Work Package prior to starting or authorising work. When delegating work to others, the use of Work Packages provide many benefits to all involved. Work Packages include:

A Product Description of the product(s) to be created
How the work should be managed
Clear understanding of who is responsible for delivering the work
Agreement of timescales, costs and resources required
Clear communication arrangements

An integral part of the Work Package is the Product Description. Company Name is committed to using Product Descriptions to ensure the quality of its deliverables. The Planning section in Techniques Guide gives more information on Product Descriptions.

Each Work Package can include details for developing one or more products. There cannot be any situation where a Work Package does not contain any Product Descriptions.

On authorising a Work Package to teams, an agreement should be reached between the Project Manager and the team member responsible for the Work Package on the contents and viability to complete the work. This will help everyone to understand the requirements and any potential problems that may occur with regards development, time, cost, etc.

For Level 2 projects, the authorisation of a Work Package can be either formal or informal. It depends on who is receiving the Work Package and what the relationship is between Customer and Supplier. The authorisation will also depend on the type of work involved, along with the levels of risk associated with the work.

When undertaking any development work yourself, you might find it useful to review the headings of the Work Package to help you better understand the requirements.

Be sure to keep a track of the work that is going in and out to the teams. As work is progressed and products are completed, you should update the Stage Plan.

The Templates Guide contains templates for a Product Description and a Work Package.

5.3 Quality Checks & the Quality Register

The Quality Register (created during Initiation) will contain all the details of the quality checking that is done. This will provide the Project Manager and the Project Board with all the information needed to ensure that what should be delivered, is delivered.

It is the responsibility of Project Support (but ultimately the Project Manager) to update the Quality Register with the relevant information, such as:

products planned quality review date
the type of check is carried out
the results of the quality check

Full details of the Quality Review technique are in the Techniques Guide. This explains the steps for checking products against agreed criteria and any considerations for the use of Test Director in aiding this process.

A template for the Quality Register is in the Templates Guide.

5.4 Checkpoint Reports

As work by the teams progresses, the Project Manager needs to be kept informed of the timescales and costs; the products being developed; what products are complete; and a summary of any problems or risks. This information is provided to the Project Manager using the Checkpoint Report. The frequency and formality of the Checkpoint Report should be agreed between the Project Manager and the team member responsible for managing the work.

The Templates Guide contains a template for the Checkpoint Report.

5.5 Highlight Reports

The Highlight Report is designed to provide the latest information from the Project Manager to the Project Board. Subject to the Project Board’s authorisation, it can also be sent to others who need to be kept in the picture.

The key benefits of Highlight Reporting are:

Provides summary information – no need for long reports
Keeps the Project Board informed of events on a regular basis
Helps the Project Manager to stand back and look at the bigger picture

The frequency of the Highlight Report should be agreed with the Project Board during the End Stage Assessment as part of the authorisation of the Stage Plan.

The template for the Highlight Report is in the Templates Guide. When information is completed, the Highlight Report should be sent to the Project Board. If there are any key points that need discussion, you might like to prepare a presentation for the Project Board.

For all levels of project, it is recommended that Highlight Reports are no more than one sheet of A4. If anybody needs more detailed information, then the project files can be viewed.

5.6 Managing Risks & the Risk Register

Risks are basically events and situation that might happen – i.e. a potential threat to achieving a successful outcome. You should have already created a Risk Register during Project Start-Up and have carried out an initial risk workshop, either in Project Start-Up or Initiation. The risks already identified will need to be monitored and managed. You will also need to record and deal with any other threats that may come to light.

The Risk Register is designed to capture this information and to help you better understand each risk. The Risk Register will also act as a guide for carrying out analysis on each risk. A Risk Register template is in the Templates Guide.

The nature of risks is volatile. Therefore all risks need to be recorded, monitored and, if necessary, actions taken to deal with the risk. This is called Risk Management. Risk Management is carried out on a day to day basis as part of managing the stage. You will find it easier to handle risks by making use of people who have knowledge of that area, or team members who are working closely with items that might be associated with the risk. These are called “Risk Owners” and are generally best placed to monitor the changing circumstances of the levels of risks.

Information on Company Name 's approach to Risk Analysis and Risk Management can be found in the Techniques Guide.

5.7 Issues, Issue Report & Issue Register

It is unusual for a project to run 100% as planned. Events occur that may bring change, overspend, or pressures on timing. These events should be raised to the Project Manager as an issue. Any questions, problems or good ideas should also be raised to the Project Manager as an issue.

Issues could originate from the Project Board, the Project Manager or anybody else. A standard process for dealing with Issuescan be found in the Techniques Guide.

On receiving an Issue, the Project Manager must record details in the Daily Log. If after an initial examination of the Issue it is apparent that the Issue should be handled on a formal basis, the Project Manager should create an Issue Report to record the impact Analysis that is carried out. A summary of the Issue Report should then be recorded in the Issue Register. This helps to ensure that the Issue is recorded and required action is taken. The Project Manager should then take the necessary actions to deal with the Issue accordingly. This might mean planning additional work for the teams to undertake; modifying the plan to ensure that activities and products can be delivered on time; or working within tolerance to change things as necessary.

Template documents for the Issue Report and the Issue Register can be found in the Templates Guide

Any Issues that result in exceeding the resources authorised in the Stage Plan need to be escalated to the Project Board. The Project Board will then make a decision on whether to commit additional resources or not (see Handling Exception).

5.8 Handling Exceptions & the Exception Report

The Project Manager is authorised to work within the remit of the agreed stage plan, within the tolerances agreed with the Project Board.

Most issues should be able to be handled by the Project Manager. However, some issues will result in forecasting that the stage will deviate beyond the agreed tolerances. In these cases the situation must be escalated to the Project Board using an Exception Report.

A Template for the Exception Report is in the Templates Guide.

The Exception Report is a quick and structured way to inform the Project Board of the following:

the caused the deviation
the options available to recover the situation
the impact of each of these options on the stage (and project) plan
the Project Manager’s recommendation

The Project Board should then review the Exception Report and provide clear guidance on what they wish to do. This might mean planning additional work to complete the remainder of the stage; put some of the products back into a subsequent stage of work; or even prematurely close the project.

An Exception Plan may be needed to be created to re-plan the stage from the current time, through to the end of the stage. A Template for the Exception Plan is in the Templates Guide.

Remember that the Project Board makes the decisions on these situations. The Project manager can make recommendations, but not the decision.

The Techniques Guide has the full process outlined for dealing with this situation.

5.9 Towards the End of the Stage

As Level 2 projects approach the end of each management stage there are a number of considerations needed; The information in this section refers to the “Managing Stage Boundaries” process in the PRINCE2 Manual which deals with these considerations.

As work comes to a conclusion and the end of the stage approaches, you will need to prepare for the End Stage Assessment. At the end of the stage you will need to prepare the information for the Project Board which will assist with the decision making.

5.10 Lessons Learned

Company Name are committed to continue improvement of project management standards. To support this initiative it is important to record management techniques that we would want to build on.

The Lessons Report is a simple report that gives the author the opportunity to feed back to the organisation details of what went well and what didn’t. A template is in the Template Guide.

The main benefit of this comes when you refer back to this information in the future when starting new projects.

5.11 End Stage Report

Creating and presenting an End Stage Report will provide the Project Board with the following information:

Summary of work completed during the stage.
Summary of outstanding issues
Summary of Risks
Summary of the Business Case
The latest updated Project Plan

A template for the End Stage Report is in the Templates Guide.

5.12 Stage Plan

The Stage Plan should not just be a graphical plan. Other elements should include Product Descriptions, stage organisation structure, details of the stage controls, and a resource summary. A template for the Stage Plan is in the Templates Guide.

You should present the End Stage Report and the Next Stage Plan to the Project Board at a meeting. This meeting is known as an “End Stage Assessment”, and can be held on a formal or informal basis.

5.12.1 At the End of Each Delivery Stage

On completing each delivery stage, you should have an End Stage Report and a Stage Plan for the next delivery stage. Authorisation for each development stage is given at a meeting “End Stage Assessment B”.
Presenting the information to the Project Board will help the decision making process on authorising the project to move into the next stage.

5.12.2 At the End of the Last Delivery Stage

At the end of the last delivery stage there will be a meeting called “End Stage Assessment C”. Here you should present the End Stage Report and the Next Stage Plan. The Next Stage Plan will be a plan for closing the project in a controlled manner. Following a successful Gateway Review 4, you will be authorised to proceed to the final stage “Closing a Project”. Details of the authorisation should be recorded and filed in the Project File or the Daily Log.

5.13 Information Checklist – Controlling a Stage

The following form should be used to monitor and track the information gathered during Controlling a Stage.

Information Checklist – Controlling a Stage Project Name: ………………………………...
Information	v	Product Name	Date	Authorised or Updated	Date
Work Packages




Quality Register
Checkpoint Report





Highlight Report





Risk Register
Issue Report
Issue Register
Exception Report
Exception Plan
Lessons Report
End Stage Report
Stage Plan

6. Closing a Project

Before Closing a Project can begin, you must have received authorisation from the Project Board. You will have presented the management products from Controlling a Stage, and a commitment to accept that the project is completing will have been made by the Project Board at the End Stage Assessment C and Gateway Review 4 will be completed and considerations now focus on Gateway Review 5.

Closing a Project ensures that the project is brought to controlled and tidy end. The management products in this section assist with:

Preparing for Project Closure
Update the Business Case and define a plan post-project benefit reviews
Document lessons for continued improvement
Summarise and planning the action of outstanding issues
Getting formal close authorisation from the Project Board

The following table lists the Management Products that will be created in this process, and the information each will provide.

Management Product	Information Provided
Customer Acceptance	Confirmation from the customer that the project has delivered the products to the expectations and criteria for the customer to officially accept the outputs.
End Project Report	A report on how the project was managed. Summarising whether the project was managed and completed as planned.
Lessons Report	Information on what went well, what didn’t go well, and what you recommend for future projects.
Follow-on Actions	Documenting any outstanding items. This document contains details of work to be completed, and by whom, following the project.
Benefits Review Plan	A schedule of wwhen post-project reviews will be carried out to assess whether expected benefits are being achieved.
Business Case	The justification for the undertaking and continuation of any project.

6.1 Customer Acceptance

To close the project you will need to have agreement from the customer environment that what has been delivered is acceptable. To help avoid this being too subjective, you will have created a set of Acceptance Criteria during Project Start-Up and Initiation (recorded in the Quality Management Strategy).. You should now use these criteria to establish and agree that what has been delivered meets the criteria.

Ideally all criteria will have been met. There may however be some instances where some outstanding work is required to fully meet the needs of the customer. If possible (and if acceptable to the customer, this can be transferred to Follow-on Items, which is explained later in this guide.

A template for Customer Acceptance is available in the Templates Guide.

6.2 End Project Report

The End Project Report is similar to the End Stage Report but covers the entire project and reviews the achievement of the objectives of the project, as laid out in the Project Initiation Document

The information in the End Project Report will include:

How the project achieved its objectives (the project’s objectives will have originally been recorded in the Project Brief)
Details of the projects performance against the timescales and costs outlined in the plan
Summary of changes and how these were handled
Summary of the products delivered and any comments on quality checks

A template for the End Project Report is available in the Templates Guide.

6.3 Lessons Report

Company Name is committed to continue improvement of project management standards. To support this initiative it is important to record management techniques that we would want to build on. Company Name Project Lessons Report should be filed and ideally made centrally available via the Intranet. Project Management Office (PMO) can advise.

The Lessons Report is a simple report that gives the author the opportunity to disseminate the information form the Lessons Log (created in Initiation) to feed into the organisation details of what went well and what didn’t. A template is in the Template Guide.

You will benefit of this approach when you refer back to previous lessons in the future when starting new projects.

6.4 Follow-on Actions

Follow-on Actions is essentially picking up any loose ends that remain at the conclusion of the project. This might include any outstanding changes in requirements, raised as issues, considered as good ideas but not actioned at the time. There might also be outstanding issues such as training, or an update to the product that is required to be raised as a Project Mandate sometime in the future.

All follow-on actions should be documented and assigned to a team of an individual for actioning.

A Template for the Follow-on Actions is in the Templates Guide as a section within End Project Report.

6.5 Benefits Review Plan

The Benefits Review Plan that was created during initiation should now be updated to reflect the projeect costs and the latest benefits projections. Information on when the benefit reviews will take place, how they will be conducted, what they will be measuring and who will be chairing and conducting the reviews must be included in readiness for the project closure authorisation.

6.6 Business Case

During the Closing A Project process the Business Case should be updated to reflect the current status on project costs and benefits. Information from the project Plan and the Benefits Review Plan can be used to summarise the Business Case prior to the final Project Closure meeting "End Stage Assessment D"

A Template for the Business Case is in the Templates Guide.

6.7 Premature Close

In the event of premature close of a project, the full Closing a Project process should be followed. It is likely that there will be products that can be accepted and used. Valuable lessons can also be recorded.

6.8 Project Closure Authorisation

In order for the project to be formally closed, the Project Board need to review the project files. In particular, the Customer Acceptance and End Project Report will confirm to the Project Board that the project has delivered the products that were required - to the quality required.

The Project Closure authorization for Level 2 projects is known as “End Stage Assessment D”. Details of this authorisation should be recorded and filed in the Project File. Once agreed, the project can be closed and the project files can be archived.

6.9 Information Checklist – Closing a Project

The following form should be used to monitor and track the information gathered during Closing a Project.

Information Checklist – Closing a Project Project Name: ………………………………...
Information	v	Product Name	Date	Authorised	Date
Customer Acceptance
End Project Report
Lessons Report
Follow-on Actions
Benefits Review Plan
Business Case