ips prince 2 manual

7/24/2019 Ips Prince 2 Manual

http://slidepdf.com/reader/full/ips-prince-2-manual 1/115

PRINCE 2PROJECTith Primavera P6 Softwar

COURSE BOOK



PRINCE 2PROJECT MANAGEMENT

Concept. Tools. Techniques.



THE BASICS



Introduction to PRINCE 2

PRINCE (PRojects IN Controlled Environments) is a structured method for effective

management of any size or type of project. It is the standard method for use in UK Government Departments and is widely used in the private sector, NHS and LocalGovernment. A growing number of overseas Governments and multi-national companieshave adopted the method, or integrated it within their existing project managementapproaches. The Method is being promoted actively by the APM Group (APMG) as a

“Best Practice” project management approach.

Benefits of PRINCE 2

There are a number of benefits to be gained from introducing and using a structured

approach to project management; among the benefits of using PRINCE 2 are that it:

♦ identifies management, technical (specialist) and quality Products or Deliverables and helps ensure that they are produced on time and to budget;

♦ focuses attention on the quality of Products or Deliverables;

♦ separates the management and technical/specialist aspects of Organisation, Planning

and Control;

♦ facilitates control at all levels;

♦ makes the project’s progress more visible to management;

♦ provides a communication medium for all staff working on the project;

♦ ensures that work progresses in the correct sequence;

♦ involves senior management in the project at the right time and in the right place;

♦ allows the project to be stopped and, if required, re-started completely under management control, at any time in the project’s life;

♦ is in the Public Domain and requires no license fee;

♦ has a well established User Group dedicated to the support, promotion and strengthening of the method.



The Structure Of A PRINCE 2 Project

Within a PRINCE 2 project environment, each project which is undertaken must:

♦ address all the processes concerned with establishing an effective project management

environment;

♦ have a stated business case indicating the benefits and risks of the venture;

♦ demonstrate a properly defined and unique set of Products or Deliverables;

♦ have a corresponding set of activities to construct the Products or Deliverables;

♦ identify appropriate resources to undertake the activities;

♦ have a finite life-span; suitable arrangements for control;

♦ identify an organisation structure with defined responsibilities;

♦ include a set of Processes with associated techniques which will help plan and control the project and bring it to a successful conclusion.

A PRINCE 2 project is divided into a number of Management Stages, each forming adistinct unit for management purposes. Like the project, a Stage is driven by a series of

Processes, has a defined set of products and activities, a finite life-span, control elements,and an organisational structure. The delivery of these products, to the agreed qualitystandards, marks the completion of the Management Stage. PRINCE 2 defines:

♦ the organisation of the project and its stages;

♦ the processes which drive the undertaking;

♦ the structure and content of the project plans;

♦ basic project management techniques;

♦ a set of controls which ensure that the project is proceeding to plan.

These, together with the products of the project and the activities which produce them, the project business case, all encompassed within a Quality Management framework, makeup the PRINCE 2 environment.

All products of a PRINCE 2 project are filed within a defined structure - the

"Configuration". Management, Specialist and Quality Products are identified and filedseparately.

The PRINCE 2 framework provides the flexibility to set stage boundaries which are

appropriate to the needs of the project. Management Stage boundaries are chosenaccording to:



♦ the sequence of production of Products/Deliverables;

♦ the grouping of Products into self-contained sets or associated Processes;

♦ natural decision points for review and commitment of resources;

♦ the risks and business sensitivity of the project;

♦ the completion of one or more discrete Processes.

The project stages correspond to the steps in the natural project life-cycle towards theeventual outcome. Thus the stage boundaries are normally defined to correspond to the

completion of the major Products to be built and key decisions concerning commitment of resources that need to be made. Whatever the nature of the project, it is advisable to

define one or more planning and/or definition processes in the early part of the project'slife. PRINCE 2 provides two Processes to cater for this - “Starting Up A Project (SU)”(where the early foundations for decision support are laid) and “Initiating A Project (IP)”(where senior management are invited to commit to the undertaking and a baseline is produced. The project is triggered by a “Project Mandate” which might take any form

from an informal request by a sponsor to a formal recommendation from a report.

PRINCE 2 recognises that few projects will be undertaken entirely in isolation. Theoutputs from one project may be used as input by another project. There may be other dependencies between projects, such as the use of shared resources. PRINCE 2, therefore, provides a mechanism for defining the boundary of a project and its relationship to other

projects. A high-level context diagram is a useful mechanism for defining these

relationships.

Figure 3: Scoping Diagram showing Inputs and Outputs for the Project

The Scoping Diagram illustrated above is particularly useful when planning and managinga Programme of Work where individual projects inter-relate with each other and it isnecessary to ensure that expected outputs from individual projects are anticipated and planned for. When all individual project Context Diagrams are assembled to complete the

The Project Under

Development

Bullet List of the Main Functionsto be produced, developed or bought-in

Key User Groups

Central LogisticsProject

Business Processes Cleaned Data

Parts Requisitions

Current System

MIS Project

Information



programme “jigsaw” it will be apparent which outputs and inputs do not match, andappropriate action can be taken by the Programme Director/Manager.

The Key Elements Contained In PRINCE 2

To understand the content of the PRINCE 2 Project Management Method, the following

model showing the key elements should be studied:

Figure 4: Summary Model of the PRINCE 2 Method

The PRINCE 2 methodology applies three key elements to each project and to the

Management Stages within a project. These are summarised in the above Model anddescribed, briefly, in the following tables. The three elements are the Processes whichdrive the project management, Components and Techniques, which are used by each of theProcesses to effect the management of the project.

PROCESSESTECHNIQUES COMPONENTS* Starting Up A Project (SU)

* Initiating A Project (IP)

* Directing A Project (DP)

* Controlling A Stage (CS)

* Managing Product Delivery (MP)

* Managing Stage Boundaries (SB)

* Closing A Project (CP)

* Planning (PL)

* Product-Based Planning

- Product Breakdown

- Product Description

- Product Flow Diagram

* Quality Reviews

- Preparation, Review, Follow-up

* Change Control - Capture, Logging,

Assessment, Decision

* Project Filing Structure

- Management File

- Specialist File

- Quality File

+ Existing Organisation

Techniques already used

within the host organisation

* Organisation

- Structure & Role Descriptions

* Planning - Products, Activities, Resources

* Controls

- Management, Team, Quality

* Stages

- Management & Technical Stages

* Management of Risk

- Risk Assessment & Management

* Quality in a Project Environment - Quality Requirements & Response

* Configuration Management

- Tracking Products & Documentation

* Change Control

- Capture & Assessment

PRINCE 2 SOFTWARE SUPPORT ENVIRONMENT

EXPERIENCE, BEST PRACTICE, COMMONSENSE

ORGANISATION STANDARDS & APPROACHES; BUSINESS STANDARDS & ETHICS

QUALITY MANAGEMENT SYSTEM (QMS) (ISO9001)

THE BUSINESS CASE * Business Benefits

RISK MANAGEMENT * Risk Analysis & Actions

* Risk Management



The PRINCE 2 Processes

DESCRIPTION

REF

EXPLANATION

Starting Up A Project SU Establishes the Objectives and Approach to the

Project; Set up the Project Management Team;Plans for the Initiation Process. This is a pre-

project Process, which looks to answer thequestion “do we have a worthwhile and viable project?” before asking for commitment of resources to set up a project environment.

Initiating A Project IP Plans the whole Project in terms of its Products,

Activities, Resource Usage and Quality; Setsthe baseline for the Business Benefits & Risks.

Directing A Project DP Provides Authorisation for work to be carriedout and Resources to be committed.

Authorisation for Project Initiation and ProjectClosure and, in some cases, its premature

termination. The Process is “owned” by theProject Board – the ultimate authority for theProject - accountable for its overall success.

Controlling A Stage CS The basic day-to-day project managementProcess - authorising work to create or changeProducts (or Deliverables), collecting andreflecting “actuals”, assessing progress and

reporting to senior management. Capturing proposed changes and errors and escalatingthese, where appropriate to management.

Managing Product Delivery MP The main “workshop” for the project where the

majority of resources are consumed. ThisProcess is where the Products of the Project arecreated. Progress reports (Checkpoint Reports)are provided to the Project Manager. Quality

Review and Delivery of Products occurs here.

Managing Stage Boundaries SB Reporting on the achievements of the Current

Management Stage and the impact on theoverall Project Plan and Business Case.Planning the Next Stage (Products, Activities,Resource Usage). Putting together ExceptionPlans when the Management Stage has suffereda significant departure from its approved plan.

Closing A Project CP Preparation for closing the Project in an orderlyway. Customer sign-off, preparation of an End-Project Report and identification of Lessons

Learned and Follow-on Recommendations.Planning for a Post-Project Review.

Planning PL Used by all the other Processes - a common-to-

all Process featuring the design of the plan andits creation.



The PRINCE 2 Techniques

DESCRIPTION

EXPLANATION

Product-Based Planning A “Product Breakdown Structure” which identifies the

Products or Deliverables to be produced during the project.A “Product Description” for each Product identified in the

Product Breakdown Structure, which defines and specifieseach Product; a key feature of the Product Description is theQuality Criteria used to ensure that the Product is indeed a“Quality Product” that conforms to its requirements. A

“Product Flow Diagram” which shows the relationship that

each Product has with others and external entities; theProduct Flow Diagram must “balance” with the ProductBreakdown Structure.

Quality Review Technique Used for measuring a Product or Deliverable against its published Quality Criteria. PRINCE 2 recognises InformalQuality Reviews (typically “Desk Checks”, Tests or Visualinspections) and Formal Quality Reviews (which are more

structured “Walkthroughs” of a Product or Deliverable).Formal Quality Reviews comprise three distinct Phases -

Preparation, The Review Meeting and Follow-Up.

Change Control Every project must be able to accommodate changesrequired by the customer or anyone else who has an interestin the project’s outcome. All suggested changes, identifiederrors and departures from the agreed Specification must becaptured as “Project Issues, logged, analysed for technical,customer and business impact, and a decision made onwhether to accept or reject the Issue.

Project Filing A suitable filing structure is suggested; this comprises a

“Management File” made up of one Project File and a seriesof Stage Files - one for each of the Management Stages of

the project. A Specialist File housing the documentationrelating to the technical aspects of the project and a QualityFile housing the Quality Review documentation and the

Project Issues complete the structure.

More on the PRINCE 2 Processes

The eight major Processes state the minimum content that can be expected to be found in

a PRINCE 2 compliant project. Exactly how the Processes are addressed within any project is the responsibility of the organisation’s senior management, represented by the

Project Board, and the Project Manager, but the method requires that each of the eightProcesses is reflected within the project one way or another.

All the Processes link to Components and Techniques some of which are described within



the method. It is anticipated that most organisations will already be using some specificTechniques and might wish to incorporate additional Components reflecting their businessenvironment and culture. PRINCE encourages this where they provide value to the

management decision making process.

Each Process is defined in the following terms:

♦ The Fundamental Principles that underpin the Process;

♦ The Context within which the Process operates;

♦ An Overview of the Process;

♦ Responsibilities identifying accountability for the Process;

♦ The Information Needs required for the Process to function effectively;

♦ The Key Criteria which will influence the success or failure of the Process;

♦ Hints and Tips for carrying out the Process in the best way.

♦ Major Processes have an additional “Scalability” heading to help with scaling down

each Process for smaller, lower risk projects, where this is required by senior managers.

The Process-based approach is a powerful feature in PRINCE 2 and is the area which mostdifferentiates it from version 1 of the method. The flexibility of the method is, however,underlined by allowing implementing organisations to choose their own destiny in termsof identifying how to meet the requirements of any given Process. In most organisationsalready operating successful project management systems there will be little need to makechanges to the way they are operating, provided effective project management proceduresare already in place.

The Organisation Component

The organisation and effective use of people assigned to manage a project needs to be

considered from the view point both of the specialist skills they bring to the project andtheir individual personalities.

Responsibilities need to be defined within a team structure to ensure that management is both efficient and responsive, and that individuals understand exactly what is expected of

them. Within PRINCE 2, responsibilities are defined in terms of roles, rather thanindividual’s jobs. Assignment of roles to individuals is a decision for each Project Board

to take in the light of organisational circumstances, and the same individual may beassigned to more than one role, or to different roles at different stages of the project.

Three roles/interests must always be represented on any PRINCE 2 project – Business,

User, and Supplier.



Corporate or Programme Management

The Project Board

Senior User Senior Supplier Executive

Project Assurance

Project Manager Project Support

Team Manager Team Manager Team Manager

Project Resources & Teams

Figure 5: The PRINCE 2 Organisation Structure

The Project Board

Every PRINCE 2 project will have a Project Board appointed. The Project Board is the

ultimate authority for the project and is normally appointed by Corporate or ProgrammeManagement to take overall responsibility and control of a PRINCE 2 project. The Project

Board consists of three senior management roles, each representing major project interests.

♦ Executive: appointed by Corporate/Programme Management to provide overall project guidance and assessment throughout. The Executive represents the interests of the

Customer and the Business and has overall responsibility for the project.

♦ Senior User: representing users (and, where appropriate, Customers) of the outcomeor the major products from the project.

♦ Senior Supplier: representing areas which have responsibility for providing the specialist “know-how” and/or committing Supplier resources for the solution. The Senior Supplier might be drawn from an external, commercial, organisation or from internal

sources responsible for delivering the specialist “End Product” to the customer (or amixture of both).



There is a requirement within the Method to have a Project Board function and this cannot be eliminated or delegated (although the terminology may be changed to suit the

organisation’s culture, for example “The Project Authority”). The Project Board’saccountability for Project Assurance cannot be delegated although the day-to-day work of Project Assurance can if Project Board members do not have the time or expertise to carry

out the tasks involved.

The Project Manager

A Project Manager will always be appointed to assume day-to-day responsibility for

planning and management of the project throughout all its Management Stages. The

Project Manager takes direction from the Project Board and is responsible for managing,on behalf of the Project Board, the Processes, planning and delivery of Products for the project, on-time, within budget, meeting the specialist/technical and quality criteria agreedwith the Project Board.

As with the Project Board, the role of Project Manager is a required role within theMethodology and cannot be shared, delegated or eliminated.

The Team Manager

In a large or complex project, one or more Team Managers may be assigned the

responsibility for ensuring that the products of one or more particular Technical, or Specialist, Stages of work are planned, controlled and produced on schedule, to thedefined and agreed quality standards, and within budget.

Figure 6: Project Manager and Team Manager Relationships

The Team Manager role is optional and will only be present in large projects or where the

Project Manager lacks the specialist skills to plan and control specific parts of the project.


Team Manager Team Manager Team Manager

Project Resources & Teams



Project Resources and (Specialist) Teams

The Project and/or Team Manager have responsibility for Teams of specialist staff, tasked

to carry out the activities and produce the Products of the stage. The team organisation,responsibility definitions and the allocation of these responsibilities to individuals willdepend upon the size and nature of the project and the skill mix available. PRINCE 2recognises the need to establish Team Manager roles where appropriate;

Project Assurance

PRINCE 2 separates the Project Assurance function from the Project Support function.The Project Board have responsibility and accountability for Project Assurance.Depending on the size, scope, risk and profile of the project, and their own knowledge,skills and time available, they may choose to delegate responsibility for overseeing day today Project Assurance to others within the organisation. However, accountability for

Project Assurance rests with the Project Board and they are not able to delegate this.Project Assurance may not be delegated to the Project Manager or to Team Managers.

Figure 7: Project Board and Project Assurance Functions

Although not specifically separated out in the PRINCE 2 Method, Project Assurance can be found in two distinct forms:

♦ External Assurance to confirm that the project is following overall and corporate standards (eg the published Quality Management System, or particular accounting

conventions) and the organisation can be expected to have an audit function already in place to check these aspects.

♦ Internal Assurance to verify that the project is delivering Products or Deliverablesthat meet the agreed Quality Criteria and that internal project standards are being followed. Internal Assurance is ultimately the responsibility of the Project Board.

