PRINCE 2 FULL DETAIL
PROJECT MANAGERS COMPANION
SECTION XX - A DETAILED INTRODUCTION TO PRINCE 2
DETAILED INTRODUCTION TO PRINCE 2
1. COMPONENTS INTRODUCTION 7
2. KEY COMPONENTS 7
3. THE REMAINING COMPONENTS: 7
4. PROCESSES INTRODUCTION 8
5. THE PROCESSES 8
5.1 LINK WITH TECHNIQUES 9
5.2 CONTEXT 9
5.3 PROCESS DESCRIPTION 9
5.4 RESPONSIBILITIES 9
5.5 INFORMATION NEEDS 9
5.6 KEY CRITERIA 9
5.7 HINTS AND TIPS 10
6. THE PROCESSES 10
6.1 PROCESS SU - STARTING UP A PROJECT 10
6.2 INITIATING A PROJECT 10
6.3 PROCESS DP - DIRECTING A PROJECT 11
6.4 MANAGING STAGE BOUNDARIES 12
6.5 PROCESS CS - CONTROLLING A STAGE 12
6.6 PROCESS MP - MANAGING PRODUCT DELIVERY 13
6.7 PROCESS CP - CLOSING A PROJECT 14
7. THE PLANNING PROCESS 15
8. ORGANISATION INTRODUCTION 16
8.1 ORGANISATION STRUCTURE: 16
8.2 ROLES AND RESPONSIBILITIES: 16
8.3 UP-DATING THE ORGANISATION: 17
9. PROJECT ORGANISATION AND STAFFING INTRODUCTION 17
9.1 THE PROJECT BOARD 17
9.1.1 Executive: Prime Responsibility 17
9.1.2 Senior User/Customer: Prime Responsibility: 17
9.1.3 Senior Supplier: Prime Responsibility: 18
9.2 THE PROJECT MANAGER 18
9.3 TEAM MANAGER(S) 19
9.4 PROJECT ASSURANCE 19
9.5 PROJECT SUPPORT 20
9.6 PRINCE VERSION 1 PROJECT ASSURANCE TEAM 20
10. PLANNING INTRODUCTION 20
10.1 PRODUCT PLANS: 20
10.2 ACTIVITY PLANS: 20
10.3 RESOURCE REPORTS: 21
10.4 QUALITY PLAN: 21
10.5 PRODUCT BREAKDOWN STRUCTURE 21
10.6 IDENTIFICATION OF PRODUCTS 22
10.7 PRODUCT DESCRIPTIONS: 23
10.8 PRODUCT FLOW DIAGRAMS 24
11. PERT NETWORK (ACTIVITY NETWORK) 24
11.1 FIRST STEPS: 24
11.2 CONSTRUCTING THE NETWORK 25
11.2.1 Earliest Start Time: Earliest Finish Time: 26
11.2.2 Latest Start Time: Latest Finish Time: 26
11.2.3 Total Float: 26
11.2.4 The Critical Path: 27
11.3 EARLIEST START CONCEPTS: 27
11.4 RESOURCE REPORTING 27
11.5 PROJECT MANAGEMENT EFFORT & COSTS: 27
11.6 GRAPHICAL SUMMARY: 28
11.7 USING THE GRAPHICAL SUMMARY: 28
11.8 EARNED VALUE CONCEPTS 28
12. SUMMARY 29
13. PRINCE VERSION 1 COMPARED TO VERSION 2 INTRODUCTION 29
13.1 TERMINOLOGY 29
13.2 THE PROCESSES 30
13.3 CUSTOMER:SUPPLIER 30
13.4 WORK PACKAGES 31
13.5 RISK MANAGEMENT 31
13.6 QUALITY MANAGEMENT 31
13.7 QUALITY REVIEWS 31
13.8 CONFIGURATION MANAGEMENT 32
13.9 CHANGE CONTROL 32
13.10 PROJECT FILING 32
13.11 ORGANISATION 32
13.12 PROJECT MANDATE & PROJECT BRIEF 34
13.13 PROJECT PLANNING 34
13.14 PRODUCT DESCRIPTIONS 34
13.15 ESTIMATING 35
13.16 CONTROLS 35
13.17 THE BUSINESS CASE 36
13.18 SMALL PROJECTS 36
13.19 HINTS AND TIPS 37
13.20 SUMMARY 37
14. PRODUCT BASED PLANNING INTRODUCTION 37
14.1 PRODUCT BREAKDOWN STRUCTURE 38
14.2 IDENTIFICATION OF PRODUCTS 38
14.3 PRODUCT DESCRIPTIONS: 39
14.4 PRODUCT FLOW DIAGRAMS 40
14.5 ACTIVITY PLANNING 40
15. RESOURCE PLANNING INTRODUCTION 40
15.1 PRODUCING THE RESOURCES REPORT 41
15.2 PROJECT MANAGEMENT EFFORT & COST: 41
15.3 GRAPHICAL SUMMARY: 41
15.4 USING THE GRAPHICAL SUMMARY: 41
15.5 EARNED VALUE CONCEPTS 42
15.6 SUMMARY 42
16. CONTROLS INTRODUCTION 42
16.1 MANAGEMENT CONTROLS: 42
16.2 TEAM REVIEWS: 43
16.3 QUALITY REVIEWS: 43
16.4 CONFIGURATION CONTROLS: 43
17. PRINCE 2 CONFORMATION INTRODUCTION 43
17.1 PROCESSES 43
17.2 ORGANISATION: 44
17.2.1 Project Board: 44
17.2.2 Project Manager: 44
17.2.3 Project Assurance: 44
17.3 PLANS: 44
17.3.1 Product Plans: 44
17.3.2 Planning Levels: 45
17.3.3 Stages: 45
17.3.4 Plans Content: 45
17.4 CONTROLS: 45
17.5 QUALITY MANAGEMENT: 45
17.6 BUSINESS CASE/VIABILITY: 46
18. WHAT IS PRINCE INTRODUCTION 46
18.1 BENEFITS 46
18.2 PROJECT STRUCTURES 47
18.3 STAGES 47
18.4 PROCESSES 48
18.5 COMPONENTS 49
18.6 TECHNIQUES 49
18.7 PROCESSES 49
18.8 THE ORGANISATION COMPONENT 50
18.8.1 The Project Board 50
18.8.2 Project Manager 50
18.8.3 The Team Manager 51
18.8.4 Teams 51
18.8.5 Project Assurance 51
18.8.6 Project Support 51
18.9 PLANNING 52
18.10 PRODUCTS/DELIVERABLES AND ACTIVITIES 52
18.11 SPECIALIST PLANNING 53
18.12 RESOURCE PLANNING 53
18.13 QUALITY PLANNING - BS/EN/ISO9000 54
18.14 EXCEPTION PLANNING 54
18.15 THE CONTROLS COMPONENT 55
18.15.1 Management Controls 55
18.15.2 Project Initiation 55
18.15.3 End Stage Assessment (ESA) 55
18.15.4 Tolerance & Mid Stage Assessment (MSA) 55
18.16 PROJECT CLOSURE 56
18.17 PRODUCT/DELIVERABLES CONTROLS 56
18.17.1 Quality Controls - Quality Review 56
18.17.2 Checkpoints 57
18.17.3 Change Controls 57
18.17.4 Configuration Management 57
18.18 CO-ORDINATION 57
18.19 FURTHER INFORMATION 57
18.20 SMALL TO MEDIUM SIZE PROJECTS 58
18.21 MINOR PROJECTS 58
19. PROCESS SU - STARTING UP A PROJECT 58
20. INITIATING A PROJECT 59
21. PROCESS DP - DIRECTING A PROJECT 60
22. MANAGING STAGE BOUNDARIES 60
23. PROCESS CS - CONTROLLING A STAGE 61
24. PROCESS MP - MANAGING PRODUCT DELIVERY 62
25. PROCESS CP - CLOSING A PROJECT 63
26. THE PLANNING PROCESS 64
27. A-Z PROJECT MANAGEMENT TECHNIQUES INTRODUCTION 65
27.1 ACCEPTANCE CRITERIA 65
27.2 ACCEPTANCE LETTERS 66
27.3 APPROVAL TO PROCEED 66
27.4 BASELINE 66
27.5 THE BUSINESS ACCEPTANCE LETTER 67
27.6 BUSINESS ASSURANCE 67
27.7 BUSINESS ASSURANCE CO-ORDINATOR (BAC) 67
27.8 BUSINESS CASE 67
27.9 CHANGE AUTHORITY 67
27.10 CHECKPOINT 67
27.11 CONFIGURATION MANAGEMENT METHOD 67
27.12 CONTROL POINTS 68
27.13 DETAILED PLANS 68
27.14 END STAGE ASSESSMENT 68
27.15 EXCEPTION REPORT 68
27.16 EXECUTIVE MEMBER OF THE PROJECT BOARD 68
27.17 HIGHLIGHT REPORT 69
27.18 IMPACT ANALYSIS 69
27.19 INFORMAL QUALITY REVIEW 69
27.20 IS 69
27.21 ISO9000 69
27.22 IT 69
27.23 LESSONS LEARNED REPORT 69
27.24 MID-STAGE ASSESSMENT (MSA) 70
27.25 OFF-SPECIFICATION REPORT (OSR) 70
27.26 OPERATIONS ACCEPTANCE LETTER 70
27.27 PAT 70
27.28 PBS 71
27.29 PFD 71
27.30 PIR 71
27.31 PIR 71
27.32 POST IMPLEMENTATION REVIEW (PIR) 71
27.33 PRINCE 71
27.34 PROCESS 71
27.35 PRODUCT/DELIVERABLE/OUTPUT 72
27.36 PRODUCT BREAKDOWN STRUCTURE (PBS) 72
27.37 PRODUCT DESCRIPTION 72
27.38 PRODUCT FLOW DIAGRAM (PFD) 72
27.39 PROJECT 72
27.40 PROJECT ASSURANCE TEAM (PAT) 72
27.41 PROJECT BOARD 73
27.42 PROJECT BRIEF 73
27.43 PROJECT CLOSURE 73
27.44 PROJECT EVALUATION REVIEW/LESSONS LEARNED 73
27.45 PROJECT FILE 73
27.46 PROJECT GANTT PLAN 74
27.47 PROJECT INITIATION DOCUMENT (PID) 74
27.48 PROJECT ISSUES LOG 74
27.49 PROJECT ISSUE REPORT (PIR) 74
27.50 PROJECT MANAGEMENT STANDARD; PROJECT MANAGEMENT SYSTEM 75
27.51 PROJECT RESOURCE PLAN (PRP) 75
27.52 PROJECT SUPPORT OFFICE (PSO) 75
27.53 PSO 75
27.54 PROVIDER 76
27.55 QUALITY ASSURANCE (QA) 76
27.56 QUALITY CONTROL 76
27.57 QUALITY CRITERIA 76
27.58 QUALITY MANAGEMENT 76
27.59 QUALITY MANAGEMENT STANDARD (QMS) 76
27.60 QUALITY PLAN 76
27.61 QUALITY REVIEW (QR) 76
27.62 QUALITY MANAGEMENT SYSTEM (QMS) 77
27.63 REQUEST FOR CHANGE (RFC) 77
27.64 REVIEWER 77
27.65 RFC 77
27.66 ROLES AND RESPONSIBILITIES 77
27.67 SENIOR BUSINESS 77
27.68 SENIOR SUPPLIER 77
27.69 SENIOR USER 78
27.70 SPOCE 78
27.71 SPOCETTE 78
27.72 STAGE 78
27.73 (SPECIALIST) TEAM MANAGER 79
27.74 STAGE RESOURCE PLAN (SRP) 79
27.75 (SPECIALIST) TEAM 79
27.76 STAGE PLAN (TIMESCALE/GANTT CHART) 79
27.77 SYSTEM ACCEPTANCE LETTER 79
27.78 TEAM MANAGER 79
27.79 TECHNICAL 79
27.80 TECHNICAL ASSURANCE CO-ORDINATOR (TAC) (PRINCE V.1) 80
27.81 (TECHNICAL) EXCEPTION 80
27.82 TECHNICAL (OR SPECIALIST) MANAGEMENT STANDARD 80
27.83 TERMS OF REFERENCE 80
27.84 TOLERANCE 80
27.85 TRANSFORMATION 81
27.86 USER 81
27.87 USER ACCEPTANCE LETTER 81
28. PROJECT INITIATION DOCUMENT INTRODUCTION (CHECKLIST) 81
28.1 THE PROJECT 81
28.2 STAFFING 81
28.2.1 Structure 81
28.2.2 Roles and Responsibilities 82
28.3 PLANS 82
28.4 CONTROLS 84
28.5 PROJECT MANAGEMENT 84
28.6 QUALITY 84
28.7 PROJECT HOUSEKEEPING (CONFIGURATION MANAGEMENT) 85
29. BUSINESS CASE INTRODUCTION 85
29.1 BUSINESS BENEFITS: 85
29.2 RISK ASSESSMENT AND PROPOSALS: 85
1. COMPONENTS INTRODUCTION
Within PRINCE 2 there are eight Components - they are:
Organisation;
Planning;
Controls;
Stages;
Management of Risk;
Quality in a Project Environment;
Configuration Management;
Change Control.
2. KEY COMPONENTS
All the Components are used by the PRINCE 2 Processes and as such, all are equally important. The three key Components essential for success are sometimes referred to as the "Three Pillars of Project Management"; they are the PRINCE 2 components of Organisation, Planning, and Control and can be expected to be present within any properly managed project.
It is common to find emphasis on Planning, often at the expense of its two sisters. However, the component of Organisation, addressing the key "people" aspects is arguably the most important of all, bringing personality, grit and determination to the project.
The Three Pillars must be built on a suitable foundation - this is the Project Business Case addressing "Why" the project should be initiated and continued. The Business Case includes a Summary of Benefits (possibly in the form of a Costs:Benefits Analysis) and the Project Risks, supported by Proposals for managing the identified risks.
Providing an umbrella for the Three Pillars and Foundation are the Standards for Quality, often in the form of a BS/EN/ISO9000 Quality Management System. Additionally, Professional Standards, Approaches and Ethics will contribute to the protective aegis.
But most important of all is the underpinning component of common-sense, providing bedrock for the Three Pillars, their foundation, and the protective canopy!
3. THE REMAINING COMPONENTS:
Each project will need to address the remaining five Components in one form or another. PRINCE 2 requires that any project will comprise at least two Management Stages (the first always being a Stage of "Initiation". A Risk Assessment must be carried out at the commencement of the project and up-dated at the end of each Management Stage. Proposals to manage identified risks must be in place and the changing level of risk logged as the project progresses.
Configuration Management and Change Controls (along with the Technique of Filing Products and Deliverables) are essential - PRINCE 2 states that Configuration Management is NOT optional! Changes will always be looming and the project must cater for this; PRINCE 2 includes Change Control as a Component and requires that all errors, deficiencies, departures from the agreed Specification, and ideas be raised as Project Issues.
SPOCE Project management Limited have assembled a PRINCE 2 Model which summarises all the above in an easy to understand diagram, also available as a mouse-mat - for a free copy please call Livia Inglis on UK 01202-780740.
4. PROCESSES INTRODUCTION
PRINCE 2 differs from other Methods by focusing on the Processes that are inherent in managing a successful outcome for any project. The Processes identified in PRINCE 2 represent the minimum content for a PRINCE-compliant project but this certainly is not intended to encourage the slavish following of any or all of them!
The key to successful management of any type or size of project is to ensure that each of the Processes identified within PRINCE 2 are addressed in one form or another; Exactly how each of Processes is actually interpreted as a project management procedure is left to the implementing organisation, or in some cases, the Project Board and Project Manager.
5. THE PROCESSES
There are eight Processes in all, identified within the PRINCE methodology; the eighth, common-to-all, Process of "Planning (PL)" is used by all other Processes to some extent. The Processes are:
* Starting Up A Project (SU)
* Initiating A Project (IP)
* Directing A Project (DP)
* Managing Stage Boundaries (SB)
* Controlling A Stage (CS)
* Managing Product Delivery (MP)
* Closing A Project (CP)
5.1 LINK WITH TECHNIQUES
All the Processes link with Techniques, some of which are identified and discussed within the PRINCE Manual and some which are general or specific approaches which the implementing organisation may already be using or may wish to introduce as part of the general improvement in managing projects effectively.
The Processes do not link with any required way of achieving the process outcome - it is important to understand this aspect as it reflects the flexibility which comes as part of the PRINCE 2 package and underlines the key differences between versions 1 and 2.
Each of the Process Models are described by reference to a common formula:
* The Fundamental Principles
- the reason(s) for the Process;
- the project management aims for the Process;
- why the Process is fundamental to good project management practice and therefore a requirement in any PRINCE-compliant project.
5.2 CONTEXT
- the relationship with the other Processes and external activities. A Context Diagram is provided for each Process showing the flows of information into and out of the Process.
5.3 PROCESS DESCRIPTION
- an explanation of the objectives of the Process and a statement of the steps contained within it. The steps identified are in no particular order and are not intended to be comprehensive.
5.4 RESPONSIBILITIES
- identification of who should be held accountable for the successful conduct of the Process, and responsible for its management.
5.5 INFORMATION NEEDS
- the key information needed for the Process to function in such a way to meet its objectives. The information needs identified might take the form of Products/Deliverables, Plans, Reports, Decisions etc.
5.6 KEY CRITERIA
- identification of significant issues which will impact upon and affect the successful working of the Process.
5.7 HINTS AND TIPS
- guidance on the application of the Process within a PRINCE environment; the method recommends that this section be augmented by reference to specific situations encountered during the use of PRINCE on projects within the implementing organisation.
Much of the PRINCE Manual is given to describing the Processes using the above headings. Understanding the structure of the Processes and their objectives is fundamental to the successful use of the method. PRINCE 2 may be likened to an organic structure which must be allowed to mature and adapt to fit changing circumstances and new knowledge within the host organisation; up-dating the Process Models and descriptions, especially with regard to the Hints and Tips section is recommended to achieve this.
6. THE PROCESSES
The Processes (plus Planning) are detailed within the PRINCE 2 Manual; a digest of each of the Processes follows:
6.1 PROCESS SU - STARTING UP A PROJECT
This is the first Process within a project. A Project Mandate in the form of a memo or informal request will normally trigger this Process. The three significant outputs from the Start-up Process are:
* to produce the Project Brief; This will normally contain the formal Terms of Reference for the Project together with an Outline Business Case, based on the information contained in the Project Mandate.
* to design and appoint the Project Management Team;
* to create a suitable Plan for the Initiation Stage.
6.2 INITIATING A PROJECT
This Process is aimed at ensuring that a firm foundation and baseline exists for the project and that everyone involved understands what the project is seeking to achieve. The major outputs for this Process are:
* to identify the business benefits and risks and to evaluate proposals for managing identified areas of risk, thus confirming that an acceptable Business Case exists for the project;
* to provide a Foundation for the project from which the Project Initiation Document can be prepared.
* to provide Decision Support Information to enable the Project Board to confirm the initial (and ongoing) viability for the project;
* to encourage the Project Board to take Ownership of the project;
* to provide sufficient information for the Project Board to Approve the whole project in principle and to Commit Resources for the next stage of the project;
* to provide a Baseline for all decision-making for the duration of the project;
* to initiate the project in an Orderly manner, thus setting "Norms" for the remainder of the project;
* to monitor the Progress of the Project Initiation Process against the approved plans.
The initiation stage of any project is a key contributor to its eventual outcome. The time, effort and resources invested in this stage will be well worthwhile, especially if some unforeseen problem occurs during the project.
The Project Board and Project Team will have firm ground on which to base decisions about proposed changes in direction and investment of resources. Another major, but intangible output from this Process is the understanding that individuals within the Project Management Team will gain about the nature, scope and possible pitfalls that the project may have to face.
6.3 PROCESS DP - DIRECTING A PROJECT
This Process operates throughout all stages of the project, from Project Start-up through to Project Closure and is the primary concern of the Project Board.
They achieve this by managing by exception, monitoring through reports provided primarily by the Project Manager, and controlling through a series of key decision points. The key Sub-Processes break into the following four areas:
* Control of the Initiation of the project ensuring it has the best possible start;
* Control of the Stage Boundaries, committing new and additional resources as the project progresses towards its ultimate aim;
* Ad-hoc Decision-making and Direction, monitoring progress and providing advice and guidance as necessary;
* When the project has achieved its outcome, or is no longer considered to be a viable business proposition, arranging for Project Closure, bringing the whole undertaking to a controlled finish.
This Process does not cover the day-to-day activities of managing the project - these rest with the Project Manager. The Process is positioned at the level of management residing above the Project Manager.
6.4 MANAGING STAGE BOUNDARIES
To achieve a successful outcome to the project, it is necessary to break it into smaller, discrete packages to enable the Project Team to focus on specific Outputs, Products or Deliverables; this approach provides the concept of Project Stages. By controlling the start and finish of each stage, specific attention can be given to whether the Stage Products/Deliverables have all been completed in accordance with their Quality Criteria, whether the remaining project Products/Deliverables are still required, and whether the Business Case for the project remains viable. The aims are:
* to assure the Project Board that all the Products/Deliverables planned for the current stage have been completed and meet their Quality Criteria;
* to provide the information on timescale, technical achievement, and the budget needed to enable the Project Board to assess whether the overall project Business Case is still viable, and whether the Benefits can be achieved within an acceptable level of risk;
* to provide decision-support information on the Status of the current stage and the overall project, which will enable the Project Board to reach a decision on final completion of the current stage, authorise the start of the next stage, and to endorse the overall project.
* to provide a vehicle for stating the Tolerance which may be allowed for the next Stage. Tolerance is a control providing cost and time "trigger-figures" beyond which the Project Manager may not progress without the approval of the Project Board.
* to record any information or Lessons Learned which might impact on later stages of the project, or on the organisation as a whole.
The Process is an iterative one as the project proceeds from one stage to the next. Controlling the start and end of stages is a key control process for the Project Board and incorporates all the key aspects of directing a project.
The steps of this Process may also be used when creating an Exception Plan, where a significant departure from the approved plan has occurred and Tolerance has been exceeded. In order to reach a decision on the future of the project, the Project Board will need to consider an impact analysis, options appraisal, and a recommendation for action prepared by the Project manager; these will all need to be supported by an up-dated Business Case confirming the benefits and re-appraising the risks.
6.5 PROCESS CS - CONTROLLING A STAGE
Following the Project Board's decision to approve a Stage, the Project Team must be fully focused on delivery of the Products, to their stated Quality Criteria, within the approved timescales and budget, within the stated Tolerances.
This Process forms the main part of the Project Manager's effort on the management of the project, and provides the direction for the day-to-day management of the Stage and the overall project.
All through the Stage there will be an on-going cycle of:
* authorising Packages of Work that must be completed during the Stage;
* gathering Progress Information about the work carried out and the resources and effort expended;
* watching for Changes to the approved plan; managing any changes raised formally against the project (Project Issues) and making decisions on the introduction of beneficial changes provided these do not result in the Stage Plans exceeding the Tolerance;
* reviewing situations for Stage and Project Impact;
* reporting to the Project Board and to other members of the Project Management Team;
* approving and initiating any Corrective Action.
It may be expected that for much of the time, controls during a Stage will follow a regular pattern. However, project management comes to the fore when things are not going in accordance with plan and it is then that the Project Manager must use knowledge, Processes, Techniques, political and people-handling skills on an "as required" basis to achieve the required result.
6.6 PROCESS MP - MANAGING PRODUCT DELIVERY
Essentially this Process is aimed at managing the interface between the Customer Project Manager and the Supplier Project Manager ensuring that work is actually progressing in accordance with the customer's expectations and that all the planned Products are created and delivered within the agreed timescales and contract price or internally approved budget, and meet their approved Quality Criteria.
This Process is also relevant to the control of Work Packages authorised for production by internal Team Members. The main difference is that where resources are under the direct control of the Project Manager the authorisation and acceptance procedures will be less formal.
The Process comprises:
* making certain that work on Products allocated to each external Team or Team Member resource is properly Authorised;
* ensuring that Packages of Work are identified, discussed, agreed, authorised and accepted by those responsible for the creation of Products;
* checking that all Interfaces between the Customer and Supplier organisations are identified, recorded, observed and handled in an appropriate way;
* ensuring that all the Work is actually Carried Out, as agreed;
* ensuring that the Progress of Work and Forecasts of the time and effort to completion are regularly assessed;
* checking that all finished Products conform to their agreed Quality Criteria;
* obtaining Approval for completed Products. This will usually be at three levels - Author and Reviewer level, Project Manager level, and ultimately endorsement by the Project Board at the end of each Project Stage. These levels of approval will be reflected in both the customer and specialist supplier organisations, although it is not essential that either will be working within a PRINCE 2 environment; it is essential, however, that all involved are working within a suitably controlled project management environment.
This Process will operate continuously throughout each Stage; it provides a separation between the Customer Project Manager and the Supplier Project Manager and requires the interface between the specialist providers (be they internal or external) and the Customer to be identified, defined and operated. Care must be taken to ensure that the interfaces are neither missed nor lost, and that bureaucracy is kept to the absolute minimum consistent with effective control.
Where a Project Manager allocates work directly to individuals responsible for carrying out the work package, this Process may not be needed.
6.7 PROCESS CP - CLOSING A PROJECT
At its conclusion, the project must be closed down in an orderly and firm manner. The end of a project may arise when all the planned work has been completed and the Products/Deliverables finished and signed off as meeting their stated Quality Criteria. Alternatively a project might be brought to a premature conclusion because of changes to requirement, removal of resources or unacceptable slippage of time, effort or costs.
Most of the work involved in this Process is concerned with preparation of information for the Project Board in order for it to make the decision to close the project, or not. Rather like Project Initiation and Stage Initiation, this Process provides a decision-support structure; it aims to:
* ensure that the Objectives for the project have been met;
* confirm that the Customer is Satisfied with the outcome;
* obtain Formal Acceptance of the project Products/Deliverables;
* confirm that all Products/Deliverables have been handed over to the Customer, and that these have been accepted;
* ensure that where Ongoing Support, enhancement and maintenance is appropriate (and required), suitable provision has been made;
* identify any recommendations for Follow-on Actions and document these in a "Continuity Memo";
* Capture (this is carried out throughout the project) and finalise the "Lessons Learned" and publish these in a suitable report for the Project Board;
* Prepare an "End Project Report" for sign-off by the Project Board;
* Notify the Customer/Sponsor/Host Organisation, as appropriate, of the Intention to Close the project, disband the project organisation and release the resources.
Obviously, it will be difficult to close down a project in an orderly manner if the expectations and criteria for completion and close-down have not been agreed at the outset and this will normally have been done and the final Acceptance Criteria included within the Project Initiation Document. Project staff and managers should be provided with as much notice as possible in order for them to plan their return to normal operations. Thanks to those who have contributed to the project are also in order!
7. THE PLANNING PROCESS
Planning embraces PRINCE 2 Components, Processes, and Techniques and is an on-going activity throughout the project. Understanding of the tasks involved and the possible pitfalls will emerge from planning the project and stages; control can only be exercised in as much detail as the project plan allows; and the approaches to planning, using manual or software supported techniques is a matter of preference and choice for the implementing organisation.
Planning for all but the smallest projects is best tackled using a software support tool as the time saved in the longer term will more than repay the initial outlay, especially where complicated inter-dependencies exist between Products and Activities.
The philosophy behind the PRINCE 2 planning concepts are:
* Plans are constructed by identifying the final Products/Deliverables and all associated intermediate Products/Deliverables;
* Products/Deliverables are defined and specified by producing associated Product Descriptions;
* The Activities and associated Resources are identified; all Activities must be thought through to a level consistent with the control requirements identified in the Project Initiation Document;
The planning framework incorporated in version is intended to cater for any type or size of project - the steps are:
* Step 1: Identify and Define what Products/Deliverables are needed;
* Step 2: Determine the sequence in which each Product/deliverable should be produced;
* Step 3: Identify the Activities needed for the creation of the Products/Deliverables.
After the initial steps the following come into play:
* Estimate the effort for each Activity;
* Estimate the Duration of each Activity;
* Decide when Activities should be carried out, and by whom;
* Agree the Quality Control Activities and Resources required;
* Calculate the Cost of the Effort;
* Identify the Management and Specialist Control Points.
Because of the wide scope of Planning (it embraces Components, processes and Techniques and is used throughout the PRINCE 2 project cycle) it is recommended that the techniques, and local standards for planning approaches (eg use of a standard software planning tool) be pursued separately.
8. ORGANISATION INTRODUCTION
The Organisation component refers to two key areas - the organisation structure for the people involved in the project (with special emphasis on the management, support and decision-making staff) and their roles, responsibilities and authority within the project.
8.1 ORGANISATION STRUCTURE:
A standard organisation structure is suggested by PRINCE, although this may be readily modified to suit the organisation, people involved, nature of the project, existing standards and the organisational culture.
8.2 ROLES AND RESPONSIBILITIES:
To ensure that everyone involved in the project has a definitive statement of the contribution expected of them, roles and responsibilities are defined at Project Initiation. Role Descriptions are defined for all the project management team, including the key decision makers (the Project Board), Project Assurance, Project Manager and Team Managers (where appointed), Project Support Staff , and Project Team Members (internal and external).
Where an organisation is controlling a number of projects under the PRINCE Methodology, it is beneficial to define a "standard" organisation structure and roles and responsibilities, ready for "fine tuning" by each Project Manager.
8.3 UP-DATING THE ORGANISATION:
The organisation structure and the associated role descriptions will be reviewed and, if necessary, adjusted and up-dated at the end of each Management Stage in the "Managing Stage Boundaries (SB)" Process.
9. PROJECT ORGANISATION AND STAFFING INTRODUCTION
Project organisation and staffing is the key to the successful management of any project.
If the project staff have the required specialist competence, understand exactly what is expected of them, and have the will to make the venture work, then the project will have an excellent chance of success.
At the top of the organisation there will normally be a strategy body (Corporate Management or Programme Management bodies) responsible for interpreting the overall objectives of the organisation into working systems or other outcomes.
The Programme Management body will be responsible for a number of projects and will appoint a Project Board (PB), usually one, for each development.
Where a particularly large development is envisaged, the Project Board will be responsible for delivering a number of projects, each one inter-related and supporting the overall objective.
9.1 THE PROJECT BOARD
The Project Board is the owner of the project and has overall responsibility for delivering the required outcome.
It is the ultimate project authority and owns the Process "Directing The Project" which incorporates the initiation, direction, review and eventual closure of the project.
To meet these responsibilities, Project Board members must have the authority required to commit resources and to initiate new work. These are the prime selection criteria for Project Board members.
The Project Board comprises representatives from three functional areas:
9.1.1 Executive: Prime Responsibility
to ensure the development is capable of achieving the expected benefits and that the project is completed within the costs and timescales approved by the Strategy Body.
9.1.2 Senior User/Customer: Prime Responsibility:
to represent the interests of the user/customer department(s) affected by the project, and to monitor progress against the requirements of user/customer management.
9.1.3 Senior Supplier: Prime Responsibility:
to represent the interests of the providers/specialists within the project and to commit the appropriate resources.
Roles and responsibilities will be provided for each member of the Project Board; these define each individual's area of responsibility and helps avoid overlap of interests.
The three functional arms comprising the Project Board should not be interpreted as a requirement for three individuals. In smaller projects, for example, two functional roles may be combined in one person (although the Project Board must not be reduced to less than two individuals). In other circumstances several individuals may take on a single functional role (eg where a number of user areas are being served by the project).
9.2 THE PROJECT MANAGER
All projects need a focal point to plan, control and oversee the day to day work and to co-ordinate the total effort. The Project Manager fulfils this role.
The prime responsibility of the Project Manager is:
to ensure that the project as a whole produces the required products, to the required standard of quality, and within the specified constraints of time and cost.
In any PRINCE 2 project, there may also be one or more (Specialist) Team Managers to assist the Project Manager to plan, manage and control a selected specialist part of a stage. It is the responsibility of the Project Manager to direct and co-ordinate the efforts of all Team Managers.
Team Managers will often be appointed to plan and control particular technical areas, where the project manager lacks the detailed knowledge and/or experience to carry through the specific tasks required.
The main tasks for the Project Manager are:
* Overall planning for the total project;
* Liaison with other related/associated projects;
* Define responsibilities for each Specialist Team Manager;
* Report to and take direction from, the Project Board;
* Present regular Highlight Reports for the overall project to the Project Board.
The Project Manager role is essential for large, complex, high-profile, high-risk, undertakings and in these circumstances the Project Manager will often be supported by one or more Team Managers. In other circumstances, it might be more appropriate to define a series of Team Managers for selected stage of the project - each Team Manager being selected as the most appropriate individual to organise, plan and control the work to be carried out.
9.3 TEAM MANAGER(S)
The Team Manager, where appointed, is responsible for the day-to-day management of the stage activities and products under his/her control. The Team Manager works to the defined and agreed plans for the stage products and activities and reports to the Project Manager.
The prime responsibility of the Team Manager is:
to ensure production of the specialist products to the defined quality criteria, in a timescale and at a cost (in terms of both effort and funding) acceptable to the Project Manager and the Project Board.
The Team Manager(s) will work with the Project Manager to define responsibilities for the team members within his/her team and provide plans, guidance and inspiration.
All changes raised during the stage will be routed through the Team Manager for his/her recommendation or decision on further action.
The Team Manager will work closely with his/her e teams, providing advice and guidance and taking decisions. He/she will attend (and run) Checkpoints and help the Project Manager to provide regular Highlight Reports to the Project Board.
Project Support (where appointed) may be used by the Team Manager in a support role.
9.4 PROJECT ASSURANCE
Project Assurance prime functions are:
to provide assurance to the Project Board, by overseeing the work of the Project Manager, and the Team Manager.
Project Assurance is the responsibility of the Project Board and the individual members might choose to carry out the assurance function personally, or they might choose to delegate the assurance work to someone else (possibly the organisation's Quality Manager where one is appointed).
Project Assurance cannot be delegated to the Project Manager or the Specialist Team Manager(s). Accountability for project assurance always resides with the Project Board, regardless of the specific processes adopted.
9.5 PROJECT SUPPORT
Project Support will be provided when and where the Project Board believe the size and scope of the project justify the appointment.
Project Support, where appointed, provide help and assistance to the Project Manager and the Team Managers. Also to Project Team Members in terms of advice and the interpretation of the project management, quality and, where appropriate, the specialist standards.
The Project Support role is essentially one of "advise and consult" only with no executive responsibility within the project structure.
9.6 PRINCE VERSION 1 PROJECT ASSURANCE TEAM
PRINCE 2 does not preclude the inclusion of a Project Assurance Team (PAT) or any of the functional roles within it, but the simpler structure of the latest version steers organisations and projects towards separate assurance and support roles.
10. PLANNING INTRODUCTION
In PRINCE 2 Planning is a ** Process** , a ** Technique** , and a ** Component** . Planning is found throughout the method and the project which it addresses.
There are typically four types of plan within a PRINCE controlled project - Product Plans, Activity Plans, Resource Plans, and Quality Plans.
10.1 PRODUCT PLANS:
The PRINCE 2 Methodology uses "Product-based" planning principles. PRINCE 2 does not require the use of the term "Product" - "Deliverable", "Output", "Outcome", "Milestone", or any other term will suffice.
Products are identified for the whole project (the ** Product Breakdown Structure** ), and each is defined in terms of a ** Product Description** , which describes its Purpose, Composition, Derivation, Format & Presentation, Allocated To, Quality Criteria, Type of Quality Check, and People & Skills Required for Quality Checking.
This enables a thorough understanding of each Product to be gained; a spin-off benefit is that the structure of each Product can be discussed and agreed with the sponsor before any work is started, and the eventual Product measured against the agreed standard.
A ** Product Flow Diagram** may be produced to show the relationships between Products.
10.2 ACTIVITY PLANS:
These show the start and finish times for the activities that must be carried out to build or obtain each Product.
The ** PERT (Programme Evaluation and Review Technique) Network** (known in PRINCE Version 1 as the "Activity Network") may be produced to demonstrate activity relationships.
The ** Gantt Chart (or Plan)** (known as the "Technical Plan" in PRINCE Version 1) shows start and finish points as well as the stage review points for control.
10.3 RESOURCE REPORTS:
These show the effort and costs that will be incurred for the delivery of the project. Direct costs (equipment, hardware, construction and other fixed price costs) are also included. PRINCE 2 presumes that planning will be carried out using a software support planning tool (no particular software is suggested or recommended) and that resource information will be able to be pulled from the software tool in the form of a standard report without the need to produce a separate plan.
Although not a part of the PRINCE 2 Method, a cumulated graph (the** Graphical Summary** ) may be used to summarise the whole project in terms of its duration, cost and technical achievement (planned and actual). This summary is particularly useful for senior managers responsible for authorising and committing project resources, as it provides a complete view of the project on just one sheet of paper!
This plan may be usefully supplemented (or even replaced) by an Earned Value Analysis Chart which will compare estimated/budgeted costs and timescale against the actual earned value of work carried out. The technique also provides predictions of overall timescale, costs and effort. BS6079:1996 includes an appraisal of Earned Value Analysis, or information can be obtained from SPOCE Project Management Limited.
10.4 QUALITY PLAN:
The** Quality Plan** resides predominantly within the Product Descriptions (the Quality Criteria and the Type of Quality Check Required to be applied to each identified Product).
It is completed by the inclusion of the ** Configuration Management** arrangements confirming where and how Products and supporting documentation will be stored, and how changes will be managed.
10.5 PRODUCT BREAKDOWN STRUCTURE
The correct start point for planning any project is to establish a clear target for the project team to aim at.
This target is encapsulated within the Terms of Reference for the project, which may be formally identified and refined during a Definition Study and published in the Project Initiation Document during the early stages of the project.
A suitable format for Terms of Reference is as follows:
* Background * The origins of the undertaking, its place in the strategy.
* Objective(s) * A clear statement of what is to be achieved, measurable wherever possible.
* Scope * What functional areas are to be addressed by the project - what is outside the project.
* Constraints * Limitations on time, finance, effort - effectively "no-go" areas.
* Assumptions * Similar to constraints but with some room for maneuver
* Review by Management * How frequently senior managers wish to review progress against plan.
A clear objective for the overall required undertaking provides an excellent foundation for the identification of the Products/Deliverables that must be produced during the project.
The first planning task, therefore, is to consider which project level Products/Deliverables will be required to be built. This differs from the traditional project management approach of first identifying the major Activities that need to be undertaken and specifying Deliverables that "spin-out"!
Products /Deliverables must be identified and specified early on. The SPOCE Method for small to medium size projects identifies and defines Products for a number of different project scenarios (Feasibility Study, developing a Quality Management System to BS/EN/ISO9000, a small IT enhancement, a generic (non-IT) project).
10.6 IDENTIFICATION OF PRODUCTS
Products are identified in the form of a Product Breakdown Structure, initially at Project level and subsequently in more detail at Stage level.
At the initial stages, a high-level list of Project Products is acceptable, with a breakdown showing more detailed "Sub-Products" prepared at the commencement of each stage of the project.
Organisations with established Work Breakdown Structures (WBS) should experience little difficulty converting the WBS to a PRINCE style Product Breakdown Structure; normally only removal of the verbs is required!
The Product Breakdown Structure is usually broken into three separate product groupings to separate the three essential elements and to focus management and technical (specialist) in an appropriate direction.
The Product Breakdown Structure will show the Management Products, Specialist Products, and Quality Products separately.
Each of the Products identified is capable of being broken down into lower-level Products, thus providing a Product Breakdown Structure for the project. Initially, however, a list of the Products for the overall Project, plus a list of the Products for the next Stage, showing the lower-level Products within the next Stage (broken down to a reasonable level) is the minimum required.
10.7 PRODUCT DESCRIPTIONS:
All Products identified in the Product Breakdown Structure must be defined and described before any development work is carried out. The vehicle for product definition within PRINCE is the ** Product Description** . Product Descriptions are fundamental to the successful management of a PRINCE controlled project and must always be present.
The make-up of a Product Description is as follows:
Description/Purpose:
a description of the Product and its objective(s)
why the Product is required
Composition:
what the Product comprises
contents list
Derivation:
preceding Products
other sources of information
Format & Presentation:
what the finished Product will look like.
Allocated To:
person or organisation who is to create the Product.
Quality Criteria:
the basis for acceptance of the Product
standards by which quality will be assessed
Type of Quality Check Required:
how the Product will be evaluated
formal/informal Quality Reviews
other methods of evaluation
People or Skills Required for Reviewing/Testing & Approving the Product
who is best positioned to review the Product against its Quality Criteria
The Product Descriptions are most important as they provide the basis for PRINCE 2 project planning and quality planning. For all Products, the Product Descriptions should be produced at the time they are identified by the staff with the required specialist knowledge.
Responsibility for ensuring that the Product Descriptions are produced and included in the Project Initiation Document is the responsibility of the Project Manager, although they will normally be prepared by (Specialist) Project Team members.
10.8 PRODUCT FLOW DIAGRAMS
From the Product Breakdown Structure, and the Product Description (especially "Derivation"), the Product Flow Diagram can be produced. Product Flow Diagrams will reflect the level of detail contained within the Product Breakdown Structure and will therefore be appropriate at all levels.
The Product Flow Diagram is not constrained by resources and is intended to show how the Products within the Product Breakdown Structure inter-relate and the derivation of each from the other(s). This will:
* identify Products which should have been included but have, for some reason been omitted.
* Set an overall strategy and an indicative chronological order for the completion of the Products.
* Assist in the identification of a multi-project environment - ie distinguish between the various sub-projects within the overall project when this situation exists.
11. PERT NETWORK (ACTIVITY NETWORK)
The Products can only be built by carrying out the necessary activities and to show these, a PERT (Programme Evaluation and Review Technique) or Activity Network must be constructed. The PERT Network is also known as a Critical Path Network and is invariably offered when using a software planning tool.
The PERT Network is produced from activities identified from the Product Flow Diagram and represents the activities needed to build each of the Products, structured into a logical form.
Each line connecting Products on the Product Flow Diagram represents one or more activities; as the high level Product Flow Diagram is decomposed to the next lower level the number of Products, and their associated activities, increases.
11.1 FIRST STEPS:
Using the simple approach described above, a list of Activities is produced. The starting point will be the Project Level Product Flow Diagram which will normally provide the Stage Level Activities.
Remember, it will not normally be possible (nor is it necessary or desirable) to descend into too much detail for the later stages of the project, but the first stage products should, by definition, be clear and achievable and properly defined.
A useful approach is to structure the Activities into a table; this allows the durations and dependencies to be associated with each Activity, and simplifies the drawing of the PERT Network and/or the insertion of Activities into a software support package.
Usually, the activities will be put straight into a software planning tool (such a Microsoft Project) and there is no need to transfer the activities identified onto a separate table, but doing so provides a record of activities and makes it easier to translate into the PERT Network.
It is important to differentiate between "Staff Days of Effort" (used in estimating the size of the Activity or Product), and "Elapsed Days" (used to calculate the time an Activity or Product is expected to take to complete). For example, 9 Staff Days estimated for an activity, assuming three resources are available, would give an estimated duration of 3 Elapsed Days.
Although this simple calculation to determine the likely elapsed days is a useful start-point, the need for contingency must be taken into account. Typically a contingency of 20-30% would be added to allow for unforeseen problems that are bound to occur.
PRINCE lays stress on the need for open-ness and visibility when managing the project, and it is important that all concerned do not "horde" contingency as the plans are passed down through the levels of planning.
Only minimum guidance is given in PRINCE 2 for estimating or adding contingency; what information is provided is essentially "good practice" and embodied in Hints and Tips.
A license-free open method is available for organisations wishing to take a structured approach to estimating. It is called Function Points Analysis Mk2 and more information can be obtained from CCTA, Rosebery Court, Norwich, NR7 0HS, UK.
11.2 CONSTRUCTING THE NETWORK
Using the above information, a PERT Network can be constructed. This diagram models the logical dependencies that exist between each Activity.
Each of the boxes (or "nodes") will contain further information. This information will enable the planner to determine timing information (ie overall duration for the project; the earliest and latest times for starting and finishing each Activity without disturbing the final end date of the project;) and the amount of "float" (the slack time available against each Activity which will enable a later start, or time over-run, without delaying the overall delivery of the project) against each Activity.
A key piece of information gleaned from the PERT Network is the Critical Path. This is the longest, linked path of Activities that have no float or slack time. Delay to any Critical Path Activity will delay the project. Conversely, completing a Critical Path Activity ahead of schedule will (usually) result in an earlier delivery of the overall project.
Each node within the PERT Network contains the following information:
* Duration
* Earliest Start Time (EST)
* Earliest Finish Time (EFT)
* Latest Start Time (LST)
* Latest Finish Time (LFT)
* Total Float (TF)
11.2.1 Earliest Start Time: Earliest Finish Time:
The Earliest Start Time is the earliest date that the work on an Activity can start. Beginning with the first node a forward pass is made through the network, adding each Activity Duration to the EST.
The first node EST will, of course, be either 0 (when working in elapsed days) or the project start date. Adding the Duration into the EST will provide the Earliest Finish Time (EFT).
The EFT provides the input for the EST of all successor nodes. When two or more Activities feed into the same node, the highest EFT value must be taken as the EST.
The final node EFT represents the total duration of the project.
11.2.2 Latest Start Time: Latest Finish Time:
The Latest Start Time is the latest date by which the Activity must be finished if the project is not to be delayed. Working back from the final node, the Activity Duration is subtracted from the LFT to give the LST.
The LFT for the final node is, of course, the same as the EFT.
The LST provides the input for all pre-predecessor nodes. When two or more Activities feed back into a pre-predecessor node, the lowest LST value must be taken as the LFT.
11.2.3 Total Float:
Total Float is calculated by subtracting the EFT from the LFT of each Activity. The calculated figure represents the total float for the path containing that Activity; it is important to understand that any reduction or increase in Total Float for any Activity will have a knock-on effect on all other related Activities on the same path.
Where linked activities share a common Total Float, the amount of Total Float available is shared among all the activities on the shared path.
11.2.4 The Critical Path:
The Critical Path is represented by groups of related Activities that have zero float. There will always be at least one critical path and there will often be more.
Activities should be prioritised in order of float. It will be apparent by examining the network that many, related, paths exist within the model. The Activities on each path can be identified by the logical connections between them and by their possession of similar Total Float.
Identification of prioritised Activities enables the Project/Stage Manager to select those Activities needing special attention in order to keep the project timescale to schedule.
11.3 EARLIEST START CONCEPTS:
The PERT Network represents the logical order of carrying out Activities. It deliberately takes no view on the availability of resources (and in fact assumes "unlimited resources").
A Bar Chart or Gantt Chart (PRINCE v1 Technical Plan) produced from the PERT Network will indicate resource clashes and shortfalls which would need adjustment to the timing (durations) and possibly the logic (dependencies). Any such changes must be reflected back into the network and the end date re-examined. This process is known as resource smoothing or leveling and is fundamental to the production of realistic and practical plans.
11.4 RESOURCE REPORTING
PRINCE 2 presumes that a software support tool will be used in the creation of the project's plans and standard resource reports will be able to be drawn from the software tool as required.
Resource Reports should be available to the Project Board at Project and Stage levels in order to identify the levels of resource that the Project Board are asked to commit. Without a statement of the effort and direct purchase funding required to complete the plan the Project Board will have little on which to judge the project.
Resource Reports will contain the following elements:
* Stages (Project-level Plans), Weeks (Stage- level Plans), Days (Team Plans);
* Effort, broken down by skill-types or individuals;
Cost of the Effort, broken down by skill-types or individuals;
* Direct costs (Hardware, Software, Bought-in Effort at a fixed price, Equipment etc).
11.5 PROJECT MANAGEMENT EFFORT & COSTS:
Project Management costs are often of great interest to senior managers; these can be estimated in a similar way to the estimating approach adopted for the development resources. Alternative approaches are to assume 1-2 days per week for Project Management, over and above the estimate for the development.
As time goes by it should be possible to calculate a typical percentage overhead for project management - targets between the range of 8% to 25% are typical, with a 15% mean being reasonable for most projects. The percentage figure will normally be applied to the cost of the effort for developing the project.
11.6 GRAPHICAL SUMMARY:
Although not part of the PRINCE 2 Method, the Graphical Summary provides an overall view of the proposals contained within the plan and is of special use to Project Board members and other senior staff. It contains information on Time, Costs/Effort, and Products; when updated to reflect "actuals" it shows the status of Products against the time and money/effort expended.
The construction of the Graphical Summary is straightforward; the time and cost axis show the cost and timescale for each Stage and are derived from the Gantt and Resource Plans. Products are plotted onto the Graphical Summary at the point in time when they will be Ready - that is completed and signed off as conforming to their Quality Criteria, and actually stored away in the Project File or Configuration Management System.
It will be found to be helpful to include a cross reference to the Products that are the outcome of Activities on the Gantt Plan, as this simplifies plotting the Products onto the Graphical Summary.
11.7 USING THE GRAPHICAL SUMMARY:
The Graphical Summary is a useful document for the Project Board as it provides a complete picture of the project, showing the time, cost (effort) and products.
When updated to reflect the progress made by the project, the Project Board will be able to assess whether the time and expenditure consumed match the planned technical progress.
The Graphical Summary should be considered for inclusion as part of the regular Highlight Report sent from the Project Manager to the Project Board members.
11.8 EARNED VALUE CONCEPTS
The Graphical Summary is very useful as a one-page summary of actual progress against that planned, for presentation to management (the Project Board). To supplement the Graphical Summary, the production of an Earned Value Chart should be considered. This is a well used concept and provides a graphical summary and projection of the planned value of work under the project, and assigns a "earned value" of work actually carried out.
Using the projections within the graph, the positive or negative movements to completion can be predicted with reasonable accuracy and confidence. More information on Earned Value concepts can be found in British Standard BS6079 (1996) which addresses Project Management.
12. SUMMARY
PRINCE 2 provides a lot of flexibility in the planning of projects. The key requirements are that the Products must be identified and defined, the Activities must be planned, and the Resources must be captured. How organisations and projects actually approach these requirements is left to the appropriate management to decide. There are plenty of consultancy companies who will be happy to provide advice!
13. PRINCE VERSION 1 COMPARED TO VERSION 2 INTRODUCTION
PRINCE version 1 provided information on the Context of a project, the Components and some Techniques. PRINCE 2 adds Processes that are inherent in managing a successful outcome for any project. The Processes identified in PRINCE 2 represent the minimum content for a PRINCE-compliant project.
13.1 TERMINOLOGY
The term "Technical" has been largely, but not completely, dropped throughout in favour of "Supplier or Specialist".
"Stage Manager" is replaced by "Team Manager".
"User" has a wider scope and is synonymous with the "Customer" and in some cases "Sponsor".
"Processes" are now the main drivers for the PRINCE 2 project management method.
Where Tolerance has been exceeded the Project Manager will produce an "Exception Report" rather than an "Exception Plan".
Distinction is made between "Project Assurance" and "Project Support" and the version 1 Project Assurance Team, which combined both functions, has been dropped.
The concept of a "Project Mandate” has been introduced as the trigger to start the project.
“Product Descriptions" are included in the documentation as "Product Outlines" although the headings for "Quality Method" and "External Influences/Dependencies" have been dropped. It is envisaged the Product Outlines will be used as the basis for agreed Product Descriptions for the project Products.
13.2 THE PROCESSES
There are seven Processes identified within PRINCE 2; the seven are supplemented by an eighth, common-to-all, Process of "Planning" (Referenced PL). The seven fundamental Processes are:
* Starting Up A Project (Referenced SU);
* Initiating A Project (Referenced IP);
* Directing A Project (Referenced DP);
* Managing Stage Boundaries (Referenced SB);
* Controlling A Stage (Referenced CS);
* Managing Product Delivery (Referenced MP);
* Closing A Project (Referenced CP).
All the Processes link with Techniques, identified within the PRINCE documentation, some which are approaches which the implementing organisation may already be using or may wish to introduce as part of the general improvement in managing projects effectively. The Processes do not link with any required way of achieving the process outcome - it is important to understand this aspect as it reflects the flexibility which comes as part of the PRINCE 2 package and underlines a key difference between versions 1 and 2.
The PRINCE documentation shows how the Processes fit together, with their respective lower level Processes, and the inputs and outputs for each Process.
The Processes make up a substantial part (about one-third) of the PRINCE 2 documentation with comprehensive advice given on each Process, including a section on "Hints and Tips" which is intended to be expanded by the implementing organisation to reflect their own experience of using the method.
13.3 CUSTOMER:SUPPLIER
PRINCE 2 reflects the most commonly-found situation where a Supplier is used to provide the resources and eventual project outcome. This scenario is embedded throughout PRINCE 2 and replaces the version 1 assumption that development would be carried out internally.
A simple organisation structure chart illustrates how the different customer and supplier structures may be brought together to form a joint Project Board for the undertaking. Role Descriptions are provided which reflect the customer:supplier relationship.
A separate publication will be produced expanding on customer:supplier situations and will eventually be integrated into the method.
13.4 WORK PACKAGES
The concept of a "Work Package" is introduced to describe (and of course control) the work that a team member has to perform. This is particularly of use when controlling packages of work that are being undertaken by a supplier. The associated Processes are "Controlling A Stage (CS)" where a Work Package will be authorised and "Managing Product Delivery (MP)" where a Team Manager or Leader carries out the work and delivers the Product.
13.5 RISK MANAGEMENT
Version 1 contained references to the importance of Risk Management. PRINCE 2 devotes a section to explaining the importance of the Assessment of Risk and Managing the Risk Elements identified; it does not contain a specific risk management tool or approach (in keeping with the overall concept of stating "what" and "why" but not "how") but does point to some example methods and tools in the associated Process "Initiating a Project (IP)".
Those singled out are CRAMM (CCTA Risk Analysis and Management Methodology) and the European Risk Management Methodology (RiskMan).
The concept of a Risk Log is introduced and emphasis is placed on the need to re-assess the risk at each major stage in the life of the project.
13.6 QUALITY MANAGEMENT
Quality has always been deemed to be embedded within the method and this idea is retained in PRINCE 2. However stronger links are established with the BS/EN/ISO 9000 Quality Management Standard, showing how PRINCE 2 fits in with this. Reference is also made to ISO 8402/BS 4778 for the definition of "Quality".
The relationships between a Quality Management System, Quality Assurance, Quality Planning and Quality Control are drawn and each one defined.
13.7 QUALITY REVIEWS
The Quality Review Technique is one of a number of options to assure that a Product meets its stated Quality Criteria (still embedded within the Product Description).
Under the heading of "Techniques", the documentation contains a list of the appropriate steps within the QR and a note of the people involved, with a Responsibility Matrix.
Exactly how to arrange and run the QR is left to the implementing organisation, although the procedure is described. This is very similar to the version 1 QR procedure but with the Author/Presenter re-named as the "Producer" and recognition that a "Scribe" is a useful attendee.
The new British Standard 6079:1996 for Project Management has also been used throughout to input to the new version of the method.
13.8 CONFIGURATION MANAGEMENT
The importance of Configuration Management is stressed, with separate sections on Project Filing and Change Controls. Again the emphasis is on describing what is meant by the terms and why it is important for them to be addressed adequately within the project management environment.
There is no statement of how configuration management ought to be operated
13.9 CHANGE CONTROL
The approach to controlling change is described with the term "Technical Exceptions" now dropped. PRINCE 2 suggests that all changes are treated as types of "Project Issue" which can be:
A Request For Change, typically to the specification of requirement;
* A Request For Change recording a suggestion to improve one or more of the project's Products;
* An Off Specification to record a failure (current or predicted) to meet the requirement;
* As with version 1, no forms are included and no specific procedures are designated.
13.10 PROJECT FILING
A filing structure is suggested as follows:
* A Management File, comprising a Project File and a separate Stage File for each stage of the project;
* A Specialist File, containing all the Configuration Items of the project and specialist correspondence;
* A Quality File providing the means of auditing the quality aspects of the project. It would typically contain the QR documentation and record Project Issues.
13.11 ORGANISATION
The organisation component reflects the most obvious and significant changes to the method, although the built-in flexibility will allow existing users to retain their current organisation structure if desired.
Project Board: Little change except to the titles, although the Role Descriptions provided in the PRINCE 2 documentation do reflect the customer:supplier scenario and are certainly better than the version 1 examples, especially as they include Specific Goals to achieve rather than just responsibilities.
The PRINCE 2 roles for Project Board members also separate out the Project Assurance responsibilities that each member is accountable for. This is done to make delegation of Project Assurance responsibilities easier.
Some re-naming has taken place, in particular, "Senior Technical" has been replaced by "Senior Supplier" to reflect the more generic application of PRINCE as a project management method suitable for all types of project rather than mainly for IT type ventures. The Senior User remains (although this may be extended to User/Customer), as does the Executive.
Senior Management: Above the Project Board, the ISSB and ITEC have been replaced by "Corporate or Programme Management" to reinforce the concept that corporate management are in full control outside the immediate project boundary, and that projects these days are often integrated into a programme of other past, present and future initiatives and cannot be regarded in isolation,
Project Assurance: As already mentioned, distinction is made between "Project Assurance" and "Project Support".
Project Assurance is the responsibility of the Project Board who may choose to appoint someone to provide what is effectively an audit function on their behalf. The organisation's existing Quality Manager might well be a suitable start point.
Delegation of this responsibility cannot be made to the Project Manager.
Project Support: Project Support will be provided for the Project Manager as and when it is deemed a necessary function for the success of the project or to support the Project Manager on a major project. Project Support will take direction from, and work directly to, the Project Manager, with no independent reporting role for assurance purposes to the Project Board.
Stage Managers: The Stage Manager title has been dropped in favour of the term "Team Manager".
This avoids the confusion between responsibility for the management of the project's "Management Stages", denoted by major milestones during the project's life, and management of discrete "Specialist Stages" where specific skills and resources may be needed, together with a real understanding of planning and managing them, to complete a series of authorised Work Packages.
13.12 PROJECT MANDATE & PROJECT BRIEF
PRINCE 2 pushes forward some of the project start-up arrangements, when compared with version 1, in that there are now two associated Processes (Starting Up A Project (SU) and Initiating A Project (IP)) which cover this.
Version 1 anticipated that a project started with a Project Brief comprising the Terms of Reference and an initial list of the Major Products for the project. PRINCE 2 expects the trigger for a project to be a "Project Mandate" which may take any form from a telephone call, memorandum, recommendation from an earlier study report, or whatever. The Project mandate is taken forward by the "Starting Up A Project" Process to produce the Project Brief, thus providing an earlier and more definitive start to the project.
13.13 PROJECT PLANNING
Planning the project and stages are fundamentally as in version 1. Product-based planning remains intact and with it the Product Breakdown Structure, Product Flow Diagram, and Product Descriptions.
Gone is the terminology of "Activity Network", "Technical Plan" "Resource Plan", "Graphical Summary" - organisations must identify the activities, effort/resource usage as part of the Planning Process but just how they go about it (for example using a software support tool of their choice) and what they output to the Project Board and for day-to-day control is left for them to determine.
The terms "Critical Path" and "Gantt Chart" are accordingly quite acceptable, as indeed are the version 1 descriptions.
Levels of plan are different from version 1 with Project-level Planning mandatory, Stage-level Planning necessary and Team-level Planning optional. The concept of "Detailed Stage Plans" is no longer present.
13.14 PRODUCT DESCRIPTIONS
Product Descriptions remain as an important means of identifying and defining the Products/Deliverables.
The main headings for Product Descriptions within PRINCE 2 are:
* Product Title
* Purpose
* Composition
* Derivation
* Format & Presentation
* Allocated To
* Quality Criteria
* Type of Quality Check Required
* People or Skills Required for Reviewing/Testing and Approving the Product\i
The two additional headings are "Allocated To" which is aimed at identifying the person(s) to whom the job of creating the Product/Deliverable has been given, and "People or Skills Required..." which identifies individuals or skill types necessary to validate the eventual Product for quality purposes.
Organisations are, of course, free to add additional information such as Checklists which may already be in use.
Product Outlines are provided within the documentation as a start-point for preparation of Product Descriptions.
13.15 ESTIMATING
This topic is addressed as part of the "Planning (PL)" Process. No specific techniques or algorithms for estimating are included, in keeping with the general PRINCE 2 approach. The advice is generic and concentrates on the high-level approach to the topic. The Hints and Tips section is comparatively comprehensive, but does not contain any specific means of creating an effective estimate.
13.16 CONTROLS
The controls are substantially the same, with Project Initiation (and the PID), ESA, MSA (but only where Tolerance has been exceeded), Project Closure, Highlight Reports, Tolerance and Checkpoints still present but with some modification to improve their effectiveness.
The main changes are:
Mid Stage Assessment: The option for holding a MSA as a "confidence boost" has been dropped. MSA's will now only be appropriate for projects where Tolerance has been exceeded and the Project Manager has produced an Exception Plan for consideration and approval.
Project Closure: Not necessarily a Project Board meeting - a written confirmation from the Project Board will suffice. The key inputs and outputs are:
End Project Notification: to advise all concerned that the project is coming to an end.
Lessons Learned Report: to disseminate the useful lessons learned during the project. Production of this report is the responsibility of the Project Manager, finalising the content just before the end of the project, after collecting the information as the project progresses.
Follow-On Actions Recommendations: to pick up outstanding actions, good ideas for improvement (but outside the scope of the contract (and project)), or even to fix known shortfalls.
Post Implementation Review: To assure that the outcome is delivering the expected benefits, a Post Implementation Review is essential. The PRINCE 2 documentation includes a Product Outline for the PIR.
Checkpoints: It is not envisaged that this will naturally be a meeting - the concept is that the Checkpoint will be a means of communication and the structure is best determined by corporate management, the Project Board and the Project Manager.
Work Package Authorisation: comprises the Product Description, Constraints (time, cost, interfaces etc), Reporting Arrangements, Hand-over Arrangements plus any other relevant documentation and materials necessary for the effective completion of the package of work.
Tolerance: This stays much as before but with a better definition. Where a management Stage exceeds its Tolerance, the Project manager will produce an Exception Report to alert the Project Board of the situation. This describes the forecast deviation, an analysis of the exception and options for the way forward, together with firm recommendations.
The Exception Report will be reviewed by the Project Board and the need for the Project Manager to prepare an Exception Plan, describing the options for recovery, will be decided.
13.17 THE BUSINESS CASE
This is embedded in the Process "Initiating A Project (IP)" and comprises the Business benefits (which may be in the form of a Costs:Benefits Analysis/Investment Appraisal) and the Key Business Risks (which will be output from the Risk Assessment). Again, exactly how the Business Case will be approached and what the output will look like is left to the implementing organisation.
13.18 SMALL PROJECTS
Little new is provided on managing smaller projects. The emphasis within PRINCE 2 on Processes enables the implementing organisation to tailor down the procedures for small projects and this is the approach recommended within the documentation. However no specific guidance is given on small projects - as with version 1, tuning to make PRINCE 2 suitable is left to the implementing organisation to define.
13.19 HINTS AND TIPS
The new version of the method encourages the employment of "Hints and Tips" in Processes and elsewhere, such as in the Organisation component. The recommendation is to build on the basic set provided within the documentation as experience is gained with projects.
13.20 SUMMARY
The new version of the PRINCE Methodology is certainly an improvement in terms of its flexibility and recognition of the practical issues facing Project Managers working in a modern commercial environment. The best advice that can be offered to existing users of version 1 of the PRINCE Methodology is to consider what aspects of PRINCE 2 are particularly attractive to their own organisation, with special regard to any area that currently causes difficulty (for example, the organisation structure - in particular the Project Assurance Team aspects). Once possible improvements have been established, a plan can be prepared to introduce the required changes in an orderly way. If users of version 1 are satisfied with their existing arrangements, things are best left as they are.
If there is a likely area of challenge, it is the limited amount of detail on "how" to operate project management within the PRINCE 2 environment.
For example, the method indicates its suitability for small projects but fails to indicate how to manage them. Our recommendation in this particular instance would be to examine the SPOCE and SPOCETTE methods which fill this gap.
SPOCE Project Management Limited is able to offer a full PRINCE 1 to PRINCE 2 Audit Service providing a report identifying differences, shortfalls, deficiencies and firm recommendations for bringing existing PRINCE project management systems up to year 2000+ standards. Any actions arising from this audit can be undertaken by SPOCE Project Management Limited, using its SPOCETTE Method as a project management tool.
14. PRODUCT BASED PLANNING INTRODUCTION
PRINCE 2 remains a "Product-Based" Method in respect of its approach to planning. This means that the starting point for planning is to identify the required Outputs, Deliverables, or Products that will need to be produced in order to satisfy the project's objectives.
Definition of these Products enables everyone involved with the project to secure a good understanding of what is to be produced, and avoids disagreement over acceptability at later stages.
The third step in Product Planning is to arrange the Products into a relationship diagram showing the dependencies and linkages both internal and external.
14.1 PRODUCT BREAKDOWN STRUCTURE
The correct start point for planning any project is to establish a clear target for the project team to aim at.
This target is encapsulated within the Terms of Reference for the project, which may be formally identified and refined during the Feasibility Study and published in the Project Initiation Document during the early stages of the project. A suitable format for Terms of Reference is as follows:
* Background - The origins of the undertaking, its place in the strategy.
* Objective(s) - A clear statement of what is to be achieved, measurable wherever possible.
* Scope - What functional areas are to be addressed by the project - what is outside the project.
* Constraints - Limitations on time, finance, effort - effectively "no-go" areas.
* Assumptions - Similar to constraints but with some room for maneuver.
* Review by Management - How frequently senior managers wish to review progress against plan.
A clear objective for the overall required undertaking provides an excellent foundation for the identification of the Products/Deliverables that must be produced during the project. The first planning task, therefore, is to consider which project level Products or Deliverables will be required to be built.
This differs from the traditional project management approach of first identifying the major Activities that need to be undertaken and specifying Deliverables that "spin-out"!
Products /Deliverables must be identified and specified early on. The SPOCE Method for small to medium size projects identifies and defines Products for a number of different project scenarios (Feasibility Study, developing a Quality Management System to BS/EN/ISO9000, a small IT enhancement, a generic (non-IT) project).
14.2 IDENTIFICATION OF PRODUCTS
Products are identified in the form of a Product Breakdown Structure, initially at Project level and subsequently in more detail at Stage level.
At the initial stages of a project, a high-level list of Project Products/Deleiverable is acceptable, with a breakdown showing more detailed "Sub-Products" prepared at the commencement of each successive stage of the project.
Organisations with established Work Breakdown Structures (WBS) should experience little difficulty converting the WBS to a PRINCE 2 style Product Breakdown Structure; normally only removal of the verbs is required!
The Product Breakdown Structure is usually broken into three separate Product groupings to separate the three essential elements of Management, Quality and Specialist.
The Product Breakdown Structure will show the Management Products, Specialist Products, and Quality Products separately.
Each of the Products identified is capable of being broken down into lower-level Products, thus providing a Product Breakdown Structure for the project. Initially, however, a list of the Products for the overall Project, plus a list of the Products for the next Stage, showing the lower-level Products within the next Stage (broken down to a reasonable level) is the minimum required.
14.3 PRODUCT DESCRIPTIONS:
All Products identified in the Product Breakdown Structure must be defined and described before any development work is carried out. The vehicle for product definition within PRINCE 2 is the Product Description.
Product Descriptions are fundamental to the successful management of a PRINCE 2 controlled project and must always be present.
The make-up of a Product Description is as follows:
Purpose:
a description of the Product and its objective(s)
why the Product is required
Composition:
what the Product comprises
contents list
Derivation
preceding Products and sources of information
Format & Presentation:
what the final Product will look likey
Allocated To:
organisation or person responsible for creating the Product.
Quality Criteria:
the basis for acceptance of the Product
standards by which quality will be assessed
Type of Quality Check Required:
how the Product will be evaluated
formal/informal Quality Reviews
other methods of evaluation
People or Skills Required for Reviewing'Testing & Approving the Product:
people best positioned to check that the Product meets its Quality Criteria
The Product Descriptions are most important as they provide the basis for PRINCE 2 project planning and quality planning. For all Products, the Product Descriptions should be produced at the time they are identified by the staff with the required specialist knowledge.
Responsibility for ensuring that the Product Descriptions are produced and included in the Project Initiation Document is the responsibility of the Project Manager, although they will normally be prepared by Specialist Project Team members.
14.4 PRODUCT FLOW DIAGRAMS
From the Product Breakdown Structure, and the Product Description (especially "Derivation"), the Product Flow Diagram can be produced. Product Flow Diagrams will reflect the level of detail contained within the Product Breakdown Structure and will therefore be appropriate at all levels.
The Product Flow Diagram is not constrained by resources and is intended to show how the Products within the Product Breakdown Structure inter-relate and the derivation of each from the other(s). This will:
* identify Products which should have been included but have, for some reason been omitted.
* Set an overall strategy and an indicative chronological order for the completion of the Products.
* Assist in the identification of a multi-project environment - ie distinguish between the various sub-projects within the overall project when this situation exists.
14.5 ACTIVITY PLANNING
The Products can only be built by carrying out the necessary activities and to show these, a PERT (Programme Evaluation and Review Technique) or Activity Network must be constructed. To learn more about this select the button on the right.
15. RESOURCE PLANNING INTRODUCTION
Resource information must be produced at Project and Stage levels in order to identify the levels of resource that the Project Board are being asked to commit. Without a statement of the effort and direct purchase funding required to complete the plan the Project Board will have little on which to judge the project.
Resource information may take any form that is acceptable to the Organisation and the Project Board, but typically contain the following elements:
* Stages (Project-level Plans), Weeks (Stage- level Plans), Days (Team-level Plans);
* Effort, broken down by skill-types or individuals;
Cost of the Effort, broken down by skill-types or individuals;
* Direct costs (Hardware, Software, Bought-in Effort at a fixed price, Equipment etc).
15.1 PRODUCING THE RESOURCES REPORT
PRINCE 2 assumes that a software planning tool will be available and this can be utilised to extract the information needed for a Resources Report. The Method does not require the use of a software support tool and does not suggest any suitable product.
15.2 PROJECT MANAGEMENT EFFORT & COST:
Project Management costs are often of great interest to senior managers; these can be estimated in a similar way to the estimating approach adopted for the development resources. Alternative approaches are to assume 1-2 days per week for Project Management, over and above the estimate for the development. As time goes by it should be possible to calculate a typical percentage overhead for project management - targets between the range of 8% to 25% are typical, with a 15% mean being reasonable for most projects. The percentage figure will normally be applied to the cost of the effort for developing the project.
15.3 GRAPHICAL SUMMARY:
Although not part of the PRINCE 2 Method, the Graphical Summary can be used to provide an overall view of the proposals contained within the plan and is of special use to Project Board members and other senior staff. It contains information on Time, Costs/Effort, and Products; when updated to reflect "actuals" it shows the status of Products against the time and money/effort expended.
The construction of the Graphical Summary is straightforward; the time and cost axis show the cost and timescale for each Stage and are derived from the Gantt and Resource Plans. Products are plotted onto the Graphical Summary at the point in time when they will be Ready - that is completed and signed off as conforming to their Quality Criteria, and actually stored away in the Project File or Configuration Management System.
It will be found to be helpful to include a cross reference to the Products that are the outcome of Activities on the Gantt Plan, as this simplifies plotting the Products onto the Graphical Summary.
15.4 USING THE GRAPHICAL SUMMARY:
The Graphical Summary is a useful document for the Project Board as it provides a complete picture of the project, showing the time, cost (effort) and products.
When updated to reflect the progress made by the project, the Project Board will be able to assess whether the time and expenditure consumed match the planned technical progress.
The Graphical Summary should be considered for inclusion as part of the regular Highlight Report sent from the Project Manager to the Project Board members.
15.5 EARNED VALUE CONCEPTS
The Graphical Summary is very useful as a one-page summary of actual progress against that planned, for presentation to management (the Project Board). To supplement the Graphical Summary, the production of an Earned Value Chart should be considered. This is a well used concept and provides a graphical summary and projection of the planned value of work under the project, and assigns a "earned value" of work actually carried out.
Using the projections within the graph, the positive or negative movements to completion can be predicted with reasonable accuracy and confidence. More information on Earned Value concepts can be found in British Standard BS6079 (1996) which addresses Project Management.
15.6 SUMMARY
PRINCE 2 provides a lot of flexibility in the planning of projects. The key requirements are that the Products must be identified and defined, the Activities must be planned, and the Resources must be captured. How organisations and projects actually approach these requirements is left to the appropriate management to decide. There are plenty of consultancy companies who will be happy to provide advice!
16. CONTROLS INTRODUCTION
There are two basic types of control within PRINCE 2. ** Management Controls** address the top-level control for the project and** Team Controls** provide tracking on a day-to-day basis. ** Quality Controls** are also effected at project team level to ensure that all Products conform to the quality criteria included in the Product Description.
16.1 MANAGEMENT CONTROLS:
Comprising ** Project Initiation** at the launch of the project, ** Project Closure** at the completion of the project, and a series of ** Project Reviews (or End Stage Assessments)** at the end of each Management Stage of the project.
At each of the reviews a "go/no-go" decision is required and if the project is to proceed, resources must be committed by management (the Project Board).
Highlight Reports (only 1xA4 page) are provided to management each month to confirm the project is proceeding according to the approved plan. The Project Manager is responsible for producing this report which is mailed to management - a meeting is not necessary!
Tolerance is the measure of the scope the Project Manager has to depart from the approved plans without needing to refer to senior management for authorisation. Tolerance is not time and money to be spent - merely "trigger-figures".
16.2 TEAM REVIEWS:
Checkpoints are held by the Project Manager, usually weekly, to assess progress and to pick up any problems while there is time to take remedial action. They typically take the form of a meeting but, if sensible, may be conducted by telephone, fax, e-mail, or video conference.
16.3 QUALITY REVIEWS:
Sometimes known as "structured walkthroughs" - these reviews usually take the form of a meeting where 2-3 Reviewers (who have knowledge of the type of Product, but have not been directly involved in the creation or acquisition of the Product under review) formally "walk-through" the Product, measuring it against the Quality Criteria recorded in the Product Description.
This is usually referred to as a "**Formal Quality Review**"; desk-checks by individuals, visual inspections, or physical tests are normally referred to as "**Informal Quality Reviews**".
16.4 CONFIGURATION CONTROLS:
This is the term used to describe how Products and supporting documentation will be stored, safeguarded and retrieved; also how changes will be managed. Configuration Management is an essential component of structured project management, and is included in the PRINCE 2 Methodology in terms of "what" and "why" but not "how".\c03
17. PRINCE 2 CONFORMATION INTRODUCTION
As a quick check whether a project under PRINCE 2 control really is conforming to the requirements and the spirit of the Methodology, apply the following criteria:
17.1 PROCESSES
The following Processes are present and can be identified:
* Starting Up A Project;
* Initiating A Project;
* Directing A Project;
* Managing Stage Boundaries;
* Controlling A Stage;
* Managing Product Delivery;
* Closing A Project;
* Planning (throughout the Project).
17.2 ORGANISATION:
17.2.1 Project Board:
A minimum of 2 people nominated to the Project Board.
Three functional roles addressed and filled covering:
* Senior User/Customer;
* Senior Supplier;
* Executive (Senior Business).
Individual Roles defined, covering:
* Who owns the project;
* Who decides the project is worth doing;
* who decides the outcome will actually work from a specialist viewpoint;
* Who decides the outcome will be usable.
17.2.2 Project Manager:
* Someone is appointed to control the day-to-day work (planning and control).
* An individual role has been defined covering the day-to-day responsibilities.
17.2.3 Project Assurance:
* Independent - not directly responsible to, and not delegated, to the Project Manager.
* Responsibility for assuring, on a day-to-day basis:
* That the outcome continues to be worth doing;
* That the outcome will function, operationally;
* That the outcome will be usable.
* Accountability for Project Assurance resides in the Project Board.
17.3 PLANS:
17.3.1 Product Plans:
A minimum of one Product (Deliverable) - ie the final outcome - must be defined in terms of:
* Purpose;
* Composition;
* Derivation;
* Format & Presentation;
* Allocated To;
* Quality Criteria;
* Type of Quality Check Required;
* People & Skills Required for Review.
17.3.2 Planning Levels:
A minimum of one level of plan at the Project Level;
17.3.3 Stages:
A Minimum of two Stages:
* Planning Stage;
* Action Stage.
17.3.4 Plans Content:
The following aspects to be planned:
* Time;
* Resources - Effort, Cost, Equipment, External (bought-in) Expenditure.
17.4 CONTROLS:
Regular, event-related reviews of the project by the Project Board must be held at least six monthly; all Project Board members must attend. Formal sign off at the end of each Project Projects must be formally approved and initiated through the preparation, acceptance and sign-off of a Project Initiation Document.
The Project Board to review and endorse the overall project Business Case and to commit resources for the next stage.
Regular reports of progress must be reported to the Project Board, usually monthly, by the Project Manager.
Any significant divergence (known or anticipated) from the approved plan that will cause the Stage to exceed Tolerance must be reported immediately to the Project Board.
17.5 QUALITY MANAGEMENT:
Where a published Quality Management System (QMS) exists, the management of the project can be demonstrated to comply with the requirements of the QMS.
Quality Criteria must be specified for each Product; each Product must be verified against its agreed Quality Criteria.
A system must be in force to track the status and whereabouts of all Products (and supporting Documentation) defined for the project.
17.6 BUSINESS CASE/VIABILITY:
The Project Initiation Document must include statements on the following:
* The Business Benefits that will arise from the undertaking;
* The Risks associated with the undertaking;
* Proposals for managing the identified risks.
The Business Case must be regularly reviewed and, as a minimum, up-dated for each formal stage review.
18. WHAT IS PRINCE INTRODUCTION
PRINCE (** PR** ojects ** IN** ** C** ontrolled ** E** nvironments) is a structured method for effective management of any size or type of project. It is the standard method for use in UK Government Departments and is used increasingly in the private sector, NHS and Local Government.
18.1 BENEFITS
The benefits of using PRINCE are that it:
* identifies Management, Specialist and Quality Products/Deliverables/Outputs and helps ensure that they are produced on time and to budget;
* focuses attention on the quality of Products/Deliverables/Outputs;
* separates the Management and Specialist aspects of Organisation, Planning and Control;
* facilitates controls at all levels;
* makes the project's progress more visible to management;
* provides a communication medium for all project staff;
* ensures that work progresses in the correct sequence;
* involves senior management in the project at the right time and in the right place;
* allows the project to be stopped and, if required, re-started completely under management control, at any time in the project's life;
* is in the public domain and requires no license fee;
* has a well established User Group dedicated to the support, promotion and strengthening of the method.
18.2 PROJECT STRUCTURES
In PRINCE 2, each project which is undertaken must:
* address a set of Processes;
* have a stated business case indicating the benefits and risks of the venture;
* have a properly defined and unique set of Products/Deliverables/Outputs;
* Identify a corresponding set of activities to construct the Products;
* Identify appropriate resources to undertake the activities;
* have a finite life-span;
* make suitable arrangements for control;
* possess an organisational structure with defined responsibilities;
* incorporate a set of processes and associated techniques which will help plan and control the project and bring it to a successful conclusion.
18.3 STAGES
A PRINCE 2 project is divided into a number of stages, each forming a distinct unit for management purposes. Like the project, a stage has a defined set of products and activities, a finite life-span, control elements, and an organisational structure. The delivery of these products, to the agreed quality standards, marks the completion of the stage.
PRINCE 2 defines the organisation of the project and its stages, the processes which drive the undertaking, the structure and content of the project plans, some basic project management techniques and a set of controls which ensure that the project is proceeding to plan. These, together with the products of the project and the activities which produce them, the project business case, all encompassed within a quality management framework, make up the PRINCE 2 environment.
All products of a PRINCE 2 project are filed within a defined filing structure - the "Configuration". Management, Specialistl and Quality products are identified and filed separately.
The PRINCE 2 framework provides the flexibility to set management stage boundaries which are appropriate to the needs of the project. Management Stage boundaries are chosen according to:
* the sequence of production of Products, Deliverables and Outputs;
* the grouping of Products into self-contained sets;
* natural decision points for review;
* the risks and business sensitivity of the project.
The project stages correspond to the steps in the natural development life-cycle towards the eventual outcome. Thus the stage boundaries are normally defined to correspond to the completion of the major products to be built.
Whatever the nature of the project, it is advisable to define one or more planning and/or definition stages in the early part of the project's life. PRINCE 2 requires two processes to cater for this - Starting Up A Project (where the early foundations are laid) and Initiating A Project (where management commit to the undertaking and a baseline is produced.
This may take the form of a Feasibility or Definition Study, providing a choice of options and a firm recommendation to proceed (or not!), allowing a management review before any commitment to implementation stage(s) and the associated resources and costs
PRINCE 2 recognises that few projects can be completed entirely in isolation. The outputs from one project may be used as input by another project. There may be other dependencies between projects, such as the use of shared resources.
PRINCE 2, therefore, provides a mechanism for defining the boundary of a project and its relationship to other projects. In defining the boundary of a project, as with a stage, the emphasis is always on the products which the project is required.
The PRINCE 2 methodology applies three key elements to each project and to the stages within a project. These are:
18.4 PROCESSES
* Starting Up A Project (SU);
* Initiating A Project (IP);
* Directing A Project (DP);
* Managing Stage Boundaries (SB);
* Controlling A Stage (CS);
* Managing Product Delivery (MP);
* Closing A Project (CP);
+ Planning (PL) - also a Component and Technique
18.5 COMPONENTS
* Organisation;
* Planning (also a Process);
* Controls;
18.6 TECHNIQUES
* Product-Based Planning;
* Change Controls;
* Quality Reviews;
* Project Filing Arrangements;
* Configuration Management.
18.7 PROCESSES
The Processes state the minimum content that can be expected to be found in a PRINCE 2 project. Exactly how the Processes are addressed within any given project is the responsibility of the organisation's senior management and the Project Manager, but the method requires that each Process is reflected within the project one way or another.
The seven fundamental Processes have been listed earlier; Planning is also a Process, which is iterated and has impact across the whole of the project throughout its life.
All the Processes link to Techniques, some of which are described within the method. It is anticipated that most organisations will already be using specific techniques and PRINCE 2 encourages the continued use of these where they provide value to the management decision making process.
Each Process is defined in the following terms:
* The Fundamental Principles underpinning the Process;
* The Context within which the Process operates;
* Process Description;
* Responsibilities identifying accountability for the Process;
* The Information Needs required for the Process to function effectively;
* The Key Criteria which will influence the success or failure of the Process;
* Hints and Tips for carrying out the Process in the best way.
The Process-based approach is a novel feature in PRINCE 2 and is the area which most differentiates it from version 1 of the method. The flexibility of the method is, however, underlined by allowing implementing organisations to choose their own destiny in terms of identifying how to meet the requirements of any given Process.
In most organisations there will be little need to make changes to the way they are operating, provided effective project management through the use of PRINCE version 1 compliant procedures are already in place.
18.8 THE ORGANISATION COMPONENT
The organisation and effective use of people assigned to manage a project need to be considered from the view point both of their specialist skills and their individual personalities.
Responsibilities need to be defined within a team structure to ensure that management is both efficient and responsive.
Within PRINCE 2, responsibilities are defined in terms of roles, rather than individuals. Assignment of roles to individuals is a decision for each project to take, and the same individual may be assigned to more than one role, or to different roles at different stages of the project.
18.8.1 The Project Board
The Project Board is the ultimate authority for the project and is normally appointed by senior management (often at Director-level) to take overall responsibility and control of a PRINCE 2 project. The Project Board consists of three senior management roles, each representing major project interests.
Executive
- appointed by corporate management to provide overall project guidance and assessment throughout. The Executive represents the interests of the business in the project.
Senior User/Customer
- representing users or customers of the outcome or the major products from the project.
Senior Supplier
- representing areas which have responsibility for providing the specialist "know-how" for the solution.
18.8.2 Project Manager
A Project Manager will normally be appointed to assume day-to-day responsibility for planning and management of the project throughout all its stages. The Project Manager takes direction from the Project Board and is responsible for planning and delivering the products of the project, on-time, within budget, meeting the technical and quality criteria agreed with the Project Board.
18.8.3 The Team Manager
In a large or complex project, one or more Team Managers may be assigned the responsibility for ensuring that the products of one or more particular specialist stages of work are produced on schedule, to the defined and agreed quality standards, and within budget.
18.8.4 Teams
The Project and/or Team Manager have responsibility for Stage/Development Teams, tasked to carry out the activities and produce the products of the stage. The team organisation, responsibility definitions and the allocation of these responsibilities to individuals will depend upon the size and nature of the project and the skill mix available. PRINCE 2 recognises the need to establish Team Leader roles where appropriate; Team Leader and Team Manager roles are often synonymous.
18.8.5 Project Assurance
PRINCE 2 separates the Project Assurance function from the Project Support function. The Project Board have responsibility and accountability for Project Assurance; depending on the size, scope, risk and profile of the project, and their own knowledge, skills and time available, they may choose to delegate responsibility for Project Assurance to others within the organisation. However, final accountability for Project Assurance rests with the Project Board and they are not able to delegate this.
Project Assurance appears in two forms:
* External Assurance to confirm that the project is following overall and corporate standards (eg the published Quality Management System, or particular accounting conventions) and the organisation will usually have an audit function already in place to check these aspects.
* Internal Assurance to verify that the project is delivering Products/Deliverables that meet the agreed Quality Criteria and that internal project standards are being followed. Internal Assurance is ultimately the responsibility of the Project Board.
18.8.6 Project Support
Within PRINCE 2, Project Support will only exist where there is a perceived need for it. Unlike version 1 of the method, a Project Manager may well find that the Project Board see no scope for any administrative support and that any day-to-day assistance that might be needed will need to be on a "grace and favour" basis.
Where a project does warrant the appointment of a Project Support function, the individual(s) selected will report directly to the Project Manager. There is no scope for combining the Project Support and Project Assurance function as was the case in version 1.
18.9 PLANNING
Estimating, planning and re-planning are constant and key activities when managing any project. PRINCE 2 provides a structure for preparing and maintaining plans at appropriate levels throughout the life of a project. Plans are prepared for the Project as a whole, for each stage within the project and, optionally, for Detailed work within each stage. There is also an Exception planning process to handle divergences from the original plan. The PRINCE 2 method includes Techniques for Product/Deliverable planning, Activity planning Resource planning and Quality planning.
18.10 PRODUCTS/DELIVERABLES AND ACTIVITIES
PRINCE provides a set of planning techniques and planning documents which give structure to the project. The key to PRINCE 2 planning is the identification and definition of the Products required.
From this comes an analysis of the work (ie the activities) required to generate these products, and the sequencing of the work.
PRINCE 2 makes a distinction between management activities and specialist activities. This is partly because these are usually the concern of different groups of people, but also to ensure that management activities are not overlooked in planning and estimating.
Management activities are concerned with planning, monitoring and reporting the work of the project, in both normal and exceptional situations. They produce management products in the form of plans, reports and other control documents. Management activities include the planning and control of all technical activities on the project. Although influenced by the specialist content, there is a similar pattern of management tasks on any PRINCE project.
Conversely, the specialist activities undertaken by a project are determined entirely by the scope and objectives of the project. The specialist activities describe the work needed to produce the products required from the project.
The Specialist Products/Deliverables required by the user/customer are identified and defined at the start of the project by the Project Manager and endorsed by the Project Board. Additional specialist products may be defined by the strategy which is appropriate to a particular stage; specialist activities may also be prescribed by a particular strategy.
PRINCE 2 therefore acknowledges the need for flexibility in the definition of specialist activities and the corresponding products.
Product planning techniques require every project to be described and defined in terms of its Products or Deliverables. This is a very effective way to ensure full understanding of what is required and to ensure that, as far as possible, all angles are covered.
18.11 SPECIALIST PLANNING
Specialist Plans are concerned with the products to be delivered and with the activities necessary to ensure that these products emerge on time and to the required quality standards.
The project Products are produced as a first step in planning; definition of each product (via the PRINCE 2 Product Description) enables its make-up and quality requirements to be documented and properly understood.
A Product Breakdown Structure illustrates the hierarchical make-up of the complete set of project products and a Product Flow Diagram provides a view of the relationship each product has with others, within and outside of the project.
The Project Gantt Plan charts the major activities of the project. It is usually derived from the Dependency Network which shows the relationships that exist between project activities. It is used with the Project Resource Plan to monitor progress on the project as a whole. It also addresses planning requirements related to Quality Control and Configuration Management.
A Stage Gantt Plan shows the products, activities and quality controls for each stage of the project. The Stage Gantt Plan is produced and approved at the end of the previous stage (the plan for the first stage is prepared with the project plan).
Detailed Gantt Plans can be expected to exist in all but the smallest projects, to give a detailed breakdown of particular major activities. In PRINCE 2 these are called "Team Plans".
Individual Work Plans (or Work-to Lists) are not formally included in PRINCE 2, but where an organisation wishes to produce them for a specific project, they are derived from the Stage and Detailed Plans to allocate detailed activities (and Products/Deliverables) to particular members of a (specialist) Stage Team.
18.12 RESOURCE PLANNING
Resource Plans are concerned with managing the funding and effort resources of the project. They are derived from the corresponding Gantt Plan.
The Project Resource Plan identifies the type, amount and cost of the resources required by the project related to each stage of the work. It will also identify equipment, building, and fixed-price costs associated with the project. The intention is to provide a complete resource and financial picture of the undertaking.
A Stage Resource Plan details the resources required by a particular stage. It defines the budget required by the stage and is used to report actual expenditure and resource usage against plan.
Team Resource Plans will be produced when required, to plan and control a particular major activity down to team level.
18.13 QUALITY PLANNING - BS/EN/ISO9000
Action must be taken at the planning stage to ensure that the project can deliver products to the desired quality. Quality criteria must be defined and agreed, and incorporated into a Product Description for each Product identified; a quality strategy must be defined, published and adopted; Quality Review procedures must be established and staff trained; review activities must be properly resourced.
Whatever action is proposed to build quality into the project, the measures must be consistent with any published Quality Management System (QMS) that is already in effect. PRINCE has been designed to comply with the BS/EN/ISO9000 Quality Management Standard and with BS6079 the Project management Standard; the foundation for quality is therefore inherent in PRINCE 2.
The results of the quality planning activity must be integrated into the Gantt and Resource Plans at each level. Just as quality must be built into the products, so must quality control be built into the plans.
The Project Level plan sets the overall quality strategy for the entire project. It defines the standards to be followed and the quality criteria for the major products. It also identifies external constraints that may apply to the project, such as a specific Configuration Management Method.
The Stage Level plan identifies the quality criteria, methods and review guidelines for each Product produced during the stage.
A Team level plan might be required for specific individual activities such as carrying out interviews within a particular user/customer area. The Project Manager is responsible for deciding whether any plans below stage-level are required; this decision will be endorsed by the Project Board at the Project Initiation or End-Stage Assessment meeting.
18.14 EXCEPTION PLANNING
The Project Board sets Tolerances for Stage Plans. These define the limits of timescale and cost (or sometimes effort) within which the Project Manager can operate without further reference to the Project Board.
An Exception Report is required in situations where costs or timescales have already exceeded, or are likely to exceed, the tolerances set by the Project Board. On receipt of an Exception Report, the Project Board may require the Project Manager to create an Exception Plan which confirms and describes the cause of the deviation from plan and its consequences and recommends corrective action to the Project Board.
Once approved, the Exception Plan replaces the remainder of the current Stage Plan.
18.15 THE CONTROLS COMPONENT
Regular and formal monitoring of actual progress against plan is essential to ensure the timeliness, cost control and quality of the system or undertaking being developed. PRINCE 2 provides a support structure of Management and Product-oriented controls to monitor progress, supported by a reporting procedure which enables re-planning or other appropriate corrective action to be taken.
18.15.1 Management Controls
PRINCE 2 provides a structure of management controls to be applied throughout the project. These controls cover all aspects of project activity and, at the highest level, allow senior management to assess project achievement and status prior to committing further expenditure. Controls are applied through meetings of project management and project staff, with each meeting producing a set of pre-defined outputs. Management Controls are defined at Project Initiation to ensure that the project is set up with clear terms of reference and an adequate management structure.
Including Project Initiation, there are 5 key management controls - End and Mid Stage Assessments, Project Closure, and Tolerance.
18.15.2 Project Initiation
To ensure a firm foundation and to provide a positive start to the project, ensuring that the terms of reference, objectives, plans and controls, business risks, benefits and financial return, organisation structure and job definitions are clearly defined, published, understood and agreed.
This first stage is very important and is the result of two Processes - Starting Up A Project and Initiating A Project. The key output is a Project Initiation Document which can be used to Baseline the project.
18.15.3 End Stage Assessment (ESA)
This is a required management control and occurs at the end of each stage. It consists of a formal presentation to the Project Board of the current project status, and reviews the overall business case (benefits and risks). The approval of the proposed Resource and Timescale (Gantt) Plans for the next stage is also obtained.
Project Board approval, endorsed by all the members, must be obtained before the project can proceed to the next stage.
18.15.4 Tolerance & Mid Stage Assessment (MSA)
This will be held to review an Exception Plan which will be produced if the project has deviated from the original, approved, plans and a significant departure from plan has occurred.
The measure of a "significant departure" is that the Tolerance stated by the Project Board at the beginning of the management stage has been exceeded.
Tolerance is variable and will be assigned to each project to reflect the respective business risk, but a rule of thumb is that Time Tolerance of plus/minus 1 week and Cost Tolerance of plus/minus 10% is generally about right.
18.16 PROJECT CLOSURE
A final review of the project's work is held, usually (but not necessarily) in the form of a Project Board meeting. This is similar to a stage assessment but relates to the entire project rather than a single stage. The objective is to ensure that all the project Products/Deliverables have been satisfactorily delivered to their stated quality standard and that the project documentation is complete.
A review of the project management standards used will be carried out and a Lessons Learned Report produced for consideration by the Project Board. This report records what has been learned from using the PRINCE 2 project management and quality management standards for the project and it will eventually be sent to the organisation's Quality Manager.
Recommendations will also be made for Follow-on Actions to record and trigger further work which is recommended following the closure of the project.
18.17 PRODUCT/DELIVERABLES CONTROLS
Quality and specialist controls are applied to specific products rather than to the overall output of a stage or project. The aim is to identify and correct errors as early as possible in the development process. They will usually take the form of a formal or informal quality review, whatever is specified in the Product Description.
Quality control may take many forms from a visual inspection, through a test programme, to a formal meeting. These are all Techniques and PRINCE 2 describes some, but not all that might be available - the selection of appropriate Techniques is left to the implementing organisation.
However, one of the most powerful Technique is the Quality review which has been successfully used in PRINCE version 1 projects for a number of years.
18.17.1 Quality Controls - Quality Review
At each Quality Review, appropriate provider and user/customer staff are designated to examine a Product to ensure that it is complete and correct. The Product is reviewed against defined quality criteria contained within the Product Description, which assures its technical integrity and its compliance with user requirements; It is thereafter subject to formal change control procedures.
This principle applies to informal quality reviews (for example a test, visual inspection, or desk-check) and to formal quality reviews where 2-3 Reviewers meet with the Producer of the product under the chair of a suitably senior person to "walk-through" the product.
18.17.2 Checkpoints
This is a regular (possibly weekly) specialist and management control point. Checkpoints are usually (but not necessarily) conducted by the Project Manager or Team Manager, together with Stage Teams. They provide the basic information used to measure actual achievement against plan, and to agree on the content of the next period of work for each team member.
Checkpoints will commonly take the form of a brief (40 minutes maximum) meeting but as the Checkpoint is essentially a communication device, other methods such as telephone, facsimile, E-Mail, video conferencing, are all viable options.
18.17.3 Change Controls
Unplanned situations relating to changes to one or more Products need to be captured as "Issues" relating to the project. Examples of this are good ideas that project team members identify, resource changes, errors discovered in a finished product, and departures from the agreed specification. Because the situation is unplanned, it needs to be recorded and action agreed, in order to contain the impact and prevent wider divergence from plans.
Issues are best handled within the framework of a formal Configuration Management scheme.
18.17.4 Configuration Management
A Configuration Management Method (CMM) controls the development of products by providing a formal mechanism for labelling products, their development status, and the relationship between them. PRINCE 2 does not define or recommend a specific CMM but emphasises the need for a suitable system.
18.18 CO-ORDINATION
To make the most effective use of PRINCE 2, each organisation should consider appointing a PRINCE 2 Co-ordinator with sufficient authority and experience to perform the role.
18.19 FURTHER INFORMATION
For more general information refer to the PRINCE 2 documentation. Specific questions may be answered by referring to each particular section, especially in "Hints and Tips".
18.20 SMALL TO MEDIUM SIZE PROJECTS
For organisations wishing to implement PRINCE 2 over a wide range of projects, the SPOCE Method published by The Stationery Office, is worth considering. SPOCE (Small Projects in a PRINCE Controlled Environment - ISBN 1-85554-428-8) is easy to implement and provides an effective but non-bureaucratic control structure for all types of projects.
SPOCE has been derived from the PRINCE Methodology and provides a platform for a smooth transition to full PRINCE for larger and more complex projects.
Copies of the SPOCE Method Manuals and help with the implementation of SPOCE can be obtained from SPOCE Project Management Limited (telephone or fax 01202-780740). A number of support tools are available, including a diskette containing a Project Initiation Document template in a variety of word processor formats. The diskette also contains Product Descriptions including those for developing an ISO9000 Quality Management System, and for completing a Feasibility Study. The diskette can be obtained by telephone or fax - call 01202-780740 to place your order (or e-mail SPOCE@dial.pipex.com).
18.21 MINOR PROJECTS
For the very smallest of projects, a fully scaled down method (SPOCETTE) is available. The method provides a framework suitable for work which otherwise might be considered to be too small to plan or control.
A SPOCETTE project will contain a Management Summary and Product Description and, if necessary, a Risk Assessment Planning a SPOCETTE project usually takes less than two hours.
The SPOCETTE Method is available only from SPOCE Project Management Limited.
Latest Information
Keep yourself updated on developments within PRINCE by accessing our web page on:
** http://ourworld.compuserve.com/homepages/spoce**
or go onto our mailing list and receive the SPOCE Centre News every six weeks. Call (UK) 01202-780740 or e-mail SPOCE@dial.pipex.com
19. PROCESS SU - STARTING UP A PROJECT
This is the first Process within a project. A Project Mandate in the form of a memo or informal request will normally trigger this Process. The three significant outputs from the Start-up Process are:
* to produce the Project Brief; This will normally contain the formal Terms of Reference for the Project together with an Outline Business Case, based on the information contained in the Project mandate.
* to design and appoint the Project Management Team;
* to create a suitable Plan for the Initiation Stage.
The Process is essentially a "scene-setting" series of activities, designed to enable the effective initiation of the project.
A key part of this Process is the creation of a plan to enable the production of a Project Initiation Document during the next Process - "Initiating A Project".
20. INITIATING A PROJECT
This Process is aimed at ensuring that a firm foundation exists for the project and that everyone involved understands what the project is seeking to achieve. The major outputs for this Process are:
* to identify the benefits and risks and to evaluate proposals for managing identified areas of risk, thus confirming that an acceptable Business Case exists for the project;
* to provide a Foundation for the project from which the Project Initiation Document can be prepared.
* to provide Decision Support Information to enable the Project Board to confirm the initial (and ongoing) viability for the project;
* to encourage the Project Board to take Ownership of the project;
* to provide sufficient information for the Project Board to Approve the whole project in principle and to Commit Resources for the next stage of the project;
* to provide a Baseline for all decision-making for the duration of the project;
* to initiate the project in an Orderly manner, thus setting "Norms" for the remainder of the project;
* to monitor the Progress of the Project Initiation Process against the approved plans.
The Initiation Stage of any project is a key contributor to its eventual outcome. The time, effort and resources invested in this stage will be well worthwhile, especially if some unforeseen problem occurs during the project.
The Project Board and Project Team will have firm ground on which to base decisions about proposed changes in direction and investment of resources.
Another major, but intangible output from this Process is the understanding that individuals within the Project management Team will gain about the nature, scope and possible pitfalls that the project may have to face.
When the project has been formally initiated, the associated process of Directing A Project and Managing A Stage come into play; to find out more about these Processes, click on the buttons on the right.
21. PROCESS DP - DIRECTING A PROJECT
This Process operates throughout all stages of the project, from Project Start-up through to Project Closure and is the primary concern of the Project Board. They achieve this by managing by exception, monitoring through reports provided primarily by the Project Manager, and controlling through a series of key decision points. The key Sub-Processes break into the following four areas:
* Control of the Initiation of the project ensuring it has the best possible start;
* Control of the Stage Boundaries, committing new and additional resources as the project progresses towards its ultimate aim;
* Ad-hoc Decision-making and Direction, monitoring progress and providing advice and guidance as necessary;
* When the project has achieved its outcome, or is no longer considered to be a viable business proposition, arranging for Project Closure, bringing the whole undertaking to a controlled finish.
This Process does not cover the day-to-day activities of managing the project - these rest with the Project Manager. The Process is positioned at the level of management residing above the Project Manager.
The Processes "Controlling A Stage" and "Managing Stage Boundaries" are associated closely with this Process; to find out more, click on the buttons on the right.
22. MANAGING STAGE BOUNDARIES
To achieve a successful outcome to the project, it is necessary to break it into smaller, discrete packages to enable the Project Team to focus on specific Products or Deliverables; this approach provides the concept of Project Stages. By controlling the start and finish of each stage, specific attention can be given to whether the Stage Products/Deliverables have all been completed in accordance with their Quality Criteria, whether the remaining project Products/Deliverables are still required, and whether the Business Case for the project remains viable. The aims are:
* to assure the Project Board that all the Products/Deliverables planned for the current stage have been completed and meet their Quality Criteria;
* to provide the information on timescale, technical achievement, and the budget needed to enable the Project Board to assess whether the overall project Business Case is still viable, and whether the Benefits can be achieved within an acceptable level of risk;
* to provide decision-support information on the Status of the current stage and the overall project, which will enable the Project Board to reach a decision on final completion of the current stage, authorise the start of the next stage, and to endorse the overall project.
* to provide a vehicle for stating the Tolerance which may be allowed for the next Stage. Tolerance is a control providing cost and time "trigger-figures" beyond which the Project Manager may not progress without the approval of the Project Board.
* to record any information or Lessons Learned which might impact on later stages of the project, or on the organisation as a whole.
The Process is an iterative one as the project proceeds from one stage to the next. Controlling the start and end of stages is a key control process for the Project Board and incorporates all the key aspects of directing a project.
The steps of this Process may also be used when creating an Exception Plan, where a significant departure from the approved plan has occurred and Tolerance has been exceeded. In order to reach a decision on the future of the project, the Project Board will need to consider an impact analysis, options appraisal, and a recommendation for action prepared by the Project manager; these will all need to be supported by an up-dated Business Case confirming the benefits and re-appraising the risks.
23. PROCESS CS - CONTROLLING A STAGE
Following the Project Board's decision to approve a Stage, the Project Team must be fully focused on delivery of the Products, to their stated Quality Criteria, within the approved timescales and budget, within the stated Tolerances.
This Process forms the main part of the Project Manager's effort on the management of the project, and provides the direction for the day-to-day management of the Stage and the overall project. All through the Stage there will be an on-going cycle of:
* authorising Packages of Work that must be completed during the Stage;
* gathering Progress Information about the work carried out and the resources and effort expended;
* watching for Changes to the approved plan; managing any changes raised formally against the project (Project Issues) and making decisions on the introduction of beneficial changes provided these do not result in the Stage Plans exceeding the Tolerance;
* reviewing situations for Stage and Project Impact;
* reporting to the Project Board and to other members of the Project Management Team;
* approving and initiating any Corrective Action.
It may be expected that for much of the time, controls during a Stage will follow a regular pattern. However, project management comes to the fore when things are not going in accordance with plan and it is then that the Project Manager must use knowledge, Processes, Techniques, political and people-handling skills on an "as required" basis to achieve the required result.
24. PROCESS MP - MANAGING PRODUCT DELIVERY
Essentially this Process is aimed at managing the interface between the Customer Project Manager and the Supplier Project Manager. It is, however, also relevant where an internal resource has responsibility for creating a Product/Deliverable. The Process is focused on ensuring that work is actually progressing in accordance with the customer's expectations and that all the planned Products are created and delivered within the agreed timescales and contract price or internally approved budget, and meet their approved Quality Criteria. The Process comprises:
* making certain that work on Products allocated to each external Team or Team Member resource is properly Authorised;
* ensuring that Packages of Work are identified, discussed, agreed, authorised and accepted by those responsible for the creation of Products;
* checking that all Interfaces between the Customer and Supplier organisations are identified, recorded, observed and handled in an appropriate way;
* ensuring that all the Work is actually Carried Out, as agreed;
* ensuring that the Progress of Work and Forecasts of the time and effort to completion are regularly assessed;
* checking that all finished Products conform to their agreed Quality Criteria;
* obtaining Approval for completed Products. This will usually be at three levels - Author and Reviewer level, Project Manager level, and ultimately endorsement by the Project Board at the end of each Project Stage. These levels of approval will be reflected in both the customer and specialist supplier organisations, although it is not essential that either will be working within a PRINCE 2 environment; it is essential, however, that all involved are working within a suitably controlled project management environment.
This Process will operate continuously throughout each Stage; it provides a separation between the Customer Project Manager and the Supplier Project Manager and requires the interface between the specialist providers (be they internal or external) and the Customer to be identified, defined and operated. Care must be taken to ensure that the interfaces are neither missed nor lost, and that bureaucracy is kept to the absolute minimum consistent with effective control.
Where a Project Manager allocates work directly to individuals responsible for carrying out the work package, this Process will be significantly less formal than where an external Supplier is involved..
25. PROCESS CP - CLOSING A PROJECT
At its conclusion, the project must be closed down in an orderly and firm manner. The end of a project may arise when all the planned work has been completed and the Products/Deliverables finished and signed off as meeting their stated Quality Criteria. Alternatively a project might be brought to a premature conclusion because of changes to requirement, removal of resources or unacceptable slippage of time, effort or costs.
Most of the work involved in this Process is concerned with preparation of information for the Project Board in order for it to make the decision to close the project, or not. Rather like Project Initiation, this Process provides a decision-support structure; it aims to:
* ensure that the Objectives for the project have been met;
* confirm that the Customer is Satisfied with the outcome;
* obtain Formal Acceptance of the project Products/Deliverables;
* confirm that all Products/Deliverables have been handed over to the Customer, and that these have been accepted;
* ensure that where Ongoing Support, enhancement and maintenance is appropriate (and required), suitable provision has been made;
* identify any recommendations for Follow-on Actions and document these in a "Continuity Memo";
* Finalise "Lessons Learned" and publish these in a suitable report for the Project Board;
* Prepare an "End of Project Report" for sign-off by the Project Board;
* Notify the Customer/Sponsor/Host Organisation, as appropriate, of the Intention to Close the project, disband the project organisation and release the resources.
Obviously, it will be difficult to close down a project in an orderly manner if the expectations and criteria for completion and close-down have not been agreed at the outset and this will normally have been done and the final Acceptance Criteria included within the Project Initiation Document. Project staff and managers should be provided with as much notice as possible in order for them to plan their return to normal operations. Thanks to those who have contributed to the project are also in order!
26. THE PLANNING PROCESS
Planning embraces PRINCE Components, Processes, and Techniques and is an on-going activity throughout the project. Understanding of the tasks involved and the possible pitfalls will emerge from planning the project and stages; control can only be exercised in as much detail as the project plan allows; and the approaches to planning, using manual or software supported techniques is a matter of preference and choice for the implementing organisation.
Planning for all but the smallest projects is best tackled using a software support tool as the time saved in the longer term will more than repay the initial outlay, especially where complicated inter-dependencies exist between Products and Activities.
The philosophy behind the PRINCE 2 planning concepts are:
* Plans are constructed by identifying the final Products/Deliverables and all associated intermediate Products/Deliverables;
* Products/Deliverables are defined and specified by producing associated Product Descriptions;
* The Activities and associated Resources are identified; all Activities must be thought through to a level consistent with the control requirements identified in the Project Initiation Document;\i
The planning framework incorporated in PRINCE 2 is intended to cater for any type or size of project - the steps are:
* Step 1: Identify and Define what Products/Deliverables are needed;
* Step 2: Determine the sequence in which each Product/deliverable should be produced;
* Step 3: Identify the Activities needed for the creation of the Products/Deliverables.\i
After the initial steps the following come into play:
* Estimate the effort for each Activity;
* Estimate the Duration of each Activity;
* Decide when Activities should be carried out, and by whom;
* Agree the Quality Control Activities and Resources required;
* Calculate the Cost of the Effort;
* Identify the Management and Specialist Control Points.
Because of the wide scope of Planning (it embraces Components, processes and Techniques and is used throughout the PRINCE 2 project cycle) it is recommended that the techniques, and local standards for planning approaches (eg use of a standard software planning tool) be pursued separately.
27. A-Z PROJECT MANAGEMENT TECHNIQUES INTRODUCTION
PRINCE 2 recognises that a number of project management techniques will need to be used within the project environment if the undertaking is to be brought to a successful conclusion.
The PRINCE 2 Processes use these Techniques, along with the Components described in the Method.
Key amongst the Techniques contained within PRINCE 2 is Product-Based Planning which requires the identification, definition and analysis of the Products of the project as a pre-cursor to producing plans which show which Activities need to be carried out.
The use of a software planning tool is presumed by the Method, although the use of software is not required, nor any recommended.
PRINCE 2 generally avoids pointing to any technique that prescribes HOW to achieve an objective incorporated within any Process; this is largely left to the Organisation and the Project Manager.
Four Techniques are, however, included within the Method; these are:
Quality Review Technique (to assess whether Products meet their Quality Criteria);
A suggested Project Filing Technique comprising a Management File, (made up of a Project File and a series of Management Stage Files), a Quality File, and a Specialist (or Technical) File where the Configuration Items and the Master Product Descriptions are filed.
Configuration Management (incorporating Change Control). Configuration Management is NOT optional in a PRINCE 2 controlled project.
Product-based planning, as described above.
Organisations are encouraged to add to this basic set of Techniques.
27.1 ACCEPTANCE CRITERIA
A prioritised set of criteria which the final (or end) Product must meet before the Customer will accept it.
Acceptance Criteria are defined in the Project Brief and agreed no later than the Initiation Process.
27.2 ACCEPTANCE LETTERS
Acceptance Letters were incorporated into PRINCE Version 1 - they have not been carried through into PRINCE 2.
There are four Acceptance Letters which may be produced during a PRINCE v1 controlled project:
The Technical (Specialist or Supplier) Acceptance Letter is signed by the Senior Technical (Supplier) member of the Project Board upon successful completion of testing of the final output of the project.
The Operations Acceptance Letter is signed by the manager responsible for operating band maintaining the project output at each installed location upon confirmation that Operations Acceptance Criteria (which should be contained within the Specification) have been met. In the absence of a nominated Operations Manager, the letter is signed by the Senior User/Customer and Senior Technical (Supplier) members of the Project Board.
The User Acceptance Letter is signed by the Senior User/Customer after the project's output has been demonstrated to have successfully met the User/Customer Acceptance Criteria, and completed User/Customer Acceptance tests.
The Business Acceptance Letter is signed by the Executive member of the Project Board as the final action of the Project Closure meeting. It is signed following confirmation that the other Acceptance Letters have been signed, and sent to the Strategy Body - ie Corporate or Programme Management.
A Security Sign-off Letter may also be produced where appropriate. This will be signed by the Senior User/Customer and Senior Technical (Supplier) members of the Project Board.
Acceptance Letters usually take the form of a simple statement on the standard sign-off form used for approving the project initiation, and continuance of the project.
27.3 APPROVAL TO PROCEED
Required from the Project Board at Project Initiation and at each End-Stage Assessment in order that the project may proceed to the next stage. It represents acceptance of the Stage Plans and a commitment by the Project Board to provide the resources identified in the Stage Plans.
27.4 BASELINE
The freezing of a Configuration Item, sub-system, or the entire system during development so that a known version of it can be released into production, or to form a firm base for subsequent work. In order to be baselined, a Configuration Item must have successfully completed a Quality Review.
A project baseline is established by the acceptance by the Project Board of the Project Initiation Document. This Product provides the project foundation and will not normally be changed to reflect subsequent variations in timescales, resource usage and objectives.
27.5 THE BUSINESS ACCEPTANCE LETTER
An approval form signed by the Executive member of the Project Board as the final action of the Project Closure meeting. It is signed following confirmation that the other Acceptance Letters have been signed, and sent to the Strategy Body (Corporate or Programme Management).
27.6 BUSINESS ASSURANCE
This is the process of monitoring actual costs and time usage against the approved plans, identifying departures and providing assurance to the Project Board that the project's Business Case remains intact.
27.7 BUSINESS ASSURANCE CO-ORDINATOR (BAC)
A role within the PRINCE Version 1 Project Assurance Team (or Project Support office) responsible for helping the Project Manager to plan, monitor and report the project's progress. The BAC provides assurance to the Project Board that the Business Case for the project remains intact and is responsible for co-ordinating all Quality Review activities.
PRINCE 2 has formally dropped this role although many organisations and projects are expected to retain their existing organisation structures incorporating the BAC role.
27.8 BUSINESS CASE
The justification for undertaking a project, defining the benefits the system is expected to deliver, and the savings it will bring, measured against the costs of developing, delivering implementing and running the outcome of the project. Another important element of the Business Case is the assessment of project risks and providing proposals for mitigating identified risks.
27.9 CHANGE AUTHORITY
A Group or individual to whom the Project Board may delegate responsibility for reviewing Project Issues. This authority would normally include a budget within which changes can be authorised.
27.10 CHECKPOINT
A specialist control conducted on a regular basis, usually weekly; it is produced from within the "Managing Product Delivery" Process.. The aim is to gather information on achievements and problems from the development team members. The Checkpoint also allows team members to hear what others are doing, and to share information.
Checkpoints may take the form of meetings, usually held by the Project Manager, but on larger projects they may be run by the Team Managers/Leaders or even by Project Support on behalf of the Project Manager. A Checkpoint may be held by telephone, fax, e-mail, or any other appropriate means.
27.11 CONFIGURATION MANAGEMENT METHOD
The process of identifying and describing all the technical products created during the development, controlling the status of, and changes to those items (Configuration Items).
27.12 CONTROL POINTS
There are four control points within PRINCE, which are common to all stages of a project:
* End Stage Assessment
* Mid Stage Assessment
* Quality Review
* Checkpoints
Corporate Management/Programme Management
A top-level management body responsible for identifying organisational objectives and approving a strategy plan to enable the organisation to meet those objectives.
27.13 DETAILED PLANS
Detailed Plans may be produced for any type of PRINCE plan. They provide more information for the Project Manager, Team Manager, Team Leaders, or Team Members and are important to assure effective project control, especially for complex projects.
Detailed Gantt Plan - a stage activity may be so complex that it merits a lower level plan to show the make up of the activity through small work units;
Detailed Resource Plan - shows the resources and costs of a Detailed Specialist Plan.
27.14 END STAGE ASSESSMENT
A key management control held at the end of each stage of the project. The ESA is driven by the Project Manager who will present the current stage status and the next stage plans, formally, to the Project Board.
A signed approval by the Project Board is needed before the project can move forward to the next stage. This approval provides an authorisation for the Project Manager to progress into the next stage, and commits the planned resources.
27.15 EXCEPTION REPORT
Produced in situations where costs and/or timescale Tolerances of a Stage Plan either have been exceeded or are forecast by the Project Manager to be likely to be exceeded.
An Exception Report comprises the same package of information as that presented to the Project Board at the end of each stage.
It is produced by the Project Manager and considered, formally, by the Project Board at an Unscheduled Mid-Stage Assessment. A departure from the approved plan may be approved, ex-committee, by the Executive of the Project Board, but this would only be done in exceptional circumstances (eg minimum schedule over-run near to the end of a Stage).
27.16 EXECUTIVE MEMBER OF THE PROJECT BOARD
The Executive member of the Project Board usually chairs each meeting. The normal reporting line is to the Strategy Body (Corporate or Programme Management) responsible for appointing Project Board members.
The Executive member is specifically responsible for ensuring that the project achieves its expected benefits within its budget and schedule.
27.17 HIGHLIGHT REPORT
Prepared by the Project Manager for Project Board members at intervals agreed with them at the time the Stage Plan is approved (but usually monthly). It is based on the Checkpoint Reports and covers achievements, real or foreseen problems, for the last period, and a forecast for the next period.
The Highlight Report contains a statement of the current project/stage timescale and cost situations. The aim should be to keep the Highlight Report on a single A4 sheet.
The Project Board do not need to meet to consider the content of the Highlight Report, although they might wish to meet after receiving a Highlight Report, if their experience indicates a deteriorating situation.
27.18 IMPACT ANALYSIS
The process of assessing the ramifications of a proposed change to the Specification, listing what Products would be affected by the change, and evaluates the size and scope of change to each of the Products.
27.19 INFORMAL QUALITY REVIEW
A Quality Review carried out, normally by one or two people; the person who created the Product (the Producer) and a Reviewer. Informal Quality Reviews are an effective (and relatively cost-effective) way of ensuring tht a Product meets its stated Quality Criteria.
The three phases of Quality Review are present but the timescale is foreshortened and the meeting is conducted in a less formal manner - typically a "Desk Check". Typically an Informal Quality review would take about 30-40 minutes and is therefore much more economic than a Formal Quality Review which would normally be carried out via a formal meeting.
27.20 IS
Information Systems. This description would be applied to all types of information systems, manual and information technology (IT).
27.21 ISO9000
The international standard for Quality Management. Organisations and/or projects may be registered for compliance to the international standard. Such registration requires a documented Quality Management System (QMS) and periodic assessment visits by an external auditor to ensure that procedures are being followed. The current nomenclature is BS/EN/ISO9000.
27.22 IT
Information Technology - the use of computerised systems to manage and process data and information.
27.23 LESSONS LEARNED REPORT
A report describing lessons learned during the project. A blank Lessons Learned Report is created in the Starting A Project Process and populated as the project progresses.
27.24 MID-STAGE ASSESSMENT (MSA)
A formal meeting between the Project Board and the Project Manager (with the Project Assurance Team in attendance). A Mid-Stage Assessment would be held for the following reasons:
* to make a decision on an Exception Plan, produced wherer there has been a significant departure from the approved plan. This is the only situation recognised by PRINCE 2 where an MSA would be held, but experience indicates that an MSA would be appropriate in the following circumstances:
* as an interim assessment of the progress of a long or complex stage of the project (formally dropped from PRINCE 2);
* to authorise limited work to begin on the next stage of the project, before the current stage work is completed and all Products delivered;
The last two, Scheduled Mid-Stage Assessments, differ from End Stage Assessments as they will consider Stage Plans only and will not normally consider the overall project situation (including the Business Case). Unscheduled Mid-Stage Assessments will usually need to consider the whole project and the Business Case.
Scheduled Mid-Stage Assessments should normally last around 40 minutes, as they are, essentially, a "confidence boost".
27.25 OFF-SPECIFICATION REPORT (OSR)
Used to document a situation where the system under development fails to meet its Specification in some respect. An OSR might also be raised where a member of the project team puts forward an idea for change which is fairly attractive, but not so much so as to make it imperative to implement; such a change would effectively change the Specification if incorporated into the system, and would be logged as an Off Specification Report.
Off Specification Reports are always converted from Project Issues, and the decision to carry out such a conversion can only come from the Project Manager or Project Board.
A project may be signed off even though there are uncleared Off-Specifications; these uncleared OSRs sometimes form the basis for a subsequent enhancement project.
27.26 OPERATIONS ACCEPTANCE LETTER
Prepared by the Operations Manager at each location where the system is installed, after ensuring that the system complies with the Operations Acceptance Criteria.
27.27 PAT
Project Assurance Team. This existed within the PRINCE Version 1 Organisation Structure but has been formally dropped from PRINCE 2, although Organisations and projects may retain the use of the PAT if they wish.
27.28 PBS
Product Breakdown Structure.
27.29 PFD
Product Flow Diagram.
27.30 PIR
Post Implementation Review
27.31 PIR
Project Issues Report
27.32 POST IMPLEMENTATION REVIEW (PIR)
An important part of the management and control aspects of a project, the Post Implementation Review is typically carried out some nine to twelve months after the project output becomes operational. The purpose of the PIR is:
* to check that the system has met, and continues to meet its objectives as stated in the project's Terms of Reference and the Customer Specification;
* to ensure that the system is meeting the user/customer needs;
* to ensure that the claimed benefits of the project are being met.
Responsibility for recommending a PIR rests with the Project Board, and is usually set up at the final Project Board meeting - the Project Closure meeting.
27.33 PRINCE
A project management methodology. The acronym is derived from the phrase PRojects IN Controlled Environments. Version 2 of the Method (Known as "PRINCE 2") was introduced on 1 October 1996 and is becoming recognised as "best practice" in project management.
PRINCE is the mandated UK Government standard for managing major projects, and is used extensively within the private and public sectors for a wide range of projects, not just those involving IT.
The methodology is owned by CCTA (Central Computer & Telecommunications Agency - formerly The Government Centre for Information Management)and is supported by an active User Group (PRINCE User Group) which meets every six months.
27.34 PROCESS
PRINCE 2 introduces a "Process-based Approach" to managing projects. There are seven processes within PRINCE 2, plus an eighth "Planning" process which is used across the board. All the Processes must be present in a PRINCE 2 controlled project. The seven Processes are:
* Starting Up A Project
* Initiating A Project
* Directing A Project
* Managing Stage Boundaries
* Controlling A Stage
* Managing Product Delivery
* Closing A Project
27.35 PRODUCT/DELIVERABLE/OUTPUT
Any interim or final output from a project. A PRINCE 2 Product may be internal (for use by the project team), or external (for delivery to the user/customer).
PRINCE 2 sub-divides Products into Management, Quality, and Specialist categories; these Products then provide, respectively, the Project Management Standard, Quality Management Standard, and the Build Standard for the project.
27.36 PRODUCT BREAKDOWN STRUCTURE (PBS)
Identifies the Products which must be produced. The PBS is usually presented in a hierarchical structure, decomposing the Products through a number of levels (typically, but not necessarily, three - Project, Stage, and Team) each with three main branches - the Management, Quality, and Specialist Products.
27.37 PRODUCT DESCRIPTION
A description of the purpose, composition, format, derivation, person with responsibility, quality criteria, quality method, and resources best placed to test the Product, to be applied to each Product within the project.
Product Descriptions are fundamental to the PRINCE 2 Methodology (and an essential part of structured project management) and must be prepared for every Product.
27.38 PRODUCT FLOW DIAGRAM (PFD)
This plan shows the sequence of the development of the Products and the relationships and dependencies between them.
27.39 PROJECT
A project may be simply described as an initiative to bring about change in a controlled way. It will normally have the following characteristics:
* A clear statement of Objectives;
* A Business Case (Benefits and Risks);
* A defined and unique set of Specialist Products, supported by Product Descriptions;
* A corresponding set of Activities to construct the identified Products;
* A defined amount of Resources (Effort, Time, Funding);
* A finite life span;
* An Organisation Structure with defined responsibilities;
* A stated and agreed Control Structure.
27.40 PROJECT ASSURANCE TEAM (PAT)
The PAT represents part of the organisation structure in the PRINCE Version 1 organisation structure; some organisations and projects are expected to continue to retain the use of the PAT even though the term has been dropped from PRINCE 2 and replaced by Project Assurance and Project Support. The PAT comprises the following three administrative and technical functional roles (which may be combined):
*Business Assurance Co-ordinator (BAC);
* Technical Assurance Co-ordinator (TAC);
* User Assurance Co-ordinator(UAC).
The PAT help provide project continuity and integrity throughout the system development.
If a Configuration Librarian is appointed, this role is usually contained within the Project Assurance Team function; where no separate Configuration Librarian is appointed, the role is often combined with the BAC role.
27.41 PROJECT BOARD
Comprises three functional roles - Executive (also sometimes termed "Senior Business); Senior User/Customer; and Senior Supplier.
One or more people may take on each role, depending on the needs of the project and the resource requirements. Roles may also be combined, usually the Senior User/Customer and the Executive roles.
Project Board members must be senior enough to commit resources to the project and make hard decisions that will stand.
The Project Board is the ultimate authority for the project. They meet only at key decision points - Project Initiation and Closure, Stage Reviews (End Stage Assessments and Mid Stage Assessments).
27.42 PROJECT BRIEF
The Project Brief comprises the Terms of Reference for the project, plus the Business Benefits for the project; it may also include an initial list of the major (project-level) Products required to be produced by the project.
It is produced by the Project Manager during the "Starting Up A Project" process, and used as a driver for initiation of the project during the "Initiating A Project" process.
27.43 PROJECT CLOSURE
When all the Products have been delivered, the project must be closed formally. The Project Closure meeting is normally combined with the final End Stage Assessment. The final action at the Project Closure meeting is for the Executive member to sign the Business Acceptance Letter, which accepts the output of the project into the business.
Any work that needs to be carried out following the Project Closure meeting must be the subject of a separate project.
27.44 PROJECT EVALUATION REVIEW/LESSONS LEARNED
During the final weeks of the project, the Project Manager, together with Project Support (and any Team Managers) will evaluate the management and quality aspects of the project and prepare a brief report for the Project Board - this is the Project Evaluation Review based on the Lessons Learned Report collected during the project.
27.45 PROJECT FILE
All key project documentation (and appropriate Products) must be stored in a suitable file. The exact layout of a project file will depend on the organisation and the existing arrangements for safeguarding important documentation and deliverables.
PRINCE 2 suggests three types of file, similar in structure to that recommended by the SPOCE Method - separate files for Specialist Products , Management Documentation and Quality Documentation.
27.46 PROJECT GANTT PLAN
This is a required plan which shows the start and end dates for the activities which must be carried out to deliver the required Products for the project. The plan also shows End Stage Assessment dates which enable the Project Board members to schedule their diaries.
27.47 PROJECT INITIATION DOCUMENT (PID)
The PID provides a good foundation for the project, and provides an opportunity for the Project Manager, Project Team, and Project Board members to think ahead and identify potential problems and risks.
The content of the Project Initiation Document will vary from organisation to organisation, but will always contain the following:
* Terms of Reference;
* Organisation Structure Chart;
* Roles and Responsibilities;
* Project Plans - Product, Activity, Resource; Plan Description;
* Next Stage Plans - Product, Activity, Resource; Plan Description;
* Control Structure, described within the Plans;
* Quality Plan - Configuration Management Arrangements;
* Business Case - Benefits and Risks (plus Proposals);
The PID is a Management Product in its own right and provides a Baseline for the project. The content of the PID will, however, change as the project progresses (ie the people involved, the plans and the benefits and risks). These elements are therefore extracted from the PID and incorporated into the Project File as separate items; they are updated as the project progresses.
The SPOCE Method incorporates a two-phase Project Initiation Document approach. The Initial PID captures what is known at the very outset of the project and includes plans up to the point when sufficient information is available to complete planning to the end of the project. The Final PID can then be produced and provides the Project Baseline. This approach enable projects to be launched under control with minimal information about the physical outcome.
27.48 PROJECT ISSUES LOG
A record of all Project Issue Reports raised during the life of the project. The Project Issues Log is input to the Senior User at each Project Board meeting for prioritisation of uncleared Project Issues (ie those which have not been rejected or converted to Requests for Change or Off-Specifications).
27.49 PROJECT ISSUE REPORT (PIR)
Used to raise issues relating to the project. The subject of a Project Issue Report can be anything to do with the project - an error or an idea for improving functionality or use of the final output of the project. Project Issue Reports can be raised by anyone involved with the project. They are the mechanism for anyone to bring issues to the attention of the Project Manager.
Project Issue Reports are always logged onto the Project Issues Log. They form the precursor to Requests for Change and Off-Specification Reports.
27.50 PROJECT MANAGEMENT STANDARD; PROJECT MANAGEMENT SYSTEM
The implemented PRINCE 2 project management standards and procedures, which all project staff will abide by.
27.51 PROJECT RESOURCE PLAN (PRP)
A summary of the resource and monetary need for the project. Its content may vary but will generally contain the following elements:
* Stages - Number and Description;
* Skill Types;
* Effort against each Skill Type identified;
* Project Management Effort;
* Effort Costs against each Skill Type;
* Bought-In Costs;
* Project Management Costs;
* Hardware/Equipment Costs;
* Contracted Costs;
* Total Costs;
* Cumulative Totals.
27.52 PROJECT SUPPORT OFFICE (PSO)
A group of Business and Specialist resources providing a Support function to a number of projects.
A PSO will typically provide a centre of project management expertise for an organisation which has a number of projects under development.
Setting up a PSO is a natural evolution for any organisation where more than half a dozen significant project initiatives are under concurrent development; it should not be regarded as an unproductive overhead, as failure to provide this type of support will merely transfer responsibility for the administrative duties they perform to more expensive Project Managers.
27.53 PSO
Project Support Office.
A Project Support Office will be established where an organisation sees the benefits of establishing a centre of expertise for project management. The PSO will be responsible for the maintenance of the PRINCE/SPOCE/SPOCETTE project management standards and will normally provide help and assistance to project managers on project start-up (see Project Initiation).
The PSO is a natural evolution where there are a number of projects under development.
27.54 PROVIDER
A term used within PRINCE 2 to describe a provider of a service to build a series of Products. The Provider might be an external contractor or an internal organisation.
27.55 QUALITY ASSURANCE (QA)
Quality Assurance derives from having properly documented procedures within the Organisation (or just the project). These procedures (sometimes referred to as a QMS - Quality Management System) provide assurance to everyone involved that the staff working within the organisation (and/or project) have sensible, agreed, and documented procedures to follow, thus reducing the risks associated with a more speculative approach.
27.56 QUALITY CONTROL
The examination and checking of a Product to ensure that it meets its stated Quality Criteria. (See also Quality Review).
27.57 QUALITY CRITERIA
A statement of the criteria that must be applied to a Product to determine whether it is a suitable Product, meeting its Requirements. Quality Criteria effectively define the meaning of "Quality" for any particular Product.
27.58 QUALITY MANAGEMENT
All the components of PRINCE contribute towards the concept of Quality Management. It comprises the right people with the right background, experience, and skills, as well as the right attitude. Product Plans containing Quality Criteria, Activity Plans confirming that time has been allowed for quality aspects, and Resource Plans providing effort and costs for quality based activities. Controls at management and team level to pick up problems while there remains sufficient time to take any remedial action required. Quality is therefore embedded throughout the PRINCE 2 Methodology.
27.59 QUALITY MANAGEMENT STANDARD (QMS)
The implemented PRINCE quality management standards and procedures, which all project staff will abide by.
27.60 QUALITY PLAN
The Quality Plan for a PRINCE project will contain, as a minimum, the Quality Criteria against which each Product will be measured, and the method showing how the Product will be measured, and the Configuration Management arrangements for the project. The Configuration Management arrangements will include Product Control, Document Control, Version Control, Access Control, and Change Control.
27.61 QUALITY REVIEW (QR)
The means of checking whether a Product meets its Quality Criteria. Quality Reviews may be Formal or Informal - the decision is the Project Board's following recommendations by the Project Manager.
Informal Quality Reviews may take the form of a test, visual inspection, or desk-check (normally one-to-one). Formal Quality Reviews will take the form of a meeting with a Chair, Producer(the author of the Product), and 2-4 Reviewers (people who can make a contribution to assessing the Product for compliance with its Product Description, especially the Quality Criteria, and assurance that it contains no errors, omissions, or inconsistencies. (See also Quality Control).
27.62 QUALITY MANAGEMENT SYSTEM (QMS)
A set of procedures to help staff achieve consistency of approach. A QMS is an integral element for any Organisation or project wishing to be registered for BS/EN/ISO9000.
27.63 REQUEST FOR CHANGE (RFC)
A means of authorising a change to a Product within the developing system. RFCs will only be appropriate for Products which have been signed-off following Quality Review.
RFCs may only be raised by the Project Manager (or Project Board) following the analysis of a Project Issue Report.
A Request for Change raised against a Product requires corrective action to be taken and must be cleared before the project can be signed off.
27.64 REVIEWER
An independent person at a Quality Review, present to check that the Product under review meets the stated, agreed and published Quality Criteria.
Reviewers must be independent and able to make a contribution to the assessment of the Product.
27.65 RFC
Request For Change.
Risk Assessment/Risk Management Checklist
An assessment of risk must be carried out as part of the Business Case. In many projects, a simple format for quantifying the risks of not delivering the project in accordance with its stated objectives and constraints will be quite adequate.
27.66 ROLES AND RESPONSIBILITIES
Provided for all those involved in the management of a PRINCE project. Roles and responsibilities are produced during the "Starting Up A Project" process and included in the Project Initiation Document when it is assembled in the "Initiating A Project" process.
27.67 SENIOR BUSINESS
This is the term sometimes given to the Executive member of the Project Board. See "Executive Member of the Project Board"
27.68 SENIOR SUPPLIER
One of the roles on the Project Board, representing (and committing) the resources of the development organisation. The Senior Supplier represents the interests of Specialist and Supplier management.
The Senior Supplier will provide a specialist briefing for senior managers if required and arbitrate on all specialist matters.
27.69 SENIOR USER
One of the roles on the Project Board, representing (and committing) the resources of the user/customer organisation.
The Senior User represents the interests of users/customers to ensure they receive the system they need.
27.70 SPOCE
A tuned version of the PRINCE Methodology which is particularly aimed at the management of small to medium size projects. The method has been used as the basis for PRINCE based Project Management Systems by a wide variety of public and private sector organisations including Government Departments, National Health Trusts, Local Government, and Multinational Businesses.
Further information can be obtained from SPOCE Project Management Limited on 01202-780740.
Like PRINCE, the method is license-free and in the public domain. It is published by The Stationery Office, the publishers of the PRINCE 2 Methodology.
27.71 SPOCETTE
A Method for recording and auditing very small projects. It is very simple to use and takes only about 1 hour to use. Many organisations have adopted SPOCETTE to provide an audit trail for all their projects, regardless of size.
SPOCETTE measures project size by reference to a Project Ready Reckoner which positions projects by their estimated cost (or effort), duration and risk factor.
The Method is license-free and is available at very low cost from SPOCE Project Management Limited on 01202-780740.
27.72 STAGE
The project will always be divided into a number of short horizon Stages; at least two stages will always be present in a PRINCE project - one for planning and one for action - although normally there will be a number of Stages.
Stages are always "event-related" - that is they will always end with the delivery of one or more major Products. This will allow the Project Board to carry out an assessment based on what was promised and committed to, against what was actually delivered, in terms of time, budget, effort, scope, and conformance to requirements.
PRINCE does not define a specific life-cycle (although this is acceptable if it reflects the business needs of the Organisation). The principle is to plan according to what is actually required, and to define stage endings at appropriate points. Guidelines for Stage lengths are somewhere between 8-12 weeks but not more than 20 weeks.
27.73 (SPECIALIST) TEAM MANAGER
Responsible to the Project Manager for managing a specialist portion of the project, the (Specialist) Team Manager will have responsibility for planning the specialist aspects of a stage, managing the Team, and delivering the Specialist Products.
(Specialist) Team Managers may be appointed to provide specialist support for a Project Manager where a particular technical skill is required (eg Building Services, Communications, Training, IT, User/Customer, Project Management, Contract Management etc).
The (Specialist) Team Manager is an optional role in PRINCE and if the role is not perceived to be required, a (Specialist) Team Manager should not be appointed.
27.74 STAGE RESOURCE PLAN (SRP)
A summary of the resource and monetary need of a defined Stage. It will not always be appropriate to produce, but when it is, it will typically contain the following elements:
* Weeks - dates;
* Skill Types;
* Effort against each Skill Type identified;
* Project Management Effort;
* Effort Costs against each Skill Type;
* Bought-In Costs;
* Project Management Costs;
* Hardware/Equipment Costs;
* Total Costs;
* Cumulative Totals.
27.75 (SPECIALIST) TEAM
The resources needed by the project to produce and deliver the Products, Deliverables or Outputs.
27.76 STAGE PLAN (TIMESCALE/GANTT CHART)
This is a required plan which shows the start and end dates for the activities which must be carried out to deliver the required Products for the Stage. The plan also shows the Quality Reviews for each Stage Product, and may show the timings for Checkpoints.
27.77 SYSTEM ACCEPTANCE LETTER
Prepared by the Project Manager, or Specialist Team Manager, for signature by the Senior Specialist member of the Project Board, confirming that the Specialist Acceptance Tests have been carried out and have been successfully concluded.
27.78 TEAM MANAGER
See (Specialist) Team Manager
27.79 TECHNICAL
The term "Technical" has been largely (but not completely) dropped from PRINCE 2 and replaced by "Specialist". Version 1 of the method made much use of the term and many organisations and projects can be expected to retain the use of "Technical" especially when describing specialist activities (the PRINCE v1 Technical Plan), and specialist support (the PRINCE v1 Technical Assurance Co-ordinator, and Technical Team Members).
27.80 TECHNICAL ASSURANCE CO-ORDINATOR (TAC) (PRINCE V.1)
The Technical Assurance Co-ordinator is a role within the PRINCE Version 1 Project Assurance Team (or Project Support Office). The TAC provides technical assistance and help to the Project Manager and the Stage Manager where appointed.
Where technical matters are under review and consideration the TAC has a responsibility to provide technical input to the Project manager's decisions; the TAC has no executive responsibility - the role is one of advice and consult only.
27.81 (TECHNICAL) EXCEPTION
An unplanned situation relating to one or more Products, usually handled by raising a Project Issue Report, which might lead to a Request for Change or Off-Specification Report.
27.82 TECHNICAL (OR SPECIALIST) MANAGEMENT STANDARD
The implemented PRINCE technical standards and procedures, which all project staff will abide by. In a PRINCE project management environment the Product Descriptions provide the Specialist Management standard, in particular under the heading "Composition".
27.83 TERMS OF REFERENCE
A definition of the objectives for the project. The contents for Terms of Reference are:
*Background;
* Objectives;
* Scope;
* Constraints;
* Assumptions;
* Review by Management.
Terms of Reference are part of the Project Brief prepared by the Project Manager during the "Starting Up A Project" process. They are usually included in the Project Initiation Document.
27.84 TOLERANCE
The permitted limits above and below a plan's budget (or sometimes the planned and approved effort) and schedule. The Project Manager has freedom to operate within these limits but must inform the Project Board immediately before exceeding the Tolerance limit.
Tolerance is not time, money, or effort to be spent -
Tolerance is a "trigger" for reference of a project, apparently going out of control, to the Project Board. Any departure from the approved plans must be explained by the Project Manager to the satisfaction of the Project Board.
A project which exceeds Tolerance will be subject to an Exception Report to the Project Board, who may require the creation of an Exception Plan. This is a plan which will enable the Stage to continue to the next planned review (End Stage Assessment) - hopefully showing the means by which the overall project can be brought back onto schedule, or budget. This will normally be achieved by trimming the scope of the project, investing more effort and/or money, or extending the timescale, or a combination of all three.
Exception Plans may only be approved by the Project Board, who will normally require options to be presented before finally deciding the course of action.
27.85 TRANSFORMATION
The process of moving from one Product to another by defining the activities that must be completed in order to build, assemble, manufacture, draft or finalise the destination Product. Essentially the set of Activities that must be carried out to create the Product.
27.86 USER
The customer for the system - essentially anyone who will actually use the delivered system.
27.87 USER ACCEPTANCE LETTER
This is a PRINCE version 1 control, prepared by the Project Manager, or Stage Manager, for signature by the Senior User member of the Project Board, confirming that the User Acceptance Tests have been carried out and have been successfully concluded.
28. PROJECT INITIATION DOCUMENT INTRODUCTION (CHECKLIST)
Before a project is approved for initiation or continuation into the next stage of work, Project Board members and the Project Management Team might find it helpful to consider the following questions...
28.1 THE PROJECT
Are the objectives clearly stated?
Have Terms of Reference been prepared and agreed (and included in the Project Initiation Document)?
Have any changes to objectives, constraints, scope, or assumptions been made? Are any necessary?
Conformance/contribution to overall strategy - where does this project fit in? Which particular part of the overall strategy plan does it stem from? What organisational objectives does it support? Can it be defended as a contributor to the overall corporate objectives?
28.2 STAFFING
28.2.1 Structure
Has the organisation structure been properly defined?
Are clear lines of authority shown?
Are there any gaps in the organisation structure? If so why? What is the impact on the project?
Is there a need for any specialist Team Manager(s)?
Does the organisation have the specialist expertise to see the project through?
Who does the Project Board (Executive) report to?
Does the Project Board User/Customer representative truly represent the whole customer base?
Is a User Group to be set up to represent the customer where large customer communities are to be affected by the undertaking? Do they know about this? Will they support the User Group and attend? What evidence is there to support the answers?
How will Project Assurance be handled for the project? Do the Project Board members intend to carry out Project Assurance themselves? what proposals are there for independent assurance to the Project Board.
Do you have confidence in the Project Manager's ability to deliver the project outputs successfully?
Will the Project Manager be capable of motivating and leading the team - does he/she have the required personal leadership characteristics?
28.2.2 Roles and Responsibilities
Have Job Descriptions/Roles and Responsibilities been defined for all staff including the Project Board?
Have roles and responsibilities been defined for team members? If not, is the Project Manager confident that team members understand their role(s)? On what is this confidence based?
Do the Job Descriptions accurately reflect what you expect of the personnel working on the project - including yourself and other members of the Project Board?
Are any external consultants to be used - are there job descriptions for these people? On what basis were they selected?
Do the Project Board members have ability to commit the resources required? The Project Manager and Team have drawn up the plans - they should be able to confirm that resources are available to the project. If they can't, why? Have the line managers been consulted and given agreement? If not, why?
28.3 PLANS
Are the timescales acceptable? (especially the end date).
How many stages are planned? - how long each stage - how long the longest, how short the shortest? - what are the reasons. Do the stage lengths reflect the review element in the Terms of Reference? Does the Project Board, and the Project Manager feel that the number of stages is right for the scope/nature/risk of the project? Have the Team Members and the Project Management Team seen and agreed the plans? Do they believe they are achievable?
Are there at least two stages - one for planning the project the other for carrying out the work?
Are the stages event-related - ie will each Project Review be tied in to the planned delivery of a significant Deliverable/Product/Output ?
Will sufficient evidence (ie that Products meet their stated quality criteria) and information (ie actual management performance against budget and plan) be available at the planned stage end, to enable the Project Board to take a decision to continue?
Are there proposals to reduce or eliminate and manage high risk areas? Is the Risk Assessment in the Project Initiation Document (PID)? What form of Risk Assessment has been used? (eg: PRINCE/SPOCE Risk Management Checklist; Software based Risk Assessment; Delphi (ask the Oracle!) Method )?
Is a list (or better still a Product Breakdown Structure) of all the project-level Products, Deliverables, or Outputs available? Are all the project-level Products supported by a Product Description defining them at least in terms of their composition and identifying the Quality Criteria to be applied? Are these in the Project Initiation Document?
Are the next stage Deliverables/Products/Outputs identified; Are there Product Descriptions, showing Purpose, Composition, Format, Derivation, Allocated To, Quality Criteria, Quality Method, and Resources for Achieving a Successful Quality Product, available to support each of the proposed next stage Products?
Have the required resources been defined? Have the resources been approved/agreed by local line managers? In particular have any user/customer resources been specified and agreed? Has the user/customer liaison contact agreed the resource plan?
Does the resource plan show costs as well as effort? Are the costs acceptable? Do they reflect the budget and any financial constraints?
On what basis have estimates for the activities in the plan been derived? Are formal estimating approaches in use - if not how have estimates been calculated?
How much confidence does the project manager have in the estimates? What do the Project Assurance staff think about the estimates? Has any outside advice been taken?
How much contingency is included in the timescales, effort and cost estimates? Has one overall contingency been incorporated or have differing levels of contingency been used to reflect high/low risk areas? What is the basis for either approach?
28.4 CONTROLS
Do you have sufficient information on which to make decisions? Are you happy with the Project Team's performance during the last stage? - Have all the promised products been delivered on time, within budget, and to the stated quality criteria?
Do the next stage plans look realisable? Are the overall project plans (timescale, cost, effort, products) still attractive? Is the scope unchanged?
Will the users/customers still be getting the end-product they want/need/require? Is the project still of interest to the business? Does it still address the requirements of the original strategy? Does the original strategy still make sense? Are there competing projects that might be of more value to the business?
How much tolerance (ie the measure of "a significant departure from plan") should be handed down to the Project Manager? Defaults over a stage are 1 week on time; 10% on cost/effort. An important, sensitive project with a well trusted and experienced Project Manager might benefit from more generous tolerance; an un-tested Project Manager responsible for a straightforward project would benefit from a tighter, lower, tolerance.
What will be the frequency of regular team meetings? - Weekly is normal.
How often will regular reports (Highlight Reports) be provided to the Project Board? Has a format for Highlight Reports been prepared and agreed? Is the information to be provided what you need? Will the Highlight Report be quick and easy to read - and actually highlight key features?
28.5 PROJECT MANAGEMENT
What effort is being planned for project management - measured in either staff days or percentage of development effort? What is the split between project team, Project Manager, Project Support/Project Assurance?
How does this project management effort compare with earlier stages and other projects? Is the Project Manager satisfied with the amount of project management effort and support?
What are the arrangements for collection of "actuals" against plan? Who will up-date the plans? Has actual data been used to produce or confirm the current estimates? Is actual data to be used in the refinement of future estimates?
28.6 QUALITY
Quality Management is essential. How will quality be assessed, for each deliverable/Product and for each stage, and for the project overall? Can the Project Manager satisfactorily explain/describe how this will be achieved?
Find out how quality will be managed in the project; will the quality management aspects be managed in accordance with proven site standards, national or international standards (BS/EN/ISO9000), or one-off project standards? Have specific Quality Criteria been produced for all project level Products?
Ensure Product Descriptions and Quality Criteria have been established for each Product.
What Products will be subject to formal Quality Review? How will the other Products be measured for quality?
Have staff been trained?
How much resource has been assigned to quality? What is the cost?
28.7 PROJECT HOUSEKEEPING (CONFIGURATION MANAGEMENT)
Has this been considered? How will completed Products be stored, safeguarded, accessed, transferred?
How will changes to Products be handled/controlled?
How will the documentation produced under the project be handled and controlled?
What Project Files will be established? Will there be a separate Project/Stage file containing a record of all management documentation? Will separate Product and Quality Files be established?
Will the project documentation facilitate subsequent maintenance and enhancements?
29. BUSINESS CASE INTRODUCTION
The Business Case within PRINCE 2 comprises two separate elements - the Business Benefits and the Risks (and Proposals for managing the identified risks).
29.1 BUSINESS BENEFITS:
A simple statement of the benefits will often suffice. To measure the benefits, a ** Costs:Benefits Analysis** may be prepared, but this is not required by PRINCE 2.
It is often helpful to describe the Project Benefits separately from those that will arise from operating the eventual outcome of the project. Standard sub-categorisations (Financial, Strategic, Customer, Staff, Organisational etc.) may also be useful for structuring the benefits statement.
29.2 RISK ASSESSMENT AND PROPOSALS:
A statement of risk and proposals for managing the risks is acceptable. However, a ** Risk Assessment Checklist** is associated with the method. This checklist is available from SPOCE Project Management in spreadsheet format and provides an overall ** Risk Factor** for the project, enabling managers to assess the likelihood of the project being delivered on schedule, within budget, and meeting the agreed requirements.
** Proposals** for managing the identified high risk areas must be provided to management responsible for authorising initiation and continuation of the project.
The Business Case must be up-dated at each formal review of the project. It is recommended that the Risk Assessment be ** up-dated and logged** at weekly intervals for the first stage of the project.
Subscribe to:
Posts (Atom)