Project Menagement

Office of the
Government Chief Information Officer
PRACTITIONER GUIDE
ON
PROJECT MANAGEMENT
[G38]
Version : 3.4
Jun 2005
The Government of the Hong Kong Special Administrative Region
The contents of this document remain the property of and may not be reproduced in whole or in
part without the express permission of the Government of the HKSAR
PRACTITIONER GUIDE
ON PROJECT MANAGEMENT
CONTENTS
TABLE OF CONTENTS
1.
PURPOSE.............................................................................................................................................................1-1
2.
SCOPE ..................................................................................................................................................................2-1
3.
REFERENCES.....................................................................................................................................................3-1
3.1
3.2
4.
DEFINITIONS AND CONVENTIONS.............................................................................................................4-1

4.1
4.2
5.
STANDARDS ..................................................................................................................................................3-1
OTHER REFERENCES......................................................................................................................................3-1
DEFINITIONS .............................................................................................................................................4-1
CONVENTIONS..........................................................................................................................................4-1
INTRODUCTION................................................................................................................................................5-1
5.1
CHARACTERISTICS OF A PROJECT ..................................................................................................................5-1
5.2
OBJECTIVE OF PROJECT MANAGEMENT.........................................................................................................5-1
5.3
WHAT IS PRINCE? .......................................................................................................................................5-2
5.3.1
Scope........................................................................................................................................................5-2
5.3.2
The Method ..............................................................................................................................................5-2
6.
PRINCE COMPONENTS...................................................................................................................................6-1
6.1
6.1.1
6.1.2
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.3
6.3.1
6.4
6.4.1
6.4.2
6.4.3
6.4.4
6.5
6.5.1
6.5.2
6.5.3
6.6
6.7
6.8
6.8.1
6.8.2
6.8.3
7.
BUSINESS CASE .............................................................................................................................................6-1

What is a Business Case? ........................................................................................................................6-1
Developing a Business Case....................................................................................................................6-1
ORGANIZATION........................................................................................................................................6-3
Project Steering Committee (PSC) ..........................................................................................................6-3
Project Manager (PM) and Team Manager (TM)...................................................................................6-5
Project Assurance....................................................................................................................................6-5
The Benefits .............................................................................................................................................6-6
PLANNING .....................................................................................................................................................6-8
Levels of Plan ..........................................................................................................................................6-8
CONTROLS ...................................................................................................................................................6-12
Project Steering Committee Controls ....................................................................................................6-13
Project Manager Controls.....................................................................................................................6-16
Team Manager Controls........................................................................................................................6-18
Stages.....................................................................................................................................................6-18
MANAGEMENT OF RISK ...............................................................................................................................6-21
Project Risk............................................................................................................................................6-21
Risk Analysis..........................................................................................................................................6-23
Risk Management ..................................................................................................................................6-24
QUALITY IN A PROJECT ENVIRONMENT ........................................................................................................6-26
CONFIGURATION MANAGEMENT ..................................................................................................................6-27
CHANGE CONTROL ......................................................................................................................................6-28
Issue Log................................................................................................................................................6-28
Impact Analysis......................................................................................................................................6-29
Follow-up on Project Issues ..................................................................................................................6-29
PRINCE PROCESSES ........................................................................................................................................7-1

7.1
PRINCE PROCESS MODEL ......................................................................................................................7-1
7.2
DIRECTING A PROJECT (DP) ..........................................................................................................................7-2
7.2.1
Authorising Initiation (DP1)....................................................................................................................7-3
7.2.2
Authorising a Project (DP2)....................................................................................................................7-3
7.2.3
Authorising a Stage or Exception Plan (DP3).........................................................................................7-4
7.2.4
Giving ad hoc Direction (DP4) ...............................................................................................................7-4
PRACTITIONER GUIDE
7.2.5
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
7.3.6
7.4
7.4.1
7.4.2
7.4.3
7.4.4
7.4.5
7.4.6
7.5
7.5.1
7.5.2
7.5.3
7.5.4
7.5.5
7.5.6
7.5.7
7.5.8
7.5.9
7.6
7.6.1
7.6.2
7.6.3
7.7
7.7.1
7.7.2
7.7.3
7.7.4
7.7.5
7.7.6
7.8
7.8.1
7.8.2
7.8.3
7.9
7.9.1
7.9.2
7.9.3
7.9.4
7.9.5
7.9.6
7.9.7
8.
CONTENTS
Confirming Project Closure (DP5)..........................................................................................................7-5

STARTING UP A PROJECT (SU).......................................................................................................................7-6
Appointing a PSC Executive and a PM (SU1).........................................................................................7-6
Designing a Project Management Team (SU2).......................................................................................7-7
Appointing a Project Management Team (SU3)......................................................................................7-8
Preparing a Project Brief (SU4)..............................................................................................................7-8
Defining Project Approach (SU5) ...........................................................................................................7-9
Planning an Initiation Stage (SU6) .........................................................................................................7-9
INITIATING A PROJECT (IP)..........................................................................................................................7-11
Planning Quality (IP1) ..........................................................................................................................7-11
Planning a Project (IP2) .......................................................................................................................7-12
Refining the Business Case and Risks (IP3) ..........................................................................................7-12
Setting up Project Controls (IP4) ..........................................................................................................7-13
Setting up Project Files (IP5) ................................................................................................................7-13
Assembling a Project Initiation Document (IP6)...................................................................................7-14
CONTROLLING A STAGE (CS) ......................................................................................................................7-15
Authorising Work Package (CS1)..........................................................................................................7-16
Assessing Progress (CS2) ......................................................................................................................7-17
Capturing Project Issues (CS3) .............................................................................................................7-17
Examining Project Issues (CS4) ............................................................................................................7-17
Reviewing Stage Status (CS5)................................................................................................................7-18
Reporting Highlights (CS6) ...................................................................................................................7-19
Taking Corrective Action (CS7) ............................................................................................................7-19
Escalating Project Issues (CS8) ............................................................................................................7-19
Receiving Completed Work Package (CS9)...........................................................................................7-20
MANAGING PRODUCT DELIVERY (MP) .......................................................................................................7-21
Accepting Work Package (MP1)............................................................................................................7-21
Executing Work Package (MP2)............................................................................................................7-22
Delivering a Work Package (MP3) .......................................................................................................7-22
MANAGING STAGE BOUNDARIES (SB) ........................................................................................................7-23
Planning a Stage (SB1)..........................................................................................................................7-23
Updating a Project Plan (SB2)..............................................................................................................7-24
Updating a Project Business Case (SB3) ..............................................................................................7-24
Updating the Risk Log (SB4) .................................................................................................................7-25
Reporting Stage End (SB5)....................................................................................................................7-25
Producing an Exception Plan (SB6)......................................................................................................7-26
CLOSING THE PROJECT (CP)........................................................................................................................7-27
Decommissioning a Project (CP1) ........................................................................................................7-27
Identifying Follow-On Actions (CP2)....................................................................................................7-28
Evaluating a Project (CP3) ...................................................................................................................7-28
PLANNING (PL) ...........................................................................................................................................7-29
Designing a Plan (PL1) .........................................................................................................................7-30
Defining and Analysing Products (PL2)................................................................................................7-31
Identifying Activities and Dependencies (PL3)......................................................................................7-32
Estimating (PL4)....................................................................................................................................7-32
Scheduling (PL5) ...................................................................................................................................7-32
Analysing Risks (PL6)............................................................................................................................7-33
Completing a Plan (PL7).......................................................................................................................7-33
PROJECT MANAGEMENT TECHNIQUES ..................................................................................................8-1

8.1
PRODUCT-BASED PLANNING................................................................................................................8-1
8.1.1
Product Breakdown Structure (PBS).......................................................................................................8-1
8.1.2
Product Flow Diagram (PFD) ................................................................................................................8-4
8.1.3
Product Description (PD)........................................................................................................................8-6
8.1.4
Product Transformation ..........................................................................................................................8-8
8.1.5
The Benefits ...........................................................................................................................................8-10
8.2
RESOURCE ESTIMATION......................................................................................................................8-13
PRACTITIONER GUIDE
8.2.1
8.2.2
8.2.3
8.3
8.3.1
8.3.2
8.3.3
8.4
8.4.1
8.4.2
8.4.3
8.5
8.6
8.6.1
8.6.2
8.7
8.7.1
8.7.2
9.
CONTENTS
Objective ................................................................................................................................................8-13
Top Down Method .................................................................................................................................8-13
Bottom Up Method.................................................................................................................................8-13
ACTIVITY NETWORK ANALYSIS .......................................................................................................8-14
Activity Networking ...............................................................................................................................8-14
Construction ..........................................................................................................................................8-14
Network Analysis ...................................................................................................................................8-20
BAR CHARTING ......................................................................................................................................8-21
Bar Charting in general.........................................................................................................................8-21
Gantt Chart............................................................................................................................................8-21
Milestone and Float...............................................................................................................................8-22
RESOURCE LEVELLING ........................................................................................................................8-23
QUALITY CONTROL ..............................................................................................................................8-25
Quality Review.......................................................................................................................................8-25
Informal Review.....................................................................................................................................8-27
QUALITY ASSURANCE..........................................................................................................................8-27
Quality Assurance Review Process........................................................................................................8-27
Participants in QA Review.....................................................................................................................8-27
APPLICATION OF PRINCE IN OGCIO.........................................................................................................9-1

9.1
9.2
9.3
9.4
9.5
9.5.1
9.5.2
9.5.3
9.5.4
9.5.5
9.6
AREA OF APPLICATION ...........................................................................................................................9-1

CUSTOMIZATION .....................................................................................................................................9-1
SMALL PROJECTS ....................................................................................................................................9-1
SDLC PROJECTS........................................................................................................................................9-2
CONTRACTING-OUT PROJECTS ...............................................................................................................9-3
Introduction .............................................................................................................................................9-3
Organisation............................................................................................................................................9-3
Planning...................................................................................................................................................9-3
Control.....................................................................................................................................................9-4
Quality .....................................................................................................................................................9-4
OUTSOURCING PROJECTS INCLUDING INFORMATION TECHNOLOGY PROFESSIONAL SERVICES
ARRANGEMENT (ITPSA) ...............................................................................................................................................9-5
9.6.1
Introduction .............................................................................................................................................9-5
9.6.2
Organisation............................................................................................................................................9-5
9.6.3
Planning...................................................................................................................................................9-5
9.6.4
Control.....................................................................................................................................................9-6
9.6.5
Quality .....................................................................................................................................................9-6
10.
APPENDIX A - ROLES OF MEMBERS IN PROJECT ORGANISATION..........................................10-1
11.
APPENDIX B - TERMS OF REFERENCE OF PROJECT STEERING COMMITTEE.....................11-1
12.
APPENDIX C - SAMPLE PROJECT ASSURANCE ROLES SET-UP..................................................12-1
13.
APPENDIX D - PRINCE PRODUCT DESCRIPTION ............................................................................13-1
14.
APPENDIX E - USING THE RISK ANALYSIS CHECKLIST...............................................................14-1
15.
APPENDIX F - RISK ANALYSIS CHECKLIST......................................................................................15-1
16.
APPENDIX G - HINTS ON PREPARATION OF A PROJECT INITIATION DOCUMENT ............16-1
17.
APPENDIX H - GLOSSARY.......................................................................................................................17-1
PRACTITIONER GUIDE
1.
PURPOSE
PURPOSE
The purpose of this document is to provide guidelines on the project management method
adopted in OGCIO. The method adopted is a customised version of PRINCE (Projects in
Controlled Environments).
PRINCE is a structured set of procedures originally designed specially for managing
projects in IS/IT environments. PRINCE is developed in 1986 by the Central Computer and
Telecommunications Agency (CCTA) which is part of HM Treasury and the centre of
information systems policy in the British government. The Agency was later renamed as
Office of Government Commerce (OGC).
PRINCE has adopted an open strategy within which the methodology is publicly
available. A customised version of PRINCE was introduced into OGCIO (the then ITSD) in
1992 and in 1994, it became the OGCIO (the then ITSD) standard of project management
methodology. The methodology was further upgraded to PRINCE2 in 1998 following its
launch in 1996 in the U.K. Revisions were made by OGC in April 2002 and this manual
has also been revised accordingly.
1-1
PRACTITIONER GUIDE
2.
SCOPE
SCOPE
This Guide composes of five sections:
i.
Introduction;
ii.
PRINCE Components;
iii. PRINCE Processes;
iv. PRINCE Techniques; and
v
Application of PRINCE in OGCIO.
This Introduction section outlines the basic principles of project management and how
PRINCE addresses them; it also shows how PRINCE fits with related aspects such as quality
management and the management of risk.
The PRINCE Components section explains and describes the major elements of project
management, such as organization and control, and how PRINCE incorporates them. These
components represent the 'raw materials' of good project management including quality
management and the management of risk.
The PRINCE Processes section describes the PRINCE process model which explains what
have to be done to manage a project successfully.
The Project Management Techniques section explains the various techniques of project
management in PRINCE.
The Application of PRINCE in OGCIO section documents the customisation of PRINCE for
our department.
This Guide is targeted for practitioners of the PRINCE methodology. It is designed to serve as
a major reference for practitioners in their day-to-day project management work. The PRINCE
Processes section provides a quick reference of the necessary steps and activities required in
managing a project. Other sections provide information about the underlying principles and the
associated techniques required in following the project management procedures.
2-1
PRACTITIONER GUIDE
3.
REFERENCES
3.1
STANDARDS
REFERENCES
None.
3.2
OTHER REFERENCES
PRINCE 2 Manual, CCTA 1996.

Resources Estimation Guide [G19], OGCIO.
Software Configuration Management Process Guide for Application Software [G46],
OGCIO.
Managing Successful Projects with PRINCE2 OGC 2002.
3-1
PRACTITIONER GUIDE
4.
DEFINITIONS AND CONVENTIONS
4.1
DEFINITIONS
DEFINITIONS AND CONVENTIONS
None.
4.2
CONVENTIONS
The following acronyms are used in the text of this Guide:
ACPC
IRS
PM
PRINCE
PSC
QA
QM
TM
Administrative Computer Projects Committee

Initial Request Statement
Project Manager
Projects in Controlled Environments
Project Steering Committee
Quality Assurance
Quality Management
Team Manager
Where appropriate, guidelines specific to small projects are indicated in italics and
those specific to OGCIO environment are indicated in underline.
4-1
PRACTITIONER GUIDE
5.
INTRODUCTION
5.1
CHARACTERISTICS OF A PROJECT
INTRODUCTION
In general, a project is considered to be one having the following characteristics:
it is to produce a set of products to meet the business needs;

there is a corresponding set of activities to construct the required products;
it needs certain amount of resources to carry out the activities;
it has a finite life-span;
it runs under an organisational structure with defined responsibilities; and
it is a temporary structure, created to achieve a specified business benefit or
objective. When the work is completed, the project is closed.
Items to be managed in a project generally include function, time, resources, quality and
risk. These items are usually mutually affecting each other. They have to be suitably
balanced and optimised under a properly managed project management environment.
Within any project there are various groups of people with an interest in the project and its
outcome, including:
Customers who have commissioned the work and will be benefiting from the end
results. (i.e. the user departments in the Government environment)
Users who will use or operate the final product; the Customer and User may be the
same group of people in some situations
Suppliers who are providing specialist resources and/or skills to the project, or are
providing goods and services. (i.e. OGCIO in the Government environment)
Sub-contractors, who provide products or services to the Supplier.
The Customer / Supplier environment assumes that there will be a Customer who will
specify the desired outcome, make use of the final products and (in most cases) pay for the
project, and a (prime) Supplier who will provide resources and skills to create that
outcome.
5.2
OBJECTIVE OF PROJECT MANAGEMENT

The general objective of project management is to create a management environment for
the effective delivery of business products according to the needs of a specific business
case.
5-1
PRACTITIONER GUIDE
5.3
INTRODUCTION
WHAT IS PRINCE?
5.3.1 Scope
PRINCE contains a complete set of concepts and project management processes that are
the minimum requirements for a properly run and managed project. However, the way
PRINCE is applied to each project will vary considerably, and tailoring the method to suit
the circumstances of a particular project is critical to its successful use.
PRINCE projects always focus on delivering specified products to meet a specified
Business Case. There will be many issues surrounding the project. These will need to be
dealt with by other methods and approaches, such as risk management and quality
management. PRINCE covers the project life cycle plus some pre-project preparation.
There are also certain aspects of project management that are well covered by existing and
proven methods and are therefore excluded from PRINCE. An example is the people
management technique. PRINCE also does not cover the specialist techniques involved in
the creation of the products. This is the job of other methods, e.g. RAD, SSADM.
5.3.2 The Method

PRINCE is a process-based approach to project management. The processes define the
activities to be carried out during the project. In addition, PRINCE describes a number of
components that are applied within the appropriate activities. Each component is described
in further detail, in the Components section of this Guide, showing how the particular
subject affects project management and providing guidance on when and how to address
the issues.
Change
Control
Business
Case
Configuration
Management
Organization
Quality in a project
environment
Plans
Management
of Risk
Controls
The PRINCE process model consists of eight distinctive management processes, covering
the activities from setting the project off on the right track, through controlling and
managing the project's progress, to the completion of the project. The common Planning
process is used by many of the other processes.
5-2
PRACTITIONER GUIDE
INTRODUCTION
Throughout the process model there are various project management products that are the
inputs and outputs of each process. Planning in PRINCE is product-based. Each product is
identified, defined and its delivery is controlled. The responsibilities for the various
activities, decision-making and support requirements are fully defined within the
Processes section of this Guide.
The product-based planning technique also enables the project to state the standard of
quality to which each product must conform. In addition, quality testing mechanisms are
specified in order to prove that the products are meeting their required quality standard.
PRINCE describes a specific technique, Quality Review, which is particularly suitable for
the quality testing of document-based products. There is a wide range of additional testing
techniques that might be appropriate for the project. The Project Quality Plan must state
what these are, when and how they will be applied and by whom. The project, by its
nature, is set up to deal with change, and the future is always less predictable than with
routine work. In addition, projects can be large and complex, dealing with novel or unusual
factors. Risk is therefore a major factor to consider during project management and
PRINCE incorporates the management of risk into its processes.
Directing a Project (DP)
Controlling a
Stage (CS)
Starting up a
Project (SU)
Managing
Stage
Boundary
(SB)
Initiating a
Project (IP)
Closing a
Project
(CP)
Managing
Product
Delivery
(MP)
Planning (PL)
The process model provides the flexibility to establish a number of Stages, each forming a
distinct unit for management purposes. Each Stage has a defined set of products or
outcomes, activities, a finite life-span, resources and an organisation structure. The
completion of each Stage is determined by the satisfactory completion of the agreed
products. Stage boundaries need to be appropriate to the particular project and may be
chosen according to one or more of the following:
5-3
PRACTITIONER GUIDE
INTRODUCTION
the sequence of delivery of the products;

the grouping of products into self-consistent sets; and
the natural decision points for feedback and review.
Whatever the nature or size of the project, PRINCE defines an Initiation Stage that covers
the planning and definition of the project. The Initiation Stage enables a management
review before making any commitment to later Stage(s) and their associated resources and
costs.
In some situations, a study might be required to investigate the situation and determine
options for the way ahead. Using PRINCE, the optimum approach would be to handle the
study as a separate and distinct project, and then operate a second project to implement the
results of the study.
Throughout a PRINCE project, the Business Case is reviewed and progress is measured
against the defined benefits. During any project there are often opportunities to discover
new benefits that may enhance the project's outcome or indeed impact on another project.
However, any deviations from the original Business Case must be controlled by the PSC.
During the project, the specification of products will inevitably need to be changed. These
changes need to be controlled as they could adversely affect the project's chance of success.
Controlling changes is linked to version control, a topic that is covered within PRINCE
under Configuration Management. Configuration Management is an essential part of
project control as it focuses on controlling the products being delivered, knowing where
they are at any point in time, what their status is, who is working on them, and which is the
latest version.
5-4
PRACTITIONER GUIDE
6.
PRINCE COMPONENTS
PRINCE COMPONENTS
PRINCE has the following components that are used by the processes :
6.1
Business Case
Organisation
Plans
Controls
Management of Risk
Quality in a project environment
Configuration Management
Change Control
BUSINESS CASE
PRINCE's key philosophy is that its Business Case must drive the project. If a satisfactory
Business Case does not exist, a project should not be started. If a Business Case is valid at
the start of a project, but this justification disappears once the project is under way, the
project should be stopped. The focus of the Business Case should be on the totality of the
business change, not just one element of it.
In PRINCE, the Business Case is developed at the beginning of the project and maintained
throughout the life of the project, being reviewed by the PSC at each key decision point,
such as end stage assessments.
6.1.1 What is a Business Case?

The Business Case is a description of the reasons for the project and the justification for
undertaking the project, based on the estimated costs of the project, the risks and the
expected business benefits and savings.
The Business Case covers the entire scope of change to the business that is affected by the
project. Thus, it is the most important set of information. It drives the decision-making
processes and is used continually to align the project's progress to the business objectives
that are defined within the Business Case.
For details on what a Business Case should contain, please refer to M110 in Appendix D PRINCE Product Description.
6.1.2 Developing a Business Case

The Executive is the "owner" of the project's Business Case. It is the Executive's
responsibility to ensure the project's objectives, costs, benefits, etc. are correctly aligned
with the business strategy.
6-1
PRACTITIONER GUIDE
PRINCE COMPONENTS
The Executive may delegate the development of the Business Case to the project Manager.
However, the data upon which the case will be developed will be largely provided by the
business and responsibility for an accurate and effective Business Case remains with the
Executive. Formal approval of the Business Case is required from the Executive to ensure
there is senior management commitment to the project. The approval is part of the formal
review done at the end of project initiation.
During each stage of the project, the Business Case is reviewed to confirm that the project
remains on track and to check that the Business Case remains valid within the business
context. The Business Case requires formal change control and configuration management
to ensure any changes to the project's environment are accurately reflected and approved
before revising the Business Case. The Business Case remains a "live" document during
the project and all decisions regarding project progress are made using the Business Case
as the "driver".
At project closure, the Business Case is used to confirm that the project has delivered the
required products and that the benefits expected can be realized in an appropriate
timeframe by the business. The Business Case provides the basis for the Post-Project
Review Plan, to ensure that the later assessment of whether the outcome was successful or
not is firmly linked to the Business Case.
6-2
PRACTITIONER GUIDE
6.2
PRINCE COMPONENTS
ORGANIZATION
A proper Project Organisation is essential for the effective management of a project.
The Project Organisation suggested by PRINCE is as follows :Project Steering Committee (PSC)
Executive
Senior
User
Project
Assurance
Senior
Technical
Project
Manager (PM)
Team Manager
(TM)
The various set-ups within the Project Organisation have their respective roles. In brief,
the Project Steering Committee (PSC) is for overall project management and major
decision making. The Project Manager (PM) is for day-to-day management. The Team
Managers (TMs) are for production of end-products. Project Assurance ensures the
integrity of the project in terms of the interests of the Customer, User and Supplier areas. 1
According to the requirements of each project, a role can be shared by more than one
person, or two or more roles can be combined. The PRINCE project organisation can be
used for projects of all sizes without building up a large management team.
Functions of the respective set-ups are described in the following sub-sections. Roles of
members in the respective set-ups are detailed in Appendix A - Roles of Members in
Project Organisation.
6.2.1 Project Steering Committee (PSC)

PSC is an organisation set-up required for the overall direction and management of a
project. PSC is the owner of the project. It has the full authorities for the project as well as
1
Optionally, project support roles may be provided to support the project variously (by some administrative or
technical roles).
6-3
PRACTITIONER GUIDE
PRINCE COMPONENTS
the associated responsibilities and accountability. Generic terms of reference of a PSC are
given in Appendix B - Terms of Reference of Project Steering Committee.
A PSC comprises representatives from the customer, user and supplier areas, namely:Executive:
The chairperson, representing the interest of the customer, and

providing overall guidance and assessment throughout the project
life.
The Executive has to ensure that the project is value for money by
regularly monitoring the Business Case of the project and balancing
the demands of customer, user and supplier.
Senior User:
Representing the users of the system (product).

The Senior User is accountable for ensuring that the products meets
user needs and falls within the constraints of the Business Case. He
is also responsible for committing user resources and monitoring
products against user requirement.
Senior Technical: Representing developer(s) or procurers, the resources which deliver

