Prince2 Practitioner Guide On Project Management

PRACTITIONER GUIDE
ON
PROJECT MANAGEMENT
[G38]
Version : 3.2
Jun 2003
© 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 STANDARDS ..................................................................................................................................................3-1
3.2 OTHER REFERENCES......................................................................................................................................3-1
4. DEFINITIONS AND CONVENTIONS.............................................................................................................4-1
4.1 DEFINITIONS .............................................................................................................................................4-1
4.2 CONVENTIONS..........................................................................................................................................4-1
5. 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 BUSINESS CASE .............................................................................................................................................6-1
6.1.1 What is a Business Case? ........................................................................................................................6-1
6.1.2 Developing a Business Case....................................................................................................................6-1
6.2 ORGANIZATION........................................................................................................................................6-3
6.2.1 Project Steering Committee (PSC) ..........................................................................................................6-3
6.2.2 Project Manager (PM) and Team Manager (TM)...................................................................................6-5
6.2.3 Project Assurance....................................................................................................................................6-5
6.2.4 The Benefits .............................................................................................................................................6-6
6.3 PLANNING .....................................................................................................................................................6-8
6.3.1 Levels of Plan ..........................................................................................................................................6-8
6.4 CONTROLS ...................................................................................................................................................6-12
6.4.1 Project Steering Committee Controls ....................................................................................................6-13
6.4.2 Project Manager Controls.....................................................................................................................6-16
6.4.3 Team Manager Controls........................................................................................................................6-18
6.4.4 Stages.....................................................................................................................................................6-18
6.5 MANAGEMENT OF RISK ...............................................................................................................................6-21
6.5.1 Project Risk............................................................................................................................................6-21
6.5.2 Risk Analysis..........................................................................................................................................6-23
6.5.3 Risk Management ..................................................................................................................................6-24
6.6 QUALITY IN A PROJECT ENVIRONMENT ........................................................................................................6-26
6.7 CONFIGURATION MANAGEMENT ..................................................................................................................6-27
6.8 CHANGE CONTROL ......................................................................................................................................6-28
6.8.1 Issue Log................................................................................................................................................6-28
6.8.2 Impact Analysis......................................................................................................................................6-29
6.8.3 Follow-up on Project Issues ..................................................................................................................6-29
7. 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 Confirming Project Closure (DP5)..........................................................................................................7-5

7.3 STARTING UP A PROJECT (SU).......................................................................................................................7-6
7.3.1 Appointing a PSC Executive and a PM (SU1).........................................................................................7-6
7.3.2 Designing a Project Management Team (SU2).......................................................................................7-7
7.3.3 Appointing a Project Management Team (SU3)......................................................................................7-8
7.3.4 Preparing a Project Brief (SU4)..............................................................................................................7-8
7.3.5 Defining Project Approach (SU5) ...........................................................................................................7-9
7.3.6 Planning an Initiation Stage (SU6) .........................................................................................................7-9
7.4 INITIATING A PROJECT (IP)..........................................................................................................................7-11
7.4.1 Planning Quality (IP1) ..........................................................................................................................7-11
7.4.2 Planning a Project (IP2) .......................................................................................................................7-12
7.4.3 Refining the Business Case and Risks (IP3) ..........................................................................................7-12
7.4.4 Setting up Project Controls (IP4) ..........................................................................................................7-13
7.4.5 Setting up Project Files (IP5) ................................................................................................................7-13
7.4.6 Assembling a Project Initiation Document (IP6)...................................................................................7-14
7.5 CONTROLLING A STAGE (CS) ......................................................................................................................7-15
7.5.1 Authorising Work Package (CS1)..........................................................................................................7-16
7.5.2 Assessing Progress (CS2) ......................................................................................................................7-17
7.5.3 Capturing Project Issues (CS3) .............................................................................................................7-17
7.5.4 Examining Project Issues (CS4) ............................................................................................................7-17
7.5.5 Reviewing Stage Status (CS5)................................................................................................................7-18
7.5.6 Reporting Highlights (CS6) ...................................................................................................................7-19
7.5.7 Taking Corrective Action (CS7) ............................................................................................................7-19
7.5.8 Escalating Project Issues (CS8) ............................................................................................................7-19
7.5.9 Receiving Completed Work Package (CS9)...........................................................................................7-20
7.6 MANAGING PRODUCT DELIVERY (MP) .......................................................................................................7-21
7.6.1 Accepting Work Package (MP1)............................................................................................................7-21
7.6.2 Executing Work Package (MP2)............................................................................................................7-22
7.6.3 Delivering a Work Package (MP3) .......................................................................................................7-22
7.7 MANAGING STAGE BOUNDARIES (SB) ........................................................................................................7-23
7.7.1 Planning a Stage (SB1)..........................................................................................................................7-23
7.7.2 Updating a Project Plan (SB2)..............................................................................................................7-24
7.7.3 Updating a Project Business Case (SB3) ..............................................................................................7-24
7.7.4 Updating the Risk Log (SB4) .................................................................................................................7-25
7.7.5 Reporting Stage End (SB5)....................................................................................................................7-25
7.7.6 Producing an Exception Plan (SB6)......................................................................................................7-26
7.8 CLOSING THE PROJECT (CP)........................................................................................................................7-27
7.8.1 Decommissioning a Project (CP1) ........................................................................................................7-27
7.8.2 Identifying Follow-On Actions (CP2)....................................................................................................7-28
7.8.3 Evaluating a Project (CP3) ...................................................................................................................7-28
7.9 PLANNING (PL) ...........................................................................................................................................7-29
7.9.1 Designing a Plan (PL1) .........................................................................................................................7-30
7.9.2 Defining and Analysing Products (PL2)................................................................................................7-31
7.9.3 Identifying Activities and Dependencies (PL3)......................................................................................7-32
7.9.4 Estimating (PL4)....................................................................................................................................7-32
7.9.5 Scheduling (PL5) ...................................................................................................................................7-32
7.9.6 Analysing Risks (PL6)............................................................................................................................7-33
7.9.7 Completing a Plan (PL7).......................................................................................................................7-33
8. 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 Objective ................................................................................................................................................8-13

