Project Menagement

Office of the Government Chief Information Officer

PRACTITIONER GUIDE

ON

PROJECT MANAGEMENT

[G38]

Version : 3.4

Jun 2005 The Government of the Hong Kong Special Administrative Region

The contents of this document remain the property of and may not be reproduced in whole or in part without the express permission of the Government of the HKSAR

PRACTITIONER GUIDE ON PROJECT MANAGEMENT CONTENTS

TABLE OF CONTENTS

1. PURPOSE.............................................................................................................................................................1-1

2. SCOPE ..................................................................................................................................................................2-1

3. REFERENCES.....................................................................................................................................................3-1 3.1 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


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


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 OGCIO.........................................................................................................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-1

1. PURPOSE

The purpose of this document is to provide guidelines on the project management method adopted in OGCIO. The method adopted is a customised version of PRINCE (Projects in Controlled Environments). PRINCE is a structured set of procedures originally designed specially for managing projects in IS/IT environments. PRINCE is developed in 1986 by the Central Computer and Telecommunications Agency (CCTA) which is part of HM Treasury and the centre of information systems policy in the British government. The Agency was later renamed as Office of Government Commerce (OGC). PRINCE has adopted an open strategy within which the methodology is publicly available. A customised version of PRINCE was introduced into OGCIO (the then ITSD) in 1992 and in 1994, it became the OGCIO (the then ITSD) standard of project management methodology. The methodology was further upgraded to PRINCE2 in 1998 following its launch in 1996 in the U.K. Revisions were made by OGC in April 2002 and this manual has also been revised accordingly.

PRACTITIONER GUIDE ON PROJECT MANAGEMENT SCOPE

2-1

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 OGCIO.

This Introduction section outlines the basic principles of project management and how PRINCE addresses them; it also shows how PRINCE fits with related aspects such as quality management and the management of risk. The PRINCE Components section explains and describes the major elements of project management, such as organization and control, and how PRINCE incorporates them. These components represent the 'raw materials' of good project management including quality management and the management of risk. The PRINCE Processes section describes the PRINCE process model which explains what have to be done to manage a project successfully. The Project Management Techniques section explains the various techniques of project management in PRINCE. The Application of PRINCE in OGCIO section documents the customisation of PRINCE for our department. This Guide is targeted for practitioners of the PRINCE methodology. It is designed to serve as a major reference for practitioners in their day-to-day project management work. The PRINCE Processes section provides a quick reference of the necessary steps and activities required in managing a project. Other sections provide information about the underlying principles and the associated techniques required in following the project management procedures.

PRACTITIONER GUIDE ON PROJECT MANAGEMENT REFERENCES

3-1

3. REFERENCES

3.1 STANDARDS None.

3.2 OTHER REFERENCES

PRINCE 2 Manual, CCTA 1996. Resources Estimation Guide [G19], OGCIO. Software Configuration Management Process Guide for Application Software [G46],

OGCIO. Managing Successful Projects with PRINCE2 OGC 2002.

PRACTITIONER GUIDE ON PROJECT MANAGEMENT DEFINITIONS AND CONVENTIONS

4-1

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 OGCIO environment are indicated in underline.

PRACTITIONER GUIDE ON PROJECT MANAGEMENT INTRODUCTION

5-1

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. OGCIO in the Government environment) Sub-contractors, who provide products or services to the Supplier. The Customer / Supplier environment assumes that there will be a Customer who will specify the desired outcome, make use of the final products and (in most cases) pay for the project, and a (prime) Supplier who will provide resources and skills to create that outcome.

5.2 OBJECTIVE OF PROJECT MANAGEMENT

The general objective of project management is to create a management environment for the effective delivery of business products according to the needs of a specific business case.


5-2

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.

Configuration Management

Change Control Business Case

Organization

Plans

ControlsManagement of Risk

Quality in a project environment

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-3

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. 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:

Directing a Project (DP)

Starting up a Project (SU)

Initiating aProject (IP)

Controlling a Stage (CS)

