The following are study notes from PRINCE2 manual published by the UK Office of Government Commerce.

Introduction

A project is an organisation created to deliver one or more products according to an agreed business case. A project introduces change, is temporary, cross-functional, unique and uncertain.

Project management is a method for planning, delegating, monitoring and controlling the aspects of a project. The aspects are scope, time, cost, quality, risk and benefits.

The PRINCE2 method includes (a) principles, (b) themes, (c) processes and (d) tailoring. There are only two specific techniques detailed; the product-based planning technique and quality review technique.

PRINCE2 does not provide specialist aspects, detailed techniques, or leadership capability.

PRINCE2 is embodies proven best practise, can be applied to any type of project, is widely recognised with a common vocabulary, provides explicit recognition of responsibilities, and provides a highly structured approach to accountability, delegation, authority, and communication. It manages by exception and manages by stages.

Principles

It is the adoption of principles that determines whether a project is using PRINCE2, not the adoption of processes and documents alone. The principles are (a) business justification, (b) learn by experience, (c) defined roles and responsibilities, (d) manage by stages, (e) manage by exception, (f) focus on products, (g) tailor to suit the environment.

A PRINCE2 project must have justification to start it and to continue throughout the project. If a project can no longer be justified it must stop. Justification must be documented and approved.

A PRINCE2 project learns by experience. When starting a project lessons learned from similar projects are sought, as the project progresses lessons are included in reports and reviews, and when the project closes lessons are identified and passed on for the future.

A PRINCE2 project has defined and agreed roles and responsibilities. All projects have the following primary stakeholders; business sponsors, users, and suppliers. Business sponsors ensure the investment provides value for money. Users gain the intended benefits and feel the pain. Suppliers, internal and external, provide the resources.

A PRINCE2 project is planned, monitored and controlled by stages. There is at least two stages; initiation plus one or more management stages. Planning is only conducted on the level that is forseeable. The greater the complexity and risk, the more stages that should be implemented.

A PRINCE2 project has agreed tolerances for its aspects. If these tolerances establish limits of delegated authority. If they are breached the next higher level must manage the exception. PRINCE2 enables appropriate governance by defining distinct responsibilities for directing, managing, and delivering the project.

A PRINCE2 project focuses on the definition and delivery of products, according to their quality criteria. This means there is a common understanding of the products required. When delivered, this provides acceptance.

A PRINCE2 project ought to be tailored for a particular situation. Tailoring ensures that the method relates to the environment, and that project controls are based on the project's scale, complexity, and importance. The Project Manager and the Project Board will make an decision on how the method will be applied, and this will be documented in the Project Initiation Document.