8.2.2 Top Down Method .................................................................................................................................8-13
8.2.3 Bottom Up Method.................................................................................................................................8-13
8.3 ACTIVITY NETWORK ANALYSIS........................................................................................................8-14
8.3.1 Activity Networking ...............................................................................................................................8-14
8.3.2 Construction ..........................................................................................................................................8-14
8.3.3 Network Analysis ...................................................................................................................................8-20
8.4 BAR CHARTING ......................................................................................................................................8-21
8.4.1 Bar Charting in general.........................................................................................................................8-21
8.4.2 Gantt Chart............................................................................................................................................8-21
8.4.3 Milestone and Float...............................................................................................................................8-22
8.5 RESOURCE LEVELLING ........................................................................................................................8-23
8.6 QUALITY CONTROL...............................................................................................................................8-25
8.6.1 Quality Review.......................................................................................................................................8-25
8.6.2 Informal Review.....................................................................................................................................8-27
8.7 QUALITY ASSURANCE..........................................................................................................................8-27
8.7.1 Quality Assurance Review Process........................................................................................................8-27
8.7.2 Participants in QA Review.....................................................................................................................8-27
9. APPLICATION OF PRINCE IN ITSD .............................................................................................................9-1
9.1 AREA OF APPLICATION ...........................................................................................................................9-1
9.2 CUSTOMIZATION .....................................................................................................................................9-1
9.3 SMALL PROJECTS.....................................................................................................................................9-1
9.4 SDLC PROJECTS ........................................................................................................................................9-2
9.5 CONTRACTING-OUT PROJECTS ...............................................................................................................9-3
9.5.1 Introduction .............................................................................................................................................9-3
9.5.2 Organisation............................................................................................................................................9-3
9.5.3 Planning...................................................................................................................................................9-3
9.5.4 Control.....................................................................................................................................................9-4
9.5.5 Quality .....................................................................................................................................................9-4
9.6 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
ON PROJECT MANAGEMENT PURPOSE
1. PURPOSE
The purpose of this document is to provide guidelines on the project management method
adopted in ITSD. 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 ITSD in 1992 and in 1994,
it became the 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
ON PROJECT MANAGEMENT SCOPE
2. SCOPE
This Guide composes of five sections:

i. Introduction;
ii. PRINCE Components;
iii. PRINCE Processes;
iv. PRINCE Techniques; and
v Application of PRINCE in ITSD.
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 ITSD 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
ON PROJECT MANAGEMENT REFERENCES
3. REFERENCES
3.1 STANDARDS
None.
3.2 OTHER REFERENCES
• PRINCE 2 Manual, CCTA 1996.

• Resources Estimation Guide [G19], ITSD.
• Software Configuration Management Process Guide for Application Software [G46],
ITSD.
• Managing Successful Projects with PRINCE2 OGC 2002.
3-1
PRACTITIONER GUIDE
ON PROJECT MANAGEMENT DEFINITIONS AND CONVENTIONS
4. DEFINITIONS AND CONVENTIONS
4.1 DEFINITIONS
None.
4.2 CONVENTIONS
The following acronyms are used in the text of this Guide:
ACPC Administrative Computer Projects Committee

IRS Initial Request Statement
PM Project Manager
PRINCE Projects in Controlled Environments
PSC Project Steering Committee
QA Quality Assurance
QM Quality Management
TM Team Manager
Where appropriate, guidelines specific to small projects are indicated in italics and
those specific to ITSD environment are indicated in underline.
4-1
PRACTITIONER GUIDE
ON PROJECT MANAGEMENT INTRODUCTION
5. INTRODUCTION
5.1 CHARACTERISTICS OF A PROJECT
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. ITSD 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 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
Business
Control
Case
Configuration Organization
Management
Quality in a project Plans

environment
Management Controls
of Risk
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
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 Initiating a Managing Closing a

Project (SU) Project (IP) Stage Project
Boundary (CP)
(SB)
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
• 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
ON PROJECT MANAGEMENT PRINCE COMPONENTS
6. PRINCE COMPONENTS
PRINCE has the following components that are used by the processes :
• Business Case
• Organisation
• Plans
• Controls
• Management of Risk
• Quality in a project environment
• Configuration Management
• Change Control
6.1 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
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 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 Senior
User Technical
Project
Project
Assurance
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
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
• 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-to-
day 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
team’s 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 ITSD/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 ITSD 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
It is the PSC’s responsibility to monitor all aspects of the project’s performance and
products independent of the PM. This is the Project Assurance Function.2
2
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.
6-5
PRACTITIONER GUIDE
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 ITSD, officer(s) from User Departments may take up project assurance regarding the
User’s interest while ITSD officers, e.g. a senior API, may take up project assurance
regarding the project expenditures.
• ITSD 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 In the PRINCE recommended organization, roles and