Closing a Project (CP)

Managing

Stage Boundary

(SB)

Managing Product Delivery

(MP)

Planning (PL)


5-4

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.

PRACTITIONER GUIDE ON PROJECT MANAGEMENT PRINCE COMPONENTS

6-1

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-2

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-3

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 :-

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).

Project Steering Committee (PSC)

Executive Senior User

Senior Technical

Team Manager (TM)

Project Manager (PM)

Project Assurance


6-4

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-5

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 teams performance, reports and finally returns the completed products to the PM. For example, a contractor responsible for producing certain products can be assigned the role of TM.

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

up by user for user-oriented task like User Acceptance Test or taken up by contractors on specific task out-sourced like LAN installation. For in-house projects, PM is usually taken up by OGCIO staff but for Turnkey and Information Technology Professional Services Arrangement (ITPSA) projects, it is taken up by the contractors; for details, please refer to section 9.5 on Turnkey Projects and section 9.6 on ITPSA Projects.

6.2.3 Project Assurance


6-6

It is the PSCs responsibility to monitor all aspects of the projects performance and products independent of the PM. This is the Project Assurance Function.2 Areas to be assured depends on where the project risks rest, e.g.:- viability of the Business Case effectiveness and usability of the solution feasibility of technical solution compliance to organisational and business strategy security Each PSC member is responsible for the areas of assurance that are related to his/her interest being represented. PSC can delegate the Project Assurance work to others who are independent of the PM and the rest of the project team, according to the needs and desires of the PSC. While the PSC has the ultimate responsibility to assure the integrity of the project, the delegate has no executive authority. Each assurance responsibility may be shared by more than one individual covering part of or the entire the project. The delegation shall be planned at Project Initiation Stage to facilitate resources control. The delegate reports to the PSC member that delegates. Hints and Tips In OGCIO, officer(s) from User Departments may take up project assurance regarding

the Users interest while OGCIO officers, e.g. a senior API, may take up project assurance regarding the project expenditures.

OGCIO project team may suggest an organisational structure on project assurance for PSC to approve. The common structure consists of three roles: Business Assurance Coordinator (BAC), User Assurance Coordinator (UAC) and Technical Assurance Coordinator (TAC). The three roles represent the business, user and technical interests respectively. A sample of Project Assurance Roles is detailed in Appendix C - Sample Project Assurance Roles Set-up.

6.2.4 The Benefits

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

Division of Roles and Responsibilities

In the PRINCE recommended organization, roles and responsibilities are suitably divided. Human resources of a project can be so arranged that the most appropriate skill and responsibility mix be assigned in

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.

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-7

the right place.

Clear Definition of Roles and Responsibilities

PRINCE emphases formal assignment of roles to all participants at the project start. It enables individuals to have a clear understanding of one's authority, responsibility and accountability so as to minimise or avoid conflicts, confusion, duplications and omissions.


6-8

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-9

within the project such as the stage boundaries. At end of each stage, Project Plans should be updated with actual figures and be assessed by the PSC with respect to the continuous viability of the business case. Stage Level Plan at stage level should detail work to be carried out during that stage by the involved parties. Stage Plans will identify, for a particular stage, the activities, end-products, the resource required and the costs. It is produced immediately before a stage and covers that stage in the detail necessary to give the PM day-to-day control of progress. For small projects, the PM may decide to combine the Stage and Project Plans. Technical Plan Technical Plans (typically in the form of a bar chart) are used to identify the sequence of events, to define timescales and to assign responsibilities for producing the end-products. A Project Technical Plan is mandatory for all projects and should identify the major control points within the project such as the stage boundaries. An example of a project technical plan is:

ID Name Start Date End Date1 Stage 0 - Project Initiation 2.5.95 29.5.95

2 Prepare PID 2.5.95 29.5.95

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

11 Stage 2 - Stage Name 14.11.95 8.1.96

12 Activity 3 14.11.95 11.12.95

13 Activity 4 12.12.95 8.1.96

14

50%

0%

0%

0%