the technical products of the project.
The Senior Technical is accountable for ensuring that the products
are technically feasible and likely to meet user needs within the
constraints of the Business Case. He is responsible for committing
technical resources.
A major characteristic of the PSC is that it involves quite substantial users' involvement.
Users have to take up two roles (Executive and Senior Users) out of the three in PSC.
They are the mandatory members and have to share the overall responsibilities and
accountability of the project.
With more user involvement in a project, user requirements and project matters would be
better communicated between the users and developers. As a result, user expectation
would be better met. Thus increasing the chance of user acceptance.
The PSC is appointed by senior management. It is responsible for assuring that the
project remains on course to deliver products of the required quality to meet the Business
Case defined in the Project Initiation Document. It approves all major plans and
authorises any exception. The PSC signs off the completion of each stage of project as
well as authorises the start of next stage.
Hints and Tips
The PSC members are always busy. There is a danger of overloading in larger projects
if they do not delegate their assurance responsibilities.
6-4
PRACTITIONER GUIDE
PRINCE COMPONENTS
For small project, roles can be combined but never eliminated.

Combining roles always leads to questions of conflicts of interest. Combining the
Executive and Senior User should be considered carefully. Moreover, it is not
advisable to combine the roles of Senior User and Senior Technical.
All roles can have their own internal discussion to debate and manage internal aspects
of the project without the presence of the other roles.
A large PSC can become unwieldy and inhibit the decision-making process. If there are
too many candidates for a PSC role, they should be encouraged to appoint a
spokesperson to carry out that role, or a committee of that group can be formed with
the chairman being the representative of that role.
6.2.2 Project Manager (PM) and Team Manager (TM)

PSC members are not expected to work full-time on a project. It delegates the day-to-day
management of the project to PM. Hence, the PM is not regarded as the owner of the
project. Instead, PM is the doer whose major task is to manage project, and be responsible
to the owner - the PSC. A person in the PM role is expected to concentrate on the day-today project management matters, with the aim to ensure that the project produces the
required products, to the required standard of quality and within the specified constraints
of time and cost.
The TM is not mandatory. The PM may find that it is beneficial to delegate the authority
and responsibility to the TM (who may possess specialised skills and knowledge) for
planning the creation of some (or all) products and managing the team(s) to produce those
products. The TM agrees with the PM what work is to be done by the team, manages the
teams performance, reports and finally returns the completed products to the PM. For
example, a contractor responsible for producing certain products can be assigned the role
of TM.
Hints and Tips
The PM/TM can be from User Department or OGCIO/contractors. TM may be taken

up by user for user-oriented task like User Acceptance Test or taken up by contractors
on specific task out-sourced like LAN installation. For in-house projects, PM is
usually taken up by OGCIO staff but for Turnkey and Information Technology
Professional Services Arrangement (ITPSA) projects, it is taken up by the contractors;
for details, please refer to section 9.5 on Turnkey Projects and section 9.6 on ITPSA
Projects.
6.2.3 Project Assurance
6-5
PRACTITIONER GUIDE
PRINCE COMPONENTS
It is the PSCs responsibility to monitor all aspects of the projects performance and
products independent of the PM. This is the Project Assurance Function.2
Areas to be assured depends on where the project risks rest, e.g.:
viability of the Business Case

effectiveness and usability of the solution
feasibility of technical solution
compliance to organisational and business strategy
security
Each PSC member is responsible for the areas of assurance that are related to his/her
interest being represented. PSC can delegate the Project Assurance work to others who are
independent of the PM and the rest of the project team, according to the needs and desires
of the PSC. While the PSC has the ultimate responsibility to assure the integrity of the
project, the delegate has no executive authority. Each assurance responsibility may be
shared by more than one individual covering part of or the entire the project. The
delegation shall be planned at Project Initiation Stage to facilitate resources control. The
delegate reports to the PSC member that delegates.
Hints and Tips
In OGCIO, officer(s) from User Departments may take up project assurance regarding
the Users interest while OGCIO officers, e.g. a senior API, may take up project
assurance regarding the project expenditures.
OGCIO project team may suggest an organisational structure on project assurance for
PSC to approve. The common structure consists of three roles: Business Assurance
Coordinator (BAC), User Assurance Coordinator (UAC) and Technical Assurance
Coordinator (TAC). The three roles represent the business, user and technical interests
respectively. A sample of Project Assurance Roles is detailed in Appendix C - Sample
Project Assurance Roles Set-up.
6.2.4 The Benefits

The benefits to be gained from the PRINCE recommended organization are:
Division of Roles and
Responsibilities
In the PRINCE recommended organization, roles and

responsibilities are suitably divided.
Human
resources of a project can be so arranged that the most
appropriate skill and responsibility mix be assigned in
Optionally, project support roles may also be assigned to the project organisation. Project support role covers user
liaison/co-ordination, technical support, standard and methodology support, tool support and project administration.
If assigned, agreement / Consent should be made between the Project Support parties and the Project Manager on
where, when and how the support services will be delivered. Depending on the project situation, project manager
may consider putting the service provision details in PID.
6-6
PRACTITIONER GUIDE
PRINCE COMPONENTS
the right place.

Clear Definition of Roles
and Responsibilities
PRINCE emphases formal assignment of roles to all

participants at the project start. It enables individuals
to have a clear understanding of one's authority,
responsibility and accountability so as to minimise or
avoid conflicts, confusion, duplications and
omissions.
6-7
PRACTITIONER GUIDE
6.3
PRINCE COMPONENTS
PLANNING
A plan is a statement of intent. It is an important component that provides a base for
comparing with the actual out-turn. Control can then be applied based on the discrepancies
found in the comparison.
A plan usually defines:
The steps required in order to achieve a specified target

The sequence of those steps
Any interdependencies between them
How long each step is estimated to take
When the steps take place
Who carries out the steps
Where controls are to be applied
On process of planning in general, Planning (PL) may be referenced (see 7.9).
6.3.1 Levels of Plan

PRINCE offers a flexible hierarchy of plans to match the needs of the PSC, the PM, and
the TMs. Each level of plan has the same format. Only the amount of details differs. There
are two major levels of plan, namely:
Project level, and

Stage level.
There are, in turn, two types of plans, namely:
Technical Plans, and

Resource Plans.
Project Level
Plans at project level provide necessary information for the PSC to oversee the project and
are used by them to progressively monitor the continuous viability of the project. It is
produced during the Initiation Stage as part of the Project Initiation Document based on
which the PSC decides whether to commit to the project. At the end of each stage, the PM
updates the Project Plan with the latest information and the PSC uses this information as
part of its judgment on whether to continue with the project. The Project Plan is the only
mandatory plan in the project.
The Project Plan is a high level plan, showing the time of production of the major products,
the stage divisions and the resources needed. They also identify the major control points
6-8
PRACTITIONER GUIDE
PRINCE COMPONENTS
within the project such as the stage boundaries. At end of each stage, Project Plans should
be updated with actual figures and be assessed by the PSC with respect to the continuous
viability of the business case.
Stage Level
Plan at stage level should detail work to be carried out during that stage by the involved
parties. Stage Plans will identify, for a particular stage, the activities, end-products, the
resource required and the costs. It is produced immediately before a stage and covers that
stage in the detail necessary to give the PM day-to-day control of progress. For small
projects, the PM may decide to combine the Stage and Project Plans.
Technical Plan
Technical Plans (typically in the form of a bar chart) are used to identify the sequence of
events, to define timescales and to assign responsibilities for producing the end-products.
A Project Technical Plan is mandatory for all projects and should identify the major
control points within the project such as the stage boundaries. An example of a project
technical plan is:
ID
1
Name
Stage 0 - Project Initiation
Start Date End Date F M A

2.5.95
29.5.95
Prepare PID
2.5.95
29.5.95
Stage 1 - Stage Name
30.5.95
13.11.95
Activity 1
30.5.95
16.10.95
10
Activity 2
17.10.95
13.11.95
14.11.95
8.1.96
11
12
Activity 3
14.11.95
11.12.95
13
Activity 4
12.12.95
8.1.96
1995
M J J
O N
M A
50%
0%
0%
0%
14
A Stage Technical Plan is prepared for each stage of the project and shows all products and
technical activities within the stage in greater details than the Project Technical Plan. An
example of a stage technical plan is:
6-9
PRACTITIONER GUIDE
ID
1
Name
Stage 0 - Project Initiation
Activity 1
PRINCE COMPONENTS
Start Date
02/05/95
M A
End Date
29/05/95
30/05/95
13/11/95
30/05/95
16/10/95
Activity 1.1
30/05/95
26/06/95
Activity 1.2
27/06/95
24/07/95
Activity 1.3
25/07/95
21/08/95
Activity 1.4
22/08/95
18/09/95
Activity 1.5
19/09/95
16/10/95
17/10/95
13/11/95
14/11/95
08/01/96
9
10
11
Activity 2
1995
J J
S O
0%
0%
0%
0%
0%
0%
14
15
16
17
Resource Plan
Resource Plan is used to identify the type, amount and period of use of the various
resources required during the life of the project. A Project Resource Plan is mandatory for
all projects. Stage Resource Plan is not required if its information has been included in the
Project Resource Plan. Note that only resources regarding the project and of interests to the
PSC should be planned and monitored. Examples of man-effort resources plan and
expenditure resources plan are:
Man Effort
Stage
0 Planned
Actual
OGCI
User
O
(md)
(md)
SM
API
APII
SCO
COI
COII
3.0
5.0
0.0
2.0
2.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1 Planned
Actual
20.0
0.0
110.0
0.0
90.0
0.0
15.0
0.0
30.0
0.0
40.0
0.0
2 Planned
Actual
2.0
0.0
7.0
0.0
2.0
0.0
2.0
0.0
5.0
0.0
0.0
0.0
25.0
0.0
25.0
0%
122.0
0.0
122.0
0%
92.0
0.0
92.0
0%
19.0
0.0
19.0
0%
37.0
0.0
37.0
0%
40.0
0.0
40.0
0%
Project
a. Planned
b. Actual
c. Est. to Complete
d. Variance (b+c-a)/a
6-10
PRACTITIONER GUIDE
PRINCE COMPONENTS
Expenditures
Stage
0 Planned
Actual
Expenditure $000
0
0
1 Planned
Actual
9,200
0
2 Planned
Actual
3,603
0
Project
a. Planned
b. Actual
c. Est. to Complete
d. Variance (b+c-a)/a
12,803
0
12,803
0%
Exception Plan
An Exception Plan is only required if a project stage is forecast to exceed its planned
tolerances. It would normally follow the Project Issue of an exception situation from the
PM to the PSC. An Exception plan covers the time period from the present moment to the
end of the current stage and permits the PM to show the change in work required to meet
the new situation, the costs and the new tolerances set by the PSC.
6-11
PRACTITIONER GUIDE
6.4
PRINCE COMPONENTS
CONTROLS
It cannot be assumed that everything will go according to plan. There is a need to check
progress against plan and be prepared to modify the plan in the light of events.
The PSC has a responsibility to senior management to ensure that money is being well
spent and that the solution produced will meet the stated business need. The PM is
responsible to the PSC for the production of the required products within the agreed time,
budget and quality constraints. TMs are responsible to the PM for the delivery of
authorised Work Packages. The work parties produce the products agreed with the TMs.
PSC
Project
Manager
Team
Manager
Authorise Authorise Ad Hoc

Initiation the Project Direction
All aspects
of a project
(scope,
nature,
Business
Case,
Output,
etc.)
Ad Hoc Mid Stage End Stage Confirm

Direction Assessment Assessment project
Closure
Project
Minutes of Evaluation
ESA
Report
Highlight
Report
Exception Plan
PID
Work
Package
Risk Log
Follow-On
Actions
Recommen
-dations
Stage Plan
Minutes of
Checkpoint
Review
meetings
Work Package
Close
Issue Log
Project
Issue
Report
Product
Checklist
Work
parties
At each management level there are performance expectations of the level below and a
need to be informed if those expectations are not going to be met. There is also a need for
6-12
PRACTITIONER GUIDE
PRINCE COMPONENTS
regular assurance that the expectations will be met. I.e. controls are needed from one level
to the next.
Project control consists of three iterative elements: planning, monitoring and controlling.
The plan plots what should be done, by whom and for how long it will take. Monitoring
checks on what actually happens. Control acts on the monitoring information and decides
if the plan needs to be modified.
A major element of control is reporting, which inputs information to the monitoring
process. The above figure shows the reporting between the management levels.
6.4.1 Project Steering Committee Controls

Business Case
Project should be justified by business case (see appendix D - PRINCE Product
Description) at its initiation, and the business case should be continuously monitored as the
project progresses. The viability of business case should be assessed at the end of each
project stage (End-Stage Assessment). Should the business case be found to have changed
or vanished, the PSC should make the appropriate business decision on whether to proceed,
re-direct or terminate the project. This control mechanism helps prevent continual
investment in unjustified projects.
Starting Up A Project
Senior management controls the inception of a project by the issue of trigger which signify
the start of a project. In OGCIO, it is the Initial Request Statement (IRS) sent from user
department to OGCIO, ACPC Funding Approval or the ITPSA Assignment Brief. PSC
and the PM will then be appointed.
In this project start up stage, the PSC will communicate with the PM the objectives and
direction of the project. This often includes an outline business case, which justifies the
expenditure on the project. With such information, the rest of the project organisation can
be established. This includes the Project Assurance, the TM and the project team members.
All aspects of the project will then be documented in a Project Initiation Document (PID)
by the PM.
Reference may be made to the process Initiating a Project (IP).
The Project Initiation Meeting
At the end of the project initiation stage, the PSC looks at two documents in the Project
Initiation Meeting, the PID and the next stage plan before deciding whether to approve the
next stage.
6-13
PRACTITIONER GUIDE
PRINCE COMPONENTS
The PID contains information of the project definition, the initial project plan, the number
and timing of project stages, the business case and the risk analysis result.
The Next Stage Plan contains the detailed technical plan and resource plan for next stage.
Stage Selection
According to the size and risk of a project, the PSC will decide to break the project down
into a suitable number of stages. This is agreed during the initiation stage. Reasons for the
breakdown of the project into stages are discussed in section 6.4.4. The end of each stage
is a major control point for the PSC and thus the selection of the number of stages and their
timing in the project life cycle is an important control for the PSC.
Tolerance
Tolerances are established to say when alarm bells should ring. They should be established
by senior management for the whole project and apportioned to each stage by the PSC.
Tolerance is the room or spare capacity given to the PM to handle exception without
asking for additional time, budget or direction from the PSC. This reduces the
administrative overheads of the PSC members and the PM. If the tolerance is exceeded or
will be exceeded, the PM should raise a Project Issue (PI) for discussion in a Exception
Assessment meeting.
Tolerances should cover at least time and budget. For example, on a total budget of
HK$100,000 a 5 percent tolerance would mean that the project can proceed within the
range of HK$95,000 to HK$105,000 without alarming the PSC. Other normal tolerance
elements include scope tolerance, quality tolerance, risk tolerance and benefit tolerance.
Hints and Tips
Tolerances are often expressed as a percentage. They may also be expressed in terms
of money or a number of days.
It may not be the same tolerance for time and budget. With zero tolerance on the
budget, the PM should argue for a greater time tolerance, allowing the use of fewer
resources, or cheaper (and probably less skilled) resources.
If no tolerance is given or all the tolerances have been used up, the PM may consider
de-scoping the project but not sacrificing the quality level of products in order to fit
within the tolerances.
End Stage Assessment

Part of the PRINCE philosophy is the concept of 'creeping commitment'. This means that,
as part of its control, the PSC only commits to the next stage of the project. At the end of
that stage, the situation is reviewed and the next stage is authorised only if the PSC is
satisfied with the project progress.
At the end of each stage the PM has to present to the PSC:
6-14
PRACTITIONER GUIDE
PRINCE COMPONENTS
The product checklist, which shows the list of major products completed within the
current stage
The updated technical plan and resources plan (both project level and stage level)
Project viability against the Business Case
The technical plan and resources plan for next stage
A review on the risks of the project
The PSC should execute its control at these checkpoints and decide to stop, continue, ask
for a plan revision or change the scope of the project.
Reference can be made to the process Managing Stage Boundaries (SB) (section 7.7).
Highlight Reports
Between End Stage Assessments, the PM submits Highlight Reports to the PSC to report
progress and problems (including potential problems), and to forecast progress over the
next period. The PSC decides on the frequency, means and contents of these reports at
project initiation.
Reference can be made to the process Controlling a Stage (CS) (section 7.5).
Product Checklist
The Product Checklist is an output from the stage planning process. It lists the major
products of the stage with their expected dates of appearing in draft, quality reviewed and
approved forms. As the stage progresses, the actual dates and names of reviewer(s) are
filled in. PM, or TM if exist, is responsible for updating the checklist when a quality
review is done. By checking the checklist against the issued Work Packages, the PM can
monitor that quality work is being done. The Product Checklist often accompanies the
Highlight Report to give the PSC a summary of the current status of the stage products.
Exception Assessment
These are ad hoc meetings where an Exception Report is presented to the PSC for its
approval. The format of the assessment is very similar to an End Stage Assessment.
Exception Report
If the PM foresees that tolerances are going to be exceeded, an Exception Report must be
given to the PSC. The report mainly composes of a description on the situation and a
revised stage plan (i.e. the Exception Plan) which describes the remaining work of the
stage modified to include the work to react to the exception situation.
6-15
PRACTITIONER GUIDE
PRINCE COMPONENTS
The PSC will usually assume the role of Configuration Board in CM. It will endorse a CM
Plan prepared at the beginning of the project. It can also give disposition on all
recommended Change Requests.
Closing The Project
The PSC can close the project at any time if it decides that the Business Case cannot be
met or the risks are too high. When the project comes to a normal close, the PSC will
check that all expected products have been delivered, that the customer is satisfied, and
that the group to whom the end-product is being handed over is ready and willing to accept
responsibility. Any follow-on actions will be passed to the appropriate group when
considered necessary by the PSC. A post-implementation review may be scheduled to
assess the attainment of the project's planned benefits.
6.4.2 Project Manager Controls

Work Package
PM exercises his control over the delivery of the project products by means of work
packages.
Work is released to a team member or TM in an agreed Work Package. A Work Package
is a set of information or specification relevant to the creation of one or more products. It
contains the Product Description(s), details of any constraints on production such as time
and cost, interfaces, and confirmation of the agreement, between the PM and the person or
TM who is to implement the Work Package, that the work can be done within the
constraints. Since the products may vary in contents and complexity, formality of work
package varies accordingly. For example, when the work is being conducted by a single
team working directly for the PM, the Work Package may be a verbal instruction (but as to
avoid misunderstanding, it would be preferable to lay down the Work Package in writing.)
Work Package is particularly useful when dealing with contractors or sub-contractors.
A Work Package can be as big or as small as the PM wishes, depending on the level of
control to be exercised.
Reference may be made to the processes Controlling a stage (CS) (section 7.5) and
Managing Stage Boundaries (SB) (section 7.7).
Hints and Tips
For small projects, it is sensible to package all the works of a specific contractor or
Team Manager into a single Work Package.
For small projects with all the works interrelated, a single work package may be
issued.
6-16
PRACTITIONER GUIDE
PRINCE COMPONENTS
Checkpoint Review
The PM requires each TM to feed back progress via Checkpoint Reviews, where the
progress of product delivery and resources (i.e. manpower and money) usage will be
reviewed. Based on the progress information, the PM will assess whether the tolerance will
be exceeded and adjust the plan if necessary. The frequency of the review is decided by
the PM, and is usually tied to the need to provide the PSC with Highlight Reports. During
the review, the TM will also discuss with the PM concerns, problems and what is to be
achieved in the next period. User may be invited to the review, if necessary.
The review usually takes the form of a meeting. If considered appropriate (e.g. having
close contact between the TM and the PM, etc.), it may take other forms, e.g. email, letter,
telephone conversation, etc.
Hints and Tips
For small projects, checkpoint meeting may be replaced by review in other forms, e.g.
email, letter, telephone conversation etc.
For project in which the user resources have been included in the project justification,
the resources should also be planned and usage be monitored.
Reference may be made to the process Controlling a Stage (CS) (section 7.5).
Issue Log
The Issue Log is used to record all statement of concerns, change requests and problems
encountered in the project. Each project issue will be analysed on the impact and a solution
will be recommended. Decision will be made on whether to implement the solution. The
PM should regularly monitor and control the progress of those issues throughout the
course of the project.
Handling of project issue is also discussed in Change Control (section 6.8.1). Reference
may be made to the process Controlling a Stage (CS) (section 7.5).
Risk Log
An important element of control is the control of risks to the project. PRINCE requires that
the PM analyses and evaluates risks at least during project initiation and at the end of each
stage. In medium to large projects, the frequency may need to be greater.
The Risk Log not only identifies each risk but also records the current status of each risk
and who is taking care of that risk. By means of the Risk Log, the PM can watch out for
any event that may affect the risks.
6-17
PRACTITIONER GUIDE
PRINCE COMPONENTS
Although the PSC usually assumes the role of Configuration Board in CM, PM may have
been granted by the PSC the authority to handle change requests that can be
accommodated within the tolerance given to PM as stated in the PID.
The configuration status reports give the PM information on the status of products and
changes being handled, particularly those from the current stage. The PM can compare this
with the Stage Plan, and information from the Checkpoint Reviews to ensure that correct
information is being given.
As part of the control, the PM needs to be sure that the various products of the project are
being controlled. The physical configuration audit, usually carried out by the
Configuration Auditor (a senior member of project team as assigned by the PM), ensures
the as-built version of products complies with the product movement log and that the
products contain all of the associated items.
6.4.3 Team Manager Controls

Work Package
Work Packages are agreed between the PM and the TM. (see also section 6.4.2 Project
Manager Controls) The agreement is a two-way control in that the PM can ensure that the
Stage Plan matches the time and effort figures agreed with the TM, and the TM can
negotiate the figures to ensure the achievement of the work is a reasonable expectation.
The TM will then receive Work Package from the PM, which states how the work is to be
quality reviewed and by whom, and also details how the products are to be approved and
returned.
6.4.4 Stages
A project should be divided into stages to facilitate project management and control.
A Stage, in the PRINCE context, is a logical sub-division of a project. The purpose of
having Stages is to enable the management to have checkpoints to assess the project
progress, to ensure the viability of the business case, and to make decision on whether to
proceed, re-direct or terminate the project. It is management stage which concerns
commitment of resources and authority to spend and is independent of technical stage
which groups activities by the set of techniques used or products created.
Reference may be made to the processes Setting up Project Controls (section 7.4.4), and
Managing Stage Boundaries (SB) (section 7.7).
6-18
PRACTITIONER GUIDE
PRINCE COMPONENTS
Benefits of Staging
Major benefits of breaking down a project into stages are summarised below:
It provides senior management the opportunities to assess the project progress by

providing them discrete packages of work for review at the stage boundaries;
It enables and encourages a reappraisal of the business case at each stage boundary;
It enables more realistic estimate to be worked out at the commencement of each

stage. With more realistic estimates, more accurate and realistic monitoring and
control can be exercised.
Consideration in Project Staging

Every project should consist of at least two stages. A small project may need only two
stages; an initiation stage and the remainder of the project is the second stage. The
initiation stage may last only a few days, but is essential to ensure that there is a formal
basis (the endorsed Project Initiation Document) for the project that is understood by all
parties. Most projects need to be broken down into more manageable stages to enable the
correct level of planning and control to be exercised.
Decision on the number of stages in a project should be made with the following
considerations:
A stage boundary should not divide a major end-product;
A stage boundary should best be defined where decisions have to be made about
the ongoing viability of the project, such as the assurance of the delivery and
acceptance of a major end-product;
At critical part of a project where visible tight control is necessary, it should be

sub-divided into a greater number of stages;
If the project nature is familiar and estimate can be accurate, fewer stages may be
acceptable as compared with project having to apply new knowledge without
previous experience;
If there is a major allocation of certain resource type within a potential long stage,
then it may be appropriate to divide it into two stages so that management decision
can be made before resource commitment.
Stages for Management Decision