Responsibilities responsibilities are suitably divided. Human
resources of a project can be so arranged that the most
appropriate skill and responsibility mix be assigned in
the right place.
Clear Definition of Roles PRINCE emphases formal assignment of roles to all

and Responsibilities participants at the project start. It enables individuals
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
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 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
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:
1995
ID Name Start Date End Date F M A M J J A S O N D J F M A M
1 Stage 0 - Project Initiation 2.5.95 29.5.95
2 Prepare PID 2.5.95 29.5.95 50%
3 Stage 1 - Stage Name 30.5.95 13.11.95
4 Activity 1 30.5.95 16.10.95
10 Activity 2 17.10.95 13.11.95 0%
11 Stage 2 - Stage Name 14.11.95 8.1.96
12 Activity 3 14.11.95 11.12.95 0%
13 Activity 4 12.12.95 8.1.96 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
1995
ID Name Start Date End Date M A M J J A S O N D J F M
1 Stage 0 - Project Initiation 02/05/95 29/05/95
3 Stage 1 - Stage Name 30/05/95 13/11/95
4 Activity 1 30/05/95 16/10/95

5 Activity 1.1 30/05/95 26/06/95 0%
6 Activity 1.2 27/06/95 24/07/95 0%
7 Activity 1.3 25/07/95 21/08/95 0%
8 Activity 1.4 22/08/95 18/09/95 0%
9 Activity 1.5 19/09/95 16/10/95 0%
10 Activity 2 17/10/95 13/11/95 0%
11 Stage 2 - Stage Name 14/11/95 08/01/96
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
ITSD User
(md) (md)
Stage SM API APII SCO COI COII
0 Planned 3.0 5.0 0.0 2.0 2.0 0.0
Actual 0.0 0.0 0.0 0.0 0.0 0.0
1 Planned 20.0 110.0 90.0 15.0 30.0 40.0

Actual 0.0 0.0 0.0 0.0 0.0 0.0
2 Planned 2.0 7.0 2.0 2.0 5.0 0.0

Actual 0.0 0.0 0.0 0.0 0.0 0.0
Project
a. Planned 25.0 122.0 92.0 19.0 37.0 40.0
b. Actual 0.0 0.0 0.0 0.0 0.0 0.0
c. Est. to Complete 25.0 122.0 92.0 19.0 37.0 40.0
d. Variance (b+c-a)/a 0% 0% 0% 0% 0% 0%
6-10
PRACTITIONER GUIDE
Expenditures
Stage Expenditure $’000

0 Planned 0
Actual 0
1 Planned 9,200
Actual 0
2 Planned 3,603
Actual 0
Project
a. Planned 12,803
b. Actual 0
c. Est. to Complete 12,803
d. Variance (b+c-a)/a 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 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.
Authorise Authorise Ad Hoc Ad Hoc Mid Stage End Stage Confirm

PSC Initiation the Project Direction Direction Assessment Assessment project
Closure
Project
All aspects Highlight Minutes of Evaluation
of a project Report ESA Report
(scope,
Project nature, PID Exception Plan Follow-On
Manager Business Work Risk Log Actions
Case, Package Recommen
Output, -dations
etc.) Stage Plan
Minutes of Project
Checkpoint
Team Issue
Review
Manager meetings Issue Log Report
Work Package Product

Close 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
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 ITSD, it is the Initial Request Statement (IRS) sent from user
department to ITSD, 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
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
• 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
Configuration Management
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
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
Configuration Management
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
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
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 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. 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
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 ITSD, 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
• 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
• 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 Plan and resource

responses to risks
Select
RISK ANALYSIS RISK MANAGEMENT

PHASE PHASE
6-25
PRACTITIONER GUIDE
6.6 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 ITSD, 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 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 project’s software assets are important to ITSD and the user departments and have to
be managed by the SCM, which makes it a mandatory process in ITSD.
Roles and responsibilities are detailed in ITSD 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 non-
software 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 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 over-
spending.
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 ITSD 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
• 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
ON PROJECT MANAGEMENT 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:
ITSD Management
Project Start-up Approved Exception Project

Notification PID Report Closure
Notification
Directing a Project (DP)
Quality, risk, Updated plans Project

IRS or ITPSA project Product checklist Evaluation Follow-on
Authori- PID Advice Reports
Assignment definition, Next stage plan Report Action
zation
Brief business case etc. Recom-
etc. mendation
Starting up a Initiating a Controlling a Managing Closing a

Project (SU) Project (IP) Stage (CS) Stage Project
Boundary (CP)
(SB)
Work Checkpoint Report

Package Product Checklist
Authorisation 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 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.
ITSD Management
Project Start-up Mobilisation of Business/
Notification support services Exception Report Technical
Approved PID Changes
Follow-on Action
Directing a Project (DP) recommendation
Project Evaluation Report
Project Closure Notification
Authorising Authorising Authorising Giving Ad Confirming

Initiation a Project a Stage or Hoc Project
(DP1) (DP2) Exception Direction Closure
Plan (DP4) (DP5)
(DP3)
Authorisation Authorisation Highlight Report