PRINCE2 themes describe the aspects of project management which must be addressed continually. There are seven themes: (i) business case (why?), (ii) organisation (who?), (iii) quality (what?), (iv) plans (how?, how much?, when?), (v) risk (what if?), (vi) change (what's the impact?), (viii) progress (where are we?, where are we going? should we continue?).

Business Case Theme

The Business Case theme establishes mechanisms to judge whether the project is and remains desirable, viable and achievable. It is the justification for the project. The business justification is documented in the Business Case.

Products are outputs, which lead to outcomes, which provide benefits. Benefits are always expressed in quantifiable terms.

In PRINCE2, the business case is developed at the beginning of the project and is maintained throughout the project, verified by the Project Board at each stage assessment and other key points, and confirmed that the benefits accrue. The Executive is responsible for the Business Case. Development may be delegated, typically to a Business Analyst or Project Manager. A detailed Business Case is derived from the outline Business Case, the Project Plan (cost, timescale, products), and the Risk Register.

It is the responsibility of the Executive to assure that the project stakeholders remains justifiable at all times. The Executive should not rely on end-stage assessment alone, but rather should make use of Project Assurance as Highlight Reports as well.

The Senior User(s) specify the benefits and is held to account by demonstrating to corporate or programme management that forecasts are in fact realised. The Executive is responsible for ensuring that benefit reviews are planned and executed. The Benefits Review Plan is first created by the Project Manager in the initiation stage and approved by the Project Board.

The three basic business options concerning investment always include (a) do nothing, (b) do the minimal (e.g., a workaround), (c) do something.

The Business Case should list each benefit that it is claimed would result from the project's outcome. This can be financial and non-financial, but must be aligned to corporate strategy, mapped to outcomes and outputs, quantified (with tolerance), measurable, and assigned.

Organisation Theme

The Organisation theme defines and establishes the project's structure of accountability and responsibilities. It is based on a customer/supplier model.

A project may be a stand-alone entity or it can be part of a programme of related projects. Regardless, it will exist within the wider context of a corporate organisation.

PRINCE2 does not define management jobs - it defines roles. This includes the three primary categories of stakeholder which are included on the Project Board; Business, User and Supplier interests. The Business is interested in value for money, the User in desired outputs, and the Supplier in producing the project products. The customer is usually interpreted as a collective term for Business and User roles. Sometimes the Executive (Business) can be combined with the Senior User.

PRINCE2 separates the direction and management of the project from the delivery of the outputs. The project management structure has four levels, of which the bottom three represent the project team. The top level is the corporate or programme management. The Project Board gives direction, the Project Board gives management, the Team Manager delivers.

The Executive can be combined with the Senior User role.

The Project Board should display four key characteristics; (a) authority, (b) credibility, (c) ability to delegate, (d) availability.

The Executive is ultimately accountable for the project's success and the key decision maker. The Executive ensure that project gives value for money and is responsible for the Business Case. The Senior User represents those who will use the project (including operations and maintenance). The Senior Supplier is accountable for the quality of products delivered and is responsible for the technical integrity of the product.

The Board is responsible for appointing a Project Assurance role, independent of the Project Manager. Assurance however is also responsible for supporting the Project Manager with advice and guidance.

Producing a matrix of products with stakeholders helps split stakeholders from decision-makers. Stakeholders need to be engaged as part of the Communications Management Strategy, project decision makers need to be on the Project Board.

The Project Board should define in the Configuration Management Strategy a scale of severity ratings for change, and determine, as Change Authority, what conditions are places for the authorisation for change or off-specifications.

In PRINCE2 the Project Manager's role should not be shared. The Project Manager managers Team Managers and Project Support, and is responsible for liaison with Project Assurance and the Project Board. The Team Manager's primary responsibility is to ensure production. PRINCE2 uses Work Packages to allocate work to Team Managers or team members.

The Project Support role, which is responsible for the documentation repository, is not optional. It does default to the Project Manager if there is no other person allocated to the role.

The use of "management by stages" also allows smooth transition for changes to the project management team if needed.

The Communications Management Strategy facilitates engagement with stakeholders through the establishment of a controlled and bi-directional flow of information.

Quality Theme

The theme of Quality defines the means by which a projects verifies that products are fit for purpose. Quality Systems and Quality Assurance exist on the Corporate level and should be differentiated from Quality Planning and Quality Control, on the Project level.

In PRINCE2 Quality is defined as the totality of features in a product, process, person, service, or system. The scope of a plan is the sum total of its products, defined by a product breakdown structure.

Project Assurance is undertaken from within the project and assures that the project is being conducted properly with regard to internal rules. Quality Assurance is the responsibility of the corporate or programme management is external to the project. It assurances the the project complies to corporate standards and legislation.

The Quality System and Quality Assurance is corporate responsibility. Quality planning and quality control is project responsibility.

The Project's acceptance criteria provide a prioritised and measurable definitions of attributes. A popular prioritisation technique is MoSCoW (must, should, could, won't).

Product Descriptions should not be written in too much detail as it increases the cost of quality in the project. Project Product Descriptions include (a) the overall purpose of the project, (b) composition (set of products), (c) customer's quality expectations, (d) acceptance criteria, methods, and responsibilities, (e) project-level quality tolerances.

The Quality Register is a diary of quality events planned and undertaken. This will include quality control, which includes carrying out quality methods (e.g., inspection, testing etc), maintaining quality and approval records, and gaining acceptance.

The quality review technique is conducted as a formal meeting with prior circulated questions. The review team agrees on actions for each question. If follow-up action is not feasible or not within tolerance, then it should be raised an issue for the Project Manager.

Plans Theme

Plans facilitate communication and control, by focusing on products and managing by stages (the where, how, by whom, and when of products).

Plans are the backbone of the management information system required for any project. They must be kept in line with the Business Case at all times.

PRINCE2 recommends three levels of plan to suit the needs of the different levels of management. Outside of the project there may be a corporate or programme plan. The Project Plan provides the Business Case, with Project costs and timescales as a baseline. The Stage plan is similar to the Project Plan but with adequate detail for day-to-day control for the Project Manager. Team plans are produced by a Team Manager to facilitate Work Packages. They are optional.