Stages of a project should be appropriately set. A Stage should not be too short, as that
will lead to too frequent Stage Assessment meetings and will result in ineffective use of
6-19
PRACTITIONER GUIDE
PRINCE COMPONENTS
senior management resources. A Stage should neither be too long, as that will defeat the
purpose of keeping control of the project.
A Stage should best be set at a logical breakpoint of a project at which milestone products
are produced so that the management can base on them to assess the project.
There is no fixed and hard rule for the duration of a stage, as it would depend on the
characteristics of the project and the extent of management control on the project.
However, as a rule of thumb, a stage of a normal project should be around 3 to 6 months.
6-20
PRACTITIONER GUIDE
6.5
PRINCE COMPONENTS
MANAGEMENT OF RISK
6.5.1 Project Risk

There are seven major elements which can affect the overall degree of risk of a project:
Timescale;
Size of project organisation;
Degree of change;
Complexity;
Constraints;
Project environment; and
Contractor (for a Turnkey/ITPSA project).
Each of these is addressed separately in the following paragraphs.

a.
Timescale
The greater the timescale over which a project is scheduled, the greater the risk in
that changes may occur which may adversely affect the project. For example:
the business may change, leading to changes in user requirement;
user department personnel may change with consequent changes to their level
of support and commitment to the project.
Too short a timescale can also affect the project. For example: poor quality control as a result of cutting corners;
overlapping of activities across stage boundaries leading to loss of management
control.
b.
Size of the Project Organisation

The greater the number of people, departments, companies involved in the project,
the greater the risk of a contributor defaulting, and also the greater the risk
involved in co-ordinating all the concerned parties. For example:
lack of top management understanding of, and commitment to, the project,
leading to bad or delayed decisions or provision of inadequate resources;
conflicting departmental interests.
c.
Change
A project to develop a new application system will involve changes to business
practices and procedures. The greater the changes involved, the greater the risk
that the changes may be misunderstood or be resented. The changes may demand
greater (or lesser) skill levels than what the current staff possess, which could lead
to difficulties of implementation.
6-21
PRACTITIONER GUIDE
d.
PRINCE COMPONENTS
Complexity
The greater the degree of complexity involved in a project, the greater the risk of
failure. For example, a project may involve many interfaces between systems or
between many different user departments. A system may be functionally complex
or involve many different/new technologies. In all these cases, the complexity
introduces risk.
e.
Constraints
Constraints always go along with risks. Constraints of a project should therefore
be well identified, recognised and addressed. Examples of constraints are:
organisation policy;
availability of skills and manpower;
performance of existing hardware and software;
deadlines, priorities and budgets;
legislation; and
security requirement.
All the constraints contribute to the risks of the project. Most of these constraints
can be overcome by means of time and money. One of the most likely risks to a
project arise from the costs to overcoming constraints not being recognised or
adequately estimated. Another comes from the imposition of arbitrary and
unrealistic budgets and timescales.
f.
Project Environment
The environment covers factors such as the experience of the project team in
relation to the type of project, existence of proven project management procedures,
use of structured analysis and design methods, reporting and control mechanism of
change, etc. The differences in environment may contribute various risks to a
project.
g.
Contractor
If contractors are involved, there may be risks associating with their capability to
complete the assigned activities.
Reference may be made to the processes Updating the Risk Log (SB4) (section 7.7.4) and
Analysing Risks (PL6) (section 7.9.6).
6-22
PRACTITIONER GUIDE
PRINCE COMPONENTS
6.5.2 Risk Analysis

Risk analysis is essential for effective management of risk. It can be a powerful and
effective way of bringing to the attention of the management:
what the sensitive issues are, and to which they should be paying particular
attention;
what actions they may need to take to increase the chances of success.
It comprises four activities:
risk identification, which determines the potential risks that may be faced by the
project. In OGCIO, this can be done with the help of a Risk Analysis Checklist. A
generic Risk Analysis Checklist is attached for reference in Appendix F. When a PM
uses the checklist, it is important for him to consider laterally about the specific
situations of the project being assessed.
risk evaluation, which determines how important each risk is, based on an assessment
of its likelihood and consequences to the project and business. A risk in a project may
have low probability of occurrence, but if it does occur it will have major impact on the
viability of the project. In other situations, a high probability risk may have little
impact. The probability of a risk occurring and its impact, must be taken together to
identify those which require particular consideration.
response identification, which decides whether the level of each risk is acceptable or
not and, if not, what actions can be taken to make it more acceptable. The actions are
broadly categorized into five types:
prevention, where countermeasures are put in place which either stop the threat or
problem from occurring, or prevent it from having any impact on the project or
business
reduction, where the actions either reduce the likelihood of the risk developing, or
limit the impact on the project to acceptable levels
transference, which is a specialist form of risk reduction where the impact of the
risk is passed to a third party via, for instance, an insurance policy or penalty clause
contingency, where actions are planned and organised to come into force as and
when the risk occurs
acceptance, where the PSC decides to go ahead and accept the possibility that the
risk may occur (believing that either the risk will not occur or the countermeasures
are too expensive).
6-23
PRACTITIONER GUIDE
PRINCE COMPONENTS
selection, which determines which risk action(s) to take. For each possible action, it is
a question of balancing the cost of taking that action against the likelihood and impact
of allowing the risk to occur. There may be several possible risk actions, each with
different effects. The choice may be one of these options or a combination of two or
more. Consideration must then be made taking into account the impact of the risk
occurring and the risk action on:
The Stage and/or Project Plans
The business
The Business Case
Other parts of the project
The results of the risk analysis activities are documented in the Risk Log.
6.5.3 Risk Management

Once the risks have been identified and evaluated, attention needs to focus on managing
them. Risk management consists of the following major activities:
Planning and Resourcing
planning, which, for the countermeasures itemised during the risk selection, consists
of:
identifying the quantity and type of resources required to carry out the actions
developing a detailed plan of action to be included in a Stage Plan
confirming the desirability of carrying out the actions identified during risk
evaluation in the light of any additional information gained
obtaining management approval along with all the other aspects of the plans being
produced
resourcing, which will identify and assign the actual resources to be used to conduct
the work involved in carrying through the actions; These assignments will be shown in
Project and Stage Plans.
Monitoring and Reporting

There must be mechanisms in place for monitoring and reporting on the actions selected to
address risks.
Some of the actions may have only been there to monitor the identified risk for signs of a
change in its status.
monitoring, however, may consist of:
6-24
PRACTITIONER GUIDE
PRINCE COMPONENTS
checking that execution of the planned actions is having the desired effect on the
risks identified
watching out for the early warning signs that a risk is developing
modelling trends, predicting potential risks or opportunities
checking that the overall management of risk is being applied effectively
Risk management is a process which will be conducted continuously throughout the

project as information becomes available, and as circumstances change. However, there is
a need to carry out a major risk analysis at the start of the project and document the result
in the Risk Log and place it in Project Initiation Document (PID). There must also be at
least an assessment of all risks at each end-stage assessment (ESA). At the end of the
project, follow-up actions will need to be considered for any outstanding risk.
Identify the risks
Evaluate the risks
Monitor and
report
Identify suitable
responses to risks
Plan and resource
Select
RISK ANALYSIS
PHASE
RISK MANAGEMENT
PHASE
6-25
PRACTITIONER GUIDE
6.6
PRINCE COMPONENTS
QUALITY IN A PROJECT ENVIRONMENT

Within projects, quality is a question of identifying what it is about the project's products
or services which makes them fit for their purpose of satisfying stated needs.
Quality Management is the process of ensuring that the quality expected by the Customer
is achieved. It encompasses all the project management activities which determine and
implement the Project's Quality Plan. The various elements of an organisation's quality
management are as follows:
Quality System which comprises an organisation structure, procedures and processes

to implement quality management. PRINCE itself will typically form part of a
corporate quality system where it has been adopted as a corporate standard.
Quality Assurance, which sets up the quality system and is the means of assuring that
the quality system operates to achieve an end product which meets quality and
customer requirements. It creates and maintains the quality system, audits and
evaluates it. A quality assurance function should be set up separate from and
independent of the organisation's project and operational activities to monitor the use
of the quality system across all projects within the organization. The quality review
and assurance procedures are briefly described in sections 8.6 and 8.7 of this guide.
For details of the quality system and procedures in OGCIO, please refer to Quality
Manual (S&M Reference [Q1]), Quality Planning Procedures (S&M Reference [Q2])
and Quality Assurance Review Procedures (S&M Reference [Q3]).
Quality Planning which establishes the objectives and requirements for quality and
lays out the activities for the application of the quality system. In the Project Initiation
Document, the quality approach for the whole project is defined in the Project Quality
Plan. It is important that the Customer's quality expectations are understood and
documented prior to project commencement. Each Stage Plan specifies in detail the
required quality activities and resources, with the detailed quality criteria shown in the
Product Descriptions.
Quality Control, which is the means of ensuring that products meet the quality criteria
specified for them. Quality control is about examining products to determine that they
meet requirements. Quality Review is the primary technique in performing project
quality work for PRINCE. It is fully described in the Project Management Techniques
section of the manual.
Hints and Tips
Both the Customer and the Supplier may have quality systems. The project may have to
use one of these systems or an agreed mixture of both.
6-26
PRACTITIONER GUIDE
6.7
PRINCE COMPONENTS
CONFIGURATION MANAGEMENT
Configuration Management (CM) is a discipline that applies technical and administrative
direction and surveillance over the life cycle of an item to:
identify and document the functional and physical characteristics of configuration

items
control changes to configuration items and their related documentation
record and report information need to manage configuration items effectively,
including the status of proposed changes and implementation status of approved
changes
audit configuration items to verify conformance to specifications, drawings, interface
control documents, and other contractual requirement
Software Configuration Management (SCM) is CM applied to software systems. SCM

involves identifying the configuration on the software at given points in time,
systematically controlling changes to the configuration, and maintaining the integrity and
traceability of the configuration throughout the software life cycle.
The projects software assets are important to OGCIO and the user departments and have
to be managed by the SCM, which makes it a mandatory process in OGCIO.
Roles and responsibilities are detailed in OGCIO Software Configuration Management
Process Guide for Application Software (S&M Ref. [G46]). Briefly, there are 5 roles in
SCM: Configuration Board, Configuration Management Officer, Configuration Librarian,
Configuration Auditor and the Impact Analysis Group. The Configuration Management
Officer should be responsible for SCM of a project or system in production. The
Configuration Librarian role may be delegated to someone, who would maintain a SCM
Library and implement the version control processes. The Impact Analysis Group will
conduct impact analysis of Change Requests and recommend implementation option to
Configuration Board, which is the decision-making authority. The Configuration Auditor
will conduct the Physical Configuration Audit at certain checkpoints as pre-defined in the
SCM plan.
If considered necessary, the SCM plan can be extended to include other important nonsoftware items such the PID, the project technical plan, the FS/SA&D report, etc. The
principle of configuration management is the same for both software and non-software
items.
The Configuration Board is usually taken up by the PSC while the PM would assume the
role of Configuration Management Officer. Impact Analysis Group would be carried out
by the PM with the assistance of any project assurance personnel. Configuration Librarian
and Configuration Auditor may be taken up by senior members of the project team as
assigned by the PM.
6-27
PRACTITIONER GUIDE
6.8
PRINCE COMPONENTS
CHANGE CONTROL
Changes may happen during the course of a project and they require proper management.
Change management is of vital importance to a project, as uncontrolled changes or
inadequate assessment of their impact may lead to project delay or resources overspending.
In PRINCE, all changes, regardless of types, are raised as Project Issues and recorded in
the Issue Log.
6.8.1 Issue Log

A project issue may address technical or management issue. It can be raised at any time by
any one in the project. Content in a project issue may include :
perceived errors;
failure of the system to meet the user requirements;
ideas for improvement (e.g. design, functionality, user interface, documentation,
standards, etc.); and
management concerns, such as those related to costs, plans, resource, etc.
Project issue is handled as follows :1. Whoever raise the project issue has to provide details to the PM;
2. Upon receipt of the information, the PM will record it in the Issue Log;
3. Impact analysis on the Project Issue will be conducted by the PM with due regards to
the Business Case, project plan and stage plan;
4. Options to cater for the project issue will be identified. Whether the tolerance will be
exceeded upon the implementation of the option will be assessed.
5. PSC approval is required if : the proposed change is on baselined products and the change is a major one (may
reference also OGCIO Software Configuration Management Process Guide for
Application Software);
the proposed change cannot be implemented within the tolerance.
6. PSC approval is not required if : the proposed change is a minor one and can be implemented within the tolerance.
7. In this case, the PM can make the decision whether to implement the option.
8. For either case, the PM is responsible for the implementation of the option.
A Issue Log is used to record information during the above process. The content should
include but not limited to :
Description of Issue
Resolution
Impact Analysis (time, resources, baselined products, tolerance etc.)
6-28
PRACTITIONER GUIDE
PRINCE COMPONENTS
Decision
Status and Date of Status
Change Request No. (if changes to baselined products are required)
Hints and Tips
For major issues whose resolutions cannot be implemented within the tolerance, the
Project Manager may consider obtaining approval from the PSC using the Issue Log or
any other documents, e.g. approval loose-minutes in subject files and a detailed report
of the project issue. References can be made from the Issue Log to those documents. In
any case, the Project Manager should monitor and control the project issues using the
Issue Log.
6.8.2 Impact Analysis

Impact analysis has to be conducted for each project issue. The analysis is to determine
the products affected as well as the resource requirement, timescale, cost and risk of the
work to implement the change or to correct the fault from the views of user, business and
supplier.
Based on the analysis, the priority of the project issue can then be established. The priority
can in general be classified as follows:(a) High
It is essential that it be implemented. An example would be a change

necessary to comply with new legislation.
(b) Medium
It is highly desirable that it be implemented. For example correction

of a fault which reduces the efficiency or benefits of the system.
(c) Low
There is no significant benefit/impact associated with the change or

fault. For example, the correction of a minor error in the
documentation which does not impact on the operation of the system.
(d) Cosmetic
The change/fault is relatively trivial and has no measurable effect on

the operation of the new system. For example, a request to change
the typeface used in a manual in order to comply with a new
recommended format.
6.8.3 Follow-up on Project Issues

Implementation of the resolution of project issues should be monitored periodically against
the plan by the PM. The status of implementation should be recorded. It is recommended
that the status of each project issue be reviewed at major checkpoints by the PSC (e.g.
End-Stage Assessment, Project Closure Meeting).
6-29
PRACTITIONER GUIDE
PRINCE PROCESSES
7.
PRINCE PROCESSES
7.1
PRINCE PROCESS MODEL

PRINCE is a processed-based approach to project management. The processes define the
activities to be carried out during the project. There are 8 major processes in PRINCE, as
depicted in the following diagram:
OGCIO Management
Project
Closure
Notification
Exception
Report
Approved
PID
Project Start-up
Notification

Quality, risk,
IRS or ITPSA
project
Assignment
definition,
Brief
business case
etc.
Authorization
Starting up a
Project (SU)
Advice
PID
Initiating a
Project (IP)
Controlling a
Stage (CS)
Work
Package
Authorisation
Updated plans
Product checklist
Next stage plan
etc.
Reports
Managing
Stage
Boundary
(SB)
Project
Evaluation
Report
Follow-on
Action
Recommendation
Closing a
Project
(CP)
Checkpoint Report
Product Checklist
Work Package
Closure
Managing
Product
Delivery
(MP)
Planning (PL)
* Only high level information flows are highlighted in the diagram; not all information flows are shown.
These levels interact in two ways:

the higher level processes exercise control over the lower level;
the output of the lower level processes provides the inputs which allows the higher level
processes to function effectively.
Interfaces among sub-processes are indicated by arrows within the process boundary.
7-1
PRACTITIONER GUIDE
7.2
PRINCE PROCESSES
DIRECTING A PROJECT (DP)

Directing a Project by the PSC runs from after the start-up of the project until its closure. The
PSC has the authority and responsibility for
defining what is required from the project
authorizing the funds for the project; and
committing the resources.
While the day-to-day charge of the project is delegated to the PM, the PSC exercises overall
control and makes the key decisions.
OGCIO Management
Project Start-up
Notification
Mobilisation of
support services
Approved PID
Exception Report
Follow-on Action
recommendation
Project Evaluation Report
Project Closure Notification
Authorising
Initiation
(DP1)
Authorisation
to proceed
Authorising
a Project
(DP2)
Authorising
a Stage or
Exception
Plan
(DP3)
Authorisation
to proceed
Quality, risk, project

definition, business case,
Draft Initiation Stage Plan
Job Definitions
Project Management
Team structure
Project Approach
Draft PID
Starting up
a Project
(SU)
Initiating a
Project
(IP)
Business/
Technical
Changes
Authorisation
to proceed
Controlling
a stage
(CS)
Giving Ad
Hoc
Direction
(DP4)
Confirming
Project
Closure
(DP5)
Highlight Report
Exception Report
Requests for advice

Project Closure recommendation
Follow-on Action recommendations
Operational and Maintenance
PID, Exception Report, confirmation
Next Stage Plan,
PID
Project Team changes,
Updated Project Plan
Updated Business Plan
Updated Risk Log, etc.
Managing
Stage
Boundary
(SB)
Closing a
Project
(CP)
7-2
PRACTITIONER GUIDE
PRINCE PROCESSES
7.2.1 Authorising Initiation (DP1)

At the start of the project initiation stage, the PSC, based on information provided by the PM
and those with assurance responsibilities, will:
confirm all aspects of the project (quality, risks, project definition, business case etc.) at a
high level, checking if necessary with the senior management of the customer;
agree tolerance margins for the plan;
agree control and reporting arrangements for the project; and
commit the resources required for the project initiation stage.
It is to confirm that a viable project exists and that everybody concerned agrees what is to be
done.
7.2.2 Authorising a Project (DP2)

At the project initiation meeting (i.e., at the end of the project initiation stage), the PSC, with
advice from those with assurance responsibilities, will look at the Project Initiation Document
(PID) prepared by the PM to:
confirm that the project's objectives and scope are clearly defined and understood by all;
confirm that the objectives are in line with OGCIO and/or User management business
objectives;
confirm that all authorities and responsibilities are agreed;
confirm that the business case is adequate, clear and, wherever possible, measurable;
confirm the existence of a credible project plan which is within the project constraints;
check that the plan for the next stage is reasonable and matches that portion of the project
plan;
confirm tolerance levels for the project and the next stage;
give written approval for the next stage (or reject, if not satisfied with any of the details);
and
schedule a date for the next End Stage Assessment.
It allows the PSC to decide whether or not to proceed with the project and approve the next
Stage Plan before major resource is committed.
Hints and Tips
For small projects, the Project Initiation Document details may need to be discussed and
agreed informally in a short period of time. The PSC may give go-ahead direction when
the last piece of information is presented without a formal Project Initiation Meeting.
Approval to proceed should still be confirmed in writing as PID is an important
management document.
7-3
PRACTITIONER GUIDE
PRINCE PROCESSES
7.2.3 Authorising a Stage or Exception Plan (DP3)

At each End-Stage Assessment (i.e. at the end of each stage except the project initiation and
closure stages), the PSC, based on information provided by the PM, will:
compare the results of the current stage against the approved stage plan;
assess progress against the project plan;
assess the acceptability of the next stage plan against the project plan;
review the prospects of achieving the business case;
review the risks facing the project;
get direction from the senior management of the customer if the project is forecast to
exceed tolerances or there is a change to the business case;
review tolerances and reporting arrangements for the next stage; and
give approval to move into the next stage (if satisfied) by approving the next stage plan
and committing the resources for next stage.
It is an important control for the PSC to approve only one stage at a time. At the end of one
stage, the PM has to justify progress so far plus the plan for the next stage before being
allowed to continue.
For exception plan (i.e. a revised stage plan for the rest of the stage in order to cater for the
exception situation documented in an Exception Report), the same mechanism applies but
authorisation will take place in an Exception Assessment.
Hints and Tips
For small projects, the decisions can be made informally (i.e. a meeting is preferred but
other communication media such as email, letter can also be used), but the PSC should
still carry out the above activities.
7.2.4 Giving ad hoc Direction (DP4)

At any time, the PSC may be consulted to give advice on direction when options need
clarifying or upon impacting external events or organisational change in project, or to resolve
conflicts including resources conflicts. Depending on the issue in concern, the PSC will:
check for external events, e.g. business changes, which may affect the project's business
case or risk exposure;
make decisions on any Exception Plan;
make decisions about any necessary changes to the project management team; and
make decisions on Project Issues escalated from the PM.
7-4
PRACTITIONER GUIDE
PRINCE PROCESSES
7.2.5 Confirming Project Closure (DP5)

At the project closure meeting (i.e. at the end of the project), the PSC, supported by those
with project assurance responsibilities, will:
ensure that the supplier gains acceptance from the customer that all the required products
have been delivered and the acceptance criteria have been met;
check that there has been a satisfactory hand-over of the finished product(s) to those
responsible for its use and support;
approve the Follow-On Action Recommendations and pass them to the appropriate group
for any unfinished work;
check that there are no outstanding Project Issues;
approve the Project Evaluation Report and passes it to the appropriate body;
release the resources allocated to the project;
sign off and advise senior management of the customer of the project's closure; and
disband the project organisation.
This designates a formal hand-over of responsibility and ownership of the projects products
to the ultimate users. Where contracts are involved, there must be agreement between
customer and supplier that the work contracted has been completed.
7-5
PRACTITIONER GUIDE
7.3
PRINCE PROCESSES
STARTING UP A PROJECT (SU)

The work of this process is built around the production of two elements:
ensuring that information of all aspects of the project (quality, risks, project definition,
business case etc.) is available
designing and appointing the Project Management Team
The process, triggered by senior management, signifies the start of the project. (In OGCIO,
the trigger may refer to an IRS, an ACPC funding approval or an ITPSA Assignment Brief).
This provides input to sub-process Authorising Initiation (DP1) which may then trigger the
process Initiating a Project (IP).
OGCIO Management
Starting up a Project (SU)

Appointing
a PSC
Executive
and PM
(SU1)
Designing a
Project
Management
Team
(SU2)
Preparing
Project Brief
(SU4)
Defining
Project
Approach
(SU5)
IRS or ACPC
Approval, ITPSA
Assignment Brief
Draft job
descriptions, PM
team structure
Appointing a
Project
Management
Team
(SU3)
Draft initiation
Stage Plan
Authorising
Initiation
(DP1)
Planning
Initiation
Stage
(SU6)
7.3.1 Appointing a PSC Executive and a PM (SU1)

Upon receipt of the trigger which signifies the start of the project (the IRS, ACPC funding
approval or ITPSA Assignment Brief in OGCIO), senior management of the customer will:
identify the appropriate PSC Executive from the project's stakeholders
identify the Project Manager most appropriate for the project
confirm the selected people's availability, their acceptance of these roles and their
commitment to carry them out
draw up and agree job descriptions
7-6
PRACTITIONER GUIDE
PRINCE PROCESSES
appoint them to their respective roles

The process satisfies the need for someone to plan and prepare the first steps, and someone to
approve the expenditure.
Hints and Tips
For small projects, the person requesting the project may well be the one paying for it. If
so, that person becomes the Executive without reference to any other body, i.e. the person
in question has the budgetary authority to pay for the project. If not, senior staff with
sufficient budgetary authority will be appointed.
In PRINCE, the executive has a role to appoint the PM. However, in the Government
environment, the PM is usually from OGCIO or the Supplier while the Executive is from
the User Department. In such a case, the PM will be appointed by OGCIO or the Supplier
instead of by user. The Executive will not have the authority to appoint the PM.
7.3.2 Designing a Project Management Team (SU2)

The complete Project Management Team needs to reflect the interests of all the concerned
parties. In order to establish the team, the Executive and the PM will:
design a PSC with representatives from the final users and the supplier, who are suitable
for the criticality and size of the project;
identify candidates for the roles and check their availability and provisional agreement;
check whether the PSC members will carry out their own assurance responsibilities;
identify candidates for any assurance functions which are to be delegated and check their
availability;
decide if any project support will be required; and
identify resources for any required support.
The Project Management Team composition should be presented to OGCIO and/or User
management for approval. The Executive will inform the Project Management Team their
appointment. The PM will discuss the job description with the team members.
Hints and Tips
For small projects, the PSC will normally carry out the assurance responsibilities on its
own. In very small projects, the Executive and Senior User roles will often be combined. If
a department is developing a product for its own use and all the project's resources are
from that department, the Senior Technical and Senior User may also be the same person.
7-7
PRACTITIONER GUIDE
PRINCE PROCESSES
7.3.3 Appointing a Project Management Team (SU3)