to proceed to proceed Exception Report Project Evaluation Report
Requests for advice Project Closure recommendation
Follow-on Action recommendations
Quality, risk, project
Operational and Maintenance
definition, business case, Authorisation PID, Exception Report, confirmation
Draft Initiation Stage Plan to proceed Next Stage Plan,
Draft PID PID
Job Definitions Project Team changes,
Project Management Updated Project Plan
Team structure Updated Business Plan
Project Approach Updated Risk Log, etc.
Starting up Initiating a Controlling Managing Closing a

a Project Project a stage Stage Project
(SU) (IP) (CS) Boundary (CP)
(SB)
7-2
PRACTITIONER GUIDE
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 ITSD 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
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
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 project’s 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 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 ITSD, 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).
ITSD Management
IRS or ACPC
Approval, ITPSA
Assignment Brief
Starting up a Project (SU)
Appointing Designing a Appointing a

a PSC Project Draft job Project
descriptions, PM
Executive Management team structure Management
and PM Team Team
(SU1) (SU2) (SU3) Draft initiation Authorising
Stage Plan
Initiation
(DP1)
Preparing Defining Planning

Project Brief Project Initiation
(SU4) Approach Stage
(SU5) (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 ITSD), 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
• 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 ITSD or the Supplier while the Executive is from the
User Department. In such a case, the PM will be appointed by ITSD 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 ITSD 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
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
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
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 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)

Refining the
Planning Planning a Business
Quality Case and Authorising
Project
(IP1) Risks a Project
(IP2)
(IP3) (DP2)
Authorising
Initiation
(DP1)
Draft PID,
Setting up Setting up Assembling Next Stage
Plan
Project Project Files a PID
Authorized
initiation
Controls (IP5) (IP6)
Stage Plan (IP4)
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
• 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 ITSD);
• 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
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
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
• Project Evaluation Report
• 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 sub-
processes 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 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)

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

Work Package Work Package Work Package Work Package
(CS1) (MP1) (MP2) (MP3)
Checkpoint report Approved work

Package
Receiving
Assessing Progress
Completed
(CS2)
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
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 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)
Next
Stage End SB1 stage SB2 Next SB3
Notification Planning a plan Updating a stage plan Updating a
Stage Project or Project
Plan exception Business
plan Case
Next stage plan or
Exception exception plan
plan
CS5 SB6 SB4 SB5
Reviewing Producing Updating Reporting
Stage an the Risk Stage End
Next stage
Status Exception Log
plan or
Plan
exception
plan
Next stage
CS8 DP3 Request for plan or
Escalating Authorizing authorization to exception
Project a Stage or proceed plan
Issues Exception End stage report
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 day-
to-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
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
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
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 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 Premature
Direction close
(DP4) Project closure
recommendation
De-
Operational and
Notification of commissioning a
project end maintenance acceptance
Project
Reviewing (CP1) Customer acceptance
Stage Status Confirming
(CS5) Project
Follow-on Action
Identifying recommendations Closure
Follow-on (DP5)
Actions
Premature Close (CP2) Post-project review
Authorizing a plan
Stage
(DP3) Project Evaluation
Evaluating a Report
Project
(CP3)
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
• 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 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 sub-
processes, 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
Planning (PL)
Plan Product Flow

Design Diagrams
Designing a Defining and Identifying

Planning an Plan Analysing Activities and
Initiation Stage (PL1) Products Dependencies
(SU6) (PL2) (PL3)
Product
Descriptions List of
Activities
Planning a
Activities
Project Draft Product Estimating
Checklist dependencies
(IP2) (PL4)
Estimated
Accepting a Assessed
Activities
Plan Schedule
Work Package
(MP1)
Completing a Analysing
Scheduling
Plan Risks
(PL7) (PL6) (PL5)
Completed
Product Plan for Resource
Checklist Risk Log availability
approval
Planning a Updating a Producing an

Stage Project Plan Exception
(SB1) (SB2) 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 ITSD, ‘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
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
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 ITSD, 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 ITSD 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
• 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
ON PROJECT MANAGEMENT PROJECT MANAGEMENT TECHNIQUES
8. PROJECT MANAGEMENT TECHNIQUES
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 Air Conditioning Fire Extinguish

Supply System System System
Air Conditioners 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 Quality Technical

Products Products Products
A B C
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)
Technical
Products
System Procurement
Development Products
Products
T100 T200 Implementation

Feasibility SA&D Report Products
Study Report
D
T110 T210
Management Technical Management Technical
Summary Specification Summary Specification
T121 T122 T221 T222 T223 T224 T225

Current Project Current Business User System Selected
Environment Definition Environment Process/ Requirements Specifications Technical
Description Description Activity System
Model 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 T122
Feasibility Study
Current Environment Project Definition
Description (FS)
(FS)
T110/T100
Management Summary/
FS Report
(FS)
SA&D Study
T221
Current Environment T222 T223 T224 T225
Description Business Process Model / User System Selected Technical
Business Activity Model Requirements Specifications System Option
(SA&D)
T210/T200
Management Summary/
SA&D Report
(SA&D)
Implementation/ T400 T500

Procurement Tender Evaluation
Specification Criteria
T311 T600
Data File Description Evaluation
Report
T312 T700
Program Procurement
Specification Contract
T800 T357
Procured Prepared
H/W & S/W 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 - A unique number, which also appears in Product Breakdown

Structure and Product Flow Diagram.
(b) Product Name - A name for the product.
(c) Purpose - A description of the function of the product.
(d) Composition - The various component parts of the product.
(e) Derivation - The methods and sources by which this product is produced.
(f) Quality Criteria - The criteria by which the quality of the product is to be assessed
(which should desirably be testable and measurable).
(g) Quality Method - 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.
(h) CM Requirement - 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
ITSD senior management
Composition. • Approval Sought;

