PRINCE2 Practitioner cheat sheet
PRINCE2 Practitioner · Keep the key ideas within reach.
Business Case
The business case is developed at the start of the project, updated at each end stage and at each exception, and confirmed as still viable at each end stage boundary.
Business case contents: reasons, business options (do nothing, do minimum, do something), expected benefits, expected dis-benefits, timescale, costs, investment appraisal, major risks.
The do-nothing option must always be evaluated and used as the baseline against which the other options are compared.
Benefits are expressed in measurable terms in the business case; the senior user is accountable for realising them, and benefit reviews are planned after project closure.
Outputs, outcomes and benefits: outputs are produced by the project, outcomes are the result of using the outputs, benefits are the measurable improvement resulting from outcomes.
The executive owns the business case and is accountable for it; the business case is part of the PID and is reviewed by the project board at every end stage.
The business case is used to decide whether to start, continue or stop the project; if it is no longer viable the project should be stopped or changed.
Investment appraisal compares the business options using techniques such as whole-life costs, net benefits, payback period, return on investment and discounted cash flow.
Organization
The project board has three roles: executive (owns the business case and is ultimately accountable), senior user (specifies needs and benefits), and senior supplier (provides resources and technical authority).
The executive is responsible for the project's single point of accountability and appoints the other project board members; the executive is supported by the project manager for day-to-day management.
Project assurance is a project board responsibility and must be independent of the project manager, team manager and project support.
The project manager manages the project on a day-to-day basis, prepares plans and reports, and escalates to the project board via exception reports.
The team manager manages the work of a team and may be internal or external; the team manager reports to the project manager and not to the project board.
Project support provides administrative services such as configuration management, document control and planning support; the role may be combined with other roles.
The four levels of organisation in a project: corporate or programme management, project board, project manager, and team manager/team members.
A project is a temporary organisation created to deliver one or more business products according to an agreed business case; it is not business as usual.
Quality
Quality management in PRINCE2 is based on a quality management system, quality planning, quality control and quality assurance; the project board approves the quality management approach.
The quality management approach describes the project's quality standards, procedures, techniques and responsibilities, and is part of the PID.
The quality register records all quality activities, including planned reviews and tests, and is updated as quality activities are completed.
Product descriptions are created for each product and include purpose, composition, derivation, quality criteria and quality method, plus the quality tolerance.
Quality criteria must be measurable; quality tolerance defines the acceptable range for each quality criterion.
Quality control comprises quality reviews, quality inspections and testing; a quality review is a structured review of a product against its quality criteria.
A quality review has defined roles: chair, presenter, reviewer and administrator; the presenter is usually the author of the product.
The quality review process: plan the review, prepare for the review, conduct the review, and follow up on actions and approval.
Plans
PRINCE2 has three levels of plan: project plan, stage plans, and team plans; exception plans are created when tolerances are forecast to be exceeded.
The project plan shows the major products, activities and resources for the whole project; it is the baseline against which progress is measured.
Stage plans cover the work of a single management stage and include the products, activities, resources and tolerances for that stage.
Team plans are optional and are prepared by the team manager for the work allocated to the team.
Planning steps: design the plan, define and analyse products, identify activities and dependencies, prepare estimates, prepare the schedule, analyse risks, and document the plan.
Product-based planning: write the project product description, create the product breakdown structure, write product descriptions, and create the product flow diagram.
Estimating techniques include analogous estimating, parametric estimating, three-point estimating and effort-based estimating; estimates should be recorded with their basis and assumptions.
Tolerances in plans are time, cost, scope, quality, risk and benefit; the project board sets project-level tolerances, and the project manager sets stage-level tolerances.
Risk
Risk is an uncertain event that, if it occurs, will have an effect on the achievement of objectives; risk management is a continual activity throughout the project.
Risk management approach describes the risk procedures, techniques, standards and responsibilities; it is part of the PID.
The risk management procedure: identify, assess (estimate and evaluate), plan, implement, and communicate.
Risk identification considers threats and opportunities; the risk register records each risk's description, cause, effect, owner, probability, impact and proximity.
Risk evaluation compares estimated risk against tolerances and prioritises risks for action; risk responses include avoid, reduce, transfer, accept, share, exploit and enhance.
The risk owner is accountable for managing a specific risk; the risk actionee implements the response, and the two roles may be combined.
The risk budget is a sum of money set aside by the project board to cover the cost of risk responses and is held by the project manager.
A risk can be escalated to the project board via an exception report if its impact exceeds the project manager's tolerances.
Change
PRINCE2 change control covers changes to baselined products, requests for change, and the management of issues and off-specifications.
The change control approach defines how changes are identified, assessed, approved and implemented, and who has authority to approve them; it is part of the PID.
The change control procedure: capture, assess, approve or reject, and implement; the change is recorded in the issue register and the change log.
The issue register records all issues, including requests for change, off-specifications and problems/concerns; the change log records the status of each change.
An off-specification is a product that does not meet its quality criteria; it must be reported as an issue and approved by the project board before being accepted.
A request for change is a proposal to change a baselined product, and it must be assessed for impact on time, cost, quality, scope, risk and benefits before approval.
Change authority is the person or group delegated by the project board to approve changes; the project board sets the change budget and the authority's limits.
Configuration management comprises planning, identification, control, status accounting and verification; the configuration item record tracks each product's version and status.
Progress
Progress control compares progress against the plan using the six tolerances: time, cost, scope, quality, risk and benefit.
Tolerance is the permissible deviation from the plan without escalating to the next management level; exceeding a tolerance requires an exception report.
Progress is reported through checkpoint reports (from team manager to project manager), highlight reports (from project manager to project board) and end stage reports.
A highlight report is produced at intervals defined in the communication management approach and covers status, progress, issues, risks and forecast.
An exception report is produced when a tolerance is forecast to be exceeded; it includes cause, impact, options and a recommendation, and may lead to an exception plan.
An exception plan replaces a stage plan or the project plan when the project board approves it after an exception; it is prepared by the project manager.
The end stage assessment is held at the end of each stage, where the project board reviews the end stage report and approves the next stage plan.
Lessons are captured in the lessons log throughout the project and reviewed at each end stage and at project closure; the lessons report is produced at the end of the project.