The Executive, assisted and advised by the Project Manager, is responsible for:
appointing people to the PSC, team management and where appropriate, Project Assurance
and Project Support;
ensuring that these individuals understand their roles and responsibilities in the
management and support of the project;
ensuring that the individuals are actively committed to carrying out their roles and
responsibilities;
confirming the reporting and communication lines, and include in management
information as this will impact on the Communications Plan.
There must be agreement and acceptance by everyone of their roles and responsibilities. The
Executive is responsible for the appointments, assisted and advised by the Project Manager.
Hints and Tips
Role definition can be tailored to the particular environment and individual.
7.3.4 Preparing a Project Brief (SU4)

The Executive, assisted by the PM and any appointed Project Support staff, is responsible for
preparing the Project Brief by:
preparing the formal terms of reference for the project;

establishing the customer's quality expectation;
establishing the Acceptance Criteria for the project;
recording any risks facing the project;
ensuring there is an outline Business Case.
The Project Brief needs to include high-level information on what needs to be done, why, the
benefits to be achieved, who will need to be involved in the process and how and when it will
be done. The aim of the Project Brief is to allow the PSC to decide whether there is sufficient
justification to warrant the expenditure proposed by the Initiation Stage Plan.
The customer's quality expectations need to be agreed at this early stage. They will impact
every part of the product development, thus affecting time and cost.
Hints and Tips
In small projects the Project Brief may not be produced as a separate document. It may be
more appropriate to go straight to producing an outline Project Initiation Document,
7-8
PRACTITIONER GUIDE
PRINCE PROCESSES
which would then be refined. In such a case, Starting up a Project (SU) and Initiating a
Project (IP) could combine into one process.
7.3.5 Defining Project Approach (SU5)

The PM, assisted by any appropriate project support (if assigned) and specialist skills, will :
identify any time, money, resource, support or constraints;

check for any direction or guidance on the approach from earlier documents such as IRS;
identify the project scope;
identify any security constraints;
check for any corporate or programme statements of direction which may constrain the
choice of approaches, e.g. Packaging;
consider how the product may be brought into use and whether there are any problems
which will impact the choice of approach;
produce a range of alternative approaches;
identify the training needs of the alternatives;
compare the alternatives against the gathered information and constraints; and
prepare a recommendation.
The project approach will affect the time-scale and costs of the project, including possibly its
scope and quality. This information should be documented in the PID for the PSC to decide
whether to initiate the project.
Hints and Tips
There is always the pressure to start work on a solution as soon as possible and this may
lead to the pressure of not performing this sub-process, but this should be resisted.
In most cases, it would be logical to group SA&D and Implementation into one PRINCE
project, with its project scope defined in the FS.
In cases where the FS is combined with SA&D and even Implementation, the project scope
may need to be extracted from ISSS or IRS. The combination logically forms a PRINCE
project.
7.3.6 Planning an Initiation Stage (SU6)

The PM, assisted by any Project Assurance and Project Support roles, will:
produce a plan (the initiation Stage Plan) that covers the production of two management
products :
the Project Initiation Document (which includes the Project Plan);
the Stage Plan for the stage immediately following initiation;
define the reporting and control arrangements for the initiation stage.
7-9
PRACTITIONER GUIDE
PRINCE PROCESSES
The Project Initiation Document is an extension and refinement of the Project Brief with the
addition of the project management team details, the Project Plan and the Risk Log. The
initiation Stage Plan needs to show the investigation and development of the extra
information required, plus the development of the Project Brief into the format required for
the Project Initiation Document. The initiation stage should be a short and inexpensive one,
compared to the likely total cost of the project.
A stage structure for the project will be developed during initiation. At the end of initiation
the PSC will expect to see not only the Project Initiation Document but also a detailed plan
for the next stage, because the extent of their actual commitment will only be for the next
stage.
The common Planning (PL) process will be used to create the initiation Stage Plan.
Hints and Tips
The normal reporting frequency may be too long for such a short stage.
While it is always important to plan any work prior to commencement, for some small,
low-risk projects it may not be necessary to produce too formal a plan for the initiation
stage.
7-10
PRACTITIONER GUIDE
7.4
PRINCE PROCESSES
INITIATING A PROJECT (IP)

Initiating a Project aims at laying down the foundations for the fulfilment of the following
principles for a successful project:
a project is a finite process with a start and an end
all parties must be clear about what the project is intended to achieve, why it is needed,
how the outcome is to be achieved and what their responsibilities are in that achievement
so that there can be genuine commitment to the project; and
well-managed projects have an increased chance of success.
Initiating a Project (IP)

Planning
Quality
(IP1)
Planning a
Project
(IP2)
Refining the
Business
Case and
Risks
(IP3)
Setting up
Project
Controls
(IP4)
Setting up
Project Files
(IP5)
Assembling
a PID
(IP6)
Authorising
Initiation
(DP1)
Authorized
initiation
Stage Plan
Authorising
a Project
(DP2)
Draft PID,
Next Stage
Plan
7.4.1 Planning Quality (IP1)

To be successful, the project must deliver a quality product, as well as meeting time and cost
constraints. Thus the means of achieving quality must be specified before work begins. The
time and cost of the project will be affected by the amount of quality work which has to be
done, therefore quality planning must be done before a realistic project plan can be produced.
To plan for the quality, the PM and those with assurance responsibilities should:
study the customer's quality expectations;
identify quality responsibilities of both the customer and supplier for project products;
7-11
PRACTITIONER GUIDE
PRINCE PROCESSES
establish how quality will be achieved; and

document the details in a project quality plan.
Hints and Tips
For small projects, even if the customer leaves the quality review to the developer, there
should be customer involvement in specifying the testing environment and with what test
situations the products should successfully cope.
7.4.2 Planning a Project (IP2)

The PM, assisted where appropriate by project support roles (if assigned) and guided by those
with project assurance responsibilities, should:
use the Planning (PL) process to create the Project Plan;

review any project constraints and dependencies;
modify the plan accordingly;
decide on a suitable breakdown of the project into stages;
invoke process Plan the Next Stage (SB1) to produce the next stage plan; and
check the plans informally with the PSC.
Details of the Project Plan help the PSC in determining the viability of the project. Details of
the next stage plan will facilitate the PM in performing day-to-day management work.
Hints and Tips
For small projects, it may not be necessary to produce stage plans if the Project Plan
holds sufficient details to allow day-to-day control.
7.4.3 Refining the Business Case and Risks (IP3)

The Executive, probably with input of benefits from the user(s) and the assistance from the
PM, should:
check if the circumstances and assumptions have changed if a Business Case was included
in some previous documents (the IRS, ACPC funding approval or ITPSA Assignment
Brief in OGCIO);
investigate with the user(s) the objectives or benefits for the project;
investigate with the Executive the business objectives or benefits for the project;
quantify the benefits wherever possible;
incorporate the costs from the Project Plan;
perform risk analysis;
modify the Project Plan to reflect any risk activities; and
prepare any contingency plans made necessary by the risk analysis.
7-12
PRACTITIONER GUIDE
PRINCE PROCESSES
The output of the above process should be documented in the PID.

Hints and Tips
For small projects, it is easy to start small projects without confirming that there are good
business reasons for doing it. It is important, however small the project, to go through the
exercise of justification. Otherwise, resources spent may be unjustified.
7.4.4 Setting up Project Controls (IP4)

The PM, assisted by project support (if assigned) and advised by those with project assurance
responsibilities, should:
agree the stage breakdown with the PSC;

agree the amount of tolerance given to the PM;
agree the format of reports to the PSC;
agree the frequency of Highlight Reports with the PSC;
establish reporting requirements (i.e. probably by the Checkpoint Review) from the TM to
the PM;
check that there are sufficient risk and Business Case monitoring activities in the plans;
(may) set up a blank Project Evaluation Report to record resources utilisation data and
useful information throughout the project.
Project controls are important to ensure that right decisions are made by the right people at
the right time, and that right information is given to the right people at the right frequency and
timing. The methods and levels of control should be agreed at the project initiation stage and
followed by all concerned parties throughout the project. The details should be documented in
the PID.
Hints and Tips
For small projects, it may be acceptable to the PSC that many of the reports be given
verbally. But there should always be a formal initiation and a formal close of the project.
7.4.5 Setting up Project Files (IP5)

The PM, assisted by project support (if assigned) and advised by those with project assurance
responsibilities, should file details of key events, decisions and agreements of the project.
They may help in future project estimation, provide input to the Project Evaluation Report or
provide a historical record of what happened, when and why.
7-13
PRACTITIONER GUIDE
PRINCE PROCESSES
Products and documentation of a PRINCE project are classified into three categories:
1)
Management Products, which include

Project Initiation Document
Project Plan, Stage Plans and Exception Plans
Minutes of PSC Meetings and Checkpoint Review Meetings/Notes
Highlight Reports
Risk Log
Issue Log etc.
2)
Quality Products, which include

Product Checklist
Invitations to Quality Reviews
Quality Review Comment Forms and Follow-up Lists etc.
3)
Technical Products, which include

System Development Products (FS Report, SA&D Report, Implementation
Products etc.)
Procurement Products (Tender Specifications, Evaluation Criteria, Evaluation
Reports, Contracts etc.)
Separate project files should be maintained for each of the above categories of documentation.
Documentation in each project file should be filed according to the project stages.
7.4.6 Assembling a Project Initiation Document (IP6)

The PM, with the help of any appointed project support (if assigned) and the advice of those
with assurance responsibilities, should gather together the information from the other IP subprocesses and assembles the PID (see Appendix D - PRINCE Product description). The
Project Initiation Document encapsulates all the information needed for the PSC to make the
decision on whether to go ahead with the project or not. It also forms a formal record of the
information on which the decision is based, and can be used after the project finishes to judge
how successful the project is. Upon completion, the PID will be distributed to the PSC for
endorsement at the Project Initiation Meeting.
7-14
PRACTITIONER GUIDE
7.5
PRINCE PROCESSES
CONTROLLING A STAGE (CS)

Controlling a stage (CS) handles day-to-day management of the project. It starts after the
approval of a Stage Plan. Any or all of the Controlling a Stage (CS) processes may be used in
an event-driven manner (driven by the problems and circumstances as they arise) as well as
on a regular basis (e.g. planned end date of a stage).
Managing
Product
Delivery
(MP)
Work package
Checkpoint report
Controlling a Stage (CS)

Directing a
Project
(DP)
Authorising
Work
Package
(CS1)
Assessing
Progress
(CS2)
Stage status
information
Work
trigger
Closing a
Project
(CP)
Notification of
project end
Taking
Corrective
Action
(CS7)
Work package
status
Updated
issue log
Examining
Project
Issues
(CS4)
Plan deviation
Stage end
notification
Managing
Stage
Boundaries
(SB)
Tolerance threat
Escalating
Project
Issues
(CS8)
Exception
plan report
Capturing
Project
Issues
(CS3)
Reporting
Highlights
(CS6)
Stage status
information
Reviewing
Stage Status
(CS5)
Receiving
Completed
Work Package
(CS9)
Highlight report
Exception
report
Directing a
Project
(DP)
7-15
PRACTITIONER GUIDE
PRINCE PROCESSES
7.5.1 Authorising Work Package (CS1)

The PM, assisted by any support roles (if assigned), and in agreement with the relevant TMs,
should:
review the Product Description(s) for the product(s) to be delivered; ensure that they
describe what is required and add any constraints and responsibilities required
brief the TMs and hand out the Work Package with all relevant documentation and
information, including terms of reference covering;
the cost and effort that the work is expected to consume
the timescale for completion
the progress reporting arrangements
any individuals, groups or products with whom it is necessary to interface in the
performance of the work
Product Descriptions
update the status information to "under development" in any affected Configuration Item
Records;
ensure that the TM has the correct resources to carry out the work;
identify any problems or risks associated with the work and incorporate any necessary
changes or other measures to handle these;
ensure the TM is committed to completion of the work within the terms of reference laid
down;
instruct the TM to proceed via an appropriate form of Work Package.
A TM receives work packages on behalf of a team. This is covered by the process Managing
Product Delivery (MP). The PM must control the sequence of all Work Packages issued
within a stage. This ensures that the PM can effectively monitor the progress of each work
package against the stage plan.
Hints and Tips
In OGCIO, where the work is being conducted by an internal project team working directly
under the PM, the Work Package assignment may be a verbal instruction, although there
are good reasons for putting it in writing, so as to avoid misunderstanding and to provide a
link to performance assessment. Where the work is being carried out by a contractor, there
is a need for a formal written instruction in line with standards laid down in that contract.
For small projects, the process can be followed in an informal way, but the PM should
consider if any record is needed for any later appraisal of individual performance.
Where the PM is also personally performing the work, this sub-process is not needed.
A Work Package should ideally not spread over more than one stage. If there is any
danger of this, it should be broken down so that its intermediate parts fit into one
management stage or another.
7-16
PRACTITIONER GUIDE
PRINCE PROCESSES
7.5.2 Assessing Progress (CS2)

In order to control the stage, to discover problems and to make sensible decisions on what, if
any, adjustments need to be made, it is necessary to gather information on what has actually
happened and be able to compare this against what was planned. Throughout each stage, the
PM, assisted by any support roles, should regularly conduct Checkpoint Review with the TMs
so as to:
collect in all of the progress information for all work currently being undertaken;
collect feedback on recent quality-checking activities carried out;
assess the estimated time and effort to complete any unfinished work (including that not
yet started);
assess the utilisation of resources in the period under review and their availability for the
remainder of the stage (or project);
review with the TMs whether work will be completed on time and to budget;
update the Stage Plan with actuals to date;
identify any points that need attention in process Reviewing Stage Status (CS5).
Minutes/Notes of Checkpoint Review (see Appendix D - PRINCE Product Description)

should be prepared and filed.
Hints and Tips
For small projects, while the Checkpoint Reviews may be conducted informally, these
activities are still required.
The PM should make a decision about their frequency according to the project situation
and environment. Normally, the frequency will align with that of the Highlight Report.
7.5.3 Capturing Project Issues (CS3)

Throughout each stage, the PM should capture, log and categorise new Project Issues. The
Issue Log (see Appendix D - PRINCE Product Description) is used to document the issues.
7.5.4 Examining Project Issues (CS4)

Having captured all issues in the sub-process Capturing Project Issues (CS3), the issues
should be examined for impact and the appropriate body for any decision identified. The PM
together with any staff allocated assurance responsibilities should:
assemble all information about the issue;

preliminarily examine the Project Issue as soon as it is logged to see if it is worth further
processing (e.g. is there sufficient information for further processing?);
carry out impact analysis on the issue from the views of user, business and supplier;
update the Risk Log if the issue reveals a new risk or a change to a known risk;
7-17
PRACTITIONER GUIDE
PRINCE PROCESSES
prepare a recommended course of action; and

update the Issue Log with the impact analysis result.
Hints and Tips

For small projects, the PM may be able to carry out impact analysis as soon as the issue is
presented and get a decision on the action to take. This, in practise, combines the capture
and examination sub-processes with the taking of corrective action or the escalation of the
project issue to the PSC for decision.
7.5.5 Reviewing Stage Status (CS5)

The PM, assisted by any project support roles (if assigned) and those with Project Assurance
responsibilities, should:
review progress against the Stage Plan;

check the Quality Log to see the state of quality checking;
check the Configuration Item Records to ensure that all products have been completed as
stated and anticipated;
review resource utilization and future availability;
review the effect of Project Issues on any change budget and Stage and Project Plans;
establish whether the stage will go outside the tolerances or not;
pass Project Issues likely to cause tolerance to be exceeded to the PSC for consideration
via process Escalating Project Issues (CS8);
identify any variation between plan and actual progress;
check for any variation in the expected future resource availability;
assess any current risk to the Stage Plan for any change to the exposure;
check the updated Stage Plan for any new risks;
review external developments for any impact on the project;
check to see whether anything has happened within tolerances
use process Authorizing Work Package (CS1) to authorize any necessary new work
required by the Stage Plan.
Hints and Tips

Although this is shown as a discrete process to emphasise the importance of regular
progress checking, it will often happen concurrently with other processes. For instance, at
the same meeting that carries out this process, highlights could be produced (Reporting
Highlights (CS6)) and the following period's work authorized (Authorizing Work
Package (CS1)).
Stage status should be reviewed regularly - the frequency of the reviews being related to
the length of activities in the plan and the need (or otherwise) for close control.
7-18
PRACTITIONER GUIDE
PRINCE PROCESSES
7.5.6 Reporting Highlights (CS6)

The PM, supported by project assurance and project support roles (if assigned) and in
consultation with the TMs if appropriate, will:
assemble the information from the Checkpoint Reports and any significant revisions to the
Stage Plan from Taking Corrective Action (CS7);
identify any current or potential problems from Reviewing Stage Status (CS5);
produce the Highlight Report;
distribute the report to the Project Board and any other agreed recipients;
review the Communication Plan for any required external reports and send these out.
Hints and Tips
The report should be kept as short as possible, consistent with the information needs of the
PSC. A suggested target is a one or two page report.
7.5.7 Taking Corrective Action (CS7)

This process is triggered by the identification of a deviation and instigates corrective action.
The PM, supported by Project Assurance and Project Support roles and in consultation with
TMs if appropriate, should:
collect any pertinent information about the deviation;

identify the full cause and effect of the deviation;
identify the potential ways of dealing with the deviation;
select the most appropriate option;
where direction from the PSC is sought, assemble all information about the problem (it
may already be a Project Issue) plus any recommendation;
update the Stage plan;
update any affected Product Descriptions/Configuration Item Records as appropriate;
make available any baselined products from the configuration library;
trigger corrective action.
Hints and Tips

Beware the cumulative effect on the budget, and the costs of small changes.
Beware the direction in which some small changes may be taking the project.
7.5.8 Escalating Project Issues (CS8)

The PM must bring to the attention of the PSC if a stage is forecast to go outside the tolerance
margins. In order to retain the PSC's overall control, the PM, and those with Project
Assurance responsibilities, should:
carry out a full impact analysis of the deviation; the analysis should cover specialist, user
7-19
PRACTITIONER GUIDE
PRINCE PROCESSES
and business impacts (normally done in Examining Project Issues (CS4));

identify and evaluate options for recovery or to take advantage of good news (normally
done in Examining Project Issues (CS4));
make a recommendation;
put the situation, options and recommendation to the PSC in an Exception Report;
the PSC indicates support or otherwise for the Project Manager's recommendation (in
Giving Ad Hoc Direction (DP4));
update the information in the Configuration Item Records of any affected products.
Hints and Tips
For small projects, the Exception Report need not be in writing if that is acceptable to the
PSC. The PM must decide if it should be documented why changes were made or decisions
taken for the purposes of an audit trail.
7.5.9 Receiving Completed Work Package (CS9)

Where work has been allocated to individuals or teams, there should be a matching
confirmation that the work has been completed and accepted. The PM, assisted by any
appointed Project Support staff, checks that:
the recipient of the products has accepted them;
the product checklist entries are complete;
the products have been transferred to configuration management.
Hints and Tips
For small projects, this process is usually done informally.
7-20
PRACTITIONER GUIDE
7.6
PRINCE PROCESSES
MANAGING PRODUCT DELIVERY (MP)

This process provides an interface between the PM and the TM. Sometimes, third parties such
as contractor, who may not use PRINCE, are involved in delivering the project products. MP
provides a description of the necessary interface between the PM and the TM.
Managing Product Delivery (MP)
Authorising
Work Package
(CS1)
Work Package
Accepting a
Work Package
Executing a
Work Package
Delivering a
Work Package
(MP1)
(MP2)
(MP3)
Checkpoint report
Assessing Progress
(CS2)
Approved work
Package
Receiving
Completed
Work Package
(CS9)
7.6.1 Accepting Work Package (MP1)

Before accepting any Work Package, the TM should:
agree with the PM on what products are to be delivered;
ensure that Product Descriptions are given for the required products;
agree on the standards to be used, the quality reviews to he made and any constraints
which apply to the work;
understand who is to provide acceptance for the finished products;
understand how hand-over of the products is to be made;
confirm the PM's reporting requirements;
plan how, by whom and when the work is to be done; and
ensure that there are sufficient resources to do the work.
It is essential for the TM (or individual) to agree and commit to the terms of a Work Package,
rather than simply accept what the PM believes can be done.
Hints and Tips
Where third parties are involved, this sub-process should be carefully observed and
checked against the contract to ensure proper safeguards for the supplier.
For small projects, the team members will probably work directly for the PM, therefore
this sub-process should be informal.
7-21
PRACTITIONER GUIDE
PRINCE PROCESSES
7.6.2 Executing Work Package (MP2)

Upon receipt of the Work Package, the TM should:
allocate work to team members;

monitor and control the work;
gather progress information to prepare for the Checkpoint Reviews with the PM;
ensure that any independent quality reviewers are fully involved in the appropriate quality
reviews;
record the results of all quality reviews carried out in the Product Checklist;
monitor any identified risks to the work; and
advise the PM of any potential failure to meet the requirements of the Work Package.
This sub-process outlines the key activities of a TM. It is not exhaustive. What methods and
tools are to be used is also up to the TM.
Hints and Tips
Even if the TM is not using PRINCE, it would be sensible to have compatible recording
and reporting procedures.
For small projects, the PM may do the work of this sub-process if there is no TM assigned.
7.6.3 Delivering a Work Package (MP3)

Upon completion of the Work Package, the TM should:
arrange and conduct Quality Review on the completed products;
hand-over the products of the Work Package; and
obtain sign-off for the designated products from the PM.
Hints and Tips
Apart from formal Quality Review for acceptance of major products, a PM may also need
to arrange informal Quality Reviews on project deliverables. Examples of these reviews
include sample inspection of program code or a system design walk-through with the
Analyst.
7-22
PRACTITIONER GUIDE
7.7
PRINCE PROCESSES
MANAGING STAGE BOUNDARIES (SB)

To enable PSC to exercise its control and authorise a project to move forward a stage, a
process is needed to create a plan for the next stage and provide the information needed by the
PSC about the current status to justify the continuity of the project.
Managing Stage Boundaries (SB)
Stage End
Notification
CS5
Reviewing
Stage
Status
SB1
Planning a
Stage
SB6
Producing
an
Exception
Plan
CS8
Escalating
Project
Issues
Next
stage
plan
SB2
Updating a
Project
Plan
Exception
plan
SB4
Updating
the Risk
Log
DP3
Authorizing
a Stage or
Exception
Plan
Next
stage plan
or
exception
plan
SB3
Updating a
Project
Business
Case
Next stage plan or

exception plan
Next stage
plan or
exception
plan
SB5
Reporting
Stage End
Request for
authorization to
proceed
End stage report
Next stage
plan or
exception
plan
7.7.1 Planning a Stage (SB1)

In order to adequately control a stage, the PM needs a plan with the detailed activities for dayto-day control. At the end of a stage, the PM should:
check the Project Approach for any guidance on how the products of the next stage are to
be produced;
check if there is any project issue which will affect the next Stage Plan; and
prepare the technical plan and resources plan for the next stage.
7-23
PRACTITIONER GUIDE
PRINCE PROCESSES
Hints and Tips

For small projects, the Project Plan may contain sufficient details to manage each stage.
Separate Stage Plans may not be needed.
7.7.2 Updating a Project Plan (SB2)

As one stage is completed and the next one planned, the Project Plan must be updated so that
the PSC has the most up-to-date information on likely project costs and schedule on which to
partially base its decision on whether the project is still a viable business proposition. Before
each End-Stage Assessment and the project closure meeting, the PM should:
ensure that the current Stage Plan has been updated with actual costs and dates;
update the Project Plan with the actual costs and dates of the current stage;
update the Project Plan with the estimated costs, resource requirements and dates of the
next stage; and
update any later stages of the Project Plan upon changes on the project resources, schedule,
approach or environment. Any such changes should be explained in written format.
7.7.3 Updating a Project Business Case (SB3)

The whole project should be business-driven, so the PSC should review a revised Business
Case as the major part of the checking on the continued viability of the project. Before each
End-Stage Assessment, the PM and whoever has responsibility for the business assurance for
the project, should:
create a new version of the Business Case ready to be updated;