• System Objectives;
• Background;
• Present Situation;
• Problem/Improvement Areas;
• Proposed System;
• Resource Implication;
• Costs;
• Benefits;
• Cost-benefits Analysis;
• Development Plan; and
• Recommendation
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 • 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) For each product on the Product Flow Diagram, list the activities required for its
construction;
(b) In listing the activities, consider the products associated with them. This may identify
additional products which should be added to the PBS and PFD;
(c) 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 Dependant
Number Number Name on Activities
1 T121 Prepare F.S. Current Environment -
Description
2 T122 Prepare F.S. Project Definition 1
3 T110 Produce F.S. Management Summary 1,2
4 T221 Prepare SA&D Current Environment 1
Description
5 T222 Prepare User Requirements 2
6 T223 Prepare System Specifications 2
7 T224 Prepare Technical System Option 2
8 T210 Produce SA&D Management Summary 4-7
9 T311 Conduct Physical Database Design 8
10 T312 Prepare Program Specifications 9
11 T400 Produce Tender Specification 8
12 T500 Draw up Evaluation Criteria 8
13 T600 Tender Evaluation 11,12
14 T700 Contract Negotiation 13
15 T357 Site Preparation 14
16 T800 Hardware & Software Delivery 14
17 T321 Programming 10, 15,16
18 T330 System Testing 17
19 T341 User Acceptance Testing 18
20 T343 User Training 19
21 T351 Prepare System Manual 20
22 T352 Prepare Program Manual 20
23 T353 Prepare Data Manual 20
24 T354 Prepare Application Operation Manual 20
25 T355 Prepare Application User Manual 20
26 T356 Prepare Computer Operating Procedure 20
Manual
27 T358 Data Conversion 20
28 T359 System Live 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 Ensures that all interested parties have the same view of the
Description requirements, eliminating the likelihood of products being
produced at the wrong level of detail, or in the wrong
format.
Activity Ensures that the activities derived are appropriate for the
Derivation 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 Product Descriptions provide the information necessary to

Training 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 Estimates can be produced based upon a detailed description

Estimating of the product to be produced including the level of the
quality required.
Hints and Tips
• In ITSD, 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) Manpower required;

(b) Cash and other resources required;
(c) Plan duration;
(d) 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) Knowledge of the activities to be estimated;

(b) Knowledge of the project environment;
(c) Information about similar projects undertaken in the past;
(d) 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
ITSD, 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 :-
B E
START A D F G 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 EFT EST Duration EFT

Start Finish Activity Name
LST LEF LST Float LFT
(c) 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
0 4 4 4 15 19 19 3 22
A D J
14 14 18 18 14 33 33 14 36
8 6 14
30 22 36
20 10 30
26 6 36
0 0 8 8 8 12 20 20 11 31 31 5 36 36
ST B F H I FIN
A
0 0 0 8 8 0 20 20 0 31 31 0 36 36
0 7 7 7 9 16
C G
4 4 11 11 4 20
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 LFT EFT Total Float

B 8 8 0
F 20 20 0
H 31 31 0
I 36 36 0
C 11 7 4
G 20 16 4
K 36 30 6
A 18 4 14
D 33 19 14
J 36 22 14
E 33 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 EST EFT Free Float

(next activity) Early
1 B 8 8 0
F 20 20 0
H 31 31 0
I 36 36 0
2 C 7 7 0
G 20 16 4
3 K 36 30 6
4 A 4 4 0
D 19 19 0
J 36 22 14
5 E 19 14 5
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
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 Mth 1 Mth 2 Mth 3 Mth 4 Mth 5 Mth 6 Mth 7 Mth 8 Mth 9
A
D
B
E, F
C
G
D
J
E
J
F
K, H
G
H
H
I
I
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 sub-
section 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 Mth 1 Mth 2 Mth 3 Mth 4 Mth 5 Mth 6 Mth 7 Mth 8 Mth 9
4
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 re-
scheduled 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 Activity Total Float

5 E 19
4 A, D, J 14
3 K 6
2 C, G 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) Activity E to start at beginning of the fifth month;

(b) Activity J to start after activity E; and
(c) Activity K to start after activity J.
The re-scheduled resource loading diagram is presented below.
No. staff Mth 1 Mth 2 Mth 3 Mth 4 Mth 5 Mth 6 Mth 7 Mth 8 Mth 9
5
4
3
2
1
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). A review