The Project Board

Senior User Senior Supplier Executive

Project Assurance

User Assurance Specialist Assurance Business Assurance



Project Support

Within PRINCE 2, Project Support, on a formal basis, will only exist where there is a

perceived need for it. A Project Manager may well find that the Project Board see noscope for any administrative support, and that any day-to-day assistance might need to be

on an “ad-hoc” basis.

Figure 8: Project Manager and Project Support Relationships

Where a project does warrant the appointment of a Project Support function, theindividual(s) selected will report directly to the Project Manager. Incidental support for

the Team Managers, where appointed, and Team resources will normally form part of Project Support’s responsibilities.

The Project Support Office

A Project Support Office might well evolve in a Programme or multi-project

environment, to support a number of individual projects. The methodology supports the possibility of a transition from several Project Support individuals to a central ProjectSupport Office where the number of projects under development warrants it. The resultantProject Support Office will be able to provide a centre of expertise for all project

management aspects within the organisation/site, effectively delivering an internalconsultancy service where required by Project Board members, Project Managers and

project team members.

Summary of The Organisation Component

In the final analysis, it is the people who are responsible for the management of the

project and the creation of its deliverables who have its success in their hands. Clear definition of responsibilities and a tenacious commitment to achieving agreed goals willalways be the predominant factor in success.

The PRINCE 2 Method must always be tuned to suit the implementing organisation’s

existing standards, business approaches, culture and people; the latter two are arguablythe most important.




PRODUCT-BASED PLANNING

TECHNIQUE



Planning - Introduction & Overview

The PRINCE 2 Method does not prescribe any particular type of plans which must be

used on a project. The principles of “Product Based Planning” are incorporated in themethod within the “Techniques” section and the overall assumption is that some form of software support planning tool will be used.

The exact form and layout of the plans is left for the implementing organisation to decide,

probably influenced strongly by whatever software planning tool is currently in use.

There will typically be up to 3 planning levels within a PRINCE 2 project, although thereis no limitation on the number of levels which might be utilised. Typical levels of planare:

♦ Level 1: Project Plans

♦ Level 2: Stage Plans

♦ Level 3: Team Plans

♦ plus Exception Plans where there has been a significant departure from the approved

plans and some re-planning must be done to recover the situation.

Individual Plans assigning particular Products and their associated work packages to

members of the project team might also be utilised if this is appropriate.

Figure 31: Levels of Plan In PRINCE 2

Plans at Levels 1 and 2 are necessary for effective planning of a major project – both theProject Plan and the Stage Plan are mandated in the Method.

Project Plan (Mandatory Plan)

Stage PlanStage Plan Stage Plan

Team

Plan

Team

Plan

Team

Plan

Team

Plan

Team

Plan

Team

Plan

Project Resources Report(Effort, Costs, Equipment, Direct Costs)



Project Plans may provide sufficient detail for the early stage plans to be incorporatedwithin them. Plans at the lower Levels are optional but will usually be necessary to produce in order to gain full understanding of the undertaking and to exercise effective

control at team level.

The plan structures at all levels (including the Exception Plans, which are intended to

replace the plan which it has been necessary to up-date) are similar in content andstructure; at team level for the individual, if these are used, the only plan needed will be asimple Gantt Chart or Activity List covering either one or two elapsed weeks. This type of plan is often available as a standard output from the planning support software.

Figure 32: The PRINCE 2 Plan Package

Project Level Plans

Construction of PRINCE plans should normally be on a top-down basis; this will provide

a logical and controlled descent into detail and will help to identify any grouping of Products and associated activities that might usefully be treated as a separate sub-project.

In some cases, however, it will be appropriate to work at the stage level in order to providea realistic picture of the total development. The more detailed activities will then need to

be grouped to provide an overall view at the project level.

Plan

Text

The Plan Text provides a high-level, overall view of

the plan, summarising its key features

Product

BreakdownStructure

Identifying the Products/Deliverables that will be

produced by the Project. The Products will be categorised

under the headings of “Specialist”, “Management”, and

“Quality” Products.

Product

Descriptions

Describing the Products/Deliverables that will be

produced by the Project. There is a prescribed format

for Product Descriptions

Product

Flow

Diagram

Describing the relationships that exist between

each Product/Deliverable, and external entities.

PERT

or

Activity

Network

Showing the relationships that extist between the Activities that will be undertaken

to create the Products identified in the Product Breakdown Structure.

Gantt

or

Timescale

Plan

Derived from the PERT Network, this shows when Activities are

planned to start and end. Major Review points (End Stage

Assessments) are also shown on this plan.



Product Breakdown Structure

The start-point will be to give consideration to the design of the plan (how many levels,

the general approach to planning, the most suitable software support tool to use,involvement of external support services etc).

As the initial step, a list of Products to be produced during the project must be created.These Products will be at the Project level and must be identified by the Project Manager

and the appropriate Team Manager where appointed. The resultant list should then becritically reviewed with the Project Management Team in the light of what is known about

the proposed project, to produce an agreed list of high-level Products to be produced. Thisis known as a Product Breakdown Structure and contains a list of the Specialist Products,Management Products, and Quality Products associated with the project.

Figure 33: Specialist, Management & Quality Products

Each Product must be supported by a Product Description which addresses the following:

♦ Product Title & Identification;

♦ Purpose;

♦ Composition;

♦ Derivation;

Management Information System

Specialist Products

SP01 - User SpecificationSP02 - Logical Design

SP03 - Physical Design

SP04 - Contract

SP05 - HardwareSP06 - Software

SP07 - Communications

SP08 - Integrated System

SP09 - Technically Tested SystemSP10 - User Accepted System

SP11 - Trained Staff

SP12 - Test Products

Quality Products

QP01 - Product DescriptionsQP02 - Quality Review Documentation

QP03 - Project Issues Log

QP04 - Quality Log

QP05 - Configuration Management

Management Products

MP01 - Project Initiation Document

MP02 - Stage Plans

MP03 - Lessons Learned Log MP04 - Risk Log

MP05 - Business Case

MP06 - Product Checklist

MP07 - Highlight ReportsMP08 - Project Start Notification

MP09 - Project End Notification

MP10 - Project Filing Structure

The Project Management

Standard for the

Project

The Quality Management

Standard for the

ProjectThe Technical Management

Standard for the

Project



♦ Format & Presentation;

♦ Allocated To;

♦ Quality Criteria;

♦ Type of Quality Check Required;

♦ People or Skills Required for Reviewing/Testing the Product .

The above headings may be added to but must not be omitted in order to secure PRINCE 2compliance.

Product Descriptions form a significant part of the Quality Plan for the project and are

fundamental to its successful outcome. For these reasons Product Descriptions must not,in any circumstances be omitted from any PRINCE controlled project.

Figure 34: Example Product Breakdown Structure For The “User Specification” Product

Every PRINCE 2 project will have at least one Product identified (the End Product) anddefined in terms of a published and baselined Product Description. Baselining of a

Product Description will take place when the plan it relates to is baselined (agreement bythe Programme Director/Executive (for Programme Plans), the Project Board (for ProjectPlans) and the Project Manager (for Team Plans)).

A Product Description, once approved and base-lined, may only be changed via the

Change Control procedure.

SP01 - User Specification

User Requirements Enhancements

Functional

RequirementsData

Requirements

Education

StrategyTesting

StrategyCut-Over

StrategyFall-Back

Strategy

Strategies

Short/Medium

TermLong

Term

Technical

TestingUser

Testing

Module

TestingSystem

Testing



Product Flow Diagram

A Product Flow Diagram may then be drawn showing how the various products identified

are derived, one from another and from external Products and Entities. This helps toconfirm that all the Products that need to be produced have, in fact, been identified; allProducts in the Product Flow Diagram must balance with those in the Product Breakdown

Structure, and each must be supported by a Product Description.

Figure 35: Product Flow Diagram

The Product Flow Diagram helps set a basic approach and chronology for the completionof the Products. Stage beginnings and endings, and candidates for sub-project groupingscan also be determined from this diagram, although the final timings of Management Stage

endings will not be able to be made until later when the Gantt Plan (or Timescale Plan) has been produced.

Construction of the Product Flow Diagram helps the project planners to appreciate theoverall approach and strategy that underpin the project. Any "missing" Products will bemore easily identified (these must of course be incorporated into the Product Breakdown

Structure and defined within Product Descriptions).

Less than obvious linkages between Products will be more clearly apparent at the time theProduct Flow Diagram is drawn, and the successive iterations will help to hone the overallapproach to a more realistic shape.

Another useful function of the Product Flow Diagram is the help it gives in identifyingActivities for inclusion in the activity plans.


SP02 - Logical Design


SP04 - Contract

SP06 - SoftwareSP05 - Hardware SP07 Communications


SP08 - Integrated System

SP09 - Technically Tested

System

SP10 - User Accepted

System

SP11 - Trained Staff

Users/Existing SystemFeasibility Study

Potential Suppliers



Figure 36: Product Flow Diagram With Activities Identified

The Activities identified on the Product Flow Diagram are sometimes referred to as

“Transformations” reflecting that they provide the means of transforming one or more

Products into another.

PERT Network

The PERT Network is a basic tool in project management; its full designation is

“P rogramme E valuation & R eview T echnique” and the information to produce it may be

derived from the Product Flow Diagram. Alternative names for the PERT Network are“Critical Path Network”, “Critical Path Method”, and “MIST - Minimum Irreducible

Sequencing Technique”.

The Product Flow Diagram defines the data flow and relationships between Products to be produced, and the PERT Network defines the activities needed to create each Product.

The PERT Logic Network & The Timed Network

The Logic Network shows the activities needed to produce each Product and establishes

the dependency relationship between activities. The Timed Network provides additionalinformation on the elapsed time to be taken for each activity and allows the total project

cycle time to be predicted. The Timed Network will also provide information on start andfinish times, critical paths, sub-critical paths and float.


SP02 - Logical Design


SP04 - Contract

SP06 - Software


Users/Existing System

Feasibility Study

* Prepare & Issue Tenders

* Produce Tender Evaluation Criteria* Assess Offers & Select Supplier

* Issue Contract * Produce & Agree Program Designs

* Write Programs (& Fixes)

* Unit Testing * Suite Testing

* Extract Test Data

* Clean Data

* Produce Test Schedule

Produce Business (Logical) Design

Produce Business (Logical) Design

* Interview Users

* Produce Specification

Review FS



Figure 37: PERT Network - Timed And Logic Diagram

Earliest Start Gantt Plan

Using the information on earliest start and finish times from the Timed Network, an

Earliest Start Gantt Plan can be produced. This chart will provide the basis for ProjectBoard approval. But first some tuning/resource smoothing has to be carried out.

Figure 38: Creating The Earliest Start Gantt Plan

Resource Smoothing

The Timed Network will have assumed unlimited resources were available andconcentrated solely on the underlying logic of the relationship between activities. This

Earliest Start Time Earliest Finish Time Latest Finish Time

Activity Total Float

0 3 3

10 Appoint The PB Executive

0 0 3

3 2 5

20 Appoint The

Project Manager

9 6 11

11 5 16

30 Design & Appoint

The Project Team

11 0 16

10 4 14

60 Prepare Board Position Paper

12 2 16

16 2 18

40 Produce The

Project Brief

16 0 18

3 7 10

50 Review The Strategy Plan

5 2 12

3 8 11

70 Plan The

Project Approach

3 0 11

0 3 3

10 Appoint The

PB Executive

0 0 3

Earliest Start Time(EST)

Earliest FinishTime(EFT)

Latest Start Time

(LST)Latest Finish Time

(LFT)

Duration

Total Float