Exception Plans are prepared for the appropriate management level to show the actions required to recover from the effects of tolerance deviation.

Plans are designed as a prerequisite. Then, simultaneous with an analysis of risks, products are defined and analysed, then activities and dependencies, then estimates, then the schedule, and finally documentation. This process is repeated for project, stage and team plans. It is a product-based planning technique.

The "philosophy" (grrr) behind producing plans in PRINCE2 is that the products required are identified first and only then are the activities, dependencies, and resources required to deliver those products identified. This is product-based planning. The benefits include (for example) involving users in specifying the product requirements, thus increasing buy-in and reducing approval disputes, and clarifying the scope boundary, defining products that are in and out of the scope.

The first task of product-based planning is to write the Project Product Description. The plan is then broken down into its major products, which are then further broken down etc, until an appropriate level of detail is reached. It is useful to identify any external products required by the plan, as the Project Manager is not accountable for their creation. For each external product there should be a corresponding entry in the Risk Register.

If a detailed requirements for specification for a product is already available, this may be used as a substitute for the Product Description.

A flow diagram needs to be created that identifies and defines the sequence in which the products of the plan will be developed and any dependencies between them. Dependencies are internal or external. An external dependency includes the delivery of a product from another project.

Risk Themes

The Risk theme identifies, assesses and controls uncertainty. Risk is an uncertain event that will have an effect on the achievement of objectives. They can be threats or opportunities. Different organisations have different 'risk appetites'.

Project Support will maintain the Risk Register on behalf of the Project Manager.

The Risk Management procedure is sequentially (a) identify (context and risks), (b) plan, (c) implement, with (d) communication, throughout.

An effective way to identify risks is to use a risk workshop. Identification should involve noting the risk cause, the event, and the effect. A typical estimation technique is a quantitative probability impact grid.

Risk responses do not necessarily remove a risk in entirety; it may leave a residual risk. It is also possible that the response to a risk can change some aspect of a project resulting in a secondary risk.

Threat responses are; avoid, reduce (probability and impact), fallback (impact only), transfer, share, or accept. Opportunity responses are exploit, enhance, share or reject.

The Risk owner is the named individual responsible for managing, monitoring, and control of a particular risk. The risk actionee carries out the risk response action.

Change Themes

The Change theme identifies, assesses and controls changes to the baseline. The baseline should use a form of version control in documentation. The process to manage changes and issues is the Configuration Management Strategy.

A configuration item is an entity that is subject to configuration management. The entity may be a component of a product, a product, or a set of products that form a release.

Issues consist of Requests for Change (funded from the Change Budget), Off-Specifications aka stuff-ups (funded from Tolerances), and Problem/Concerns, which require approval from the Project Board. Tolerances should not be used to fund Requests for Change!

The following management products are used to establish and maintain the project's controls for issues, changes, and configuration management: (a) configuration management strategy, (b) configuration item records, (c) product status accounts, (d) daily log, (e) issue register, (f) issue reports.

Effective issue and change control is only possible if it is supported by a configuration management system that facilitates impact assessments (relationships between products) and maintains product baselines (the basis from which the entity will change).

The Configuration Management Strategy should define the configuration management procedure and the issue and change control procedure.

It is the Project Board's responsibility to review and approve requests for change and off-specifications. But for projects where there is likely to be lots of changes the Project Board may choose to delegate this to a Change Authority (e.g., the Project Manager).

The Project Manager needs to consider whether it is worthwhile going a detailed impact analysis as the effort itself may cause a deviation from the plan. An impact analysis must cover the three areas of business, user, and supplier. Having taken an impact analysis, the severity or priority should be re-evaluated/

Progress Theme

The Purpose of the progress theme is establish mechanisms to monitor and compare actual achievements against those planned and provide forecasts. It is based on the principles of manage by stages, manage by exception, and business justification.

An exception is a situation where it can be forecast that there will be a deviation beyond the agreed tolerance levels. The principle of manage by exception uses different types of tolerance against which a project can be controlled which equate to setting and reporting. They are (i) project tolerance, from programme and corporate management and (ii) project progress/exceptions, to programme and corporate management, (iii) stage tolerance, to the project manager, (iv) stage progress/exceptions, from the project manager, (v) work package tolerance, from the project manager, (vi) work package progress/issues, to the the project manager.