normally has three distinct phases :-
• 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 (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 (Ref. Q3) for details of their
responsibilities.
8-27
PRACTITIONER GUIDE
ON PROJECT MANAGEMENT APPLICATION OF PRINCE IN ITSD
9. APPLICATION OF PRINCE IN ITSD
9.1 AREA OF APPLICATION
PRINCE is a generic project management method that can be applied to projects of any
nature. In ITSD 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 ITSD environment. ITSD’s 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 ITSD
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 ITSD, the classification of a small
PRINCE project is in line with the ACPC’s 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 ITSD 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 SDLC SSADM RAD

Phase Step Stage Stage
Feasibility • Feasibility (0a) Problem Definition Requirement
Study Study (0b) Project Identification Planning
System • System Analysis (1) Investigation of current environment User Design

Analysis & (2a) Selection of Business System Option
Design (2b) Requirement Specification
(3) Selection of technical option
• Logical Design (4) Logical design
Imple- • Physical (5) 1st-cut Physical Design Rapid

mentation Design (6) Physical Design Optimisation Construction
• Program and Transition
Development
• System Tests
& Integration
• User Acceptance
• System Install’n &
Production
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

ITSD. 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
Project Steering Committee
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 ITSD, if applicable. If ITSD 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 ITSD
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/ITSD 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. ITSD 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 ITSD 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
Project Steering Committee
The outsourcer will take up the Senior Technical role in PSC. ITSD 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. ITSD 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 outsourcer’s standards.
9-6
PRACTITIONER GUIDE ON APPENDIX A – ROLES OF
PROJECT MANAGEMENT MEMBERS IN PROJECT
ORGANISATION
10. APPENDIX A - ROLES OF MEMBERS IN PROJECT

ORGANISATION3
A. 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 ITSD about project progress
• organise and chair PSC meetings
• recommend future action on the project to User management or ITSD if
the project tolerance is exceeded
• approve the sending of the notification of project closure to User
management or ITSD.
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 ITSD 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:
3
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
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-of-
view 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
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
ORGANISATION
B. 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 ITSD 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
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.
c. 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 project’s 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
PRACTITIONER GUIDE ON APPENDIX B –TERMS OF
PROJECT MANAGEMENT REFERENCE OF PROJECT
STEERING COMMITTEE
11. 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 ITSD/user standards and policies, plus
any associated contract with the Supplier
• agreement with the PM on that person’s responsibilities and objectives
• confirmation with user management and ITSD 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 ITSD 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 ITSD.
11-1
PRACTITIONER GUIDE ON APPENDIX C – SAMPE
PROJECT MANAGEMENT PROJECT ASSURANCE ROLES
SET-UP
12. APPENDIX C - SAMPLE PROJECT ASSURANCE ROLES SET-UP
With reference to section 6.2.3 - Project Assurance, ITSD 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 Senior
User Technical
Project Assurance Project

Business Manager (PM)
User Technical
Assurance Assurance Assurance
Coordinator Coordinator Coordinator 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 project’s 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 user’s requirements are properly specified, and are well understood and
agreed by the project team;
12-1
PRACTITIONER GUIDE ON APPENDIX C – SAMPE
PROJECT MANAGEMENT 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
3. 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
PRACTITIONER GUIDE ON APPENDIX D –PRINCE
PROJECT MANAGEMENT PRODUCT DESCRIPTION
13. 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 Quality Technical

Products Products Products
A B C
13-1

Management
Products
M100 M300 M400 M500 M600 M800

Project Minutes of Minutes of Highlight Project Work
Initiation Steering Checkpoint Reports Evaluation Package
Document Committee Review Report Authorisation
Meetings Meetings
M700
Risk
Plans & Log
Exception
Reports
M210 M220 M230

Project Stage Exception
Plan Plans Report
13-2

Quality
Products
Q100 Q200 Quality Q400 Q500

Product Quality Review Review Issue Product
Descriptions Invitation Results Log Checklist
Q310 Q320
Quality Review Quality Review
Comment Form Follow-up List
13-3
Index of Product Descriptions
Product ID Product Name

M100 Project Initiation Document
M110 Business Case
M210 Project Plan
M220 Stage Plan
M230 Exception Report
M300 Minutes/Notes of End-Stage Assessment / Exception Assessment
M400 Minutes/Notes of Checkpoint Review
M500 Highlight Reports
M600 Project Evaluation Report
M700 Risk Log
M800 Work Package Authorisation
Q310 Quality Review Comment Form
Q320 Quality Review Follow-up List
Q400 Issue Log
Q500 Product Checklist
13-4
Product ID 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. ITSD 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
Product ID 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 on-
going viability of the project will be monitored by the PSC against the Business Case.
Composition
1. Reasons
2. Benefits
3. Cost and timescale
4. 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 ITSD's strategy?
Method: Informal Quality Review with the Executive and his/her delegate for project
assurance.
13-6
Product ID 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 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.
2. Planning Assumptions 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.
3. Project Dependencies 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.
4. Risk Log Documents the identified project risks and the measures to
counter or avoid them.
5. Quality Plan Outlines the standards, methodologies and procedures
which are to be applied in the project.
6. Project Technical Plans Used to show the project activities, parties involved, the
• Brief Description timescale and the products to be produced. Besides bar
• Bar Chart charting, it should also be presented in the form of an
• Activity Network, if any Activity Network. The Network is used to show the
dependencies between activities as well as the Critical Path
of the project.
1. Project Resource Plan Used to show the types and amount of resources required
• Brief Description in a project. It is presented in a Table form where the
• Table of Resources resources requirements are shown by resource type per
Requirement respective stage of the project.
2. Configuration Management Documents the CM activities, reporting and controlling
Plan 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
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
Product ID 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 day-
to-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
Product ID 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 Manager’s recommendations.
Reference
Derivation
1. Project Plan
2. Updated Stage Plan
3. Issue Log
4. Risk Log
5. 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
Product ID 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. Current Stage Plan with all the Actuals
2. Updated Project Plan (see M210)
3. Business Case review
4. Risk Log review
5. Issue Log review
6. Actual or Potential Problems/Obstacles and Suggested Solution
7. Next Stage Plan (see M220)
8. Decision for next stage (to proceed, terminate or others)
9. Commitment to resources of next stage
10. Appointment of Project Assurance
Derivation Notes of Meeting
Quality Criteria:
1. Are the documents accurate and agreed by the PSC members?
CM Requirement:
13-11
Product ID 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
Product ID 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
Highlight Report
Project : Reporting Period :
Stage : Page of
Project Time : Ahead wks On Schedule Behind wks
Expenditure : Underspent % On Budget Overspent %
1. 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.)
Prepared by : Date :
( )
13-13
Product ID 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 A brief description of functionality delivered as compared with that required
by users.
2. System Performance A brief description of the performance level of certain functionality, if any,
as compared with that specified by users.
3. Project Achievement A comparison of the project's achievements with the objectives set out in
the PID.
4. Resource Utilisation A comparison of the actual expenditure and resources usage with the
planned figures.
5. Productivity An assessment of the productivity achieved.
6. Project Issue Final statistics on project issues and their impact.
7. Quality Review Statistics for all quality work carried out.
8. Development Issues encountered or comments on the development methods and any
special techniques applied.
9. Project Management Issues encountered or recommendations for future enhancement or
modification of the project management method.
10. Problems Encountered Problems encountered during project and actions taken to solve them or
recommendations for future projects.
11. Others 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. Updated Project and Stage Plans
2. Project Initiation Document
3. Issue Log
4. Product Checklist
5. Observation and experience of the processes
6. Completed Work Packages
Timing 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
Product ID 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. Risk number
2. Description
3. Likelihood
4. Severity
5. Countermeasure(s)
6. 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
Product ID 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
CM Requirement:
1. Must be base-lined when work package is authorized
13-17
Product ID Q310
Product Name Quality Review Comment Form
Purpose To document the comment on the product being reviewed.
Composition
1. Project Name
2. Review No.
3. Product Name
4. Comment Serial - A sequential reference number referring to the comment
5. Location - The location within the product related to the comment
6. Description - Comment/observation
Sample Layout
Quality Review Comment Form
Project : Date :
Product: Review No. :
Comment Location Description
Serial
( )
13-18
Product ID 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. Project Name
2. Review No.
3. Product Name
4. Comment Serial - A sequential reference number referring to the comment
5. Location - The location within the product related to the comment
6. Follow-up Action
7. 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 : Date :
Product : Review No. :
Comment Location Follow-up Action Actioned Signed-off
Serial by by
(date) (date)
( )
13-19
Product ID 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 Description of Resolution Time Resource Baslined Within Decision Status Date of Change
No. Issue Adde Added Product Toler- Status Request No.
d Changed? ance? /Remarks
(Note: reference to supporting documents may be noted in the Remarks field.)
13-20
Product ID 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: Project:
Product Product Name & Work Package Planned Actual Achieved Reviewer/Date
ID File Reference Assigned to Completion Draft Quality Complete
Date Review
13-21
PRACTITIONER GUIDE ON APPENDIX E – USING THE RISK
PROJECT MANAGEMENT ANALYSIS CHECKIST
14. 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
PRACTITIONER GUIDE ON APPENDIX E – USING THE RISK
PROJECT MANAGEMENT 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
PRACTITIONER GUIDE ON APPENDIX F – RISK ANALYSIS
PROJECT MANAGEMENT CHECKLIST
15. APPENDIX F - RISK ANALYSIS CHECKLIST