does not, of course mean that any number of people are available to the project, but thatthose that are assigned to the project are assumed to be able to work at any time (even tothe extent of carrying out simultaneous multiple activities.

Figure 39: Creating The Resource Smoothed Gantt Plan

The Earliest Start Gantt Plan will clearly show overlapping activities where resource usagewill be over-stretched. To inject reality into the plan it will be necessary to smooth theresources.

Although not dealt with in the methodology, resource smoothing is an essential feature of project planning. Resource smoothing is best carried out using a software support package

(such as Microsoft Project (MS Project), Project Manager’s Workbench (PMW), or Primavera), initially, and then tuning "by hand". Full manual resource smoothing is a timeconsuming and tedious task involving many iterations and modification of both the Time-

scale/Bar Chart and the underlying Timed Network.

After smoothing, the resource usage may still be excessive, or the end date for the project

may have slipped back too far to be acceptable to the sponsor. In these cases it will benecessary to reconsider the logic of the Timed Network and to plan for overlaps of activity

that would enable more effective use of resources and bring forward the delivery forecast.Such action will invariably increase the risks to the project and will need to be properly

assessed and documented for a decision by the Project Manager or Team Manager andsubsequent endorsement by the Project Board.

Produce PlanId Sources

Prepare Docs

Prepare I/Vs

AppointmentsInterviews

Un-smoothed Gantt Plan (Earliest Start)

Produce Plan

Id Sources

Prepare DocsPrepare I/Vs

Appointments

Interviews

Management

Stage 1

Management

Stage 3Management

Stage 2

Resource Smoothed Gantt Plan (With Stage Reviews)



Project Gantt Plan

The Gantt Plan is the result of the resource-smoothed earliest-start bar chart. and provides

a view of the Products related to the envisaged time-scales for the total project, readilyshowing where "clusters" of Products will be ready and thus point to natural Stage beginnings and endings. The Project level Gantt Plan has the End Stage Assessment

control symbols added in, at appropriate key decision and resource commitment points andis then ready for approval by the Project Board.

Figure 40: Gantt Plan With End Stage Assessments Added

Project Resource Reporting

A Project Resource Report provides a summary of the Effort and Cost of that effort on a

Stage-by-Stage basis. A separate Resource Plan is not specifically required by PRINCE 2,as the Method presumes that a software planning tool will be in use and any resource

information required will be able to be drawn from the Project Plan and presented inwhatever format is required.

Information on the planned use of resources (and the subsequent record of actual usage) is

an essential element of decision support for management and should not be omittedwithout good reason.

In projects where a software support tool is not being utilised, it may be produced bytaking a copy of the Project Gantt Plan and creating a "Transfer Sheet" for each resourcetype. The transfer sheet provides a statement of the resource usage against each activityfor the whole project; the planned effort usage for each stage is totalled and transferred to

the Project Resource Plan.

Initiate

Specify

Design

Build

TestTrain

Hand-over

ManagementStage 1

ManagementStage 3

End Stage Assessment (ESA)

Project InitiationProject Closure

ManagementStage 2



Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual

EFFORT (Staff Weeks)Skill Types

CustomersEngineersIT Analysts

Others

COSTS (£K)Skill Types

CustomersEngineersIT AnalystsOthers

Equipment

Fixed Price Elements

Total Stage Costs

Total Project Costs

Figure 41: Resources Report (or Plan)

The resource effort on the Project Resource Plan is then converted to resource cost byreference to capitation or charge-out rates. Direct costs (for purchase of equipment etc) is

also added, as is the cost of any purchases for the development.

The aim is to capture the total, true costs of the project. When all the costs have been

identified on the Project Resource Plan, they are cumulated in order to provide input to aGraphical Summary of the overall project.

Graphical Summary

This plan is not a stated or required part of the PRINCE 2 Method, but is useful to knowabout as it enables the project plans to be summarised on a single sheet in a graphicalformat. It summarises the planned expenditure using the vertical axis to illustrate costsand the horizontal axis for time. At the project level it is acceptable to show a cumulativesummary of each stage's planned costs , although the Project Board may require a more

detailed analysis. If this is required, the Project Resource Plan should be re-drawn to showinformation at a similar level as it is important that all plans should be consistent with eachother.



Figure 42: Graphical Summary Of The Plans

A useful feature on the Graphical Summary is the inclusion of delivery slots for major Products. This information provides essential technical progress data and enables the

Project Board to assess the actual achievement against actual spend when reviewing the plans at the end of each stage. The headings used in the Graphical Summary to show thestatus of each Product may be used in conjunction with the Product Checklist. Thisdocument has planned and actual dates inserted to show progress of Products. It is mostuseful at Management Stage level but is also produced at Project level.

Earned Value Analysis

An extension to the Graphical Summary is the Earned Value Analysis chart. This

technique takes performance measurement a step further, enabling a clear measurement of the project work accomplished and more disciplined forecasts of the likely task and

Product completion dates and associated costs. The concept of Earned-Value Analysis isnot incorporated into the PRINCE 2 Method, but is being used increasingly and may be

expected to be included in a subsequent revision.

Earned Value replaces the traditional practice which only compares Actual Cost with Actual Progress and is based on assigning a value to the achievement of project work.Ideally achievement is measured in terms of Milestones and Major (ie Product-level)Products delivered.

Time

Cost

S p e c i f i c a t i on

B u s i n e s s D e s i gn

A gr e e d D e s i gn

C on t r a c t

C om pl e t e d S y s t em

T e s t e d S y s t em

T r ai n e d S t af f

I ni t i al S u p p or t C om pl e t e

P i l o t H an d ov er

C u s t om er A c c e p t an c e

P r o j e c t C l o s e- O u t

Product Ready

Quality Reviewed

Work Finished

Work Started

Work Package Agreed

Management

Stage 1

Management

Stage 3

Management

Stage 4

Management

Stage 2

Stage

£20K ....

Stage

£14K ....

Stage£58K ....

Stage

£18K ....

£20K

£34K

£92K

£110K



Figure 43: Earned Value Analysis

The value is usually monetary but can be expressed in any appropriate unit such as staff

hours or days. The value to be earned when a specific Milestone or Major Product isachieved is based on the planned cost of achieving the Milestone.

For example, if the plan showed that £100,000 was required to achieve a specifiedMilestone/Project Product, £100,000 worth of Earned Value would be credited to the

Project Manager (as “owner” of the Product”) when achievement of the Product wasdemonstrated (ie that the Product had successfully met all its Quality Criteria). Again, it is

worth emphasising that the plans described above, the Graphical Summary and the EarnedValue Analysis plan are not requirements of PRINCE 2, but are useful vehicles for illustrating project situations to the Project Board and other senior managers.

Risk Analysis

R isk analysis must be carried out in a structured manner. A Risk Analysis should always

be completed at Project Initiation and up-dated, minimally, when preparing for each EndStage Assessment/Project Board meeting.

PRINCE 2 requires that a Risk Log be kept to record the (hopefully reducing) risks faced

as the project progresses. The risk analysis provides a complementary part of the BusinessCase for the Project and will be summarised in the Project Plan Description.

Time

Cost

S p e c i f i c

a t i on

B u s i n

e s s D

e s i gn

A gr e

e d D

e s i gn

C on

t r a c t

C om

pl e

t e d S y s t em

T e s t e d S y s t em

T r ai n

e d S t af f

I ni t i al

S u p p or t

C om

pl e

t e

P i l o

t H

an

d ov

er

C u s t om

er A

c c e p t an

c e

P r o

j e c t C l o

s e- O

u t

Product Ready

Quality Reviewed

Work Finished

Work Started

Work Package Agreed

£200K

£110K

Time Now

Actual Cost

Planned

Cost

Value Earned

Predicted

Revised Cost

Predicted Cost

Over-Run

Predicted

Schedule

Over-Run

Projection of

Actual Costs

Original

Planned Cost



The risk analysis will address other issues, of course, (eg staff turnover; projectmanagement expertise, third party suppliers etc) but if time is to be saved by thecompression of time-scales by overlapping naturally dependent activities, this presents a

very real risk to the success of the undertaking and may well involve some nugatoryexpenditure. For these reasons the implications of resource smoothing at this point in planning must be seriously considered.

Measuring The Business Benefits

When all the resource usage and cost information has been assembled, the Project

Business Case can be created (“Initiating A Project”) or reviewed (“Managing Stage Boundaries”).

Figure 44: Simplified Business Benefits - Costs:Benefits Analysis & Investment Appraisal

A high-level Business Case would normally have been produced during the Feasibility or Preliminary Study, based upon information contained in the organisation's Strategic Plan.

This initial business case would have been subsequently refined and, following approval by Corporate or Programme Management, passed with the Project Mandate to the Project

Manager for formal Start-up and, following approval at the Project Initiation Meeting, the

Initiation of the project.

The main elements of the Business Case are the reasons for the project, and a Benefits

and Costs Statement. An optional Costs:Benefits Analysis and Investment Appraisal mayalso be created to measure the Business Benefits of the project’s outcome. If thought to benecessary a Sensitivity Analysis may also be produced. A Risk Analysis and proposalsarising from it, recorded in the Risk Log, is also closely linked to the PRINCE Business

Case.

Essentially all costs are fed into the model and all tangible benefits added in. The resultwill be a Cash-flow for the project. This is then discounted by the appropriate rate(currently 6% in Government, but often higher within the private sector) and the Dis-

counted Cash Flow identified. The areas of main interest are:

Year 0 1 2 3 4 5

Costs: (100 ) (20) (20) (20) (40) (30)

Benefits : 0 40 80 100 100 100

CashFlow: (100 ) 20 60 80 6 0 70

Cumulat ed: (100 ) (80) (20) 6 0 120 190

Discount Factor (@6 %) 1.0 0 .94 .8 8 .83 .78 .74

Discounted Cash Flow (100) 19 53 6 6 47 52

Cumulat ed DCF (100 ) (81) (28) 38 85 137



♦ the point at which the project starts showing a positive return

♦ the overall return on the investment in the project (the Net Present Value).

Where a full Cost:Benefits Analysis and Investment Appraisal is not required by theProject Board, a narrative statement of the Benefits should be produced. This lists all the

anticipated benefits but does not attach any specific financial value to them.

Project Plan Text

The plans described are used for the overall control of the project and provide a summary

of the planned work and expenditure.

To initiate the project (and to approve each successive Management Stage) the Project

Board will require a document which ties the complete plan package together anddescribes the approach and general philosophy. This document is the Plan Text (alsoknown as the Plan Description, Plan Narrative or Executive Summary) and will be mainlya narrative summary with the plans described above attached as appendices.

The Plan Text typically contains the following information:

♦ the plan pre-requisites (what must be in place in order for the plan to work - eg staff recruited, users assigned, equipment installed and building work completed);

♦ the plan assumptions (the bases upon which the plans has been constructed - eg staff

rates, discount factors used etc);

♦ the plan risks (the specific areas of risk that have been identified and must be closely

monitored - eg overlapping activities, staffing concerns etc);

♦ the overall time-scale for the project and how it has been achieved;

♦ the impact of resource usage on this project on other projects, undertakings etc.

♦ the return on the investment and the overall business case related to project viability.

Management Stage Plans

The Management Stage Plan package has a similar structure and its production follows a

similar path to the Project Plan package. The Stage Plans are produced in the “Managing

Stage Boundaries (SB)” Process.

Short horizon, limited commitment, planning is a fundamental feature of PRINCE. The

aim is to provide an overall view of the likely project profile (via the Project Plan package)with a succession of short term limited commitments for the sponsor (via the Management



Stage Plan documentation). The structure of the PRINCE 2 Stage Plan package is asfollows:

♦ Stage Product Breakdown Structure - listing all the Stage Products to be produced. Product Descriptions must also be available (or produced) for all Stage Products.

♦ Stage Product Flow Diagram - listing the Products to be produced during the stageand the derivation paths.

♦ Stage Timed PERT Network - showing the Earliest Start/Finish Times, Float and overall project timings.

♦ Stage Gantt Plan - This plan relates specialist activities against time-scales (typically

on a week-by-week basis) and summarises the level of control (frequency of

Checkpoints, Quality Reviews and another meetings required by the Project Board).

♦ Stage Resources Report- summarises the resource effort and costs for the stage.Where there is no software support package in use, a Stage Resource Plan should be

provided to identify the effort and costs to be approved by the Project Board. It is produced by taking the Stage Gantt Plan and creating a Transfer Sheet for eachresource. The Stage Resource Plan is usually constructed on a week-by-week timescale and, in any case, must match the Stage Gantt Plan.

♦ Optional Stage Graphical Summary - provides a graphical view of the time:cost:achievement for the stage. This might be supplemented or replaced by and Earned Value Analysis Plan.

♦ Stage Plan Text - ties together and summarises the above plans and will essentiallycover the stage plan pre-requisites, assumptions and risks. This narrative might be

incorporated into the Project Plan Description.

Initiate

SpecifyDesign

Build

TestTrain

Handover

Management

Stage 1

Management

Stage 2

Management

Stage 3

Start-Up

Project Brief

Project Approach

PIDInterview Users

Produce Spec

Outline DesignFinal Design

Agree Design

Figure 45: Stage Plan Derived From The Project Plan



Team Plans

Team Plans will usually (but not necessarily) be required for all but the smallest of

projects. They drop the Stage Plans down to an increased level of detail in much the sameway that the Stage Plans reflect an increased level of detail of the Project Plans.

Team plans are optional within the PRINCE 2 Method and where they are produced they

will normally be prepared by the Team Manager within the “Managing Product Delivery(MP)” Process, based on the authorised Work Package in consultation with the TeamMembers and agreed with the Project Manager.

The Team Plan Package, where produced, will be related to a specialist team working on aspecific Product or set of Products or they might be aimed at an individual working within

the project. Team Plans will often reflect the work to be carried out in a Technical Stagewithin a Management Stage of the project.

Individual Plans

Individual Plans (sometimes referred to as Work-to Lists) are not required within

PRINCE 2 but may, at the Project Manager/Team Manager’s discretion, be drawn up for individuals working on specified Products. The Individual Plans, where used, will be

derived directly from the Detailed Gantt Plan and will form the basis for discussion of

progress at the regular (usually weekly, but at the regularity agreed within the authorisedWork Package) Checkpoints.

The Individual Plan may comprise a detailed Bar Chart/Gantt Chart, Activity List, or might only identify start and finish dates and Activity Status for specific Products.

PRINCE 2 Planning - Summary

There is a need within any project to produce plans in sufficient detail to derive

understanding of the way that objectives are to be achieved.

In the final analysis, control can only be exercised at the level that is enabled by the plans.If a project is planned only at a high level then detailed control cannot be effected. Therecommended approach is to plan in detail to get a full understanding of what is involvedand then to select an appropriate level of control based on what is known about the project.



STARTING UP A PROJECT (SU)



Starting Up A Project (SU) - Introduction

This is the first Process within a PRINCE 2 managed project. A Project Mandate in the

form of a memo, formal or informal request will normally trigger this Process, althoughthere is no prescribed format.

Figure 62: Starting Up A Project (SU) Process

The “Starting Up a Project (SU)” Process provides a solution to the “ragged beginning”concept that bedevils many projects. Just how a project gets under way is a question often posed by managers who find that they are asked to carry out planning and preparatorywork by Customers but are warned against committing any resources without authority!Quite a dilemma which PRINCE 2 seeks to bridge by the use of this Process.

The Process seeks to set up the project by creating clear objectives, set up a suitableProject Management Team, identify a realistic approach to the work to be done, and planning for the next stage of the work (normally the Initiation Stage). The project

formally exists at the conclusion of this Process when the Project Board will be asked togive a “go/no-go” decision on whether there is the rationale, will and business need for the

proposed project. This decision will normally take place at a “Project Initiation Meeting(PIM) which marks the formal start to the project.

Appointing a

PB Executive

and PM

SU1

Designing a

Project

ManagementTeam

SU2

Appointing a

Project

ManagementTeam

SU3

Preparing a

Project Brief

SU4

Defining

Project

Approach

SU5

Planning an

Initiation Stage

SU6

Authorising

Initiation

DP1

Planning

Quality

IP1

Assembling

a PID

IP6

Project

Brief

Project

Approach

Project

Management Team

structure and job

descriptions Project

Brief

ProjectMandate

Draft Initiation

Stage Plan



SU1 - Appointment of a Project Board Executive and a Project

Manager

To get any undertaking under way, there is a need for a decision-maker (the Project Board

Executive) and a planner (the Project Manager). As soon as the project is “floated” by thereceipt of a Project Mandate, these two appointments must be made by CorporateManagement. Between them they will arrange to set up the proposed project in an orderly

and structured way by creating suitable decision-support documentation comprising The Project Brief, The Project Management Team, The Project Approach, and the Plan for the

Initiation Stage.

PROCESS

INPUT & SOURCE

PRODUCTS CREATED,UPDATED, REFERENCED OR

USED

OUTPUT TO

Project Board Executive Appointment [C]

Designing A Project Management Team(SU2)

SU1 –AppointingA ProjectBoardExecutive &ProjectManager

Project Mandate(CorporateManagement)

Project Manager Appointment [C] Designing A Project Management Team(SU2)

Figure 63: SU1 Plus Inputs and Outputs

The appointment of the Project Board Executive and the Project Manager will allow anumber of Products to be started. Although the PRINCE 2 Manual indicates an order of

precedence - design and appointment of the Project Management Team as the next step -there is no reason why the Project Manager should not immediately commence work on

the Project Approach and the Project Brief. These two documents will have a major

influence on the design of the Project Management Team and identification of the mostappropriate individuals to make the project management actually work.

In practice, the Executive needs to have a close involvement with the production of the

Project Approach and the Project Brief, as these are the two prime documents which will provide the decision support information for the Project Board Members when they areasked to approve the Initiation Stage of the project.



SU2 & SU3 - The Project Management Team

The Project Management Team is the group of people who are responsible for the

planning, management , and control of the project. It might not always be possible toappoint the whole team at this early stage but as many of the key appointments as possibleshould be made.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

SU2 –Designing AProjectManagementTeam


Executive & Project Manager Appointment (SU1)

Project Management TeamStructure [C]

Appointing A Project Management Team(SU3)

Job Definitions [C] Assembling A PID (SU6)

Authorising Initiation(DP1)

SU3 –Appointing AProjectManagement

Team

Project Management TeamStructure (SU2)


Assembling A PID (SU6)


Figure 64: SU2 & SU3 Plus Inputs and Outputs

Part of the work in this Process will include the definition of Roles and Responsibilities for each member of the Project Management Team. A start point for these is included atAppendix C of the PRINCE 2 Manual. It is important to ensure that each member of the

Project Management Team clearly understands the expectations that go with the job, andthe Role Descriptions ensure that this is clearly communicated. Role Descriptions will

apply to all members of the Project Management Team including the senior managers whoare on the Project Board for the project.

Responsibility for establishing the Project Management Team rests jointly with theExecutive and Project Manager, the Executive taking the lead in identifying and

appointing the Project Board Members. When the Project Management Team has beenestablished it will accompany the other outputs of SU to be endorsed by the newly

established Project Board during consideration of the Initiation Stage Plan in DP1. Thesource documentation will be used to assemble the Project Initiation Document in IP6



SU4 - The Project Brief and Its Relationship To The Project

Mandate

The Project Brief will normally contain the formal Terms of Reference (objectives, scope,

constraints, interfaces etc) for the Project together with an Outline Business Case, basedon the information contained in the Project Mandate

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Brief [C] Defining Project Approach (SU5

Planning An InitiationStage (SU6)

Planning Quality (IP1)

Planning A Project (IP2)

Refining The BusinessCase & Risks)

Assembling A PID (IP6)


SU4 –Preparing AProjectBrief


Risk Log [C] Planning An InitiationStage (SU6)

Planning A Project IP2

Refining The BusinessCase & Risks (IP3)


The Project Brief is based on the Project Mandate which provides the “trigger” for the project. The Project Mandate may take any form from an informal request by a senior

manager to a formal request to provide a proposal from a customer to a potential supplier.The Project Mandate may therefore be quite thin on information in which case the Project

Brief will take a fair amount of effort to complete. On the other hand, where the ProjectMandate is a comprehensive document emanating from, say, a feasibility or scoping study,

there should be little to add to turn it into a suitable Project Brief.

The Project Brief is used primarily in “ DP1 - Authorising Initiation”, by the ProjectBoard, to decide whether the proposed project merits the time and effort needed to produce



a Project Initiation Document. It needs to address the fundamental reasons and constraintsthat support the proposal for the project - it is essentially a “first-cut” Project InitiationDocument.

The Customer’s Acceptance Criteria are contained within the Project Brief and although

the Product Outline for the Project Initiation Document , included in the PRINCE 2Manual , does not specifically mention the Acceptance Criteria within the “Composition”

section, it makes sense to incorporate Acceptance Criteria within the PID as these can then be used for comparative purposes at each Management Stage review ( End Stage Assessment ), at Project Closure (“Decommissioning A Project (CP1)”) where Customer Acceptance is obtained, and in “Confirming Project Closure (DP5)” where the project is

formally shut down.



SU5 - The Project Approach:

A suitable Approach to the project must be considered, discussed with the Project Board

Executive Member and agreed before seeking authority to prepare a Project Initiation Document (acceptance of which by the full Project Board will signal the formal start of the project). Examples of the Approach to the project are:

♦ In-house development/construction;

♦ Out-sourcing to one or more Suppliers;

♦ Joint venture development as a partnership;

♦ Prime Contractor sourcing with multiple sub-contractors;

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

SU5 –DefiningProject

Approach

Project Brief (SU4)

Risk Log (SU4)

Project Approach [C] Planning An InitiationStage (SU6)






Planning (PL)


After formal endorsement by the Project Board, the Project Approach is included in the

Project Brief (and possibly also the Project Initiation Document). It provides a major contribution to planning the project - Initiating A Project (IP2).



SU6 - The Initiation Stage Plan

A suitable plan for the Initiation Stage must be produced to enable the Project Board toauthorise the creation of a suitable Project Initiation Document (PID) to authorise the

commencement of the project. Production of the PID might well consume considerabletime, effort and cost and is a key document that will be used to Baseline the project. Ittherefore needs to be properly planned, resourced and authorised at a level appropriate tothe investment being proposed.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Draft Initiation Stage Plan [C]


SU6 –Planning AnInitiationStage

Project Brief (SU4)

Risk Log (SU4)

Project Approach(SU5)

Risk Log [U] Authorising Initiation(DP1)


The Method presumes that the “Starting Up A Project (SU)” Process will be a separate“front-end” to the project and approval of the Initiation Stage Plan will provide

authorisation for the first Management Stage of the project. However, for smaller, low risk, projects, the first stage might well embrace the “Starting Up A Project (SU)” and“Initiating A Project (IP)” Processes. Indeed other Processes might also come into playduring the first Stage of the project - these include “Controlling A Stage (CS)”,“Managing Product Delivery (MP)”, “Managing Stage Boundaries (SB)”. Because of the

involvement in the authorisation processes, the Project Board will also be in play withinthe “Directing A Project (DP)” Process.

The “Planning (PL)” Process, the “Planning A Stage (SB1)” Process, and the Product

Based Planning Technique, are all used in Planning An Initiation Stage. The planningaspects are straightforward as there is a need only to plan for a short time-scale and for avery simple series of Products and related Activities.



Starting Up A Project - Summary

This Process, with the next (“Initiating A Project (IP)”) is critical to the success of any

PRINCE 2 project as it sets the scene, expands the often flimsy Project Mandate, and laysdown the foundation for the organisational structure for the project. It will often becombined with the IP Process and others, especially where a smaller project is being

addressed. If “Starting Up A Project (SU)” serves to put a brake on the understandableenthusiasm to commence development work before the basics of the project have been

thought through, then it will have served its purpose.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Board Executive Appointment [C]

Designing A Project Management Team(SU2)

SU1 –Appointing AProjectBoardExecutive &ProjectManager


Project Manager Appointment [C] Designing A Project Management Team(SU2)

SU2 –Designing AProjectManagementTeam


Executive & Project Manager Appointment (SU1)


Appointing A Project Management Team(SU3)

Job Definitions [C] Assembling A PID (SU6)


SU3 –Appointing AProjectManagementTeam



Assembling A PID (SU6)




Project Brief [C] Defining Project Approach (SU5

Planning An InitiationStage (SU6)



Refining The BusinessCase & Risks)


Authorising Initiation

(DP1)

SU4 –Preparing AProject Brief


Risk Log [C] Planning An InitiationStage (SU6)

Planning A Project IP2


SU5 –DefiningProject

Approach

Project Brief (SU4)

Risk Log (SU4)

Project Approach [C] Planning An InitiationStage (SU6)






Planning (PL)

Draft Initiation Stage Plan [C]


SU6 –Planning AnInitiationStage

Project Brief (SU4)

Risk Log (SU4)


Risk Log [U] Authorising Initiation(DP1)

Figure 68: Summary of the “Starting Up A Project (SU) Process



INITIATING A PROJECT (IP)



Initiating A Project (IP) - Introduction

The “Initiating A Project (IP)” Process is aimed at ensuring that a firm Baseline exists

for the project and that everyone involved understands what the project is seeking toachieve. In smaller projects, this Process might well be combined with the “Starting Up A Project (SU)” process but this should be considered carefully. A controlled break between

“Starting Up A Project” and “Initiating A Project” is always required event though bothProcesses may be combined within the same Management Stage.

Figure 69: Initiating A Project (IP) Process

The Project Initiation Document

The major output for this Process is a Project Initiation Document (PID), which will be

used throughout the project to ensure that the work carried out and theProducts/Deliverables being produced are supporting the key objectives and meet thecustomer’s needs. The PID will always need to address the following:

♦ to identify the benefits and risks and to evaluate proposals for managing identified

areas of risk, thus confirming that an acceptable Business Case exists for the project;

Planning

Quality

IP1

Planning a

Project

IP2

Refining the

Business

Case and

RisksIP3

Setting up

Project

ControlsIP4

Setting up

Project Files

IP5

Assembling a

PID

IP6

Authorising a

Project

DP2

Authorising

Initiation

DP1Authorised

StageInitiation

Plan

Project

Brief

Draft PID

Corporate QMS



♦ to provide a foundation for the project from which the Project Initiation Document can

be assembled or prepared.

♦ to provide decision support information to enable the Project Board to confirm theinitial (and ongoing) viability for the project;

♦ to encourage the Project Board to understand and take ownership of the project;

♦ to provide sufficient information for the Project Board to approve the whole project in principle and to commit resources, formally, for the next Management Stage;

♦ to provide a Baseline for all decision-making for the duration of the project;

♦ to initiate the project in an orderly manner, thus setting “Norms” for the remainder of

the project;

♦ to monitor the progress of the project initiation process against the approved plans.

An Initiation Stage is recommended to be included in any PRINCE 2 managed project;given that the minimum number of Management Stages within any PRINCE 2 project will

be two, this principle ensures that there will always be at least one “planning” Stage andone “action” Stage.

The PID is used as a Baseline for the project. It is assembled from Products generated inthe “Starting Up A Project (SU)” Process and the “Initiating A Project (IP)” Process andwhen approved by the Project Board it signifies the official start of the project. The

approved PID will be input to every formal review of the Project (ESAs and MSAs) tocheck progress against the agreed baseline. It is also used at Project Closure

(“Decommissioning A Project (CP1)”) to measure the project outcome against theAcceptance Criteria; successful matching will generate a Customer Acceptance of theoutcome.



IP1 - Planning For Quality

Quality plays an important role in any PRINCE 2 project and as such it must be

considered before any major planning activity takes place. The Customer’s QualityExpectations will have been identified in the “Starting Up A Project (SU)” at the time theProject Brief was prepared.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

IP1 –PlanningQuality

Quality Standards(Programme and/or Corporate QMS)

Project Brief (SU4)


Project Quality Plan [C]


Setting Up Project Controls (IP4)

Setting Up Project Files(IP5)


Figure 70: IP1 Plus Inputs and Outputs

This needs to be built upon and cross-matched with the supplier organisation’s own qualitystandards, usually resident in the Quality Management System (QMS).

A correlation between the International Standards Organisation BS/EN/ISO 9001 standardfor quality management and what is offered within the PRINCE 2 Method is provided in

Appendix B of the PRINCE 2 Manual. This Appendix should be used to match thesupplier organisation’s QMS to the requirements of PRINCE 2 and is especially useful

where a QMS is being specified and introduced.

Where an organisation-wide QMS is not already in force, management should consider introducing a specific Project QMS - having no quality strategy is not an option!

Other aspects that need to be considered are the project staff’s ability to perform effective

Quality Reviews and to understand the significance of the Quality Criteria that will beincluded in the Product Description for each Product/Deliverable.



IP2 - Planning A Project

Although PRINCE 2 includes a separate Process for “Planning (PL)” and includes

planning as a Component and a specific Technique (Product-Based Planning), theactivities associated with planning for a specific project situation come into operationwithin the Process concerned with the specific plan required. For example, planning the

project is an activity which must be undertaken right at the start of the project and liesnaturally within the “Initiating A Project (IP)” Process. Similarly, planning for each

Management Stage is a function of “Managing Stage Boundaries (SB)” as the ProjectManager prepares for the transition from the Current Stage to the Next Stage and preparesdocumentation for the Project Board to reach an informed decision.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Plan [C] Refining The BusinessCase & Risks (IP3)




Planning A Stage (SB1)

Risk Log [U] Refining The BusinessCase & Risks (IP3)

IP2 –Planning AProject

Project Brief (SU4)

Risk Log (SU4)


Project Quality Plan(IP1)

Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1)