review the expected costs against the new forecast in the updated Project Plan;
review the financial benefits against any new forecasts;
review the business reasons and check that no change nor new reasons have arisen; and
modify the new version in the light of any changes on the costs, benefits and reasons.
Hints and Tips

The Business Case should be reviewed at least at each stage end, but more frequently if the
stages are long or the Business Case is marginal.
Continuous update of Business Case (for assessing the project viability) is important to all
projects.
7-24
PRACTITIONER GUIDE
PRINCE PROCESSES
7.7.4 Updating the Risk Log (SB4)

Before each End-Stage Assessment, the PM should:
ensure that the Risk Log is up-to-date with the latest information on the identified risks;
ensure that any new risks identified in creating the next Stage Plan have been entered into
the risk Log;
assess all open risks to the project, as defined in the Risk Log;
decide if the next Stage Plan needs to be modified to avoid, reduce or monitor the risks;
and
create contingency plans for any serious risks which cannot be avoided or reduced to
manageable scale.
Hints and Tips
Risks should be re-assessed at least at each stage end.
Continuous risk assessment and management are important to all projects.
7.7.5 Reporting Stage End (SB5)

The PSC gives approval to the PM to undertake only one stage at a time, at the end of which
PSC reviews the anticipated benefits, costs, time-scales and risks and makes a decision
whether to continue with the project or not. Therefore, at the End-Stage Assessment, the PM
should:
check that relevant quality review activities have been completed;
report on the actual costs and time of the current stage by providing the updated current
stage plan;
report on the impact of the current stage's costs and time on the project by providing the
updated project plan;
report on the status of each Project Issue;
report on the status of product delivery in the current stage by providing the product
checklist;
provide details of the next Stage Plan (if applicable);
identify any necessary revisions to the Project Plan caused by the next Stage Plan;
identify any changes to the Business Case;
report on the risk situation; and
recommend next action (e.g. approval of the next Stage Plan).
Minutes/Notes of End-Stage Assessment (see PRINCE Product Description) should be
prepared and filed.
7-25
PRACTITIONER GUIDE
PRINCE PROCESSES
Hints and Tips

The above information should be presented to the PSC prior to the End-Stage Assessment
so that the PSC can make sensible decision in a well-informed manner.
On small project with only couple of stages, a PSC may decide to use Highlight Reports to
replace End Stage Assessment for a stage of short duration. However, a PSC meeting is
still required if : the budget and tolerance set out by the PSC for the project stage have been exceeded, or;
the overall budget and tolerance set out by the PSC for the project is anticipated to be
exceeded, or;
a significant change in business case, technical and operational viability of the project.
7.7.6 Producing an Exception Plan (SB6)

When an exception situation indicates that the current tolerances are likely to be exceeded,
the PSC may ask for a new plan which reflects the changed situation and which can be
controlled within the newly specified tolerance margins. In this case, the PM should prepare a
new plan to replace the remainder of the current Stage Plan. An Exception Plan has exactly
the same format as a Stage Plan, together with a description of the exception situation.
Reasons for the exception situation can be many, such as:
Work on approved Requests For Change cannot be implemented within current tolerances
The stage cannot deliver all its products within tolerances.
7-26
PRACTITIONER GUIDE
7.8
PRINCE PROCESSES
CLOSING THE PROJECT (CP)

Every project should come to a controlled completion. In order to have its success measured,
a project must be brought to a normal close when it has met the objectives set out in the
Project Initiation Document, or terminated when it is no longer viable to continue.
Closing a Project (CP)
Project Files
Giving ad hoc
Direction
(DP4)
Premature
close
Project closure
recommendation
Notification of
project end
Reviewing
Stage Status
(CS5)
Authorizing a
Stage
(DP3)
Decommissioning a
Project
(CP1)
Premature Close
Identifying
Follow-on
Actions
(CP2)
Evaluating a
Project
(CP3)
Operational and
maintenance acceptance
Customer acceptance
Follow-on Action
recommendations
Confirming
Project
Closure
(DP5)
Post-project review
plan
Project Evaluation
Report
Lessons learned
report
7.8.1 Decommissioning a Project (CP1)

When a project comes to its normal end, the customer and supplier must agree that the project
has met its objectives before the project can close. Once agreed, the PM should:
check that all quality assurance reviews have been completed;

check that all Project Issues have been closed or transferred to follow-on activities;
ensure that all products have been completed and accepted by the customer;
ensure that, where applicable, those who will be responsible for maintenance and support
of the products are ready to accept the hand-over;
complete and archive the project files for hand-over; and
prepare notification to all parties that the project's resources and facilities are to be
disbanded.
There will need to be a carefully managed hand-over of the products between the project and
operational and/or support staff.
For pre-mature close, the PM should:
7-27
PRACTITIONER GUIDE
PRINCE PROCESSES
assess all outstanding Project Issues and transfer appropriate items to follow-on activities;
complete and archive the project files; and
prepare notification to all parties that the project is to be closed and resources disbanded.
7.8.2 Identifying Follow-On Actions (CP2)

Any knowledge of unfinished business at the end of a project should be documented. Upon
project closure, the PM should:
check for any omissions in the product or suggestions on how to improve the product;
check the Issue Log for any issues which are still outstanding;
draw up Follow-On action recommendations; and
check with the PSC and pass to the appropriate body for action.
Hints and Tips
For system implementation, one of the Follow-On actions is the Post Implementation
Departmental Return six months after the system live run.
7.8.3 Evaluating a Project (CP3)

One way to improve the quality of project management is to learn from the lessons of past
projects. Upon project closure, the PM should:
examine the Risk Log and actions taken and record any useful comments;
examine the Issue Log and actions taken and record any useful comments;
examine the Product Checklist and record any useful comments; and
write the Project Evaluation Report, evaluating the management, quality and technical
methods, tools and processes used and useful lessons. The report contains assessment of
the project's results against its objectives. It also contains statistics on the performance of
the project.
As part of the project closure, the PSC needs to assess the performance of the project and the
PM by reviewing the Project Evaluation Report (and endorse it if the PSC is satisfied with the
performance).
Hints and Tips
This may be part of the customer's appraisal of a supplier, to see if the contract has been
completed, or to see if that supplier has performed well.
The Project Evaluation Report should be updated throughout the project.
7-28
PRACTITIONER GUIDE
7.9
PRINCE PROCESSES
PLANNING (PL)
To ensure that all plans are prepared in the same way and have the same composition, a
common process is provided.
Planning is an essential part of project management. PRINCE offers a product-based planning
process (see section Project Management Techniques) which can be applied to any level of
plan. It is a repeatable and iterative process, and plays an important role in other subprocesses, the main ones being:
Planning an Initiation Stage (SU6)
Planning a Project (IP2)
Planning a Stage (SB1)
Updating a Project Plan (SB2)
Accepting a Work Package (MP1)
Producing an Exception Plan (SB6)
7-29
PRACTITIONER GUIDE
PRINCE PROCESSES
Planning (PL)
Plan
Design
Designing a
Plan
(PL1)
Planning an
Initiation Stage
(SU6)
Product Flow
Diagrams
Defining and
Analysing
Products
(PL2)
Identifying
Activities and
Dependencies
(PL3)
Product
Descriptions
Planning a
Project
(IP2)
Accepting a
Work Package
(MP1)
Draft Product
Checklist
Estimating
(PL4)
Assessed
Plan
Completing a
Plan
(PL7)
Product
Checklist
Completed
Plan for
approval
Planning a
Stage
(SB1)
List of
Activities
Schedule
Analysing
Risks
(PL6)
Risk Log
Updating a
Project Plan
(SB2)
Activities
dependencies
Estimated
Activities
Scheduling
(PL5)
Resource
availability
Producing an
Exception
Report
(SB6)
7.9.1 Designing a Plan (PL1)

This sub-process probably needs to be done only once early in the project by the PM to:
agree the format to be used for plans;
decide what planning tool, if any, will be used (In OGCIO, Microsoft Project is the
standard project management tool);
decide on the levels of plan needed for the project;
decide on the content and level of details required for each plan level;
decide how estimation of effort will be done; and
identify the recipients of plan copies and their needs.
7-30
PRACTITIONER GUIDE
PRINCE PROCESSES
Hints and Tips

The work of the sub-process can be very brief, especially if there are company standards
relating to tools and format.
7.9.2 Defining and Analysing Products (PL2)

Identification of the products required is a good starting point for planning. Identifying the
products whose delivery is to be planned naturally leads to the activities needed to produce
and deliver those products. It is also possible to define the quality requirements of a product
rather than an activity.
The PM with input and verification from the Project Assurance Personnel, should:
draw a hierarchy of the products required down to the level of detail appropriate to the plan
(i.e. the Product Breakdown Structure, see the section on Project Management Techniques);
make sure that the products include management and quality products as well as the
technical ones;
write Product Descriptions for all the products;
get agreement from the PSC that the Product Descriptions are complete and correct; and
draw a diagram showing the sequence in which the products must be created/delivered (i.e.
the Product Flow Diagram, see the section on Project Management Techniques).
Hints and Tips
For products that are simple and well-known by members of the project organisation, only
the product name and purpose are required to be put into the product description.
7-31
PRACTITIONER GUIDE
PRINCE PROCESSES
7.9.3 Identifying Activities and Dependencies (PL3)

Transforming a product into the activities will facilitate the PM to go down to the level
needed for control. The PM should:
for each product on the Product Flow Diagram identify the activities needed to
produce/deliver it;
check for dependencies on other products or activities in the plan and add these details;
create a diagram showing the activities and their sequence;
ensure that quality tests or checks are added; and
ensure that management products are added at the appropriate points.
7.9.4 Estimating (PL4)

Estimation of resource requirements is a prerequisite to being able to schedule the activities
and define how long the planned work will take and how much it will cost.
The PM should:
identify the skills and experience required for each activity;

estimate the number of resources and the effort required to carry out each activity;
identify any non-human resource requirements;
ensure that resources have been allocated to quality reviews and the production of
management products; and
record any assumptions made in arriving at the estimates.
Hints and Tips
Product Descriptions can help produce estimates by detailing the composition of the
products and the quality criteria to be met.
In OGCIO, a set of A/P Resources Estimation Guidelines, mainly based on the size of the
system to be developed (in term of Function Point) has been established for project teams
to follow. For details, please refer to the OGCIO Resources Estimation Guide (S&M Ref.
[G19]).
7.9.5 Scheduling (PL5)

In order to see if the targets are achievable, the activities, now with estimated duration and
resources, must be drawn out into a schedule to show when activities will begin and end. The
PM should:
add resources to each activity;
7-32
PRACTITIONER GUIDE
PRINCE PROCESSES
extend each activity to reflect the estimated effort;

produce a draft schedule based on the identified dependencies;
smooth resource utilisation to remove over and under utilisation where possible (i.e.
Resource Levelling, see the section on Project Management Techniques);
discuss the draft with the assurance personnel;
check if the draft meets target dates and costs;
discuss any problems with the PSC and obtain a resolution;
produce a final schedule and human resource estimate;
add any non-human resource costs; and
ensure that the plan contains adequate control points.
7.9.6 Analysing Risks (PL6)

Before a plan is approved, its risks should be evaluated and the plan may be modified where
possible to avoid or reduce those risks. To do this, the PM and the Project Assurance
Personnel should:
examine each activity, its time-scale and dependencies to identify any risk on it;
do the same for each resource to be used;
assess the likelihood and severity of each identified risk;
modify the plan to remove, reduce or monitor the risks; and
enter each risk into the Risk Log, together with the action taken.
All plans should be analysed on risk before it is put forward for approval. Risk log should be
documented in a project plan and placed under the Project Initiation Document. It should be
reviewed periodically, at least at each End-Stage Assessment.
7.9.7 Completing a Plan (PL7)

The complete understanding of a plan needs knowledge of the background, assumptions and
risks involved. To facilitate this, the PM should:
describe what activities the plan covers and the planned approach;
describe the quality control methods to be used;
identify any plan dependencies on items outside the project's control; and
list the assumptions, agreed tolerances and the reporting arrangements.
Hints and Tips

Tolerance margins must be agreed with the PSC as part of its control of the plan.
For small projects, it may be acceptable for the PM to present most of the items of the plan
verbally to the PSC, but assumptions and tolerances should be documented.
7-33
PRACTITIONER GUIDE
PROJECT MANAGEMENT TECHNIQUES
8.
8.1
PRODUCT-BASED PLANNING
Product-Based Planning is a planning approach of PRINCE. It approaches the planning of
projects from the viewpoint of the products required to be produced. It focuses the attention
on the goal, thereby ensuring that any activities to be undertaken in the project are the
necessary ones required for the production of the ultimate products.
By focusing on the goal rather than the means of getting there, all products required by the
project can be identified and described before development of the products commences,
ensuring that a common understanding exists between all interested parties.
There are four planning techniques associated with this Product-Based Planning approach,
namely:
Product Breakdown Structures;

Product Flow Diagrams;
Product descriptions; and
Product Transformations.
Details of these planning techniques are described in the following paragraphs.
8.1.1 Product Breakdown Structure (PBS)

A Product Breakdown Structure (PBS) identifies all products which are required to be
produced by the project. It describes the composition of products in terms of their
components, and forms a hierarchy by decomposing the product through a series of levels
down to all of its constituent parts.
The following is simple example of PBS:Computer Room
Raised Floor
Electricity
Supply System
Air Conditioning
System
Air Conditioners
Fire Extinguish
System
Chillers
8-1
PRACTITIONER GUIDE
The level of decomposition is dependent upon the level at which planning is targeted. The
more detailed the planning, the further the products are decomposed. It should be noted that
not all products need to be decomposed to the same level of detail; as this will depend on the
needs of the project and the nature of the product.
In the process of identifying products for the PBS, 3 major types of products need to be
considered. They are, namely:
Technical Products which are the component products necessary for the production
and operation of the ultimate product of the project;
Quality Products which are those required to provide assurance that the appropriate
level of quality has been built into the products;
Management Products which are those constructed to ensure (and document) the
effective management of the project.
These 3 major types of products are presented as separate groups in the Product Breakdown
Structure as shown below:Project
Products
Management
Products
Quality
Products
Technical
Products
Further break down of Technical Products is illustrated in the next page.

Note :
1. Structure Box with a Product ID is a product to be delivered in the project.
2. Structure Box without a Product ID is a product group.
8-2
PRACTITIONER GUIDE
Product Breakdown Structure

(of generic products of normal I.S. Project)
C
Technical
Products
System
Development
Products
Procurement
Products
E
T100
T200
Feasibility
Study Report
SA&D Report
Implementation
Products
D
T110
Management
Summary
T121
Current
Environment
Description
T210
Technical
Specification
T122
Project
Definition
Management
Summary
T221
Current
Environment
Description
Technical
Specification
T222
Business
Process/
Activity
Model
T223
T224
User
System
Requirements Specifications
T225
Selected
Technical
System
Option
8-3
PRACTITIONER GUIDE
8.1.2 Product Flow Diagram (PFD)

The Product Flow Diagram (PFD) takes the products identified on the Product Breakdown
Structure and identifies the logical sequence of their production, i.e. product dependencies.
This enables the identification of omission in the product set, and helps the development of
activity network in later part of the planning process.
PFD starts at the top with what is available at the start of the project and ends at the bottom
with the required business products.
An example of PFD is shown in the following page.
8-4
PRACTITIONER GUIDE
Product Flow Diagram

T121
Current Environment
Description
(FS)
Feasibility Study
T122
Project Definition
(FS)
T110/T100
Management Summary/
FS Report
(FS)
SA&D Study
T221
Current Environment
Description
(SA&D)
T222
Business Process Model /
Business Activity Model
T223
User
Requirements
T224
System
Specifications
T225
Selected Technical
System Option
T210/T200
Management Summary/
SA&D Report
(SA&D)
Implementation/
Procurement
T400
Tender
Specification
T311
Data File Description
T600
Evaluation
Report
T312
Program
Specification
T500
Evaluation
Criteria
T700
Procurement
Contract
T800
Procured
H/W & S/W
T357
Prepared
Site
8-5
PRACTITIONER GUIDE
8.1.3 Product Description (PD)

A Product Description describes the purpose, components and derivation of a product, and
lists quality criteria which apply to it as well as the methods which are to be used to measure
the product against its quality criteria.
Product Descriptions should be produced for all major products identified on the Product
Breakdown Structure.
A Product Description is expected to contain the following information:(a)
Product ID
(b)
(c)
(d)
(e)
(f)
Product Name
Purpose
Composition
Derivation
Quality Criteria
(g)
Quality Method -
(h)
CM Requirement -
A unique number, which also appears in Product Breakdown

Structure and Product Flow Diagram.
A name for the product.
A description of the function of the product.
The various component parts of the product.
The methods and sources by which this product is produced.
The criteria by which the quality of the product is to be assessed
(which should desirably be testable and measurable).
The methods to be used when assessing the product's quality,
and the points at which quality is to be assessed, e.g. testing,
walk-through, informal/formal quality review.
The timing for version control and baseline should be specified.
The format and location of the controlled copy should also be
stated.
An example of Product Description is shown in the following page.
8-6
PRACTITIONER GUIDE
Product Description Example

Product ID
T110
Product Name
Feasibility Study Management Summary
Purpose
To document the findings and recommendations of a

Feasibility Study for seeking the approval from users' and
OGCIO senior management
Composition.
Derivation
Technical Specification
Quality Criteria
Is the report based on reliable data, e.g. notes of

interviews etc.?
Is the level of details suitable for Management to read?
Is the recommendation technically sound and feasible?
Method: Informal quality review by PAT.
CM Requirement
Approval Sought;
System Objectives;
Background;
Present Situation;
Problem/Improvement Areas;
Proposed System;
Resource Implication;
Costs;
Benefits;
Cost-benefits Analysis;
Development Plan; and
Recommendation
Version control should be applied at FS phase.

Must be base-lined at the end of FS phase.
Controlled copy in software format.
8-7
PRACTITIONER GUIDE
8.1.4 Product Transformation

Product Transformations identify the activities required for the production of the identified
products, as well as the dependencies between the activities. They are the link between
product-based planning and activity based planning. By means of Product Transformations,
the information in Product Flow Diagram can be used for the production of Activity Network.
The steps in Product Transformations are:(a)
(b)
(c)
For each product on the Product Flow Diagram, list the activities required for its
construction;
In listing the activities, consider the products associated with them. This may identify
additional products which should be added to the PBS and PFD;
With the assistance of the PFD and Derivation Section of Product Descriptions,
identify the dependencies between the activities.
An example of Product Transformation is shown in the next page.
8-8
PRACTITIONER GUIDE
Product Transformation Example

Product Transformation
Product Transformation
Activity Product
Activity
Number
Number
Name
1
T121
Prepare F.S. Current Environment
Description
2
T122
Prepare F.S. Project Definition
3
T110
Produce F.S. Management Summary
4
T221
Prepare SA&D Current Environment
Description
5
T222
Prepare User Requirements
6
T223
Prepare System Specifications
7
T224
Prepare Technical System Option
8
T210
Produce SA&D Management Summary
9
T311
Conduct Physical Database Design
10
T312
Prepare Program Specifications
11
T400
Produce Tender Specification
12
T500
Draw up Evaluation Criteria
13
T600
Tender Evaluation
14
T700
Contract Negotiation
15
T357
Site Preparation
16
T800
Hardware & Software Delivery
17
T321
Programming
18
T330
System Testing
19
T341
User Acceptance Testing
20
T343
User Training
21
T351
Prepare System Manual
22
T352
Prepare Program Manual
23
T353
Prepare Data Manual
24
T354
Prepare Application Operation Manual
25
T355
Prepare Application User Manual
26
T356
Prepare Computer Operating Procedure
Manual
27
T358
Data Conversion
28
T359
System Live
Dependant
on Activities
1
1,2
1
2
2
2
4-7
8
9
8
8
11,12
13
14
14
10, 15,16
17
18
19
20
20
20
20
20
20
20
21-27
8-9
PRACTITIONER GUIDE
8.1.5 The Benefits

There are substantial benefits to be gained as a result of adopting the product-based approach
to project planning. They are summarised as follows:
Focus
Focuses the attention on the end goal rather than the means
of getting there.
Communication
Product based planning clearly communicates the

requirements of the project at all levels, from the PSC who
own the project to the Project Team who is required to
produce the products.
Product
Description
Ensures that all interested parties have the same view of the
requirements, eliminating the likelihood of products being
produced at the wrong level of detail, or in the wrong
format.
Activity
Derivation
Ensures that the activities derived are appropriate for the

particular project and based upon the required products.
Control
Enables control by means of measurable product completion.

This is especially beneficial when staff are working remotely
or external resources are involved in the product production
Interfaces
Identifies those products being produced externally to the

project and those products required by other projects. This
identifies inter-project interfaces which can then be
managed.
Impact Analysis
Identification of the impact of change on the project's

products via Product Breakdown Structure, Product Flow
Diagram and Product Description.
Quality
Product Descriptions containing the quality expectation and

the Quality Control Method help ensure the attainment of the
required quality.
Motivation
By providing clear objectives via the Product Description,

individual Project Team members will become better
motivated and, using the specified Quality Criteria, will be
able to access their own performance.
Performance
The Product Description with their specified Quality Criteria

and Method, provide a vehicle for managers in the objective
assessment of personnel performance.
8-10
PRACTITIONER GUIDE
8-11
PRACTITIONER GUIDE
Selection and
Training
Product Descriptions provide the information necessary to

identify the skill, knowledge and experience required of the
producer and can, therefore, be used as a basis for Project
Team selection and for the identification of training needs.
Improved
Estimating
Estimates can be produced based upon a detailed description

of the product to be produced including the level of the
quality required.
Hints and Tips
In OGCIO, the Product Breakdown Structure (PBS) and Product Flow Diagram (PFD)
will be regarded as the interim working documents in the planning process and are not
required to be included as a mandatory document in the Project Initiation Document (PID).
The Product Description will be the only mandatory product-based planning document to
be shown in PID. However, if a PM considers that the PBS and PFD can facilitate a better
understanding of the products of the project, he/she may include them as appendices of
the PID.
8-12
PRACTITIONER GUIDE
8.2
RESOURCE ESTIMATION
8.2.1 Objective
An estimate is an assessment of the time and resources required for the successful delivery of
a specific end-product. The objective of producing an estimate is to provide information to be
incorporated into the project and stage plans. Such information includes:(a)
(b)
(c)
(d)
Manpower required;
Cash and other resources required;
Plan duration;
Plan timetable.
An estimate is not an absolute forecast, it is a 'best guess' or 'educated guess', whose reliability
depends on the quality of information available and on the estimator's skill and experience.
To produce a good estimate, an estimator would need the following:
(a)
(b)
(c)
(d)
Knowledge of the activities to be estimated;

Knowledge of the project environment;
Information about similar projects undertaken in the past;
Estimation skill and experience.
8.2.2 Top Down Method

A top down method can be used to estimate the overall resource requirements of a project. In
OGCIO, the commonly used top-down method Function Point Analysis (FPA) is adopted. In
applying FPA, a FPA figure should first be derived based on the functions identified in the
Information System. By referencing the appropriate FPA Resource Estimation Model, the
FPA figures can then be used to derive the resource estimates for the SA&D and
Implementation of the System.
8.2.3 Bottom Up Method

In the bottom up approach, resources requirements are derived by adding up the estimates of
individual activities involved. For example, an individual activity may be the programming
of a program in a sub-system. By adding up the resources required for developing individual
programs in each sub-system, the resource required for the programming project can then be
worked out.
In the bottom up approach, the estimate is basically based on the experience of the estimator,
taken into account the size and complexity of the activity to be estimated. Information about
similar activity undertaken in the past can be used for reference.
8-13
PRACTITIONER GUIDE
8.3
ACTIVITY NETWORK ANALYSIS
8.3.1 Activity Networking