F M A M J J A S O N D J F M A M1995

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-10

ID Name Start Date End Date1 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

6 Activity 1.2 27/06/95 24/07/95

7 Activity 1.3 25/07/95 21/08/95

8 Activity 1.4 22/08/95 18/09/95

9 Activity 1.5 19/09/95 16/10/95

10 Activity 2 17/10/95 13/11/95

11 Stage 2 - Stage Name 14/11/95 08/01/96

14

15

16

17

0%

0%

0%

0%

0%

0%

M A M J J A S O N D J F M1995

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

OGCI

O (md)

User (md)

Stage SM API APII SCO COI COII 0 Planned Actual

3.0 0.0

5.00.0

0.00.0

2.0 0.0

2.0 0.0

0.00.0

1 Planned Actual

20.00.0

110.00.0

90.00.0

15.0 0.0

30.0 0.0

40.00.0

2 Planned Actual

2.00.0

7.00.0

2.00.0

2.0 0.0

5.0 0.0

0.00.0

Project a. Planned b. Actual c. Est. to Complete d. Variance (b+c-a)/a

25.00.0

25.00%

122.00.0

122.00%

92.00.0

92.00%

19.0 0.0

19.0 0%

37.0 0.0

37.0 0%

40.00.0

40.00%


6-11

Expenditures

Stage Expenditure $000 0 Planned Actual

0 0

1 Planned Actual

9,200 0

2 Planned Actual

3,603 0

Project a. Planned b. Actual c. Est. to Complete d. Variance (b+c-a)/a

12,803 0 12,803 0%

Exception Plan An Exception Plan is only required if a project stage is forecast to exceed its planned tolerances. It would normally follow the Project Issue of an exception situation from the PM to the PSC. An Exception plan covers the time period from the present moment to the end of the current stage and permits the PM to show the change in work required to meet the new situation, the costs and the new tolerances set by the PSC.


6-12

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.

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

Ad Hoc

Direction

Ad Hoc

Direction

Mid Stage

Assessment

Authorise the Project

Confirm project Closure

End Stage

Assessment

Authorise Initiation

Highlight

Report

Work Package

Exception Plan

PID

Project Evaluation

Report

Follow-On Actions

Recommen-dations

Minutes of

ESA

Risk Log

Stage Plan

All aspects of a project

(scope, nature,

Business Case,

Output, etc.)

Minutes of Checkpoint

Review meetings

Work Package

Close

Issue Log

Project Issue

Report

Product Checklist

PSC

Project Manager

Team Manager

Work parties


6-13

regular assurance that the expectations will be met. I.e. controls are needed from one level to the next. Project control consists of three iterative elements: planning, monitoring and controlling. The plan plots what should be done, by whom and for how long it will take. Monitoring checks on what actually happens. Control acts on the monitoring information and decides if the plan needs to be modified. A major element of control is reporting, which inputs information to the monitoring process. The above figure shows the reporting between the management levels.

6.4.1 Project Steering Committee Controls Business Case Project should be justified by business case (see appendix D - PRINCE Product Description) at its initiation, and the business case should be continuously monitored as the project progresses. The viability of business case should be assessed at the end of each project stage (End-Stage Assessment). Should the business case be found to have changed or vanished, the PSC should make the appropriate business decision on whether to proceed, re-direct or terminate the project. This control mechanism helps prevent continual investment in unjustified projects. Starting Up A Project Senior management controls the inception of a project by the issue of trigger which signify the start of a project. In OGCIO, it is the Initial Request Statement (IRS) sent from user department to OGCIO, ACPC Funding Approval or the ITPSA Assignment Brief. PSC and the PM will then be appointed. In this project start up stage, the PSC will communicate with the PM the objectives and direction of the project. This often includes an outline business case, which justifies the expenditure on the project. With such information, the rest of the project organisation can be established. This includes the Project Assurance, the TM and the project team members. All aspects of the project will then be documented in a Project Initiation Document (PID) by the PM. Reference may be made to the process Initiating a Project (IP). The Project Initiation Meeting At the end of the project initiation stage, the PSC looks at two documents in the Project Initiation Meeting, the PID and the next stage plan before deciding whether to approve the next stage.