The Project Manager and the rest of the Project Management Team will use the “Planning (PL)” Process and the Product Based Planning Technique to prepare the required planswithin the appropriate Processes.

The Process requires a demonstration of an understanding of the project in the long term.The Project Manager is not expected to be able to predict accurately to the full term of the project, but must make an intelligent stab at what the future holds and plan for

contingencies.



On their part, the Project Board must take a sensible and realistic view of the project,especially where the duration is extended, and view the project plan as a “soft estimate”.The Management Stage Plan (produced in “Managing Stage Boundaries (SB1)”) provides

the firm, but limited, commitment of resources within the framework of the Project Plan.

This approach ensures that a realistic planning horizon is always in focus (the Stage Plan)within the context of the overall Project Plan.



IP3 - Refining The Business Case

The Project Brief will have identified an outline Business Case for the project. This

preliminary assessment will have been approved in principle by the Project Board whenconsidering the package put forward in support of investing resources into creating asuitable Project Initiation Document to support the authorisation of the project.

The outline Business Case needs to be enhanced and refined before a final decision to startthe project can be made. The expected Business Benefits will need to be clearly specified

and the risks associated with the project identified.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Risk Log [U] Setting Up Project Controls (IP4)


Business Case [C] Assembling A PID (IP6)

IP3 –RefiningTheBusinessCase &Risks

Project Brief (SU4)


Project Plan (IP2)

Risk Log (IP2) Project Plan [U] Assembling A PID (IP6)


Where possible, both elements of Business Benefits and Risk will need to be measured inconcert. In the case of the Business Benefits, a Costs:Benefits Analysis/InvestmentAppraisal should be considered.

Risks can be measured in many ways; PRINCE 2 does not recommend any particular approach from the many software-based risk assessment tools that are available but thereneeds to be a balance between creating an effective Risk Assessment, suitable as the basisfor Risk Management, and the time and effort that a comprehensive assessment is bound to

consume. A simple Risk Analysis Checklist has been in use in PRINCE projects for manyyears and an enhanced variant of this has been included at Chapter 7. Use of the Risk

Analysis Checklist is straightforward and an advantage is its visibility - it is well worth atry and usually provides acceptably accurate results.

The Business Case, when approved by the Project Board will need to be reviewed and up-dated when preparing for each Management Stage Review (see “Managing Stage

Boundaries (SB)”).



IP4 - Setting Up Project Controls

Project controls are the key to the successful management of any project. It is only possible to control a project to the level of detail in which it has been planned so the

Project (and later, the Stage) plans are critical to the successful management of the project.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Plan [U] Assembling A PID (IP6)

Project Controls [C] Assembling A PID (IP6)

Risk Log [U] Assembling A PID (IP6)

IP4 –Setting UpProjectControls


Project Plan (IP2)

Risk Log (IP3)

Communication Plan [C] Assembling A PID (IP6)


This Process is concerned with the identification of the most appropriate level of control

for the project. For large, high-risk projects it may be expected that all the controls listed below will be appropriate. For smaller, low-risk projects it will be necessary to consider

both the types of control that are appropriate and their frequency. In principle, however,all the controls listed below will be appropriate to all projects whatever their size. Themanagement controls that will be identified and used in any PRINCE 2 project fall intotwo main categories:

Project Board Controls

♦ Project Initiation Meeting & Project Initiation;

♦ Management Stages - End Stage Assessment;

♦ Exception Reporting & Management - Mid Stage Assessment;

♦ Tolerance – Time & Costs;

♦ Highlight Reporting (from the Project Manager to Project Board Members).

♦ Business Case Re-evaluation (Business Benefits)



♦ Risk Analysis (+ Up-date of the Risk Log);

♦ Project Closure.

Project Manager/Team Controls:

♦ Checkpoints;

♦ Quality Reviews (Informal);

♦ Quality Reviews (Formal);

♦ Day-to-Day Communication/Ad-hoc Meetings.

Controls may also be appropriate at the Programme level but this will depend on thenumber, size and relationship of the projects that fall within the aegis of the PRINCE 2arrangements within a particular implementing organisation.



IP5 - Set Up Project Files

All projects will produce documentation which must be stored in an appropriate and

secure way. A fair amount of documentation will already have been produced in the“Starting Up A Project (SU)” Process and organisations implementing PRINCE 2 projectmanagement systems will wish to consider whether setting up the project filing structure

would best be carried out during the SU Process.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Filing Structure [C] Assembling A PID (IP6)

Issue Log [C] Controlling A Stage (CS)

Quality Log [C] Controlling A Stage (CS)

IP5 –Setting UpProjectFiles


Project Plan (IP2)

Lessons Learned Report [C] Controlling A Stage (CS)

Figure 74: IP5 Inputs & Outputs

The documentation which will already be in place following “Starting Up A Project (SU)”is:

♦ The Project Management Team Organisation Structure;

♦ Roles and Responsibilities for Project Management Team Members;

♦ The Project Brief;

♦ The Project Approach;

♦ The Risk Log;

♦ The Plan for the Initiation Stage;

♦ The Project Board Sign-off Approving the Initiation Stage Plan;

♦ Records of the Project Board Meeting (if appropriate).



PRINCE 2 suggests a filing structure but does not require an electronic format, a physicalfile or both. Perhaps the best approach is to have both electronic and physical file

structures sharing a common structure. This will enable Project Managers to maintaincopies of documentation in a format which is permanent, structured and flexible.

All files and their associated documentation, whatever their format, will need to bearchived at the conclusion of the project to allow for appropriate auditing.

Figure 75: PRINCE 2 Suggested Filing Structure

Project File

OrganisationPlans

Business Case

Risk Log

Control Documents

Products Checklist

Files

Stage File(s)

OrganisationPlans

Control Documents

Daily Log

Correspondence

Products Checklist

Specialist File

Configuration ItemsConfiguration Log

CI Locations

Off-Specifications

Quality File

Product DescriptionsQuality Checks

Project Issues



IP6 - Assembling The Project Initiation Document

The key document to be output from the “Initiating A Project (IP)” Process is the Project

Initiation Document. (PID) This document provides a comprehensive view of the projectas it is viewed from the outset of the project.

The PRINCE 2 concept of “assembling” a Project Initiation Document is understandable

but not necessarily realistic as there are always many additional elements that, at the pointthe PID is put together, are not available. To help with this, a Project Initiation Document

Template should be prepared for use in all projects within the implementing organisation.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

IP6 –AssemblingA PID


Project Brief (SU4)

Project Management TeamStructure + JobDefinitions (SU3)