Activity Networking technique uses Network Diagram to illustrate the dependencies of
activities within a project. The diagram shows the total project duration and expected
completion date. It also shows the earliest start, earliest finish, latest start and latest finish
times of each activity.
Project Networking can help identify Critical Path, which is the path of activities that has no
spare time available. Late delivery of any one of the critical path activities will result in the
slippage of the project.
Identifying critical path enables the management to concentrate their attention and resources
on critical activities. Resources may be deployed from non-critical activities to critical ones
in order to keep a project on schedule.
8.3.2 Construction
Normally, practitioners do not need to construct Activity Network by themselves, as most
project management tools in the market can provide such function. However, practitioners
may need to understand the terminology and to appreciate the concepts behind a Network.
These are briefly described in the following paragraphs.
(a)
Basic Symbols
There are two basic symbols used in the construction of a Network. They are the
Activity Box and the Arrow.
An Activity Box contains descriptions of an activity, such as its name, duration, etc.
The Activity Boxes at the start and end of a Network are called the Start Box and
Finish Box respectively.
An arrow, emerging from one activity box and entering into another, denotes the
dependency between the two activities. A sample network is shown below :-
START
FINISH
8-14
PRACTITIONER GUIDE
(b)
Timing the Network

When the project network has been logically constructed in terms of activity
dependencies, the timings of each activity should be added.
The duration of each activity should first be determined. The following timing figures
can then be calculated:
Earliest Start Time (EST);

Earliest Finish Time (EFT);
Latest Start Time (LST);
Latest Finish Time (LFT); and
Float.
The respective timing figures are shown in a Start Box, Finish Box and Activity Box
as follows :EST
Start
LST
(c)
EFT
Finish
LEF
EST
LST
Duration
EFT
Activity Name
Float
LFT
Earliest Start and Earliest Finish Times

The Earliest Start Time (EST) is the earliest date that work on an activity can start.
The EST's of a network are calculated starting from the Start Box. EST's of the boxes
next to the Start Box are zeros.
Activity duration is added to the EST. This calculation gives the Earliest Finish Time
(EFT) of the activity.
A forward pass is made to the network. The EFT is carried forward to the next box
where it becomes the EST for that box. If two or more arrows head into the same box,
then whichever is the highest (latest) is taken to be the EST. EFT of the Finish Box
gives the total duration of a project.
Examples of EST, EFT, LST and LFT are given in para. (e).
8-15
PRACTITIONER GUIDE
(d)
Latest Start and Latest Finish Times

The Latest Finish Time (LFT) is the latest date by which an activity must be
completed if the project is to be delivered on time.
LFT's are calculated in the direction starting from the Finish Box backwards to the
Start Box. LFT of the Finish Box is assigned the value of its EFT calculated in (c)
above. LFT's of the boxes immediately before the Finish Box are the same as that of
the Finish Box.
Activity duration is subtracted from the LFT to give the Latest Start Time (LST) of
each activity.
A backward pass is made to the network. The LST is carried backward to the prior
box where it becomes the LFT for that box. If two or more arrows end into the same
box, then whichever is the lowest (earliest) is taken to be the LFT. Please note that the
process is just a reverse of the calculation of the EST and EFT.
Examples of EST and EFT are given in para. (e).
(e)
Floats
There are four different types of Float:
Negative Float;
External Float;
Total Float; and
Free Float Early.
Descriptions of each type of Float are provided in the following paragraphs.

The example in the next page helps explain the various types of Float.
8-16
PRACTITIONER GUIDE
A
14
15
19
D
14
18
18
19
22
33
14
36
14
30
22
36
20
10
30
26
36
31
36
J
14
33
ST
A
0
12
20
F
0
20
16
20
11
31
20
20
I
0
31
31
36
FIN
36
36
G
4
11
11
Legend :Earliest Start Time

Duration
Earliest Finish Time
Activity
Latest Finish Time

Float
Latest Start Time
represents the Critical path
8-17
PRACTITIONER GUIDE
(i)
Negative Float
Negative Float will occur when imposed project duration is less than the critical path.
In the quoted example, the critical path lasts for 36 weeks. If the imposed project
duration is 30 weeks, the project will have a negative float of 6 weeks. When a project
has a negative float, the critical activities have to be shortened in order to meet the
target date. Resources may need to be re-deployed from non-critical activities to
critical ones.
(ii)
External Float
External Float will occur when the allowed project duration is longer than the critical
path. For example, the critical path lasts for 36 weeks but the project is allowed to
complete in 40 weeks, then the project will have an external float of 4 weeks. It
should be noted that a project with external float still has a critical path. However,
there is some flexibility for critical activities to be extended, yet still meeting the target
date.
(iii) Total Float

Total float is the maximum spare time available for an activity. In calculating the
Total Float, all activities before the one being calculated are taken to finish as early as
possible, and those after it to start as late as possible. The Total Float of an activity
can be expressed as follows:Total Float = Latest Finish Time - Earliest Finish Time
In our example, the total float of each activity, in ascending order of the float, are as
follows:Activity
B
F
H
I
C
G
K
A
D
J
E
LFT
8
20
31
36
11
20
36
18
33
36
33
EFT
8
20
31
36
7
16
30
4
19
22
14
Total Float
0
0
0
0
4
4
6
14
14
14
19
In an activity network, there are paths that contain activities having the same Total
Float. From the preceding Total Float Table, it can be seen that there are five separate
paths of activities that have the same Total Float. The path of activities with zero
Total Floats is the Critical Path.
8-18
PRACTITIONER GUIDE
Delay of any activity in the Critical Path will extend the project duration. Delay of a
non-critical activity within the limits of available float would have no effect on the
project duration.
If any activity within a path uses up the Total Float, the path will become a
Critical Path. In the preceding example, if the actual duration for Activity A takes
18 weeks, then the path A, D, J will become another Critical Path.
Activities can be listed in ascending order of Total Float. A table showing floats in
this way automatically puts critical activities before the less critical ones (i.e. those
with more floats). This enables management to concentrate on the critical activities.
(iv) Free Float Early
Free Float Early is the amount of time by which an Activity can be delayed without
affecting subsequent activities.
In calculating the Free Float Early, all activities before the one being calculated are
taken to finish as early as possible and those after it to start as early as possible. Free
Float Early can be expressed as:Free Float Early
Earliest Start Time (Succeeding Activity) - Earliest Finish

Time
From the preceding example, the Free Float Early for each activity are calculated as
follows:Path
Activity
(next activity)
1
B
F
H
I
EST
EFT
8
20
31
36
8
20
31
36
Free Float
Early
0
0
0
0
C
G
7
20
7
16
0
4
36
30
A
D
J
4
19
36
4
19
22
0
0
14
19
14
8-19
PRACTITIONER GUIDE
It can be seen in the above table that the Free Float Early only exists in the last activity
of a path, and is equal to or less than the Total Float figure.
It should be noted that if an activity consumes additional time within the Free
Float Early figure, it will not affect the timing of other activities on the network.
8.3.3 Network Analysis

The Activity Network can be analysed with the help of the above mentioned floats.
In summary, the Total Float helps identify the Critical Path which enable the management to
focus their attention and perhaps resources on critical activities. The External Float and the
Free Float Early help identify possible areas for activities re-scheduling for levelling out
resources requirements.
8-20
PRACTITIONER GUIDE
8.4
BAR CHARTING
8.4.1 Bar Charting in general

Activity Networking is a useful way of graphically presenting the dependencies between
activities. Bar Charting is a complementary technique that helps to present the activities in
the form of a scaled timetable. A key benefit of a bar chart is its ability to quickly and simply
convey time scale related information to project planners and decision makers.
Various types of Bar Chart exist, and different tools would have different conventions and
methods in plotting Bar Charts. This sub-section aims to describe some common symbols and
convention used in Bar Charting.
8.4.2 Gantt Chart

The best known Bar Chart is the one developed by Henry L Gantt, called the Gantt Chart.
The Gantt Chart is described here for illustration purpose.
In a Gantt Chart, the vertical lines, forming columns, show the divisions of time. Horizontal
lines drawn through the columns show the relationship between the work actually done and
the work planned. The columns are headed with dates, weeks, or months. Activity
descriptions are entered into the left-hand column.
The date, on which an activity is due to start, is indicated by a right-angle opening to the right
([). The planned completion date is denoted by a right-angle opening to the left (]). A light
line joins the angles to form a rectangle.
As work progresses, a heavy line is drawn to identify the progress against the planned
duration. A 'V' is placed at the top of the appropriate column to show the date to which the
plan has been updated.
An example of a Gantt Chart is shown below:Activity
Mth 1
Mth 2
Mth 3 V Mth 4
Mth 5
A
B
C
D
8-21
PRACTITIONER GUIDE
8.4.3 Milestone and Float

Dependencies between activities can be shown by means of Milestone indicators.
In a project, there may be a point in time, that a succeeding activity can be started. The
relevant point is shown as a Milestone designated by an inverted triangle (), with the
dependent succeeding activity/ies specified against it.
A Gantt Chart is usually drawn to reflect the situation as if all activities commence at the
Earliest Start Time. Free Float Early is shown as a broken line from the final activity of each
path to the following dependent activity. For our example in sub-section 8.3, the Gantt Chart
of the project, with milestones and floats, is shown as follows:Activity
A
Mth 1
Mth 2
Mth 3
Mth 4
Mth 5
Mth 6
Mth 7
Mth 8
Mth 9
D
B
E, F
C
G
D
J
E
J
F
K, H
G
H
H
I
I
J
K
8-22
PRACTITIONER GUIDE
8.5
RESOURCE LEVELLING
Resource levelling is a technique to schedule, within the limits of the floats available, the
timing of individual activity that would best meet the overall project objectives of timescale,
resource utilisation and cost-effectiveness. The Free Float Early and Total Float in an Activity
Network provides the parameters within which individual activity can be re-scheduled to
meet these objectives.
The following diagram shows the resource requirements in the previous example in subsection 8.3. The diagram is drawn up based on the Gantt Chart in sub-section 8.4.2. It is
assumed that the same type of resource is required on each activity.
No. staff
4
Mth 1
Mth 2
Mth 3
Mth 4
Mth 5
Mth 6
Mth 7
Mth 8
Mth 9
3
2
1
If a project team of only 3 staff is assigned to the project, some activities, say, those in months
3 and 4, cannot be conducted as shown in the above chart, and that re-scheduling of activity is
needed.
Based on information in the Free Float Early Table, activities G, K, J and E can be rescheduled without affecting other activities. Based on information in the Total Float Table,
activities in the following activity paths can also be re-scheduled within their floats without
creating additional critical paths:Path
5
4
3
2
Activity
E
A, D, J
K
C, G
Total Float
19
14
6
4
(It should be noted that the above table is arranged in descending order of Total Float. Path 5
has the largest float and is the one which has the greatest flexibility for re-scheduling.)
8-23
PRACTITIONER GUIDE
Based on the above tables, the following re-scheduling can be worked out:(a)
(b)
(c)
Activity E to start at beginning of the fifth month;

Activity J to start after activity E; and
Activity K to start after activity J.
The re-scheduled resource loading diagram is presented below.

No. staff
5
4
3
2
1
Mth 1
Mth 2
Mth 3
Mth 4
Mth 5
Mth 6
Mth 7
Mth 8
Mth 9
Automatic resource levelling function is provided by most project management tools. The
following are some guidelines to eliminate a resource conflicts, if resource levelling is
required to be performed manually:
Decide on the priority for the resources, and deal with the highest ones first (usually it
is the most scarce resource);
Give the resource to the task with the least free float because it is harder to move that
task;
If the tasks have equal free float, give the resource to the longest task. That task needs
the resource for the most time, and the other tasks may be moved;
Give the resource to the task that uses the largest amount of resource;
Move the task if possible, first with the one having free float and starting early in the
network;
Set the planned start dates of tasks with free float so that they begin later, after the
conflicting task is finished;
Use a different resource if one is available;
Allow resources to work overtime if possible;
Schedule a resource to work part time on a task for a longer duration; and
Add delay (lag) to a task where a resource is scheduled to start working.
After levelling the resources, a revised technical plan has to be produced. From the revised
technical plan, a resource plan can be compiled.
8-24
PRACTITIONER GUIDE
8.6
QUALITY CONTROL
Quality is a key element that needs to be monitored and controlled in a project. Quality
control process helps ensure that the completed products are up to the required quality
expectation.
It helps detect errors and omissions at the early stage, thereby
avoiding/minimising the time and effort that may otherwise be required to correct the faults at
the latter part of the project.
Quality Control may be in various forms. It may be a formal Quality Review, or in a less
formal form an inspection of program source code or a system design walk-through.
8.6.1 Quality Review

Quality Review is a formal process by which a product is assured to have achieved the
required quality standards. Quality Review has to be applied to every major product of a
project and has to be scheduled in Project Plan or Stage Plans. Details of a formal Quality
Review are described below.
a
The Quality Review Process

A quality review involves a chairperson, a presenter and reviewer(s).
normally has three distinct phases :
A review
Preparation;
The Review;
Follow-up.
During the Preparation phase, the PM selects a review team and fixes the time and
place for the review. He/she then distributes the product to be reviewed and the
associated checking criteria. The checking criteria may include:
Specification of the product;

Quality Criteria in the Product Description;
Departmental Standards, such as those on documentation, design, coding, testing,
etc.; and
any specific standards/criteria which have previously been agreed with the user
(e.g. screen/report layout, naming conventions, etc.)
8-25
PRACTITIONER GUIDE
The reviewers will check the product against the criteria and record relevant
comments they have on a Comment Form (see PRINCE Product Description
section).
At the Review, comments recorded in the Comment Form are discussed. Changes or
corrections agreed to be made are recorded in a Follow-up List (see PRINCE Product
Description section).
In the Follow-up phase, the product producer effects the changes according to the
Follow-up List. After the changes, the producer passes the revised product and the
Follow-up List to the reviewer(s) for their sign-off. The review process is complete
after all the follow-up actions are signed-off.
b.
Participants in a Quality Review

The main duties of the Chairperson are to:
ensure that the review process is properly organised;

chair the review;
ensure that the direction of the review does not stray from the main purpose to
detect deviations from the pre-set standards or criteria;
raise comments noted by absent reviewers;
agree with the reviewers the responsibilities for signing off the action noted.
The main duties of the Reviewers are to:
check the review product for completeness and correctness by referencing to the
checking criteria;
record any relevant comments on a Comment Form during review preparation;
forward the Comment Form to the presenter prior to the review meeting;
confirm with the presenter the resolution of problems noted at the review in
review follow-up.
The main duties of the Producers are to:
ensure that the reviewers have the information required to perform the review in
review preparation;
distribute the product and review invitation with sufficient time;
walk through the Comment Form and the recommended actions (corrected/to be
corrected/not to be corrected with reasons) during review;
follow-up the action list;
obtain acceptance from the reviewer after the follow-up.
8-26
PRACTITIONER GUIDE
8.6.2 Informal Review

Sometimes a PM may conduct an informal review instead of a formal Quality Review. An
informal review is usually applied to less important products in a project. An informal review
may not necessarily be in the form of a formal meeting.
In an informal review, the reviewer reviews the product sent in from the producer. The
reviewer records their comments on the Comment Form and send it to the producer. The
producer enhances or corrects the products according to the list, and sends the revised
products to the reviewer where necessary. The review is complete after all follow-up actions
have been completed.
8.7
QUALITY ASSURANCE
Quality Assurance (QA) Review is a process to ensure that proper quality control on the
products has been done in accordance with the project quality plan. It is usually conducted at
the QA checkpoints, i.e. the end of FS / SA&D / Physical Design and pre-production.
8.7.1 Quality Assurance Review Process

A QA Review Process typically comprises three stages:
Preparation;
Evaluation; and
Consolidation.
Please refer to Quality Assurance Review Procedure (S&M Ref. [Q3]) for details.
8.7.2 Participants in QA Review

The participants in a QA Review may include the PM, the Reviewer and the Technical
Support Team. The PM is responsible for arranging the review. The Reviewer shall conduct
the review.
Please refer to Quality Assurance Review Procedure (S&M Ref. [Q3]) for details of their
responsibilities.
8-27
PRACTITIONER GUIDE
9.
APPLICATION OF PRINCE IN OGCIO
9.1
AREA OF APPLICATION
PRINCE is a generic project management method that can be applied to projects of any
nature. In OGCIO environment, all projects covering one or more SDLC phases (i.e. FS,
SA&D, Implementation) should adopt PRINCE for project management.
9.2
CUSTOMIZATION
PRINCE has been customised to fit the OGCIO environment. OGCIOs internal
customisation are given in Underline in various sections of this guide.
9.3
SMALL PROJECTS
PRINCE is a scaleable methodology that suits projects of different sizes. In the OGCIO
environment, guidelines on using PRINCE in Small Projects are given. These guidelines
are presented in Italics in various sections as appropriate.
The cost of project is usually the determining factor for the degree of using PRINCE. A
large project that involves substantial manpower and money investment may justify more
project management control than in a small project. In OGCIO, the classification of a
small PRINCE project is in line with the ACPCs classification of Small Project by
project cost.
Taking into account other factors such as the project duration and risk level, a small
PRINCE project is usually referred to one that is of low cost, short duration, low impact
and low risk.
Under the above criteria, FS will usually be classified as Small Project. SA&D and
Implementation projects may be Large or Small Project depending on the project costs.
9-1
PRACTITIONER GUIDE
9.4
SDLC PROJECTS
"SDLC Projects" refer to projects conducted within the OGCIO System Development
Life Cycle. Examples of SDLC projects include SA&D and System Implementation
projects. The following table presents the activities in FS, SA&D and Implementation
phases of the SDLC. SSADM and RAD Stages are also shown in the table for reference.
SDLC
Phase
Feasibility
Study
SDLC
Step
Feasibility
Study
SSADM
Stage
(0a) Problem Definition
(0b) Project Identification
RAD
Stage
Requirement
Planning
System
Analysis &
Design
System Analysis
(1)
(2a)
(2b)
(3)
(4)
User Design
Logical Design
Implementation
Physical
Design
Program
Development
System Tests
& Integration
User Acceptance
System Installn &
Production
Investigation of current environment

Selection of Business System Option
Requirement Specification
Selection of technical option
Logical design
(5) 1st-cut Physical Design

(6) Physical Design Optimisation
Rapid
Construction
and Transition
In general, a SDLC project can be divided into project stages that correspond to the SDLC
steps. For example, a SA&D project can be divided into a System Analysis stage and a
Logical Design stage.
In dividing stages of a project, the SDLC steps should be taken as reference only. Other
factors such as, the duration of the stage; the technology or staff involved in the stage, and
the associated risks should also be considered. (See PRINCE Components section.)
Sometimes, 2 or more SDLC steps may be combined to form 1 project stage. An example
would be the combination of the User Acceptance step and System Installation step in
small projects. In other occasions, a SDLC step may be divided into a number of project
stages. An example would be the splitting of the System Analysis step into, say, a
Requirement Specification Stage and a Technical Option Selection Stage in large projects.
Products produced in SDLC project are similar in one to another. A list of products for
SDLC projects have been identified in the Repertoire of Product Description.
9-2
PRACTITIONER GUIDE
9.5
CONTRACTING-OUT PROJECTS
9.5.1 Introduction
This is the engagement of a contractor to provide IT services to the user on behalf of
OGCIO. In this type of projects, the contractor should follow the procedures, standards
and methods as agreed with the users such that the project products can be delivered
within the pre-defined cost, time and quality level.
For those projects also adopting PRINCE as the management method, some additional
guidelines are provided in this section.
9.5.2 Organisation
It is preferred to have the PSC established before the selection of the contractor. The PSC
would have the responsibility of selecting the contractor and to ensure that the contractor
fulfils its contractual commitments.
The PSC members should come from user and OGCIO, if applicable. If OGCIO staff is
involved, they will usually assume the Senior Technical role in the PSC and the contractor,
if required to attend PSC meetings, they should be in attendance only.
Project Manager
Services from the contractor may cover all project stages from project initiation to closure
or they may cover some stages. For cases where the contractor takes up all parts of the
project or is required explicitly to play the PM role in the project, the PM of the project
should be taken up by the contractor. Otherwise, staff from the user department or
OGCIO will act as the PM. The contractor should only take the Team Manager role for
the work they are contracted to deliver, and should be under the control of the PM. In this
connection, the user/OGCIO PM would participate in the user and contractor interface for
the purpose of overall project management.
Project Assurance
Appointed personnel of the contractor who are not in the project team can be delegated
the role of Project Assurance by the PSC. However for project that requires high level of
assurance (i.e. high risk), the PSC or its delegates should take up the project assurance.
9.5.3 Planning
9-3
PRACTITIONER GUIDE
The contractor should work out the project technical plan and resource plan with the
responsible staff and ensure that non-SDLC activities such as funding approval be
accounted for and resources for those activities be budgeted. OGCIO monitoring effort, if
applicable, should also be planned. In general, guidelines and procedures of project
planning applicable to an in-house project should be followed.
9.5.4 Control
The responsible staff should assure the PID be prepared in accordance with the
specification of assignment, especially on aspects such as the scope of the project, the
business case, the products to be delivered and their levels of details. Thereafter, the PID
should be agreed and followed thoroughly by the contractor.
Tolerance
Cost tolerances would not be applicable for fixed-priced Contracting-Out projects.
Work Package
For cases where the contractor takes up part of the project, Works should be packaged as
Work Package and assigned to the contractor with time, cost and quality criteria and
specification on the works to be done. For cases where the contractor takes up the whole
project, the contract is already a Work Package.
In both cases, acceptance of the completed works should be documented (either in
any formal paper, memo or the accepted Work Package).
Change Control Process

A change control process should be defined in the contract such that changes, e.g.
changes on scope of services, arisen during the project can be handled properly by user
and/or OGCIO and contractor. An example would be the Project Log, which is a change
control mechanism introduced in PRINCE.
9.5.5 Quality
Quality of any product should always be controlled by the PM, and reviewed by the
person(s) responsible for Project Assurance before it is accepted by the PSC. The review
would be based on the quality criteria committed by the Contractors in the Work
Packages, contracts and/or Government or Contractors standards.
9-4
PRACTITIONER GUIDE
9.6 OUTSOURCING PROJECTS INCLUDING INFORMATION

TECHNOLOGY PROFESSIONAL SERVICES ARRANGEMENT (ITPSA)
9.6.1 Introduction
Under the Outsourcing scenario, the Outsourcing contractor (i.e. the outsourcer) can have
the freedom of adopting its own project management methodology which has been
assessed and pre-qualified by the Government. The project management methodology
adopted by the outsourcer may not be PRINCE. However, if PRINCE is adopted, the
following section may be applied and referenced.
9.6.2 Organisation
The outsourcer will take up the Senior Technical role in PSC. OGCIO responsible staff, if
required, may take up the role of IT Advisor. The IT Advisor can sit in any PSC meeting
to provide technical advice on a need basis. However, since it is not a formal member in
the PRINCE project organisation, roles and responsibilities of IT Advisor should be
clearly defined and documented in the PID.
Project Manager
Either the user or the outsourcer will act as the PM. OGCIO responsible staff will not take
up the PM role. If user has taken up the PM role, the outsourcer may take the Team
Manager role for the work they are responsible to deliver, and should be under the control
of the PM.
Project Assurance
An independent person or group of staff, probably from the user, may be assigned for
assuring the quality of major deliverables during the project or at the end of each stage.
Project assurance on the quality of project deliverables is particular important in these
projects where the outsourcer is giving the freedom to perform quality control on project
deliverables in its own way.
9.6.3 Planning
The PM should identify the works to be undertaken by the outsourcer and group them into
Work Packages.
9-5
PRACTITIONER GUIDE
9.6.4 Control
Tolerance
Cost tolerance would not be applicable for fixed-price projects.
Work Package
The PM may use a Work Package to formally pass the responsibility for work delivery to
the outsourcers. A Work Package forms a written 'contract' between the PM and the
outsourcer who receives it.
There should be space on the Work Package to record acceptance of the return of the
completed Work Package. This may be further enhanced to include an assessment of the
work and go towards performance appraisal.
Control Meetings
Checkpoint Reviews should be held periodically to control the progress and to deal with
matters relating to the delivery of products or status of the Work Packages. PM will keep
the PSC informed of the project status by submitting to them Highlights reports
periodically. End-stage assessments (ESA) should be held with PSC to review the project
on the aggregate level on production status, next stage plan/resources plan and review on
the business case and project risk.
9.6.5 Quality
During the project, quality review on project products should be done by the outsourcer
based on the quality criteria stated in the Work Packages, Contract, Project Initiation
Document and/or Government or outsourcers standards.
9-6
PRACTITIONER GUIDE ON
PROJECT MANAGEMENT
10.
A.
APPENDIX A ROLES OF
MEMBERS IN PROJECT
ORGANISATION
APPENDIX A - ROLES OF MEMBERS IN PROJECT