(a) (b) (c) (d) (e)
Low risk Scale High risk Weighting Total
(range) (bxd)
Project Management
1 Full time, experienced PM 1234 Inexperienced or part time *

PM (5-7)
2 User management is 1234 Inexperienced user

experienced and likely to be management, with little (4-6)
active participators participation expected
Project Staff
3 Users expected to be of good 1234 Little user involvement *

quality, actively involved, and little relevant (3-5)
with relevant knowledge of knowledge expected
the system
4 High standard of supervision 1234 Span of supervision too

and narrow span of control wide and level of control (4-6)
inadequate
5 The technical team is 1234 Inexperienced team
experienced, of good quality lacking the appropriate (2-4)
and with appropriate skills skills
6 Staff are dedicated to the 1234 Staff have other

project responsibilities such as (3-5)
system maintenance
7 Low staff turnover 1234 High staff turnover

(2-4)
8 Sufficient staff 1234 Insufficient Staff *
(4-6)
Nature of the Project
9 A typical system 1234 A system development
development cycle, with cycle having no formal (2-4)
requirements definition, requirements definition,
system specification, system design and build
systems design, etc. merged etc.
10 No unique or new features 1234 Pioneering, new hardware

or software etc. (2-4)
11 Current main operations will 1234 Significant impact on

be affected minimally mainstream operations (3-5)
12 Little or no modification to 1234 Extensive modification

existing application software needed (2-5)
13 Little or no other 1234 Other projects being

development work being developed concurrently (4-5)
undertaken concurrently
14 Little/No dependence on 1234 Dependent on other
15-1
(a) (b) (c) (d) (e)

(range) (bxd)
existing or developing facilities not under the (3-6)
systems not under the control of staff on this
control of staff on this project
project
15 Project duration of 1 year or 1234 Project duration more than

less, or small number of 1 year, or a large number (2-4)
workdays compared with of workdays
other projects
16 Little constraint on 1234 Mandatory completion
completion date beyond date (3-5)
availability of resources
17 Plans and estimates are 1234 Planing and estimation

based on reliable data data are unreliable (3-6)
18 Investment appraisal and 1234 Approximations used;