Project Plan (IP2)

Business Case(IP3)

Risk Log (IP3)

Project Controls

(IP4)

CommunicationPlan (IP4)

Project Filing Structure (IP5)

Draft Project Initiation Document(PID) [C]

Authorising A Project (DP2)




Completion of the PID will trigger the need to plan for the next Management Stage of the project. The work for this activity will be carried out in the Process “Managing Stage Boundaries (SB)” within the Sub-Process “Planning A Stage (SB1)”.

The PRINCE 2 Method does not recommend that the plan for the next stage be included in

the Project Initiation Document, thereby putting the emphasis on this document beingconcerned with the project itself.

Approach to Assembling or Producing The PID

Assembly of the PID is a very simple task if all the component parts are available and it

can easily be performed by Project Support or the Project Manager. If this is not the case,

the use of the PID Template will make the task much simpler and enable the work to beshared. In practice, the best approach has been found to be to hold a “PIDWorkshop”attended by all members of the Project Management Team (including Project Boardmembers where they can spare the time). Typically one or two days is sufficient, providedsome foundation work has been undertaken. Where this approach is taken, the Project

Initiation Stage Plan should reflect the time and resources needed.



Initiating A Project (IP) - Summary

Successful initiation of any project is a key contributor to its eventual outcome. The time,

effort and resources invested in this stage will be well worthwhile, especially if someunforeseen problem occurs during the project. The Project Board and ProjectManagement Team will have firm ground on which to base decisions about proposed

changes in direction and investment of resources.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

IP1 –PlanningQuality

Quality Standards(Programme and/or Corporate QMS)

Project Brief (SU4)


Project Quality Plan [C]





Project Plan [C] Refining The Business

Case & Risks (IP3)





Risk Log [U] Refining The Business

Case & Risks (IP3)

IP2 –

Planning AProject

Project Brief (SU4)

Risk Log (SU4)



Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1)

Risk Log [U] Setting Up Project Controls (IP4)


Business Case [C] Assembling A PID (IP6)

IP3 –RefiningTheBusinessCase &Risks

Project Brief (SU4)


Project Plan (IP2)

Risk Log (IP2) Project Plan [U] Assembling A PID (IP6)



Project Plan [U] Assembling A PID (IP6)

Project Controls [C] Assembling A PID (IP6)

Risk Log [U] Assembling A PID (IP6)

IP4 –

Setting UpProjectControls

Project Quality Plan

(IP1)

Project Plan (IP2)

Risk Log (IP3)

Communication Plan [C] Assembling A PID (IP6)

Project Filing Structure [C] Assembling A PID (IP6)

Issue Log [C] Controlling A Stage (CS)

Quality Log [C] Controlling A Stage (CS)

IP5 –Setting UpProjectFiles


Project Plan (IP2)

Lessons Learned Report [C] Controlling A Stage (CS)

IP6 –AssemblingA PID


Project Brief (SU4)

Project Management TeamStructure + JobDefinitions (SU3)


Project Plan (IP2)

Business Case(IP3)

Risk Log (IP3)

Project Controls(IP4)


Project Filing Structure (IP5)

Draft Project Initiation Document(PID) [C]

Authorising A Project (DP2)

Figure 77: Summary Of The Initiating A Project (IP) Process

Another major, but intangible output from this Process is the understanding thatindividuals within the Project management Team (including the Project Board Members)

will gain about the nature, scope and possible pitfalls that the project may have to face.



The inclusion of an Initiation Stage in any PRINCE 2 controlled project is not optional -the method is very clear that an Initiation Stage be included whatever the type, scope or size of the project. The PID itself will be used to provide a baseline for the project

throughout its life and beyond, extending to the completion of a Post-Project Reviewsometime after the project is closed down (typically some 6-9 months after the Productfrom the project has been handed over to the customer).

When the PID has been completed and assembled, it is ready to be reviewed by the ProjectBoard within the “Directing A Project (DP2)“ Process. The vehicle for this is an EndStage Assessment (at the completion of the mandatory Initiation Stage). Acceptance of the PID and approval by the Project Board signals the formal start of the project.



DIRECTING A PROJECT (DP)



Directing A Project (DP) - Introduction

D irecting A Project (DP) operates throughout all stages of the project, from the end of

Project Start-up through to Project Closure and is the primary concern of the ProjectBoard. They achieve this by managing by exception, monitoring through reports provided primarily by the Project Manager, and controlling through a series of key decision points.

Figure 78: Directing A Project (DP) Process

The key Processes break into the following areas:

♦ Control of the Initiation of the project ensuring it has the best possible start;

♦ Authorisation of the Project, committing the organisation to its successful outcome;

♦ Authorising Continuation of the project where a significant departure from theapproved plans has occurred;

♦ Control of the Stage Boundaries, committing new and additional resources as the

project progresses towards its ultimate aim;

Authorising

Initiation

DP1

Starting up

a Project

SU

Authorising

a Project

DP2

Authorising

a Stage or

Exception

PlanDP3

Giving

Ad hoc

Direction

DP4

Confirming

Project

Closure

DP5

Initiating a

Project

IP

Controlling

a Stage

CS

Managing

Stage

Boundaries

SB

Closing a

Project

CP

Project Brief

Draft Initiation Stage Plan

Job Definitions

Project Management Teamstructure

Project Approach

Authorisation

to proceed

Draft

PID

Authorisation

to proceed

Authorisation

to proceed

Highlight Report

Exception Reports

Requests for adviceEnd Project Report

Project Closure

Recommendation

Draft Post Implementation

Review Plan

Follow-on Action

Recommendations

Lessons Learned Report

Operational and

maintenance confirmationPID

Follow-on Action Recommendations

Lessons Learned ReportPost Implementation Review Plan

Project Closure Notification

Information from external sourcesProject Start-up

Notification

PIDException Plan

End Stage Report

Next Stage Plan

Project Team changesUpdated Project Plan

Updated Business Case

Updated Risk Log

Mobilisation of support

services

Approved PID Exception Report

Request For

Exception Plan



♦ Ad-hoc Decision-making and Direction, monitoring progress and providing advice and

guidance as necessary;

♦ When the project has achieved its outcome, or is no longer considered to be a viablebusiness proposition, arranging for Project Closure, bringing the whole undertaking to

a controlled finish.

This Process does not cover the day-to-day activities of managing the project - these restwith the Project Manager. The Process is positioned at the level of management residingabove the Project Manager.

Information will be presented to the Project Board in a number of ways, from formal

report documents such as the Project Initiation Document (PID) through HighlightReports, usually prepared on a monthly basis, to requests for ad-hoc direction by the

Project Manager where a gentle “touch on the tiller” is required and senior managementsupport is recommended. The Process is one of the busiest within the Process Model interms of potential and actual inputs and outputs and the physical interpretation of how todirect a project may be expected to add further reports and directives.

A key requirement within this Process is having senior managers on the Project Board whohave the organisational authority to commit the resources that will be needed to see the project through to a successful conclusion. The ability to make decisions on commitmentof additional resources in the event of problems and the vision to see the wider picture are

also vital ingredients resident within this Process.

Management By Exception

A guiding principle at this level should always be the ability for senior managers to adopt

a “hands-off” approach and to become involved with the project only at those points intime when their input is needed and to adopt a Management by Exception approach.

Essentially this approach requires Project Board members to view the project strategicallyand to become involved only at planned review dates and at unscheduled meeting called

only because the project has significantly departed from the approved plan. This ismeasured by a control known as “Tolerance” - essentially the scope a Project Manager has

to depart from an approved Stage Plan without needing to report the departure to theProject Board.

A forecast that the current Stage will not be able to complete within Tolerance (standard

Tolerance of Time and Cost) will result in an Exception Report being prepared by theProject Manager for consideration by the Project Board members. An Exception Plan will

often follow, this being produced by the Project Manager, which will be considered by theProject Board at a specially convened Mid-Stage Assessment.



DP1 – Authorising Initiation

The work carried out in the “Starting Up A Project (SU)” Process is designed to put

together enough information for the Project Board to make a “ go/no-go” decision onwhether to invest the necessary resources into the creation of a Project InitiationDocument (PID).

The Project Board will be presented with a set of decision support documentation andasked to approve the project in principle.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Authorisation To Proceed [C]

Stage Plan [U]

Project Brief [U]

Risk Log [R]

Project Management TeamStructure [R]

Project Approach [U]

Initiating A Project (IP)

DP1 –AuthorisingInitiation


Job Definitions(SU3)

Project Brief (SU)

Risk Log (SU)


Draft InitiationStage Plan (SU6)

Project Start-up Notification [C] Corporate or ProgrammeManagement

Figure 79: DP1 Plus Inputs and Outputs

The project formally starts when this approval is gained (not when the Project InitiationDocument has been prepared and approved).

For low risk, smaller, projects a formal meeting of the Project Board may not be necessaryand approval may be given directly by the Executive member (having responsibility for the overall business objectives).



DP2 – Authorising A Project

Following the creation of the Draft Project Initiation Document (PID) in “Initiating A

Project (IP)” the project can be approved formally by the Project Board and the PID“frozen”. The point of doing this is to establish a baseline against which to judge the project as it proceeds towards its conclusion and to measure against the final out-turn

although certain parts of the PID are reviewed and modified at the end of eachManagement Stage; these are the Project Plan, the Business Case and the Risk Log .

PROCESS

INPUT & SOURCE

PRODUCTS CREATED,UPDATED, REFERENCED ORUSED

OUTPUT TO

Authorisation To Proceed [C] Authorising Work Package (CS1)

DP2 –AuthorisingA Project

Draft Project Initiation Document (IP6)

Next Stage Plan(SB1)

Approved Project InitiationDocument [U]

Corporate or ProgrammeManagement


The above diagram shows how both the Draft Project Initiation Document and the plansfor the next Management Stage are input to this Process as decision supportdocumentation. Note that the plans for the next Management Stage are not included as part of the PID but are prepared within a separate Process (“Managing Stage Boundaries(SB1)”) and accompany the PID as a separate document (the End Stage Report ).

Approval of the draft PID and the next Management Stage plans commits the resourcesand triggers commencement of work, providing authorisation for the Project Manager to

begin using the resources in the plans.

A copy of the approved PID is lodged in the Project File and Corporate Management isnotified of the existence of the project by dispatch of a notification, or copy of the PIDwhatever is most appropriate.



DP3 – Authorising A Stage Or Exception Plan

As it proceeds, the project will be reviewed by the Project Board at the conclusion of each

Management Stage. Essentially the Project Board will be looking for evidence that theManagement Stage has been completed to budget, on time and meeting the requirementsof the Product Descriptions. This will be formally undertaken at an End Stage Assessment

(ESA) and an approval will be sought for the project to continue and the next ManagementStage plans approved and resources committed.

PROCESS

INPUT & SOURCE


OUTPUT TO

Authorisation To Proceed [C] Controlling A Stage (CS)

Tolerances [C] Controlling A Stage (CS)

Business Case [U] Controlling A Stage (CS)

Project Plan [U] Controlling A Stage (CS)

DP3 –AuthorisingA Stage or ExceptionPlan


Project Management TeamChanges (SB5)

Product Checklist (SB5)

Business Case(SB5)

Risk Log (SB5)

End-Stage Report (SB5)

Request for Authorisation ToProceed (SB5)

Exception Plan(SB6)

Project InitiationDocument (IP6)

Project Tolerances(Corporate or ProgrammeManagement)

Progress Information [C] Corporate or ProgrammeManagement and other interested parties.




A number of products and documentation are needed for the Project Board to properlycarry out this responsibility and these are all created and/or updated within the “Managing Stage Boundaries (SB)” Process. Logs and on-going reports will be retrieved from the

appropriate file and input to the Project Board either before or at the Project Boardmeeting. Care should be taken not to swamp the Project Board with too much paper or unimportant information.

Approval of Exception Plans

This Process is used also for approving Exception Plans. An exception occurs when a

significant deviation from an approved plan occurs; a “significant deviation” is measured

by whether Tolerance is exceeded and may occur as a result of a technical or quality

problem within the project or a suggested change to one or more Products.

The procedure is for an Exception Report to be raised by the Project Manager, alerting theProject Board members of the perceived problem. The Exception Report provides astatement of the problem, an analysis of its impact, the options available for recovery and

a firm recommendation for recovery.

The Exception Report is considered by the Project Board and a decision taken on whether

the project may continue without any further action, or whether the remainder of theManagement Stage needs to be re-planned to reflect the problem or required change.

If the Project Board decide that the situation is serious enough to warrant it, an Exception

Plan is produced by the Project Manager. The Exception Plan will be considered by theProject Board at a Mid Stage Assessment and after its approval, substitutes the plan itreplaces.



Figure 82: Exception Reporting and Planning

Figure 76 summarises the procedure for notifying the Project Board of a significant

departure from plan (via the Exception Report) and subsequently the creation of the