ORGANISATION3
Members in Project Steering Committee
a.
Executive
The specific responsibilities of the Executive are to: oversee the development of the Project Brief and Business Case
ensure that there is a coherent project organization structure and logical
set of plans
ensure that a tolerance is set for the project
seek approval on Customer expenditure and set stage tolerance
monitor and control the progress of the project at a strategic level, in
particular reviewing the Business Case continually (e.g. at each end stage
assessment)
ensure that risks are being tracked and mitigated as effectively as
possible
approve the Project Evaluation Report and ensure that any outstanding
issues are documented and passed on to the appropriate body
brief User management or OGCIO about project progress
organise and chair PSC meetings
recommend future action on the project to User management or OGCIO
if the project tolerance is exceeded
approve the sending of the notification of project closure to User
management or OGCIO.
The Executive is also responsible for business assurance on:
validation and monitoring of the Business Case against external events and
against project progress
keeping the project in line with User or OGCIO strategies
monitoring project finance and any Supplier and contractor payments
monitoring the business risks to ensure that these are kept under control
monitoring changes to the Project Plan to see if there is any impact on the
needs of the business or the project Business Case
assessing the impact of potential changes on the Business Case and Project
Plan
constraining User and Supplier excesses
informing the project of any changes caused by external events
monitoring stage and project progress against the agreed tolerances.
b.
Senior User
The specific responsibilities of the Senior User is to:
Additional roles on Project Support may also be defined. The provision of project support is driven by the
needs of the individual project and PM. They may cover user liaison / co-ordination, technical support,
standard and methodology support, tool support and project administration.
10-1
PROJECT MANAGEMENT
APPENDIX A ROLES OF
MEMBERS IN PROJECT
ORGANISATION
ensure the desired outcome of the project is correctly and completely specified
make sure that progress towards the outcome required by the users remains
consistent with the specified requirement
promote and maintain focus on the desired project outcome from the point-ofview of the end users
ensure that any user resources required for the project are made available
approve Product Descriptions for those products that act as inputs or outputs
(interim or final) from the supplier function or will affect them directly
ensure that the products are signed off once completed
prioritise and contribute user opinions on PSC decisions on whether to
implement recommendations on proposed changes
resolve any conflicts in user requirements and priorities
provide the user view on Follow-on Action Recommendations
brief and advise user management on all matters concerning the project.
The assurance responsibilities of the Senior User are to confirm that:

specification of the user's needs is accurate, complete and unambiguous
development of the solution at all stages will continue to meet the user's needs
and is progressing towards that target
impact of potential changes is evaluated from the user point of view
risks to the users are constantly monitored
quality checking of the product at all stages has the appropriate user
representation
quality control procedures are used correctly to ensure products meet user
requirements
user liaison is functioning effectively.
c.
Senior Technical
The specific responsibilities of the Senior Technical is to:
make sure that progress towards the outcome remains consistent from the
supplier perspective
promote and maintain focus on the desired project outcome from the point of
view of supplier management
ensure that the supplier resources required for the project are made available
approve Product Descriptions for products on behalf of the supplier
contribute supplier opinions on PSC decisions on whether to implement
recommendations on proposed changes
resolve supplier requirements and priority conflicts
arbitrate on, and ensure resolution of, any supplier resource or priority
conflicts
brief non-technical management on supplier aspects of the project.
The Senior Technical is responsible for the technical integrity of the project. The
technical assurance role responsibilities are to:
advise on the selection of technical strategy, design and methods
ensure that any technical standards defined for the project are met and used to
good effect
monitor potential changes and their impact on the correctness, completeness
10-2
PROJECT MANAGEMENT
APPENDIX A ROLES OF
MEMBERS IN PROJECT
ORGANISATION
and integrity of products against their Product Description from a technical

perspective
monitor any risks in the technical and production aspects of the project
ensure quality control procedures are used correctly so that products adhere to
technical requirements.
10-3
PROJECT MANAGEMENT
B.
APPENDIX A ROLES OF
MEMBERS IN PROJECT
ORGANISATION
Members in Project Team

a.
Project Manager
The specific responsibilities of the PM is to:
manage the development and delivery of the required products
manage the project team, plan and monitor the project and project risks
work with any project assurance roles appointed by the PSC
produce PID and prepare any required plans in conjunction, where appropriate,
with TMs, and the Project Assurance personnel, and agree them with the PSC
liaise with User management or OGCIO or any related projects to ensure that
required products are neither overlooked nor duplicated
monitor overall progress and use of resources, and initiate corrective action,
where necessary, within the tolerance limits defined by the PSC
implement change control and any required Configuration Management
procedures
report to the PSC in the manner and at the frequency defined in the PID
liaise with the PSC or its appointed Project Assurance personnel to assure the
overall direction and integrity of the project
agree technical and quality strategy with appropriate members of the PSC
compile a report on any lessons learned about the project management and
technical methods and tools used
prepare the Project Evaluation Report and Follow-on Action
Recommendations
ask the PSC for any support and advice required for the management, planning
and control of the project
liaise with any sub-contractors.
b.
Team Manager
The specific responsibilities of the TM is to:
receive authorisation from the PM to create products (via a Work Package)
prepare plans for the team's work and agree these with the PM
manage the team
take responsibility for the progress of the team's work and use of team
resources, and initiate corrective action where necessary within the constraints
laid down by the PM
advise the PM of any deviations from plan, recommend corrective action, and
help prepare any appropriate Exception Plans
pass products which have been completed and approved in line with the agreed
Work Package back to the PM
ensure that any Project Issues arising from the Work Package are properly
reported to the person maintaining the Issue Log
ensure the evaluation of Project Issues which arise within the team's work and
recommend action to the PM
liaise with any Project Assurance personnel
attend any stage assessments as required by the PM
arrange and attend Checkpoint Reviews
10-4
PROJECT MANAGEMENT
c.
APPENDIX A ROLES OF
MEMBERS IN PROJECT
ORGANISATION
ensure that the quality of the team's work is planned and controlled correctly
ensure the maintenance of records of the team's work
identify and advise the PM of any risks associated with a Work Package
manage specific risks as directed by the PM.
Team Member
The main tasks of the Team Member in typical project include:
assist the PM or TM in preparation of plans;
develop the products of the project;
participate in Checkpoint Reviews;
advise the PM or TM on deviation from plans;
evaluate and implement changes for Technical Exceptions;
C.
Project Assurance
Project assurance function stands for the need in project organisation for an independent
monitoring of all aspects of the projects performance and product. It may be performed
by the PSC members themselves or they may delegate some or all of their assurance
responsibilities (see Part A) to others who have more time or more appropriate skills.
10-5
PROJECT MANAGEMENT
11.
APPENDIX B TERMS OF
REFERENCE OF PROJECT
STEERING COMMITTEE
APPENDIX B - TERMS OF REFERENCE OF PROJECT STEERING

COMMITTEE
The PSC has the following responsibilities. The list may be tailored according specific
project needs.
At the beginning of the project:
assurance that the PID complies with relevant OGCIO/user standards and policies,
plus any associated contract with the Supplier
agreement with the PM on that persons responsibilities and objectives
confirmation with user management and OGCIO of project tolerances
specification of external constraints on the project such as quality assurance
approval of an accurate and satisfactory PID
delegation of any project assurance roles
commitment of project resources required by the next Stage Plan
As the project progresses:
provision of overall guidance and direction to the project, ensuring it remains within
any specified constraints
review of each completed stage and approval of progress to the next
review and approval of Stage Plans and any Exception Report
ownership of one or more of the identified project risks as allocated at plan approval
time, i.e. the responsibility to monitor the risk and advise the PM of any change in its
status and to take action, if appropriate, to ameliorate the risk
approval of changes
compliance with User management or OGCIO directives.
At the end of the project:
assurance that all products have been delivered satisfactorily
assurance that all Acceptance Criteria have been met
approval of the Project Evaluation Report and the passage of this to the
appropriate party to ensure action
decisions on the recommendations for follow-on actions and the passage of these
to the appropriate authorities
arrangements, where appropriate, for a Post Implementation Review
project closure notification to User management or OGCIO.
11-1
PROJECT MANAGEMENT
12.
APPENDIX C SAMPE
PROJECT ASSURANCE ROLES
SET-UP
APPENDIX C - SAMPLE PROJECT ASSURANCE ROLES SET-UP
With reference to section 6.2.3 - Project Assurance, OGCIO project team may suggest, yet at the
discretion of PSC, three roles to look after the quality assurance work on the business, user and
technical interests. The three roles respectively are Business Assurance Coordinator (BAC), User
Assurance Coordinator (UAC) and Technical Assurance Coordinator (TAC).
The following depicts a possible project organisation and suggests terms of references of the
respective roles.
A.
SAMPLE ORGANISATION OF PROJECT ASSURANCE

Project Steering Committee (PSC)
Executive
Senior
User
Project Assurance
Business
Assurance
Coordinator
User
Assurance
Coordinator
Technical
Assurance
Coordinator
Senior
Technical
Project
Manager (PM)
Team Manager
(TM)
Delegation of the Project Assurance work
B.
SAMPLE ROLES OF PROJECT ASSURANCE
1.
Business Assurance Coordinator (BAC)

The main tasks of the Business Assurance Coordinator are to :
match actual against planned figures in technical and resource plans;
monitor progress and costs against the projects Business Case;
co-ordinate quality control activities;
co-ordinate technical exception activities;
attend Checkpoint Reviews;
attend and minute Stage Assessment Meetings; and
contribute to the project evaluation review.
2.
User Assurance Coordinator (UAC)

The main tasks of the User Assurance Coordinator (UAC) are to :
monitor and report to the Senior User and user related problems that arise during the
project;
ensure that the users requirements are properly specified, and are well understood and
agreed by the project team;
12-1
PROJECT MANAGEMENT
3.
APPENDIX C SAMPE
PROJECT ASSURANCE ROLES
SET-UP
ensure that the project plans include all products required by the users;
ensure that the quality criteria of the user related products are properly established and
to attend relevant quality review;
attend Checkpoint Reviews (where necessary);
attend Stage Assessment Meetings;
assist with analysis of the impact of technical exceptions on user related areas;
ensure that the impact of all request for change is understood and accepted by users;
and
Technical Assurance Coordinator (TAC)

The main tasks of the Technical Assurance Coordinator are to :
select the appropriate technical strategy and methods for the project;
advise on the application of departmental technical standards;
advise on the quality criteria and attendees for reviews of technical products;
monitor technical progress against the plan and inform the Project Manager of any
major deviations;
attend Checkpoint Reviews;
attend quality reviews (where necessary);
ensure proper assessment of all technical exceptions;
monitor all technical exceptions;
advise on the technical impact of changes to the project;
assist the Project Manager to propose recovery actions in Exception Report;
ensure changes to project do not affect system integrity; and
12-2
PROJECT MANAGEMENT
13.
APPENDIX D PRINCE
PRODUCT DESCRIPTION
APPENDIX D - PRINCE PRODUCT DESCRIPTION

PRINCE products fall under 3 categories: Management Products, Quality Products and
Technical Products. The following shows the Product Breakdown Structure and Product
Description of the management and quality products.
(of generic products of a normal I.S. Project)
Note :
1. Structure Box with a Product ID is a product to be delivered in the project.
2. Structure Box without a Product ID is a product group.
Project
Products
Management
Products
A
Quality
Products
B
Technical
Products
C
13-1
PROJECT MANAGEMENT
APPENDIX D PRINCE
PRODUCT DESCRIPTION

A
Management
Products
M100
Project
Initiation
Document
M300
Minutes of
Steering
Committee
Meetings
M400
Minutes of
Checkpoint
Review
Meetings
M220
Stage
Plans
M600
Project
Evaluation
Report
M800
Work
Package
Authorisation
M700
Risk
Log
Plans &
Exception
Reports
M210
Project
Plan
M500
Highlight
Reports
M230
Exception
Report
13-2
PROJECT MANAGEMENT
APPENDIX D PRINCE
PRODUCT DESCRIPTION

Quality
Products
Q100
Product
Descriptions
Q200
Quality Review
Invitation
Quality
Review
Results
Q310
Quality Review
Comment Form
Q400
Issue
Log
Q500
Product
Checklist
Q320
Quality Review
Follow-up List
13-3
PROJECT MANAGEMENT
APPENDIX D PRINCE
PRODUCT DESCRIPTION
Index of Product Descriptions

Product ID
M100
M110
M210
M220
M230
M300
M400
M500
M600
M700
M800
Q310
Q320
Q400
Q500
Product Name
Business Case
Project Plan
Stage Plan
Exception Report
Minutes/Notes of End-Stage Assessment / Exception Assessment
Minutes/Notes of Checkpoint Review
Highlight Reports
Risk Log
Work Package Authorisation
Quality Review Comment Form
Quality Review Follow-up List
Issue Log
Product Checklist
13-4
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M100
Product Name Project Initiation Document (PID)

Purpose
To bring together the information needed to start the project, and to convey that
information to the project team.
Composition
1. Introduction
2. Project Definition
Project Brief - A statement of the project terms of reference (TOR) and defining:
project objectives and
major products.
Project Boundary - Defined by the Project Steering Committee detailing:
functional boundary, describing significant functions to be contained within;
this ties into 'major products'
relationships and areas of common interest with other projects
3. Business Case (see M110)
4. Organisation - Names and responsibilities of key personnel:
PSC
PM and any TM
Project Assurance delegates, if any
5. Project Plan (see M210)
6. Stage Plan (for next stage, see M220)
7. Project Control:
End-Stage Assessment (see M300)
Highlight reports (see M500)
Checkpoint Review (see M400)
Product Checklist (see Q500)
Tolerance
Change control (see Q400)
Work Package Authorisation (see M900)
Reference
1. OGCIO Practitioner Guide on Project Management [G38]
2. Software Configuration Management Process guide for Application Software [G46]
Derivation
1. Based on management information input to the project, will depend on the IS
Strategic Planning products and tactical planning for the organisation.
Quality Criteria:
1. Are all components present?
2. Have individuals been assigned for all the required roles?
3. Have the individuals identified agreed to act and to commit the time as scheduled?
4. Have dates been set for all control meetings and reports?
5. Have measures been proposed for all the risks identified?
6. Has the project plans been reviewed and agreed?
Method: Informal review with Senior Technical and Senior User (or perhaps Executive)
before submission to the PSC for approval.
CM Requirement:
1. The PID itself must be base-lined at the end of Project Initiation; however, dynamic
products like technical plan and stage plan are subject to changes and corresponding
CM requirements are stated in the respective product descriptions
2. Controlled copy in software form
13-5
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M110
Product Name Business Case

Purpose
To document the justification for the undertaking of a project based on the estimated cost
of development and the anticipated business benefits to be gained. The Business Case
is used to say why the forecast effort and time will be worth the expenditure. The ongoing viability of the project will be monitored by the PSC against the Business Case.
Composition
1.
2.
3.
4.
Reasons
Benefits
Cost and timescale
Investment Appraisal, if any
Derivation
1. Different aspect of a project (scope, nature, output, etc),
2. Project Plan
3. The Users
The existence of a provisional Business Case is checked during Starting Up a Project
(SU). If one is missing, it will be created. The Business Case is finalised during Initiating
a Project (IP).
Quality Criteria:
1. Can the benefits be justified?
2. Do the cost and timescale match those in the Project Plan?
3. Are the reasons for the project consistent with User management's or OGCIO's
strategy?
Method: Informal Quality Review with the Executive and his/her delegate for project
assurance.
13-6
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M210
Product Name Project Plan

Purpose
To provide a high level plan of how the project objectives are to be achieved against
which the project progress will be measured.
Composition
1. Plan Description
2. Planning Assumptions
3. Project Dependencies
4. Risk Log
5. Quality Plan
6. Project Technical Plans
Brief Description
Bar Chart
Activity Network, if any
1. Project Resource Plan
Brief Description
Table of Resources
Requirement
2. Configuration Management
Plan
Narrative part of the plan. Items covered in this part include

Stage Breakdown of the project, and descriptions of the
Major Products to be produced from the project.
Documents the technical and management assumptions
made in compiling the plan. Assumptions are something
uncertain but very likely to happen. Each assumption should
be supported by both why it has to be made and upon what
basis.
States the external dependencies of the project. In general,
external dependencies include the information, resources
and products outside the control of the project. External
dependencies may be on the availability of equipment, the
development state of another project, or a decision of an
external organisation. Risk analysis should also be done for
each dependency.
Documents the identified project risks and the measures to
counter or avoid them.
Outlines the standards, methodologies and procedures
which are to be applied in the project.
Used to show the project activities, parties involved, the
timescale and the products to be produced. Besides bar
charting, it should also be presented in the form of an
Activity Network.
The Network is used to show the
dependencies between activities as well as the Critical Path
of the project.
Used to show the types and amount of resources required
in a project. It is presented in a Table form where the
resources requirements are shown by resource type per
respective stage of the project.
Documents the CM activities, reporting and controlling
mechanism to be conducted in the project.
Annex
Product Descriptions
Product Breakdown Structure, if any
Product Flow Diagram, if any
Reference
Derivation
1. Confirmed Project information (quality, risks, project definition etc.)
2. Business Case
3. Input from PSC
13-7
PROJECT MANAGEMENT
APPENDIX D PRINCE
PRODUCT DESCRIPTION
Quality Criteria:
1. Are all required products present?
2. Does the overall plan clearly portray a realistic and achievable way of meeting the
project objectives?
3. Is the overall plan produced at a consistent level across all the required products?
4. Is the overall level of the plan consistent with the project priority and the overall
importance of the project to the organisation?
5. Is the plan consistent across all its component parts?
assurance.
CM Requirement:
1. Must be base-lined at end of Project Initiation stage and version control should be
applied throughout the project
13-8
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M220
Product Name Stage Plan

Purpose
To provide a detailed activity plan of a stage
Composition
1. Brief Description
2. Bar Chart
3. Activity Network, if any
Reference
Derivation
1. Confirmed Project Plan
2. Work in Earlier Stages
Quality Criteria:
1. Are all required products present?
2. Does the overall plan clearly portray a realistic and achievable way of meeting the
stage objectives?
3. Is the overall plan produced at a consistent level across all required products?
4. Is the plan in a sufficient level of detail in order for PM to control the project on a dayto-day basis?
assurance.
CM Requirement:
1. Version Control should be applied throughout every stage and to be base-lined once
confirmed.
2. Controlled copy in Software format.
13-9
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M230
Product Name Exception Report

Purpose
It is produced when costs and/or timescales for an approved Stage Plan are forecast to
exceed the tolerance levels set. It is sent by the Project Manager in order to appraise the
PSC of the adverse situation.
An Exception Report will normally result in the PSC asking the Project Manager to
produce an Exception Plan (a revised stage plan, see M220).
Composition
a description of the cause of the deviation from the Stage Plan

consequences of the deviation
the available options
the effect of each option on the Business Case, risks and stage tolerances
the Project Managers recommendations.
Reference
Derivation
1.
2.
3.
4.
5.
Project Plan
Updated Stage Plan
Issue Log
Risk Log
Minutes/Notes of Checkpoint Review
Quality Criteria:
1. Are all components present?
2. Does the recommended option clearly portray a realistic and achievable way of
meeting the exception?
3. Has the effect of each option been analysed?
Method: Informal Quality Review by project assurance personnel.
CM Requirement:
1. Must be base-lined once confirmed.
2. Controlled copy in software form.
13-10
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M300
Product Name Minutes/Notes of End-Stage Assessment / Exception Assessment

Purpose
To provide an accurate record of decisions at PSC Meetings/Reviews.
Composition
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Derivation
Current Stage Plan with all the Actuals

Updated Project Plan (see M210)
Business Case review
Risk Log review
Issue Log review
Actual or Potential Problems/Obstacles and Suggested Solution
Next Stage Plan (see M220)
Decision for next stage (to proceed, terminate or others)
Commitment to resources of next stage
Appointment of Project Assurance
Notes of Meeting
Quality Criteria:
1. Are the documents accurate and agreed by the PSC members?
CM Requirement:
13-11
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M400
Product Name Minutes/Notes of Checkpoint Review

Purpose
To provide a summary of project progress at periodic intervals.
Composition
1. Follow-up from Previous Reports
2. Project Progress
Completed Products since Previous Meeting
Uncompleted Products and Revised Estimated Dates of Completion
3. Actual or Potential Problems/Obstacles and Suggested Solution
4. Quality review carried out during the period
5. Changes to Plan and Implication
6. Products/Works to be completed during the next period
Derivation
1. Verbal reports from team members
2. Previous minutes/notes of Checkpoint Review
3. Analysis of Actual Figures (information from Product Checklist, Time-sheet etc.)
against Stage Plan
Quality Criteria:
1. Are all component present?
2. Does the document give a clear picture of the situation?
3. Does the document give a clear warning of potential problems?
Method: Informal Quality Review by Project Manager
CM Requirement:
13-12
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M500
Product Name Highlight Report

Purpose
To provide the PSC with a brief summary of Project Progress at periodic intervals.
Quality Criteria:
1. Are all the components present?
2. Does the report give a clear picture of the situation?
CM Requirement:
Sample Layout
Project :
Stage
:
Project Time
Expenditure
1.
:
:
Highlight Report
Reporting Period :
Page
of
Ahead
wks
On Schedule
Underspent
%
On Budget
Behind
Overspent
wks
%
Product Status
(a) Started Earlier As planned Later

(b) Finished Earlier As planned Later
(c) Planned to Finish, but Not Finished
(d) Planned to Start, but Not Started
2.
Project Highlights
(This section reports the progress of project in the narrative form. Major achievements or failures
should be highlighted in this section for the attention of the Project Steering Committee.)
3.
Problems
(This Section reports the major problems that were encountered during the period and how they
were/are to be tackled. Potential problems should also be indicated in this section.)
4.
Outlook for Next Period