Stages should be shorter when there is greater risk, uncertainty, or complexity. They can be longer when the risk is lower, typically in the middle of projects. PRINCE2 provides two types of progress control reports throughout the life of a project; event-driven controls and time-driven controls.

The Work Package and report back to the Project Manager is via Checkpoint Reports. There is one Checkpoint Report per Work Package.

If the forecast is project tolerances will be exceeded, the Project Board has the authority to manage the project and must refer the matter to corporate or programme management for a decision.

Processes

PRINCE2 is a process-based approach to management. Pre-project there is a project mandate to set the inquiry into action. It is important to verify that the project is worthwhile and viable. This is the Project Brief and a stage plan for initiation.

The Project Board reviews the brief and decided whether to initiate the project. The initiation stage culminates in the production of a Project Initiation Document. The Project Board delegates day-to-day control to the Project Manager on a stage-by-stage basis. The Project Manager ensures that a set of project records are maintained to assist with project control. The Team Managers execute the Work Packages and keep the Project Manager appraised of progress via Checkpoint Reports. During the final stage, once the Project Manager has gained approval for all of the Project's products, it is time to decommission the project.

Starting Up A Project (SU)

The purpose of the starting up a project process is to determine whether or not there is a worthwhile project. At this stage, do the minimum necessary to come to this decision. The effort involved with vary (business context).

During the Starting Up process, the activities include appointing the Executive and Project Manager, capture previous lessons, prepare the outline Business Case, assemble the Project Brief, and plan the initiation stage.

Appointing a Project Manager will allow the project to be managed on a day-to-day basis. The Project Manager will initiate a Daily Log and Lessons Learned Log and develop the Project Brief, which will include an outline Business Case and a Project Product Description, along with the project approach and additional role descriptions.

Documentation includes the Project Brief (Role descriptions, Outline Business Case, Project Product Descriptions, Project Approach), Daily Log, Lessons Log, Initiation Stage Plan, and the Request to Initiate A Project.

Directing A Project (DP) Process

The purpose of the directing a project process is to enable the Project Board to be accountable for the project's success whilst delegating day-to-day management to the project manager. The Project Board manages by exception. It monitors via reports through a small a number of decision points. The Project Board is responsible for ensuring there is continued business justification.

The Directing a Project process is initiated from the Starting up a Project process, as input, and concludes with the Closing a Project process, as an output. i.e.,

Starting Up a Project - Directing A Project (Initiating A Project - Controlling A Stage (Managing Product Delivery) - Managing A Stage Boundary) - Closing A Project

Within the directing a project process, the Project Board will authorise initiation, authorise the project, authorise a stage or exception plan, give ad-hoc direction, and authorise project closure. Initiation is triggered by a request from the Project Manager for authorisation to deliver the project. Ad-hoc direction may occur as a response to reports e.g., Highlight Report (time-driven within a stage), Exception Report, Issues Report.

Authorising closure of the project is the last activity undertaken by the Project Board, prior to its own disbandment, and may require endorsement from corporate or programme management.

Initiating A Project Process (IP)

The purpose of the initiating a project process is to establish a solid foundation for the project. It establishes a common understanding of benefits and risks, the scope, the products and their cost, etc as baselines.

During this process the Project Manager will create a suite of management products required for the level of control specified by the Board. This will include the Risk Management Strategy, the Configuration Management Strategy, the Quality Management Strategy, the Communications Management Strategy, the project controls, the Project Plan, a refined Business Case, and assembling the Project Initiation Documentation.

The refined Business Case will include a Benefits Review Plan. The Business Case will be part of the Project Initiation Documentation.

The activities to establish the strategies for the project may be executed in parallel, but it is recommended that the Communications Management Strategy is completed last as it will need to include any communications required of the other strategies.

Project controls include the frequency and formation of communication between project management levels, the number of stages and end-stage assessments, mechanisms to capture issues and changes, mechanisms to escalate exceptions, tolerances for delegated authorities, monitoring of delegated authority.

Documentation of the Initiating a Project stage includes the Project Initiation Document (Strategies, Role descriptions (U), Project Controls, Project Plan, Project Product Description (U), Detailed Business Case), the Risk Register, Benefits Review Plan, Configuration Item Records, Issue Register, Quality Register, Request to Deliver a Project

Controlling A Stage Process (CS)

The purpose of the controlling a stage process is to assign and monitor work, deal with issues, report progress to the Board, and take corrective actions to ensure that the stage remains within tolerance levels.