6-14

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-15

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-16

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-17

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-18

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-19

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-20

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-21

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-22

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-23

6.5.2 Risk Analysis

Risk analysis is essential for effective management of risk. It can be a powerful and effective way of bringing to the attention of the management:-

what the sensitive issues are, and to which they should be paying particular attention;

what actions they may need to take to increase the chances of success. It comprises four activities:

risk identification, which determines the potential risks that may be faced by the

project. In OGCIO, this can be done with the help of a Risk Analysis Checklist. A generic Risk Analysis Checklist is attached for reference in Appendix F. When a PM uses the checklist, it is important for him to consider laterally about the specific situations of the project being assessed.

risk evaluation, which determines how important each risk is, based on an assessment

of its likelihood and consequences to the project and business. A risk in a project may have low probability of occurrence, but if it does occur it will have major impact on the viability of the project. In other situations, a high probability risk may have little impact. The probability of a risk occurring and its impact, must be taken together to identify those which require particular consideration.

response identification, which decides whether the level of each risk is acceptable or

not and, if not, what actions can be taken to make it more acceptable. The actions are broadly categorized into five types:

prevention, where countermeasures are put in place which either stop the threat or

problem from occurring, or prevent it from having any impact on the project or business

reduction, where the actions either reduce the likelihood of the risk developing, or

limit the impact on the project to acceptable levels transference, which is a specialist form of risk reduction where the impact of the

risk is passed to a third party via, for instance, an insurance policy or penalty clause contingency, where actions are planned and organised to come into force as and

when the risk occurs acceptance, where the PSC decides to go ahead and accept the possibility that the

risk may occur (believing that either the risk will not occur or the countermeasures are too expensive).


6-24

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-25

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.

Evaluate the risks

Identify suitable responses to risks

Identify the risks

RISK ANALYSIS PHASE

RISK MANAGEMENT PHASE

Select

Monitor and report

Plan and resource


6-26

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 OGCIO, please refer to Quality Manual (S&M Reference [Q1]), Quality Planning Procedures (S&M Reference [Q2]) and Quality Assurance Review Procedures (S&M Reference [Q3]).

Quality Planning which establishes the objectives and requirements for quality and

lays out the activities for the application of the quality system. In the Project Initiation Document, the quality approach for the whole project is defined in the Project Quality Plan. It is important that the Customer's quality expectations are understood and documented prior to project commencement. Each Stage Plan specifies in detail the required quality activities and resources, with the detailed quality criteria shown in the Product Descriptions.

Quality Control, which is the means of ensuring that products meet the quality criteria

specified for them. Quality control is about examining products to determine that they meet requirements. Quality Review is the primary technique in performing project quality work for PRINCE. It is fully described in the Project Management Techniques section of the manual.

Hints and Tips Both the Customer and the Supplier may have quality systems. The project may have to

use one of these systems or an agreed mixture of both.


6-27

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 projects software assets are important to OGCIO and the user departments and have

to be managed by the SCM, which makes it a mandatory process in OGCIO.

Roles and responsibilities are detailed in OGCIO Software Configuration Management Process Guide for Application Software (S&M Ref. [G46]). Briefly, there are 5 roles in SCM: Configuration Board, Configuration Management Officer, Configuration Librarian, Configuration Auditor and the Impact Analysis Group. The Configuration Management Officer should be responsible for SCM of a project or system in production. The Configuration Librarian role may be delegated to someone, who would maintain a SCM Library and implement the version control processes. The Impact Analysis Group will conduct impact analysis of Change Requests and recommend implementation option to Configuration Board, which is the decision-making authority. The Configuration Auditor will conduct the Physical Configuration Audit at certain checkpoints as pre-defined in the SCM plan. If considered necessary, the SCM plan can be extended to include other important 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-28

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. Con

Documents

Project Menagement