(This section describes the activities to be conducted and the major products to be
produced in the next reporting period.)
Date :
Prepared by :
(
13-13
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M600
Product Name Project Evaluation Report

Purpose
To provide an assessment of the effectiveness of the management procedures used in

the project, to ensure that experience gained on the project is documented and used to
improve procedures in future projects.
Composition
1. System Functionality
2. System Performance
3. Project Achievement
4. Resource Utilisation
5.
6.
7.
8.
Productivity
Project Issue
Quality Review
Development
9. Project Management
10. Problems Encountered
11. Others
A brief description of functionality delivered as compared with that required

by users.
A brief description of the performance level of certain functionality, if any,
as compared with that specified by users.
A comparison of the project's achievements with the objectives set out in
the PID.
A comparison of the actual expenditure and resources usage with the
planned figures.
An assessment of the productivity achieved.
Final statistics on project issues and their impact.
Statistics for all quality work carried out.
Issues encountered or comments on the development methods and any
special techniques applied.
Issues encountered or recommendations for future enhancement or
modification of the project management method.
Problems encountered during project and actions taken to solve them or
recommendations for future projects.
Any other materials that will be of value to the PSC.
Annex
Final Project Technical Plan with actual out-turn
Final Project Resource Plan with actual utilisation
Reference
Derivation
1.
2.
3.
4.
5.
6.
Timing
Updated Project and Stage Plans

Issue Log
Product Checklist
Observation and experience of the processes
Completed Work Packages
The report may be updated at the end of each stage as part of Reporting Stage End (SB5)
and is completed in Evaluating a Project (CP3).
Quality Criteria:
1. Does the report describe the impact of the approved changes on the Project Initiation
Document?
2. Does the report cover all the benefits which can be assessed at this time?
3. Does the quality work done during the project meet the quality expectations of the
Customer?
4. Has every management control been examined?
CM Requirement:
1. Must be base-lined at the end of Project Closure Stage
13-14
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M700
Product Name Risk Log

Purpose
1. To allocate a unique number to each risk
2. To record the type of risk
3. To be a summary of the risks, their analysis and status.
Composition
1.
2.
3.
4.
5.
6.
Risk number
Description
Likelihood
Severity
Countermeasure(s)
Status.
Reference
Derivation
1. Business risks may have been identified in the Project Brief and should be sought
during Project Initiation. There should be a check for any new business risks every
time the Risk Log is reviewed, minimally at each End Stage Assessment. The PSC
has the responsibility to constantly check external events for business risks.
2. Project risks are identified during Project Initiation when the Project Plan is being
created. Project risks should be reviewed every time the Risk Log is reviewed,
minimally at each End Stage Assessment.
3. Risks to a Stage Plan should be examined as part of the production of that plan. They
should be reviewed at each time of plan update.
Timing
The Risk Log is created during Refining the Business Case and Risks (IP3).
Quality Criteria:
1. Does the status indicate whether action has been taken or is in a contingency plan?
2. Are the risks uniquely identified, including to which risk type they refer?
3. Is access to the Risk Log controlled?
4. Is the Risk Log kept in a safe place?
5. Are activities to review the Risk Log in the Stage Plans?
Method: Informal Quality Review by the PSC or its delegates.
CM Requirement:
1. Must be put under version control at the end of Project Initiation Stage
13-15
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
M800
Product Name Work Package Authorisation

Purpose
To formally pass responsibility for work or delivery to a TM or team member.

A Work Package Authorisation forms a 'contract' between the PM and the TM or team
member who receives it. It should include the Product Description(s) in question.
Composition
This product will vary in form and content, and indeed in degree of formality, depending
on circumstances.
Although the content may vary greatly according to the relationship between the PM and
the recipient of the Work Package Authorisation, it should cover:
Identifier
Date
Team or person authorised
Work Package description Product Description(s)
Stage Plan extract
Joint agreement on effort, cost, start and end dates
Techniques/processes/procedures to be used
Interfaces to be satisfied by the work
Interfaces to be maintained during the work
Any other constraints to be observed
Reporting arrangements
Quality review arrangements
There should be space on the authorisation to record acceptance of the return of the
completed Work Package. This can be enhanced to include an assessment of the work
and go towards performance appraisal.
Reference
Derivation
There will be many Work Packages authorised during each stage. This is covered by
Authorising Work Package (CS1). A Work Package Authorisation is created by the
PM from the Stage Plan. After the initial start of a stage subsequent
Work Package Authorisations will be triggered after the process Reviewing Progress and
Stage Status.
Changes to the Stage Plan brought about by the process Taking Corrective Action may
also trigger new Work Package Authorisations.
Quality Criteria:
1. Is the required Work Package clearly defined and understood by the assigned
resource?
2. Is there agreement between the PM and the recipient on exactly what is to be done?
3. Is there agreement on the constraints, including effort, cost and targets?
4. Is there a Product Description with clearly identified and acceptable quality criteria?
5. Does the Product Description match with the other Work Package documentation?
6. Are standards for the work agreed?
7. Are the defined standards in line with those applied to similar products?
8. Are the dates and effort in line with those shown in the Stage Plan?
9. Have all necessary interfaces been defined?
10. Do the reporting arrangements include the provision for exception reporting?
13-16
PROJECT MANAGEMENT
APPENDIX D PRINCE
PRODUCT DESCRIPTION
CM Requirement:
1. Must be base-lined when work package is authorized
13-17
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
Q310
Product Name Quality Review Comment Form

Purpose
To document the comment on the product being reviewed.
Composition
1.
2.
3.
4.
5.
6.
Project Name
Review No.
Product Name
Comment Serial - A sequential reference number referring to the comment
Location - The location within the product related to the comment
Description - Comment/observation
Sample Layout
Quality Review Comment Form
Project :
Product:
Comment
Serial
Date :
Review No. :
Description
Location
Date :
Prepared by :
(
13-18
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
Q320
Product Name Quality Review Follow-up List

Purpose
To document the follow-up action taken in response to comments from quality review.
Composition
1.
2.
3.
4.
5.
6.
7.
Project Name
Review No.
Product Name
Comment Serial - A sequential reference number referring to the comment
Location - The location within the product related to the comment
Follow-up Action
Actioned By - The person nominated to follow-up the required changes brought
forwards by the comment
8. Signed-off By - The nominated person's signature to approve the follow-up action
Sample Layout
Quality Review Follow-up List
Project
Product :
Comment
Serial
Date :
Review No. :
Follow-up Action
Location
Actioned
by
(date)
Signed-off
by
(date)
Date :
Prepared by :
(
13-19
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
Q400
Product Name Issue Log

Purpose
To document project issues, which may be any changes requested during the project.
Quality Criteria:
1.
Is the project issue well explained and described?
2.
Is the project issue supported with full evidence?
Method: Informal Quality Review by the PSC or its delegates.
CM Requirement:
1. Must be base-lined before Project Closure
Sample Layout
Issue Log
Department:
Project:
Impact Analysis
Issue
No.
Description of
Issue
Resolution
Time
Adde
d
Resource
Added
Baslined
Product
Changed?
Within
Tolerance?
Decision
Status
Date of
Status
Change
Request No.
/Remarks
(Note: reference to supporting documents may be noted in the Remarks field.)
13-20
PROJECT MANAGEMENT
Product ID
APPENDIX D PRINCE
PRODUCT DESCRIPTION
Q500
Product Name Product Checklist

Purpose
To list the project products and their status
Derivation
Produced as an output from Completing a Plan (PL7)
Quality Criteria:
1. Do the details and dates match with those in the Plan?
Method: Informal Quality Review by project assurance personnel
CM Requirement:
1. Must be base-lined before Project Closure
Sample Layout
Product Checklist
Department:
Product
ID
Project:
Product Name &

File Reference
Work Package
Assigned to
Planned
Completion
Date
Actual Achieved Reviewer/Date

Draft
Quality
Complete
Review
13-21
PROJECT MANAGEMENT
14.
APPENDIX E USING THE RISK

ANALYSIS CHECKIST
APPENDIX E - USING THE RISK ANALYSIS CHECKLIST

Risk factors are those which affect the probability that the project will complete on time,
within budget, and deliver quality products. Possible risks factors of a project would
include the following :
Project management;
Project staff;
Nature of the project,
Maturity of the departmental management culture,
User Management; and
Others
These factors are analysed with the help of a Risk Analysis Checklist (Appendix F refers).
The procedures for completing the Sheet are as follows :1. Select one number in each of the scales 1-4 in column (b).
2. Assess a weighting for each of the risk factors, and enter it in column (d). A
recommended range is shown in brackets for each factor. Figure outside the
recommended range can be used, but its reasons should be recorded.
3. Multiply each selected number by the appropriate weighting, and enter the result in
column (e).
4. Assess whether there are any additional risks not included in this assessment sheet. If
there are, enter them on a continuation sheet, and assess them as in steps 1 to 3 above.
Total the continuation sheet and carry the totals to the grand total in the last page of
the assessment sheet.
5. Total the weighting factors in column (d). Multiply the resulting figure by 2.0 to
obtain the low risk limit, and by 2.6 to obtain the high risk limit. Enter these two
limits to the "Low risk" and "High risk" rows on the last page.
6. Total column (e) and enter the result in the Grand Total row on the last page.
7. Assess the risk of the whole project by referencing the Grand Total worked out in
column (e); the spread of markings in column (b); the experience with other projects;
and any relevant departmental standards.
14-1
PROJECT MANAGEMENT
APPENDIX E USING THE RISK

ANALYSIS CHECKIST
N.B. The risk factors marked with an * in column (e) are regarded as critical ones. If
any of them receives a marking of "4" in column (b), the project would be considered as a
high risk one, regardless of the score in the Grand Total.
The overall risk assessment and any areas of high risk within the project should be
recorded in the Project Initiation Document. The recommendations about the action to
counter the risks should also be recorded for approval by the PSC.
During the project, any change in the project risk must be kept under review. Change of a
low risk project to a high risk one should be monitored and reported to PSC where
necessary. The risk should be reassessed before each ESA is held, and be reported to the
PSC as part of the request to commence the next stage. All changes of assessed risk from
the previous submission must be pointed out and commented upon.
If the assessment indicates that the project has little or no chance of successful completion,
the PSC must be informed.
14-2
PROJECT MANAGEMENT
15.
APPENDIX F RISK ANALYSIS

CHECKLIST
APPENDIX F - RISK ANALYSIS CHECKLIST

(a)
Low risk
(b)
Scale
(c)
High risk
1234
Inexperienced or part time

PM
(d)
Weighting
(range)
(e)
Total
(bxd)
Project Management
1
2
Full time, experienced PM

User management is
experienced and likely to be
active participators
1234
*
(5-7)
Inexperienced user
management, with little
participation expected
(4-6)
Little user involvement

and little relevant
knowledge expected
(3-5)
Project Staff
3
Users expected to be of good

quality, actively involved,
with relevant knowledge of
the system
1234
High standard of supervision

and narrow span of control
1234
The technical team is

experienced, of good quality
and with appropriate skills
1234
Staff are dedicated to the

project
1234
Low staff turnover
1234
High staff turnover
Sufficient staff
1234
Insufficient Staff
4
5
Span of supervision too

wide and level of control
inadequate
Inexperienced team
lacking the appropriate
skills
Staff have other
responsibilities such as
system maintenance
(4-6)
(2-4)
(3-5)
(2-4)
*
(4-6)
9
10
11
12
13
14
Nature of the Project

A typical system
development cycle, with
requirements definition,
system specification,
systems design, etc.
No unique or new features
1234
1234
Current main operations will

be affected minimally
1234
Little or no modification to
existing application software
1234
Little or no other
development work being
undertaken concurrently
1234
Little/No dependence on
1234
A system development
cycle having no formal
requirements definition,
system design and build
merged etc.
(2-4)
Pioneering, new hardware

or software etc.
(2-4)
Significant impact on
mainstream operations
(3-5)
Extensive modification
needed
(2-5)
Other projects being

developed concurrently
(4-5)
Dependent on other
15-1
PROJECT MANAGEMENT
(a)
Low risk

CHECKLIST
(b)
Scale
existing or developing
systems not under the
control of staff on this
project
15
16
17
18
19
20
(c)
High risk
facilities not under the
control of staff on this
project
Project duration of 1 year or

less, or small number of
workdays compared with
other projects
Little constraint on
completion date beyond
availability of resources
1234
Plans and estimates are

based on reliable data
1234
Investment appraisal and

estimates prepared and well
documented, using proven
standards
1234
Suppliers are large, well

established companies
1234
Few user departments
1234
1234
Project duration more than

1 year, or a large number
of workdays
(d)
Weighting
(range)
(3-6)
(2-4)
Mandatory completion
date
(3-5)
Planing and estimation

data are unreliable
(3-6)
Approximations used;
estimates not properly
documented; or based on
unproven standards
Suppliers are new or oneman businesses
(e)
Total
(bxd)
(3-5)
(2-4)
Several user departments

(4-6)
21
22
23
24
25
26
27
28
Work affects few sites which

are easily accessible to the
team
1234
Many/remote sites are

involved
(3-5)
Maturity of the Departmental Organisation

Well developed set of
1 2 3 4 Few standards are
standards is in use
available
(2-4)
A well defined quality policy

exists
1234
The quality policy is ill

defined
(2-4)
Clear delegation of authority

is practised
1234
Centralised management
with little delegation
(2-4)
Good relationship with user

staff
User Management
Full commitment from
Users Top Management
1234
Relationship with user is

poor
(2-4)
No commitment from
Users Top Management
(5-7)
No client responsibility,
ownership
(4-6)
1234
High client responsibility,

ownership
1234
Low probability of Changing

Ownership or Senior
Management
1234
High probability of
Changing Ownership or
Senior Management
*
(5-7)
15-2
PROJECT MANAGEMENT
29
30
31

CHECKLIST
(a)
Low risk
(b)
Scale
(c)
High risk
Low probability of Changing

Scope/Objectives
1234
High probability of
Changing
Scope/Objectives
No conflict between user

parties
1234
Frequent conflicts
between user parties
(d)
Weighting
(range)
(e)
Total
(bxd)
*
(5-7)
(4-6)
Brought forward from

Continuation Sheet
(attached, if any)
Grand Totals
Risk Assessment
High risk if greater
Low risk if less
than
than
(Total of column (d) * 2.6)

(Total of column (d) * 2.0)
The overall assessment of risk of this project is :(Tick one)

Very High
High
Acceptable
Low
The assessment and recommendations for meeting the risks with scale marked at "4" are given in the corresponding
PID.
15-3
PROJECT MANAGEMENT
16.
APPENDIX G HINTS ON
PREPARATION OF A PROJECT
INITIATION DOCUMENT
APPENDIX G - HINTS ON PREPARATION OF A PROJECT

INITIATION DOCUMENT
Area
Check Item
General
May refer to the sample PID.
General
Include all external dependencies. e.g. shipment of computer equipment.

(External dependencies are something which the project depends on but out of
the control of project team.)
General
Include all assumptions. e.g. no major changes in business rules of the user.
(Assumptions are something uncertain but very likely to happen.)
General
Include all constraints. e.g. limited budget and time. (Constraint is something
generic that the project team has to follow or cater for.)
General
Include all high risk areas. e.g. additional user requirement raised during the
project life span. All others, related to uncertainty, are considered as risks.
General
Assess the project risk using the Risk Analysis Checklist. Give recommendations
for items marked at 4 (high risk).
General
Include Project Technical Plan and Next Stage Technical Plan
General
Include Project Resource Plan
General
The Prepared By officer in the Distribution List is the PM of the project. The
Endorsed By officer is, in general, the Senior Technical of PSC.
Terms of
Reference
Check if all roles and responsibilities of each member in PSC are relevant and
applicable to the project.
Terms of
Reference
In case of more than one person takes up a single role (e.g. Senior User), state
each of the specific areas of responsibility separately.
Organisation
For in-house project, PM role is taken up by OGCIO staff, preferably a staff of

SM rank or above. For other cases, the PM is generally taken up by staff from
the user department or the contractor.
Organisation
Ensure people assigned as Senior User(s) are able to represent the interest of all
user communities concerned.
Organisation
When there are several senior users in the PSC, ensure there are no potential
conflicts among them or there are measures to resolve conflicts that might arise.
Product
Description
Product
Description
Specify the Quality Criteria of each product (N/A for small projects).
Project Control
Include change control mechanism to the project. e.g. Issue Log.
Project Control
Spell out the four major issues to be discussed in an End-Stage Assessment :-
Tick
here
Specify which specific persons or parties are responsible for reviewing the
product (N/A for small projects).
Re-assess Business Case

Approve Current Stages Products
16-1
PROJECT MANAGEMENT
Area
APPENDIX G HINTS ON
PREPARATION OF A PROJECT
INITIATION DOCUMENT
Check Item
Endorse Next Stage Plan

Commit Next Stage Resources
Project Control
Check if Formal/Informal Quality Review procedures of products are stated

clearly.
Project Control
Ensure Formal Quality Reviews are required for major products.
Project Control
Ensure that in a Checkpoint Review, the product status, actual resources

spending, any problems and exception situation will be reviewed.
Project Control
Ensure that the Highlight Report, which reports project progress and major
problems encountered and actions taken will be prepared on a regular basic, as
an reassurance to the PSC.
Project
Technical Plan
Ensure the following activities are included :
Tick
here
A Project Initiation Meeting for Project Initiation Stage.

A Project Closure Meeting at the final stage.
An End-Stage Assessment at the end of all other stages.
Project
Technical Plan
Include the activities of Prepare Quality Plan and Prepare Quality Assurance
Review, each with an effort estimation of 2 man-days, in FS, SA&D and
Implementation phases. An extra Prepare Quality Assurance Review activity
must also be included in the Physical Design stage.
Project
Technical Plan
Ensure activities for Project Closure Meeting and Prepare Project Evaluation
Report are included at the end of the project.
Project
Technical Plan
Ensure there is no overlapping stage. (Overlapping of stages implies that the next
stage is started without the necessary review at the end of the preceding stage.)
Project
Technical Plan
A project stage is so designed to allow a major checkpoint for the PSC to review
the business case of the project and its progress. As a rule of thumb, a stage is
usually within 3 to 6 months. If a stage is short in duration, say less than 2
weeks, consider combining it with the adjacent stage to reduce administrative
overhead.
Project
Technical Plan
Ensure all project activities are included in the project technical plan. E.g.
procurement, funding approval, technical approval etc.
Quality Plan
Prepare a Quality Plan for the project.
Tolerance Level
Tolerance for both time and resource are set out in both directions (plus &
minus).
16-2
PRACTITIONER GUIDE
17.
APPENDIX H - GLOSSARY
Change Control
The procedure to ensure that the processing of all Project Issues is controlled,
including the submission, analysis and decision-making.
Checkpoint Review
A structured routine progress review of the Project Assurance Personnel and the
Project Manager. The frequency of checkpoints is set in the Project Initiation
Document (PID) by the PSC; and is usually fortnightly or monthly. The
Checkpoint is the most frequent control point in a project.
Commissioning Body
The group which authorises and mandates a PSC to conduct a project. Small
project often has the commissioning persons (the sponsors) on the PSC.
ESA (End Stage Assessment)
A PSC meeting/review is also attended by the PM and any Project Assurance
personnel delegated by the PSC, scheduled at end of a stage. This is a major
control in a project, where the PSC decides whether the project should proceed to
the next stage or not.
Exception Assessment
A PSC meeting/review (see ESA), which is scheduled mainly to consider an
Exception Plan for approval. This is equivalent to the previous Mid-Stage
Assessment.
Exception Plan
A plan, following an Exception Report, that replaces the current stage plan to
include activities from the present to the end of the stage. If the exception is at
project level, the Project Plan would be revised.
Exception Report
A report which describes an exception, provides an analysis and options for the
way forward and identifies a recommended option. It is given by the Project
Manager to the PSC.
Executive
The senior role in the PSC representing the interests of business. The Executive
acts as chairperson at the PSC meetings.
17-1
PRACTITIONER GUIDE
Follow-on Action Recommendation

A report which can be used as input to the process of creating a Business Case for
any follow-on PRINICE project, and for recording any follow-on instructions
covering incomplete products or outstanding issues.
Gantt Chart
A graphical representation of a schedule as bars across a calendar. Gantt charts
are commonly used to represent technical plans, and are often generated by a
computer supported project management tool.
Initiation Stage
The very first stage in a PRINCE project. It is purely for project management,
where the aims are to set up the appropriate project management environment of
the project, and to generate the Project Plan. The major end product of the
initiation stage is the PID.
MSA (Mid-Stage Assessment)
A PSC meeting/review (see ESA), which is scheduled mainly to consider an
Exception Plan for approval. The control is renamed as Exception Assessment
according to the revised PRINCE2 manual published in 2002.
PBS (Product Breakdown Structure)
This is a graphical technique for decomposing a product into its constituent
products. This is one of the product based planning techniques of PRINCE. It is a
powerful technique when is used to identify products required in a project.
PFD (Product Flow Diagram)
A graphical technique used for identifying the sequence to produce the products.
This is one of the product-based planning techniques of PRINCE.
PID (Project Initiation Document)
A document that describes how the PSC manages the project. The PID is the
major end product of the project initiation stage and contains the Project Plan and
the next Stage Plan.
PRINCE (Projects In a Controlled Environments)
It is a formal system of methods and techniques for managing a project. PRINCE
is originally developed by the Central Computer and Telecommunication Agency
(CCTA) to provide a standard and open framework for the management of
projects.
17-2
PRACTITIONER GUIDE
Product Description
A structured text description of a product, usually no more than one A4 page.
Product Descriptions of major products are normally included as an appendix to
the Project and Stage Plans.
A report presented by the Project Manager to the Project Steering Committee at
the Project Closure Meeting at the completion of a project. It is a summary of the
experiences of managing the project, the lessons learnt and the level of satisfaction
of user requirements.
PM (Project Manager)
The person with day-to-day planning and control responsibility for the whole
project. He is responsible for reporting to the PSC.
PSC (Project Steering Committee)
The owner of the project. The PSC is accountable to the Project Sponsors or
Commissioning Body for the progress and performance of the project. The
committee contains the Executive, Senior User and Senior Technical roles. It
appoints individuals to the other roles within the project organisation.
Quality Assurance Review
A quality assurance process conducted by independent reviewers to verify the
proper executions of product quality control and follow up actions of nonconformance.
Quality Review
A checking performed on completed products to see if they meet their quality
objectives and whether they are fit for purpose.
Resource Plan
The part of a Project or Stage Plan that presents the effort (e.g. days per
person/group/resource type) and cost over time.
Senior Technical
The PSC role which provides knowledge and experience of the main discipline(s)
involved in the production of the projects deliverable(s).
Senior User
A member of the PSC, accountable for ensuring that user needs are specified
correctly and that the solution meets those needs.
Technical Plan
The part of a Project or Stage Plan which represents the schedule of work, usually
in a form of a Gantt Chart.
17-3
PRACTITIONER GUIDE
Tolerance
The amount of time and cost variation allowed around the target in a plan. A
money tolerance may be plus or minus certain percent of the estimated cost. A
time tolerance may be plus or minus certain no. of weeks from the target date.
Work Package
The set of information relevant to the creation of one or more products. It will
contain the Product Description(s), details of any constraints on production such
as time and cost, interfaces, and confirmation of the agreement between the PM
and the person or TM who is to implement the Work Package that the work can be
done within the constraints.
17-4

Project Menagement

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Menagement

Uploaded by

Copyright:

Available Formats

Office of the

Government Chief Information Officer

DEFINITIONS AND CONVENTIONS.............................................................................................................4-1

BUSINESS CASE .............................................................................................................................................6-1

PRINCE PROCESSES ........................................................................................................................................7-1

Confirming Project Closure (DP5)..........................................................................................................7-5

PROJECT MANAGEMENT TECHNIQUES ..................................................................................................8-1

APPLICATION OF PRINCE IN OGCIO.........................................................................................................9-1

AREA OF APPLICATION ...........................................................................................................................9-1

APPENDIX A - ROLES OF MEMBERS IN PROJECT ORGANISATION..........................................10-1

APPENDIX B - TERMS OF REFERENCE OF PROJECT STEERING COMMITTEE.....................11-1

APPENDIX C - SAMPLE PROJECT ASSURANCE ROLES SET-UP..................................................12-1

APPENDIX D - PRINCE PRODUCT DESCRIPTION ............................................................................13-1

APPENDIX E - USING THE RISK ANALYSIS CHECKLIST...............................................................14-1

APPENDIX F - RISK ANALYSIS CHECKLIST......................................................................................15-1

APPENDIX G - HINTS ON PREPARATION OF A PROJECT INITIATION DOCUMENT ............16-1

PRINCE 2 Manual, CCTA 1996.

DEFINITIONS AND CONVENTIONS

DEFINITIONS AND CONVENTIONS

Administrative Computer Projects Committee

In general, a project is considered to be one having the following characteristics:

it is to produce a set of products to meet the business needs;

OBJECTIVE OF PROJECT MANAGEMENT

5.3.2 The Method

Directing a Project (DP)

the sequence of delivery of the products;

6.1.1 What is a Business Case?

6.1.2 Developing a Business Case

6.2.1 Project Steering Committee (PSC)

The chairperson, representing the interest of the customer, and

Representing the users of the system (product).

Senior Technical: Representing developer(s) or procurers, the resources which deliver

For small project, roles can be combined but never eliminated.

6.2.2 Project Manager (PM) and Team Manager (TM)

The PM/TM can be from User Department or OGCIO/contractors. TM may be taken

6.2.3 Project Assurance

viability of the Business Case

6.2.4 The Benefits

In the PRINCE recommended organization, roles and

the right place.

PRINCE emphases formal assignment of roles to all

The steps required in order to achieve a specified target

On process of planning in general, Planning (PL) may be referenced (see 7.9).

6.3.1 Levels of Plan

Project level, and

There are, in turn, two types of plans, namely:

Technical Plans, and

Start Date End Date F M A

Stage 1 - Stage Name

Stage 2 - Stage Name

Stage 1 - Stage Name

Authorise Authorise Ad Hoc

Ad Hoc Mid Stage End Stage Confirm

6.4.1 Project Steering Committee Controls

End Stage Assessment

6.4.2 Project Manager Controls

6.4.3 Team Manager Controls

It provides senior management the opportunities to assess the project progress by

It enables more realistic estimate to be worked out at the commencement of each

Consideration in Project Staging

A stage boundary should not divide a major end-product;

At critical part of a project where visible tight control is necessary, it should be

Stages for Management Decision

6.5.1 Project Risk