estimates prepared and well estimates not properly (3-5)
documented, using proven documented; or based on
standards unproven standards
19 Suppliers are large, well 1234 Suppliers are new or one-

established companies man businesses (2-4)
20 Few user departments 1234 Several user departments

(4-6)
21 Work affects few sites which 1234 Many/remote sites are

are easily accessible to the involved (3-5)
team
Maturity of the Departmental Organisation

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

exists defined (2-4)
24 Clear delegation of authority 1234 Centralised management

is practised with little delegation (2-4)
25 Good relationship with user 1234 Relationship with user is

staff poor (2-4)
User Management
26 Full commitment from 1234 No commitment from *
Users’ Top Management Users’ Top Management (5-7)
27 High client responsibility, 1234 No client responsibility,

ownership ownership (4-6)
28 Low probability of Changing 1234 High probability of *

Ownership or Senior Changing Ownership or (5-7)
Management Senior Management
15-2
(a) (b) (c) (d) (e)

(range) (bxd)
29 Low probability of Changing 1234 High probability of *
Scope/Objectives Changing (5-7)
Scope/Objectives
30 No conflict between user 1234 Frequent conflicts

parties between user parties (4-6)
31 Brought forward from

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

Low risk if less than (Total of column (d) * 2.0)
The overall assessment of risk of this project is :-
(Tick one)
Very High Acceptable
High Low
The assessment and recommendations for meeting the risks with scale marked at "4" are given in the corresponding
PID.
15-3
PRACTITIONER GUIDE ON APPENDIX G – HINTS ON
PROJECT MANAGEMENT PREPARATION OF A PROJECT
INITIATION DOCUMENT
16. APPENDIX G - HINTS ON PREPARATION OF A PROJECT

INITIATION DOCUMENT
Area Check Item Tick
here
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 Check if all roles and responsibilities of each member in PSC are relevant and
Reference applicable to the project.
Terms of In case of more than one person takes up a single role (e.g. Senior User), state
Reference each of the specific areas of responsibility separately.
Organisation For in-house project, PM role is taken up by ITSD 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 Specify the Quality Criteria of each product (N/A for small projects).
Description
Product Specify which specific persons or parties are responsible for reviewing the
Description 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 :-
• Re-assess Business Case

• Approve Current Stage’s Products
16-1
PRACTITIONER GUIDE ON APPENDIX G – HINTS ON
PROJECT MANAGEMENT PREPARATION OF A PROJECT
INITIATION DOCUMENT
Area Check Item Tick

here
• 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 Ensure the following activities are included :-

Technical Plan
• 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 Include the activities of ‘Prepare Quality Plan’ and ‘Prepare Quality Assurance
Technical Plan 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 Ensure activities for ‘Project Closure Meeting’ and ‘Prepare Project Evaluation
Technical Plan Report’ are included at the end of the project.
Project Ensure there is no overlapping stage. (Overlapping of stages implies that the next
Technical Plan stage is started without the necessary review at the end of the preceding stage.)
Project A project stage is so designed to allow a major checkpoint for the PSC to review
Technical Plan 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 Ensure all project activities are included in the project technical plan. E.g.
Technical Plan 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
ON PROJECT MANAGEMENT APPENDIX H - GLOSSARY
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.
Project Evaluation Report

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 non-
conformance.
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 project’s 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

Prince2 Practitioner Guide On Project Management

Uploaded by

Copyright:

Available Formats

Prince2 Practitioner Guide On Project Management

Uploaded by

Document Information

Original Title

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

Prince2 Practitioner Guide On Project Management

Uploaded by

Copyright:

Available Formats

PRACTITIONER GUIDE

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

8.2.1 Objective ................................................................................................................................................8-13

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

PRINCE is a structured set of procedures originally designed specially for managing

This Guide composes of five sections:

3.2 OTHER REFERENCES

• PRINCE 2 Manual, CCTA 1996.

4. DEFINITIONS AND CONVENTIONS

The following acronyms are used in the text of this Guide:

ACPC Administrative Computer Projects Committee

5.1 CHARACTERISTICS OF A PROJECT

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;

5.2 OBJECTIVE OF PROJECT MANAGEMENT

The general objective of project management is to create a management environment for

5.3 WHAT IS PRINCE?

PRINCE projects always focus on delivering specified products to meet a specified

5.3.2 The Method

PRINCE is a process-based approach to project management. The processes define the

Quality in a project Plans

Directing a Project (DP)

Starting up a Initiating a Managing Closing a

• the sequence of delivery of the products;

6.1 BUSINESS CASE

6.1.1 What is a Business Case?

6.1.2 Developing a Business Case

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)

6.2.1 Project Steering Committee (PSC)

Executive: The chairperson, representing the interest of the customer, and

Senior User: Representing the users of the system (product).

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

The Senior Technical is accountable for ensuring that the products

Hints and Tips

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

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

Hints and Tips

• The PM/TM can be from User Department or ITSD/contractors. TM may be taken up

6.2.3 Project Assurance

Areas to be assured depends on where the project risks rest, e.g.:-

• viability of the Business Case

Hints and Tips

6.2.4 The Benefits

The benefits to be gained from the PRINCE recommended organization are:

Division of Roles and In the PRINCE recommended organization, roles and

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

to have a clear understanding of one's authority,

A plan is a statement of intent. It is an important component that provides a base for

A plan usually defines:

• The steps required in order to achieve a specified target

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