Exception Plan. Also shown on the above diagram is the Project Board’s option toterminate the project prematurely if they do not wish to continue with the undertakingfollowing a major change in the approved plans (although this decision might have been

taken earlier, when the exception was first reported and considered in the Process “Giving Ad-Hoc Direction (DP4)”. Where the cancellation option is preferred, the prematureclosedown of the project will be handled within the “Closing A Project (CP)” Process.

CS8

Escalating

Project IssuesDP4

Giving

Ad-Hoc Advice

1: Exception Report

DP3

Authorising A Stage or

Exception Plan

SB6

Producing An

Exception Plan

2A: Direction

3: Trigger - (Copy of

Exception Report)

4: Exception Plan

CS1 -

Authorising A

Work Package

5: AuthorisationTo Proceed

Premature Termination of Project

2B: Request for

Exception Plan

Mid-Stage

Assessment

Problem … Forecast to Exceed Tolerance



DP4 – Giving Ad-Hoc Direction

This Process is the most powerful of all the Processes in that it includes provision to

terminate the project prematurely if the Project Board are unhappy about the progress being made or if a significant departure from the approved plans occurs.

The Process is also concerned with giving advice to the Project Manager and other staff

employed on the project as and when it is needed and requested.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Exception Plan Request [C] Producing An ExceptionPlan (SB6)

Premature Close [C] De-Commissioning AProject (CP1)

Response to External Sources(Corporate & Programme

Management)

Corporate & ProgrammeManagement

DP4 –Giving Ad-HocDirection

Information from &to External Sources(Corporate or ProgrammeManagement)

Highlight Reports(CS6)

Requests for

Advice (CS7)

Exception Report (CS8)


Response to Requests for Advice Project Manager


Highlight Reports, prepared by the Project Manager (usually monthly, but at the frequency

required by the Project Board) will provide much of the everyday input for the ProjectBoard’s advice, comments and direction. Information coming into the project fromexternal sources will also be filtered by the Project Board and acted upon, usually by providing direction to the Project Manager.



DP5 – Confirming Project Closure

The responsibilities of this sub-process will usually (but not necessarily) be exercised

through the holding of a Project Closure Meeting where the project will be shut down inan orderly and structured way.

The information needed for the Project Board to shut down the project will be produced in

“Closing A Project (CP)” Process and will include Customer Sign-off and identificationof any follow up actions.

The approval of a plan for performing a Post-Project Review (usually some 9-12 monthsafter the closedown of the project will also be considered during this final Process.

A fuller summary of the inputs and outputs to DP5 is shown in the following diagram:

Project Closure Notification [U](Approved)


Follow0on ActionRecommendations [U] (Approved)


Post-Project Review Plan [U]

(Approved)

Corporate or

ProgrammeManagement

DP5 –ConfirmingProjectClosure

Operational &Maintenance Acceptance (CP1)

Customer Acceptance (CP1)

Project ClosureRecommendation(CP1)

Post-Project Review Plan (CP2)

Follow-on ActionRecommendations(CP2)

Lessons Learned Report (CP3)

End Project Report (CP3)

Baselined Project Initiation Document (DP2)

Lessons Learned Report [U](Approved)





Specifically, the Project Board will wish to satisfy themselves that the project has a clearlydefined end and that an orderly hand-over to operational use has been effected. The

Project Board will look to the Senior User for confirmation that an acceptable End-Productis in existence and that it can be supported in an operational environment.

A close liaison with the Project Board members will need to be maintained throughout theProject Manager’s preparation for this very important Process, ensuring that there are nosurprises awaiting the members at the closure meeting.



Summary of the DP Process

It is within the “ Directing A Project (DP )” Process that every authorisation takes place.

The Process is extremely important to the successful outcome of the project.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Authorisation To Proceed [C]

Stage Plan [U]

Project Brief [U]

Risk Log [R]

Project Management TeamStructure [R]

Project Approach [U]

Initiating A Project (IP)

DP1 –

AuthorisingInitiation

Project

Management TeamStructure (SU3)

Job Definitions(SU3)

Project Brief (SU)

Risk Log (SU)


Draft InitiationStage Plan (SU6)

Project Start-up Notification [C] Corporate or ProgrammeManagement

Authorisation To Proceed [C] Authorising Work Package (CS1)

DP2 –AuthorisingA Project

Draft Project Initiation Document (IP6)


Approved Project InitiationDocument [U] Corporate or

ProgrammeManagement



Authorisation To Proceed [C] Controlling A Stage (CS)

Tolerances [C] Controlling A Stage (CS)

Business Case [U] Controlling A Stage (CS)

Project Plan [U] Controlling A Stage (CS)

DP3 –

AuthorisingA Stage or ExceptionPlan

Next Stage Plan

(SB5)

Project Management TeamChanges (SB5)

Product Checklist (SB5)

Business Case(SB5)

Risk Log (SB5)

End-Stage Report (SB5)

Request for Authorisation ToProceed (SB5)

Exception Plan(SB6)


Project Tolerances(Corporate or ProgrammeManagement)

Progress Information [C] Corporate or ProgrammeManagement and other interested parties.

Exception Plan Request [C] Producing An ExceptionPlan (SB6)

Premature Close [C] De-Commissioning AProject (CP1)

Response to External Sources

(Corporate & ProgrammeManagement)

Corporate & Programme

Management

DP4 –Giving Ad-HocDirection

Information from &to External Sources(Corporate or ProgrammeManagement)

Highlight Reports(CS6)

Requests for Advice (CS7)



Response to Requests for Advice Project Manager



Project Closure Notification [U]

(Approved)

Corporate or

ProgrammeManagement

Follow0on ActionRecommendations [U] (Approved)


Post-Project Review Plan [U](Approved)


DP5 –

ConfirmingProjectClosure

Operational &

Maintenance Acceptance (CP1)

Customer Acceptance (CP1)

Project ClosureRecommendation(CP1)

Post-Project Review Plan (CP2)

Follow-on Action

Recommendations(CP2)

Lessons Learned Report (CP3)

End Project Report (CP3)

Baselined Project Initiation Document (DP2)

Lessons Learned Report [U](Approved)


Figure 85: Summary of the Directing A Project (DP) Process



CONTROLLING A STAGE



Controlling A Stage (CS) - Introduction

Following the Project Board’s decision to approve a Stage, the Project Management Team

must be fully focused on delivery of the Products, to their stated Quality Criteria, withinthe approved time-scales and budget, within the stated Tolerances.

Figure 86: Controlling A Stage (CS) Process

This Process forms the main part of the Project Manager’s effort on the management of the project, and provides the direction for the day-to-day management of the Stage and the

overall project. All through the Stage there will be an on-going cycle of:

♦ authorising Packages of Work that must be completed during the Management Stage

and receiving Completed Work Packages (or Products) back into the host organisation;

♦ gathering Progress Information about the work carried out and the resources and

effort expended;

Closing a

Project

CP

TakingCorrective

Action

EscalatingProject Issues

CS8

AuthorisingWork Package

AssessingProgress

Receiving

CompletedWork

PackageCS1CS7 CS2 CS9

Reviewing

Stage Status

CS5

Reporting

Highlights

CS6

ExaminingProject Issues

CS4

Capturing

Project Issues

CS3

Directing aProject

DP

Managing

StageBoundaries

SB

ManagingProductDelivery

MP

Project EndNotification

Work Package

Checkpoint ReportQuality Log

CompletedWork Package

Exception ReportIssue Log

Highlight

Report

Stage Plan

Risk Log

Business Case

New ProjectIssues

Authorisation toproceedStage/ExceptionPlan

Copy of Exception Report



♦ watching for Changes to the approved plan; managing any changes raised formallyagainst the project (Project Issues) and making decisions on the introduction of

beneficial changes provided these do not result in the Stage Plans exceeding theTolerance;

♦ reviewing situations for Stage and Project Impact;

♦ reporting to the Project Board and to other members of the Project Management Team;

♦ approving and initiating any Corrective Action.

It may be expected that for much of the time events during a Management Stage willfollow a regular and predictable pattern. However, personal qualities and projectmanagement abilities need to combine to address situations which are not going accordingto plan and it is then that the Project Manager must use knowledge, political and peopleskills to bring things back on course.



CS1 – Authorising A Work Package

Work is released to Team Managers or directly to staff working on the project via the

issue of authorised Work Packages. The format for these might be a formal contract,where the Products are being produced by a Supplier external to the host organisation, or much less formal (for example by internal memorandum or discussion) where the provider

is employed within the host organisation.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Plan Adjustments [C] Assessing Progress(CS2)

CS1 –AuthorisingWorkPackage

Stage or ExceptionPlan (DP3)

Authorisation ToProceed (DP3)

Proposed Work Package (CS5)

Work Trigger (CS7

Product Descriptions (PL2)

Work Package [C] Accepting A WorkPackage (MP1)

Figure 87: CS1 Plus Inputs and Outputs

The Project Manager is responsible for the preparation, release and agreement of Work Packages; authority for this responsibility stems from the Project Board’s approval of the

relevant Management Stage Plan and for this reason Management Stage Plans (produced

in the “Managing Stage Boundaries (SB)” Process) must be sufficiently detailed for theProject Board to understand to what they are committing.

Changes necessary as the Management Stage progresses must be reflected in the work being carried out on the relevant Work Packages – this demands a close association between the Project Manager and the Team Manager(s) responsible for producing the

Product(s). Where a formal contract is in existence, care must be taken not to upset thecontract arrangements by demands for trivial changes.

This Process provides the Project Manager with the main vehicle for release of work andis a major control on a day to day basis.



CS2 – Assessing Progress

The Project Manager must keep track on how well the Management Stage, and the

Project, is performing against the plan approved by the Project Board at the last End StageAssessment. This Process provides the mechanics for capturing “Actuals” and passingthe information forward to “ Reviewing Stage Status (CS5)” where the Project Manager can

take stock of progress so far.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

CS2 –AssessingProgress

Checkpoint Reports(MP2)

Quality Log (MP2)

Plan Adjustments(CS1)

Stage Plan (CS5)

Work Package

Status (CS9)

Up-dated Stage Plan [U] Examining Project Issues (CS4)

Reviewing Stage Status(CS5)


The information needed to update the approved Management Stage Plan comes from three

major sources:

♦ Checkpoint Reports (created within the “Managing Product Delivery (MP2)”

Process);

♦ Timesheets (where these are in use within the host organisation – otherwise anassessment by the Project Manager of effort expended and financial liability incurred);

♦ Project Issues – especially where errors or departures from the agreed requirement have been identified.

This Process is best carried out by Project Support, where appointed, with a presentation

of the plans, updated to show “actuals”, to the Project Manager for overall assessment onat least a weekly basis.

Use of a suitable software planning tool (such as MS Project, Project Manager Workbench, Primavera etc) will simplify this Process especially if standard “actuals”



reporting forms generated within the package are fully utilised.

The output from CS2 goes towards the Project Manager’s review of how well the

Management Stage is progressing when measured against the Management Stage planapproved by the Project Board at the previous End Stage Assessment.



CS3 - Capturing Project Issues

As the project progresses there will be a need to capture and decide upon changes that

occur. All changes within a PRINCE 2 project are treated as types of Project Issue. Theseinclude errors found in signed-off Products, departures from the agreed Specification,ideas and suggestions people have for improving the project’s outputs, resource changesthat need to be reflected in the project and stage plans.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

CS3 –CapturingProjectIssues

Issue Log (Quality File)

New Project Issues(Any Project Source)

Up-dated Issue Log [U] Examining Project Issues (CS4))


A Project issue can be raised by anyone associated with the project. Typicallyorganisations will have their own existing change control arrangements and these should

be adopted where they are performing satisfactorily.

The first job on receipt of a Project Issue is to record it on the Issue Log - this willnormally be a function of Project Support or the Configuration Librarian where appointed.The Issue can then be passed to “CS4 - Examining Project Issues”.

The types of Project Issue are:

♦ Request For Change - causing a change to the Customer’s Specification or AcceptanceCriteria; usually paid for by the Customer.

♦ Off-Specification causing errors or omissions in work already completed or planned;usually paid for by the Supplier.

♦ Other Changes such as modification to the Project Management Team.

More information can be found in the Chapter on Understanding The Change ControlComponent and Technique.



CS4 - Examining Project Issues

This Process enables each Project Issue to be examined and its impact assessed; this

should be carried out as soon as possible after receipt and logging of the Project Issue.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Issue Log [U] Reviewing Stage Status

(CS5)

Risk Log [U] Reviewing Stage Status(CS5)

CS4 –

EvaluatingProjectIssues

Business Case

(SB3)

Stage Plan (CS2)

Issue Log (CS3)

Risk Log (SB4)

Project Plan (SB2)

Issue Log [U] Reporting Highlights(CS6)


The examination and evaluation of Project Issues may take place via a regular meeting or by circulation of the Issue and comments to those involved. Whatever route is chosen, progress needs to be recorded in the Issues Log.

Project Issues should always be examined from a Customer, Supplier and Business perspective; any action needed which would take the Management Stage over the agreed

Tolerance must be referred to the Project Board in the form of an Exception Report (see“Escalating Project Issues (CS8))”.

Responsibility for examining Project Issues rests with the Project Manager who will usethe support services of Team Managers in helping arrive at an appropriate decision. TheSenior User member of the Project Board will prioritise and if necessary canvas theProject Board for any additional resources needed to clear outstanding Project Issues.

Prioritisation of outstanding Project issues is usually done by referring to the Issues Log at

each End Stage Assessment.



CS5 - Reviewing Stage Status

This Process provides for a regular check of how the Management Stage is performing

against its approved plan. The intention is to allow the Project Manager to stand back from the day to day problem solving activities and take stock, prior to reporting thesituation to the Project Board.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Notification of Project End [C] De-Commissioning A

Project (CP1)

Work Trigger(s) [C] Authorising Work Package (CS1)

Stage Status Information [C] Reporting Highlights(CS6)

Plan Deviation [C] Taking Corrective Action(CS7)

Stage Plan [U] Escalating Project Issues (CS8)


Project Issue [R] Escalating Project issues (CS8)

CS5 –

ReviewingStageStatus

Stage Plan (CS2)

Issue Log (CS4)

Risk Log (CS4)

Tolerances (DP3)

Business Case(DP3)

Project Plan (DP3)

Stage End Notification [C] Planning A Stage (SB1)


The key driver for assessing Management Stage status is the “Assessing Progress (CS2)”Process which captures information from Checkpoint Reports and Timesheets and updatesthe approved plans with “actuals”. Inputs will also be needed from the Issues Log wheremodifications to the Management Stage plans may be brewing following the discovery of errors and omissions or ideas for improvement., and the Risk Log which will enable theProject Manager to review emerging risks identified at the outset of the ManagementStage.

The overall outcome of the Process is to ensure on a regular basis (recommended weeklyat the minimum) that the Management Stage remains within Tolerance and that nothing

untoward is likely to occur without warning.

Information and knowledge gleaned from this Process will feed the creation of the

Highlight Report for the Project Board.



CS6 - Reporting Highlights

Having approved a Management Stage Plan, the Project Board will need to be kept

informed of the progress being made towards the successful conclusion of the stage.Reporting Highlights to the Project Board will be a regular, time-related activity, typicallyevery month but specifically at the frequency required by the Project Board.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Highlight Reports [C] Giving Ad-Hoc Direction(DP4)

CS6 –ReportingHighlights

CommunicationPlan (Project File/PID)

Stage Plan (CS5)

Checkpoint Reports(CS5)

Issue Log (CS5)

Risk Log (CS5)

Tolerances (CS5)

Plan Revisions(CS5)

Communications To InterestedParties [C]



The objective of the Highlight Report is to provide summary information to the Project

Board - one sheet of paper (or its equivalent) is all that is needed. The steps taken in performing this Process are:

Assemble information from Checkpoint Reports and Project Issues received during the previous period since the last Highlight Report

♦ Identify any new or potential problem arising from “Reviewing Stage Status (CS5)”

♦ Identify any significant revisions to the approved plan from “Taking Corrective Action(CS7)”

♦ Create the Highlight Report (Project Support might well produce the first draft)



♦ Distribute the Highlight Report to Project Board members and any other agreed

recipients.

The Highlight Report does not normally require a meeting of the Project Board althoughthis is an option for high-profile, high-risk projects where the Project Board are

particularly sensitive about the progress that is being made.



CS7 - Taking Corrective Action

In even the best managed projects, departures from the planned course of action will occur

and remedial action must be taken to bring the work back into line. This Process enablesthe Project Manager to make small adjustments, within the agreed Tolerance, to the work being carried out.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Work Trigger [C] Authorising Work Package (CS1)

Up-dated Stage Plan [U] Reporting Highlights(CS6)

CS7 –TakingCorrectiveAction

Stage Plan (CS5)

Issue Log (CS5)

Plan Deviation(CS5)

Risk Log (CS5) Request For Advice [C] Giving Ad-Hoc Direction

(DP4)


The main driver for the Process comes from “CS5 - Reviewing Stage Status” wheredeviations from the required and planned outcome will start to become apparent. Projects

seldom change course dramatically but rather significant slippage is prompted by manysmaller incidents and this Process aims to treat each incident as it occurs. Additional Work Packages may be identified in this Process.

Advice and guidance may well need to be sought from Project Board members and thiswill usually be informal. The results of this Process will need to be considered for

reporting to the Project Board by inclusion on the next Highlight Report but this should bethe exception rather than the rule.

The Project Manager is responsible for the operation of this Process helped by the ProjectManagement Team. Project Managers should always be aware of the build-up of

apparently minor problems being symptomatic of bigger trouble with the project.



CS8 - Escalating Project Issues

As soon as it is forecast that a Management Stage (or the Project) is likely to go outside

the Tolerance the Project Manager must notify the Project Board by raising an ExceptionReport.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Exception Report [C] (+ Responseback from Project Board)

Giving Ad-Hoc Direction(DP4)

Producing An ExceptionPlan (SB6)

Project Board Response [R] Producing An ExceptionPlan (SB6)

CS8 –EscalatingProjectIssues

Business Case(CS5)

Issue Log (CS5)

Project Plan (CS5)

Stage Plan (CS5)

Risk Log (CS5)


Stage Plan [R] Producing An ExceptionPlan (SB6)


Although many things may contribute to or trigger this Process the most common situation

is where a Project Issue has been raised to record an error or deficiency with one or moreProducts. The steps to be taken in this Process are:

♦ Identify the problem and carry out an Impact Analysis

♦ Identify and Evaluate options for recovery

♦ Select a recommended direction

♦ Document the problem, reasons, impact, options and recommendations in an Exception Report for the Project Board

♦ Await the Project Board’s response

The expected outcome will be a request to produce an Exception Plan which will replace

the plan that has gone into exception. The Project Board’s views and advice shouldalways be sought before producing an Exception Plan and the effect on the overall Project

Plan (including the Business Case and Risks) must always be evaluated.



CS9 - Receiving A Completed Work Package

This Process records the successful completion of a Work Package (or Product) anddelivery of it back into the host organisation. It is closely associated with “Authorising A

Work Package (CS1)” discussed earlier.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

CS9 –ReceivingCompletedWorkPackage

Approved Work Package (MP3) Work Package Status [C] Assessing Progress(CS2)


The arrangements for delivering the Completed Work Package will have been agreed

when the Work Package was accepted by the Supplier, Team Manager or personresponsible for its production in the Process “ Accepting A Work Package (MP1)”.

Completed Work Packages or Products delivered into the host organisation will all have been Quality Reviewed (in Process “Executing A Work Package (MP2)”) in accordance

with the requirements agreed when the Work Package was accepted.

The results of the Process are used to assess the progress made by recording the task as

complete and updating the Management Stage and project records accordingly.



Summary of the Controlling A Stage Process

C ontrolling A Stage (CS) is the main project management driver for a PRINCE 2

controlled project. The Process is owned by the Project Manager and is where most of the“day-to-day” project management activities are carried out.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Plan Adjustments [C] Assessing Progress(CS2)

CS1 –AuthorisingWorkPackage

Stage or ExceptionPlan (DP3)

Authorisation ToProceed (DP3)

Proposed Work Package (CS5)

Work Trigger (CS7

Product Descriptions (PL2)

Work Package [C] Accepting A WorkPackage (MP1)

CS2 –AssessingProgress

Checkpoint Reports(MP2)

Quality Log (MP2)

Plan Adjustments(CS1)

Stage Plan (CS5)

Work PackageStatus (CS9)

Up-dated Stage Plan [U] Examining Project Issues (CS4)

Reviewing Stage Status(CS5)

CS3 –CapturingProjectIssues

Issue Log (Quality File)

New Project Issues(Any Project Source)

Up-dated Issue Log [U] Examining Project Issues (CS4))



Issue Log [U] Reviewing Stage Status

(CS5)

Risk Log [U] Reviewing Stage Status(CS5)

CS4 –

EvaluatingProjectIssues

Business Case

(SB3)

Stage Plan (CS2)

Issue Log (CS3)

Risk Log (SB4)

Project Plan (SB2)

Issue Log [U] Reporting Highlights(CS6)

Notification of Project End [C] De-Commissioning AProject (CP1)

Work Trigger(s) [C] Authorising Work Package (CS1)

Stage Status Information [C] Reporting Highlights(CS6)

Plan Deviation [C] Taking Corrective Action(CS7)

Stage Plan [U] Escalating Project Issues (CS8)


Project Issue [R] Escalating Project issues (CS8)

CS5 –ReviewingStageStatus

Stage Plan (CS2)

Issue Log (CS4)

Risk Log (CS4)

Tolerances (DP3)

Business Case(DP3)

Project Plan (DP3)

Stage End Notification [C] Planning A Stage (SB1)

Highlight Reports [C] Giving Ad-Hoc Direction(DP4)

CS6 –ReportingHighlights

CommunicationPlan (Project File/PID)

Stage Plan (CS5)

Checkpoint Reports(CS5)

Issue Log (CS5)

Risk Log (CS5)

Tolerances (CS5)

Plan Revisions(CS5)

Communications To InterestedParties [C]

Corporate or Programme

Management



Work Trigger [C] Authorising Work

Package (CS1)

Up-dated Stage Plan [U] Reporting Highlights(CS6)

CS7 –

TakingCorrectiveAction

Stage Plan (CS5)

Issue Log (CS5)

Plan Deviation(CS5)

Risk Log (CS5) Request For Advice [C] Giving Ad-Hoc Direction

(DP4)

Exception Report [C] (+ Responseback from Project Board)

Giving Ad-Hoc Direction(DP4)

Producing An ExceptionPlan (SB6)

Project Board Response [R] Producing An ExceptionPlan (SB6)

CS8 –EscalatingProjectIssues

Business Case(CS5)

Issue Log (CS5)

Project Plan (CS5)

Stage Plan (CS5)

Risk Log (CS5)


Stage Plan [R] Producing An ExceptionPlan (SB6)

CS9 –ReceivingCompletedWorkPackage

Approved Work Package (MP3)

Work Package Status [C] Assessing Progress(CS2)

Figure 96: Summary of the Controlling A Stage (CS) Process



MANAGING PRODUCT DELIVERY



Managing Product Delivery (MP) - Introduction

This major Process is aimed primarily at managing the interface between the Customer

Project Manager and the Supplier Project Manager ensuring that work is actually progressing in accordance with the customer’s expectations and that all the plannedProducts are created and delivered within the agreed time-scales and contract price or

internally approved budget, and meet their approved Quality Criteria. The Process is alsoused for managing the delivery of Products where an external Supplier is not involved in

the project and where all resources managed by the project are internal; it is alsoappropriate where there is a mixture of both.

Figure 97: Managing Product Delivery (MP) Process

The Process comprises:

♦ making certain that work on Products allocated to each external Team or Team Member resource is properly Authorised;

♦ ensuring that Packages of Work are identified, discussed, agreed, authorised and

accepted by those responsible for the creation of Products;

♦ checking that all Interfaces between the Customer and Supplier organisations are

identified, recorded, observed and handled in an appropriate way;

Assessing

Progress

CS2

Checkpoint Report

Quality LogStage Plan

Work Package

ClosureProduct Sign-off

Accepting a

Work Package

MP1

Executing a

Work Package

MP2

Delivering a

Work Package

MP3

Receiving

Completed

Work

PackageCS9

Authorising

Work Package

CS1

Work Package

Stage Plan



♦ ensuring that all the Work is actually Carried Out, as agreed;

♦ ensuring that the Progress of Work and Forecasts of the time and effort to completion

are regularly assessed;

♦ checking that all finished Products conform to their agreed Quality Criteria;

♦ obtaining Approval for completed Products. This will usually be at three levels – Producer and Reviewer level, Project Manager level, and ultimately endorsement bythe Project Board at the end of each Project Stage. These levels of approval will be

reflected in both the Customer and Specialist Supplier organisations, although it is not necessary that either will be working within a PRINCE environment; it is essential,

however, that all involved are working within a suitably controlled project management environment.

This Process will operate continuously throughout each Stage; it provides a healthy

separation between the Customer Project Manager and the Supplier Project Manager andrequires the interface between the Supplier(s) (be they internal or external) and theCustomer to be identified, defined and operated. Care must be taken to ensure that theinterfaces are neither missed nor lost, and that bureaucracy is kept to the absoluteminimum consistent with effective control.

Where a Project Manager allocates work directly to individuals responsible for carryingout the work package, this Process will be informal but will always exist.



MP1 - Accepting A Work Package

The Process provides for the establishment of agreement between the Project Manager

and the Team Manager, Team or individual who will be responsible for creating anddelivering the completed Work package (or Product) for the host organisation.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Risk Log [U] Up-Dating The Risk Log (SB4)

Work Package (Authorised) [C] Executing A Work Package (MP2)

MP1 –Accepting AWorkPackage

Work Package(CS1)

Team Plan [C] Executing A Work Package (MP2)

Figure 98: MP1 Plus Inputs and Outputs

The interface between the Project Manager and those responsible for creating the Productsof the project needs to be properly managed. This Process enables the agreement to beestablished before any work is commenced. The agreement/interface manifests itself inthe form of a Work Package authorisation of which the key elements are:

♦ Agreement of the Objectives for the Work Package

♦ Tolerances for the Work Package

♦ The Reporting Arrangements - Timing and Content

♦ A Plan for the Work Package

♦ A Product Description specifying the Product’ s content, its Quality Criteria and the Method of measuring if the Product conforms to its stated Quality Criteria.

The Project Manager is responsible for delivering the Products to the Project Board as partof the Management Stage objectives; responsibility for agreement of the Work Package

resides with the Project Manager and the Team Manager, where appointed (and the Project

Manager where no Team Manager exists).



MP2 - Executing A Work Package

This Process addresses the creation of the Products of the project. It may be that thecreators of the Products are not using PRINCE or any other formal project management

method and where this is the case agreement of the Work Package in MP1 is even moresignificant.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Quality Log [U] Assessing Progress(CS2)

Checkpoint Reports [C] Assessing Progress(CS2)

Completed Work Package [C] Delivering A Work Package (MP3)

MP2 –Executing AWorkPackage

Work Package(Authorised) (MP1)

Team Plan (MP1)

Team Plan [U] Stage File


It is within this Process that “actuals” are captured, at source, to enable the effort and costs

in the Management Stage Plan and the Project Plan to be updated within the “Controlling A Stage - Assessing Progress (CS2)” Process.

The quality checking arrangements agreed within MP1 will be performed during thisProcess; the objective is to ensure that quality is integral to the Product(s) being built so

that Products delivered back into the host organisation are complete and ready to be placed

into the Configuration Management System as finalised Products. Indeed it might well bethat the Configuration Librarian may be the first recipient of completed Work Packages or Products to log and file them before reporting the situation to the Project Manager.

Checkpoint Reports are generated within MP2 at the frequency and in the format agreed inthe Work Package. Checkpoint Reports are used within CS2 to update the Management

Stage and Project Plans.

Responsibility for all activities within this Process is vested in the Team Manager whereappointed, or the Project manager where no such appointment has been made.



MP3 - Delivering A Work Package

Formalising the return of a completed Work Package is the focus for this Process.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

MP3 –Delivering A

WorkPackage

Completed Work Package (MP2)

Approved Work Package [C] Receiving Completed Work Package (CS9)


A simple but significant Process, MP3 provides for final sign-off of the Product(s),dispatch and hand-over of the Product(s) and formal notification to the Project manager of

the completion of work by the Team Manager or person responsible.

The arrangements for hand-over and notification should have been established in MP1 and

will often be embodied into a formal contract document.

Responsibility lies with the Team Manager where appointed.



Summary of the Managing Product Delivery Process

Managing Product Delivery is the “engine room” for the PRINCE 2 project, creating the

Products required for Management Stage; it is where the bulk of the project’s time, effortand financial resources will be spent. The Process will always be present in some formalthough it will be less formal where no outside Supplier or sub-contractor is being used.

External suppliers may not be using the PRINCE 2 Method for their project managementstandard and this Process may not, therefore be physically implemented or understood

where this is the case.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Risk Log [U] Up-Dating The Risk Log (SB4)

Work Package (Authorised) [C] Executing A Work Package (MP2)

MP1 –Accepting AWorkPackage

Work Package(CS1)

Team Plan [C] Executing A Work Package (MP2)

Quality Log [U] Assessing Progress(CS2)

Checkpoint Reports [C] Assessing Progress(CS2)

Completed Work Package [C] Delivering A Work Package (MP3)

MP2 –Executing AWorkPackage

Work Package(Authorised) (MP1)

Team Plan (MP1)

Team Plan [U] Stage File

MP3 –Delivering A

WorkPackage

Completed Work Package (MP2)

Approved Work Package [C] Receiving Completed Work Package (CS9)

Figure 101: Summary of the “Managing Product Delivery (MP)” Process



MANAGING STAGE BOUNDARIES



Managing Stage Boundaries (SB) - Introduction

To achieve a successful outcome to the project, it is necessary to break it into smaller,

discrete packages to enable the Project Team to focus on specific Products or Deliverables;this approach provides the concept of Project Stages. By controlling the start and finish of each stage, specific attention can be given to whether the Stage Products/Deliverables

have all been completed in accordance with their Quality Criteria, whether the remaining project Products/Deliverables are still required, and whether the Business Case for the

project remains viable.

Figure 102: Managing Stage Boundaries (SB) Process

The aims of the Process are:

♦ to assure the Project Board that all the Products/Deliverables planned for the current stage have been completed and meet their Quality Criteria;

♦ to provide the information on time-scale, technical achievement, and the budget needed to enable the Project Board to assess whether the overall project Business Case is still

viable, and whether the Benefits can be achieved within an acceptable level of risk;

ReportingStage End

SB5

Updating aProject Plan

SB2SB1

Updating aProjectBusinessCase SB3

Updating theRisk Log

Producing An

ExceptionPlan

SB4

Authorising a

Stage or ExceptionPlan

DP3Project Plan, Business Case,Project Brief

Issue Log

Risk Log

Business Case

Request for Authorisation to proceed

Next Stage Plan

End Stage ReportLessons Learned Report

Risk, Issue andQuality Logs

Current Stage Plan

Current PM Team

Risk & Issue Log

Project Plan

Updated PM team

Request For Exception Plan

+ Exception Report

Agreed Tolerance

CurrentStagePlan

Issueand RiskLog

Project Approach

ProjectQualityPlan

PlansIssueand RiskLogs

Plans Plans

Closing aProject

CP

Project Brief

Planning AStage

SB6



♦ to provide decision-support information on the status of the current stage and the

overall project, which will enable the Project Board to reach a decision on final completion of the current stage, authorise the start of the next stage, and to endorse the

overall project.

♦ to provide a vehicle for stating the Tolerance which may be allowed for the next Stage.Tolerance is a control providing cost and time “trigger-figures” beyond which the

Project Manager may not progress without the approval of the Project Board.

♦ to record any information or Lessons Learned which might impact on later stages of the project, or on the organisation as a whole.

The Process is an iterative one as the project proceeds from one stage to the next.

Controlling the start and end of stages is a key control process for the Project Board and

incorporates all the key aspects of directing a project.

Exception Plans

The steps of this Process may also be used when creating an Exception Plan, where asignificant departure from the approved plan has occurred and Tolerance is forecast to beexceeded. In order to reach a decision on the future of the project, the Project Board willneed to consider an impact analysis, options appraisal, and a recommendation for action

prepared by the Project Manager; these will all need to be supported by an up-datedBusiness Case confirming the benefits and re-appraisal of the risks.



SB1 - Planning A Stage

As the project progresses the Project Board will limit their commitment and risk exposure

by releasing the commitment of effort and funding via End Stage Assessments at thecompletion of each Management Stage. A key input to these major Project Board controlsis the plan for the next Management Stage put together in SB1.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Next Stage Plan [C]

Up-Dating A Project

Plan (SB2)

Project Plan [R] Up-Dating A Project Plan (SB2)

Project Management TeamChanges [U]

Reporting Stage End (SB5)

SB1 –

Planning AStage

Current Stage Plan

(CS5) (Stage File)

Stage End Notification (CS5)

Project Plan (IP2)(Project File)

Trigger For Next Stage Plan (IP2)

PID (IP6) (Project File)

Current Project Management Team(IP6) (Project File &Stage File)

Product Checklist [U] Reporting Stage End (SB5)

Figure 103: SB1 Plus Inputs and Outputs

The aim of the Process is to identify all the Products (Specialist, Management and Quality)

that will need to be produced during the next Management Stage and estimate the effortand cost to its completion. A number of inputs will be necessary to achieve this end

(including the agreed Project Plan) to accurately position the Management Stage, and theyare summarised in the above diagram.

The Organisation Structure for the Project Management Team will also be reviewedduring this Process, to ensure that the most appropriate resources and management teamare available for the work to be undertaken.

Much of the work involved in creating the Next Stage Plan will be carried out by membersof the Project Management Team under the supervision of the Project Manager, who has

prime responsibility for the timely production of the plan.

Any individuals having responsibility for Project Assurance will need to be consulted

during this Process especially in respect of the proposed management controls and qualitycontrol structure.



SB2 - Updating A Project Plan

Information needed for decision support at the end of each Management Stage obviouslyincludes an updated view of the Project Plan to identify what impact work so far on the

project has impacted on the final delivery date and cost.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Up-Dated Project Plan [U] Up-Dating A Project Business Case (SB3)


Up-Dating The Risk Log (SB4)

SB2 – Up-Dating AProject Plan

Current & Next Stage Plans (SB1)

Exception Plan(SB6)

Project Approach(IP6) (Project File)

Project Quality Plan(IP6) (Project File)

Next Stage Plan [R]

or

Exception Plan [R]



The three key inputs to this Process are:

♦ the Management Stage which has just been completed (the Current Stage Plan)

♦ the Next Management Stage Plan created in SB1

♦ the approved Project Plan

Actual schedule, effort and cost information is extracted from the Current Stage Plan and

any changes proposed in the Next Stage Plan are used to present an up-to-date view of thelikely final out-turn for the project.

Other inputs are also available to this Process from a number of sources; the mainobjective is to present a comprehensive view of what the Project Board is being asked tocommit to, long term, at the approaching End Stage Assessment.

Any significant changes in the Project Plan brought about by this Process should beincluded in the End Stage Report produced by the Project Manager for the Project Board.



SB3 - Updating A Project Business Case

The Business Case is the main driving force behind any PRINCE 2 controlled and this

must be kept up to date and reviewed at the completion of each Management Stage as aminimum requirement.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Business Case [U] Reporting Stage End (SB5)

SB3 – Up-Dating AProjectBusinessCase

Up-Dated Project Plan (SB2)

Exception Plan or Next Stage Plan(SB2)

Risk Log (SB4)

Issue Log (SB4)

Risk Log [R] Reporting Stage End SB5)


Many events would have occurred during the previous Management Stage which willimpact the Business Benefits which were used to justify the project initially and at the lastformal Project Board Review. For example, if the overall project plan has been extendedor its predicted out-turn cost increased then there will be a detrimental effect on theBusiness Benefits; the reverse is also true!

On the positive side, it can be expected that the risks faced by the project will be reducedas progress is made. This aspect is treated in SB4 - “Updating The Risk Log” but needs to

be considered here as the two topics are very closely related.

Changes requested (and made) during the Management Stage will also impact on theBusiness Benefits, especially where required changes for improved functionality haveincurred additional effort and costs.



SB4 -Updating The Risk Log

As the project proceeds towards its planned conclusion, the risks faced for delivering ontime, within budget and to the required specification should reduce. This must be recorded

and presented to the Project Board when they are being asked to approve the nextManagement Stage Plan.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Risk Log [U] Up-Dating A Project Business Case (SB3)

Accepting A Work Package (MP1)

SB4 – Up-Dating TheRisk Log

Project Plan (SB2)


Exception Plan(SB2)

Issue Log CS4(Quality File)

Issue Log [U] Up-Dating A Project Business Case (SB3)


Essentially the Risk Management Component comes back into play and the project risk re-assessed. Although PRINCE 2 does not include any requirement to use any specific risk

management tool the Risk Analysis Checklist described in Chapter 6 can be used to updatethe risks. Whatever approach is used, the results must be logged and presented to the

Project Board at the End Stage Assessment. The Risk Log should indicate a downwardtrend if the project is to proceed without any changes. Significant increases in the risk

measurement must always be brought to the attention of the Project Board andrecommendations made.

Ownership of each identified risk should always be considered - the most appropriatemember of the Project Management Team being best placed to keep a watchful eye onmovements against the baseline.

Changes in approach, planning and resource usage will always have a potential impact onthe risks facing the project and so changes to the Project Plan or Next Stage Plan shouldalways be reviewed for their impact within this Process.



SB5 - Reporting Stage End

The results of a Management Stage needs to be reported back to those who have provided

the resources which have contributed to its completion

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

End Stage Report [C] Authorising A Stage or

Exception Plan (DP3)

Request for Authorisation ToProceed [C]

Authorising A Stage or Exception Plan (DP3)

Next Stage Plan [R] Authorising A Stage or Exception Plan (DP3)

Exception Plan [R] Authorising A Stage or Exception Plan (DP3)

Risk Log [R] Authorising A Stage or Exception Plan (DP3)

Product Status Account [C] De-Commissioning AProject (CP1)

SB5 –

ReportingStage End

Project Plan (SB2)

Current Stage Plan(SB2)

Next Stage Plan or Exception Plan(SB2)

Business Case(SB3)

Issue & Risk Logs(SB3)

Quality Log (CS5)(Quality File)

CommunicationPlan (IP4) (Project File)

Communications to interestedparties [C]



This Process is activated as near as possible to the end of the Current Management Stage.

The results of the Process are presented as an End Stage Report which summarises theresult of the Management Stage; the report provides the following information to the

Project Board:

♦ Planned vs out-turn costs

♦ Planned vs out-turn effort



♦ Planned vs out-turn milestone dates

♦ Products delivered (and confirmation they meet the stated Quality Criteria

The End Stage Report acts as the vehicle for presentation of the Stage results and the NextStage Plan to the Project Board.

Responsibility for creation of the report rests with the Project Manager, with help andsupport from the Project Management Team as appropriate. It will be provided up to aweek in advance of the End Stage Assessment to allow Project Board members to consider its content; arrangements for handling Management Stage endings to allow for this arediscussed in the Chapter on Understanding The Stages Component .



SB6 - Producing An Exception Plan

As soon as it is forecast that a Management Stage is likely to deviate beyond the

Tolerance set by the Project Board at the previous End Stage Assessment, it is deemed to be in Exception and an Exception Report must be prepared for the Project Board. Thelikelihood is that the Project Board will require an Exception Plan to be prepared and this

Process is where such a plan is created.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

SB6 –ProducingAnExceptionPlan


Stage Plan (CS8)

Exception PlanRequest (DP4)

Exception Plan [C] Up-Dating A Project Plan (SB2)



Standard Tolerance is measured in Time (Schedule) and Cost. For each ManagementStage Tolerance is recommended by the Project Manager, based on the latest assessmentof risk and the nature of the work, and confirmed by the Project Board at the End StageAssessment. There is a separate component within PRINCE 2 for Tolerance described in

the Controls Component. Additional Tolerances might be usefully considered – theseinclude Scope, Quality and Risks.

The Exception report, raised by the Project Manager as soon as it is forecast that Tolerance

will be exceeded, describes the nature of the exception, its impact on the ManagementStage and Project, the options open to recover the situation, and the recommendation bythe Project Manager. The Exception Report is considered in “Giving Ad-Hoc Direction

(DP4)” by the Project Board members (although no specific meeting or control for thisconsideration is identified by PRINCE).

The Project Board will normally require an Exception Plan to be created to replace theapproved plan which has been departed from; they might, of course decide to prematurelyterminate the project or to just live with the departure but this could not be described asrealistic management.

This Process creates the Exception Plan which will be approved by the Project Board in

“Authorising A Stage or Exception Plan (DP3)” Process at a specially convened MidStage Assessment.



Summary of the Managing Stage Boundaries Process

The “Managing Stage Boundaries Process (SB)” Process will always be present in a

PRINCE 2 controlled project (since every PRINCE project will have a minimum of twoManagement Stages, and therefore at least one SB Process).

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Next Stage Plan [C]

Up-Dating A Project Plan (SB2)

Project Plan [R] Up-Dating A Project Plan (SB2)

Project Management TeamChanges [U]


SB1 –Planning AStage

Current Stage Plan(CS5) (Stage File)

Stage End Notification (CS5)

Project Plan (IP2)(Project File)

Trigger For Next Stage Plan (IP2)


Current Project Management Team(IP6) (Project File &Stage File)

Product Checklist [U] Reporting Stage End (SB5)

Up-Dated Project Plan [U] Up-Dating A Project Business Case (SB3)


Up-Dating The Risk Log (SB4)

SB2 – Up-Dating AProject Plan

Current & Next Stage Plans (SB1)

Exception Plan(SB6)

Project Approach(IP6) (Project File)

Project Quality Plan(IP6) (Project File)

Next Stage Plan [R]

or

Exception Plan [R]




Business Case [U] Reporting Stage End (SB5)

SB3 – Up-Dating AProject

BusinessCase

Up-Dated Project Plan (SB2)

Exception Plan or Next Stage Plan(SB2)

Risk Log (SB4)

Issue Log (SB4)

Risk Log [R] Reporting Stage End SB5)

Risk Log [U] Up-Dating A Project Business Case (SB3)

Accepting A Work Package (MP1)

SB4 – Up-Dating TheRisk Log

Project Plan (SB2)


Exception Plan(SB2)

Issue Log CS4(Quality File)

Issue Log [U] Up-Dating A Project Business Case (SB3)

End Stage Report [C] Authorising A Stage or Exception Plan (DP3)

Request for Authorisation ToProceed [C]


Next Stage Plan [R] Authorising A Stage or Exception Plan (DP3)

Exception Plan [R] Authorising A Stage or Exception Plan (DP3)

Risk Log [R] Authorising A Stage or Exception Plan (DP3)

Communications to interestedparties [C]

Corporate or Programme

Management

SB5 –ReportingStage End

Project Plan (SB2)

Current Stage Plan(SB2)

Next Stage Plan or Exception Plan(SB2)

Business Case(SB3)

Issue & Risk Logs(SB3)

Quality Log (CS5)(Quality File)

CommunicationPlan (IP4) (Project

File)

Product Status Account [C] De-Commissioning AProject (CP1)

SB6 –ProducingAnExceptionPlan


Stage Plan (CS8)

Exception PlanRequest (DP4)

Exception Plan [C] Up-Dating A Project Plan (SB2)


Figure 109: Summary of the “Managing Stage Boundaries (SB)” Process



CLOSING A PROJECT



Closing A Project (CP) - Introduction

At its conclusion, the project must be closed down in an orderly and firm manner. The

end of a project may arise when all the planned work has been completed and theProducts/Deliverables finished and signed off as meeting their stated Quality Criteria.Alternatively a project might be brought to a premature conclusion because of changes to

requirement, removal of resources or unacceptable slippage of time, effort or costs.

Figure 110: Closing A Project (CP) Process

Most of the work involved in this major Process is concerned with preparation of information for the Project Board in order for it to make the decision to close the project,

or not. Rather like Project Initiation and Stage Initiation, this Process provides a decision-support structure; it aims to:

♦ ensure that the Objectives for the project have been met;

♦ confirm that the Customer is Satisfied with the outcome;

ProjectEvaluation

Review

CP3

Confirming

Project

Closure

DP5

De-

commissioning

a Project

CP1

Identifying

Follow-on

Actions

CP2

Reviewing

Stage Status

CS5

Reporting

Stage EndSB5

Giving ad hoc

Direction

DP4

Follow-on Action

Recommendations

Post-Project

Review Plan

Issue, Risk and

Quality Logs

Lessons Learned

Report

Project Files

Notification of

approaching

Project End

Premature

Close

Product Status

Account

PID

Project Closure Notification

Operational and

Maintenance

Acceptance

Customer Acceptance

Lessons Learned

Report

End Project Report



♦ obtain Formal Acceptance of the project Products/Deliverables;

♦ confirm that all Products/Deliverables have been handed over to the Customer, and

that these have been accepted;

♦ ensure that where Ongoing Support, enhancement and maintenance is appropriate (and required), suitable provision has been made;

♦ identify any recommendations for Follow-on Actions and document;

♦ Capture “Lessons Learned” and publish these in a suitable report for the Project Board;

♦ Prepare an “End Project Report” for sign-off by the Project Board;

♦ Notify the Customer/Sponsor/Host Organisation, as appropriate, of the Intention toClose the project, disband the project organisation and release the resources.

Obviously, it will be difficult to close down a project in an orderly manner if the

expectations and criteria for completion and close-down have not been agreed at the outsetand this will normally have been done and the final Acceptance Criteria included withinthe Project Initiation Document. Project staff and managers should be provided with asmuch notice as possible in order for them to plan their return to normal operations.Thanks to those who have contributed to the project are also in order!



CP1 - Decommissioning A Project

The main aim of this Process is to bring the project to an orderly close, ensuring that the

Customer is happy with the outcome and demonstrates this by providing a Customer Acceptance sign-off. Assurance that the outcome can be supported and that a proper audittrail exists for the project documentation, should it be needed in the future, must also be

forthcoming.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Closure Notification [C] Confirming Project Closure (DP5)

Operational & Maintenance Acceptance [C]

Confirming Project Closure (DP5)

Customer Acceptance [C] Confirming Project Closure (DP5)

Draft communication to interestedparties [C] Confirming Project

Closure (DP5)

CP1 – De-Commissioning AProject

Premature Close(DP4)

Notification of Project End (CS5)

Product Status Account (CS5)

Issue Log (SB5)


Communication Plan (IP6) (Project File)

Project Files [R] Archives

Figure 111: CP1 Plus Inputs and Outputs

Key features of CP1 are:

♦ Checking that all Project issues have been dealt with;

♦ Checking that all Products have been completed, documented and handed over;

♦ Confirmation that the Customer’ s Specification has been addressed;

♦ Confirmation that the outcome can be supported, operationally;

♦ Archive of all project documentation (mainly for audit purposes);



♦ Notify all concerned that the project is coming to a conclusion and resources will be

returned.

This Process is primarily the responsibility of the Project Manager in that it marks theconclusion of the work performed over what will often be a considerable period of time.There will be a need for close contact between the Project Manager and Project Board

members to ensure there are “no surprises” at the final meeting to close the projectformally.



CP2 - Identifying Follow-on Actions

Essentially picking up any loose ends that remain at the conclusion of the project. In

particular any outstanding changes in requirements, raised as Project Issues, which werenot actioned for fear of prejudicing a contractual situation or because time and budget didnot allow the changes to be introduced. There might also have been some general

technical improvements that would benefit the project’s outcome that the Supplier wishesto bring to the Customer’s attention.

PROCESS

INPUT & SOURCE


OUTPUT TO

Post-Project Review Plan [C] Confirming Project Closure (DP5)

CP2 -IdentifyingFollow-OnActions

Business Case(SB5)

Risk Log (SB5)

Issue Log (SB5) Follow-On ActionRecommendations [C]


Figure112: CP2 Plus Inputs and Outputs

A major output from this Process is the Post-Project Review Plan which will be used to setup a future project to review whether the Business Benefits identified at the outset (andreviewed and updated at each formal review) of the project, have been achieved. This will

usually take place between 6-12 months after the project has been formally closed.

The follow-on Actions Recommendations will provide the basis for Project Mandates for

any future projects which may arise from the recommendations made.



CP3 – Project Evaluation Review

The lessons learned during the project must be captured as it progresses and disseminated

to those in the host organisation that would benefit from it at the conclusion of the project.There is also a need to compare what was intended to be achieved by the project againstwhat was actually achieved. This review addresses the project and its outcome rather than

the outcome itself (which will the subject of a Post-Project Review (see CP2).

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Lessons learned Report [U] Confirming Project Closure (DP5)

CP3 -ProjectEvaluationReview

Lessons Learned Report (SB5)

Risk Log (SB5)

Quality Log (SB5)

Issue Log (SB5)


End-Project Report [C] Confirming Project Closure (DP5)

Figure 113: CP3 Plus Inputs and Outputs

The Lessons Learned Report (Log) is a prime input to this Process, along with the variousLogs needed to provide a comprehensive view of the performance of the project.

The outputs are:

♦ An assessment of the project against its targets;

♦ An examination of the records to establish how well the Project Management and

Quality Management Standards performed and to what extent they supported the project;

♦ Identify any lessons learned and to recommend changes to the existing standards.

The Project Manager has responsibility to produce these analyses and present them to theProject Board



Summary of the Closing A Project Process

Closing A Project provides the “housework” tasks for properly shutting down a project.

Authority for closure can only be given by the Project Board. The Process is essential for an orderly and effective shut-down of the project.

PROCESS

INPUT & SOURCE


USED

OUTPUT TO

Project Closure Notification [C] Confirming Project Closure (DP5)

Operational & Maintenance Acceptance [C]


Customer Acceptance [C] Confirming Project Closure (DP5)

Draft communication to interestedparties [C]


CP1 – De-Commissioning AProject

Premature Close(DP4)

Notification of Project End (CS5)

Product Status Account (CS5)

Issue Log (SB5)


Communication Plan (IP6) (Project File)

Project Files [R] Archives

Post-Project Review Plan [C] Confirming Project Closure (DP5)

CP2 -IdentifyingFollow-OnActions

Business Case(SB5)

Risk Log (SB5)

Iss e Log (SB5) Follow-On Action Confirming Project