The controlling a stage processes is first used after the Board authorises the Project. Work Packages are used to define and control the work being done, and sets tolerances for the Team Managers. There must be a level of autonomy within the project teams.

Activities include the authorisation, reviewing work package status, and receiving completed work packages, reviewing stage status, reporting highlights to the Board, examination of issues and risks, escalation of issues and risks and taking corrective action.

Documentation in the Controlling A Stage process include Work Packages, Configuration Item Records (C, U), Quality Register (U), Risk Register (U), Issue Register (U), Stage Plan (U), Lessons Log (U), Issue Report (C, U), Highlight Reports. Daily Log (U), Exception Report (C), Stage Boundary Approaching notification, Project End Approaching Notification, Requests for Advice, Exception Raised notification.

Managing Product Delivery (MP) Process

The purpose of the managing product delivery process is to control the link between the Project Manager and the Team Managers by placing formal requirements on accepting, executing, and delivering project work.

Activities are simply to accept, execute and deliver a work package.

The Team Manager agrees works on products allocated to the team and is authorised to carry out the tasks by the Project Manager. Accurate progress information is provided to the Project Manager via Checkpoint Reports.

Documentation in the Managing Product Delivery process includes the Team Plan (C, U), Quality Register (U), Specialist Products (C), Configuration Item Records (U). Checkpoint Reports (C), Work Package (U), Completed Work Packages, and Approval Records (formalises that the product is complete).

Managing A Stage Boundary (SB) Process

The purpose of the managing a stage boundary process is for the Board to review the current stage, approve the next stage, review the updated project plan, confirm business justification and acceptance of risks. The Board must assure that all products in the current stage plan have been completed and approved. For exceptions, the Project Manager must prepare an Exception Plan and seek approval from the Board for the Exception Plan.

If a stage or the project is forecast to deviate beyond its agreed tolerances, it no longer has the approval of the Project Board. Exception Plans are requested by the Project Board in response to an Exception Report. Although an Exception Plan will be produced prior to the planned stage boundary, its approval by the Project Board marks a stage boundary for the revised stage.

The activities within the managing a stage boundary process include planning the next stage, updating the project plan, updating the business case, reporting a stage end, and producing exception plans.

Documentation for the Managing A Stage Boundary process include the Project Initiation Document (U) (Project Plan, Business Case), Stage Plan/Exception Plan (C) (Product Descriptions)

Closing A Project (CP) Process

The purpose of the closing a project process is to provide a fixed point where acceptance of the project product has been confirmed and that the objectives in the Project Initiation Document have been achieved.

The activities of the process are Project-Manager orientated and are to prepare planned closure, prepare premature closure, hand over products, evaluate the project and recommend project closure. It must include transfer of ownership to the customer and terminate the responsibility of the project management team.

Project closure is confirmed by the Board. The Communication Management Strategy is used to identify stakeholders who should be notified of closure. The project's registers (Issues, Risks, Quality, Daily Log, Lessons Learned) should be closed. Project information should be secured and archived. The Manager must seek approval to give notice to the corporate or programme management that resources are about to be released.

In some situations, the Project Board may have instructed the Project Manager to close the project prematurely. In such circumstances, the Project Manager must ensure that the work in progress is not simply abandoned, but that the project salvages anything of value created to date and checks that any gaps left by the cancellation of the project are raised to corporate or programme management.

Documentation in the Closing A Project process include the Project Plan (U), Product Status Account (C), Issues Register (U), Additional Work Estimates (C), End Project Report (C), Configuration Item Records (U), Benefits Review Plan (U). Follow-On Recommendations (C, U), Lessons Report (C), Acceptance Records (formalises that the project has met its agreed acceptance criteria).

Tailoring PRINCE2 to the Project Environment

Tailoring refers to the appropriate use of PRINCE2 on any given project, ensuring there is the correct amount of planning, control, governance, and use of processes and themes, whereas the adoption of PRINCE2 across an organisation is known as embedding. Tailoring is about thinking about how to apply the method and then using it with a lightness of touch.

The distinction between projects and programmes is that projects typically produce or change something and are then disbanded. The benefits of the understanding are likely to be accrued afte the projects are complete. Programmes are typically used to transform organisations and have a lifespan that covers the realisation of the benefits - which could be several years.

Overall, the purpose of PRINCE2 can be regarded as reducing the risk of failure. Thus, whenever an element of PRINCE2 is reduced, this should be seen as a risk.