Purpose of this Guide
PRINCE2 is one of the most widely used project management methods in the world – it addresses project management with four integrated elements of principles, themes, processes and the project environment.
– The principles are the guiding obligations and good practice;
– The themes describe aspects of project management that must be addressed continually and in parallel throughout the project;
– The processes describe a progression through the project lifecycle;
– The project environment is defined by the organizations’ way of working and PRINCE2 is tailored to create their own project management method, providing a consistent approach that is embedded into the organization.
Whilst it is not intended for PRINCE2 to cover every aspect of project management, it does provide a set of activities to be done, together with roles and also techniques for undertaking those activities. This is different to a “Body of Knowledge”, which looks at what a competent project manager should know and focuses on what and how to do it.
PRINCE2 has been designed to be generic so that it can be applied to any project regardless of project scale, type, organization, geography or culture and it achieves this by separating the management of project from the specialist contributions _ and focusing on describing what needs to be done, rather than prescribing how everything is done.
The benefits of using PRINCE2 include that:
– it is based on established and proven best practice and can be tailored to the needs of the organization, and scaled to the size and complexity of different projects
– it is widely recognized and understood, and provides a common vocabulary; thus promoting consistency
– it ensures that stakeholders are properly represented in planning and decision-making and promotes learning from project experience and continual improvement.
One aim of PRINCE2 is to make the right information available at the right time for the right people to make the right decisions about the project. Those decisions include whether to take corrective action or implement measures to improve performance.
PRINCE2 assumes that there will be a customer who will specify the desired result and a supplier who will provide the resources and skills to deliver that result.
PRINCE2 is a principle-based rather than a prescriptive based method; the principles are:
1. universal in that they apply to every project
2. self-validating in that they have been proven in practice over many years
3. empowering because they give practitioners of the method added confidence and ability to influence and shape how the project will be managed
The PRINCE2 themes describe aspects of project management that must be addressed continually as the project progresses through its lifecycle. However, the strength of PRINCE2 is the way in which the seven themes are integrated with the PRINCE2 processes that address the chronological flow of the project, with actions relating to different themes mixed together.
PRINCE2 is a process-based approach for project management and there are seven processes in PRINCE2, which provide the set of activities required to direct, manage and deliver a project successfully.
The project board is accountable to corporate, programme management or the customer for the success of the project, and has the authority to direct the project within the remit set by corporate, programme management or the customer as documented in the project mandate.
And is also responsible for the communications between the project management team and stakeholders external to that team (e.g. corporate, programme management or the customer).
The executive is ultimately accountable for the project, supported by the senior user and senior supplier. The executive’s role is to ensure that the project is focused throughout its life on achieving its objectives and delivering a product that will achieve the forecast benefits.
The executive has to ensure that the project gives value for money, ensuring a cost-conscious approach to the project, balancing the demands of the business, user and supplier.
Throughout the project, the executive is responsible for the business case.
The senior user is responsible for specifying the needs of those who will use the project’s products, for user liaison with the project management team, and for monitoring that the solution will meet those needs within the constraints of the business case in terms of quality, functionality and ease of use.
The role represents the interests of all those who will use the project’s products (including operations and maintenance), those for whom the products will achieve an objective or those who will use the products to deliver benefits. The senior user role commits user resources and monitors products against requirements.
The senior user specifies the benefits and is held to account by demonstrating to corporate, programme management or the customer that the forecast benefits which were the basis of project approval have in fact been realized.
The senior supplier represents the interests of those designing, developing, facilitating, procuring and implementing the project’s products. This role is accountable for the quality of products delivered by the supplier(s) and is responsible for the technical integrity of the project. If necessary, more than one person may represent the suppliers.
The project manager is accountable to the project board and ultimately the executive and has the authority to run the project on a day-to-day basis, within the constraints laid down by them.
The project manager’s prime responsibility is to ensure that the project produces the required products within the specified tolerances of time, cost, quality, scope, benefits and risk. The project manager is also responsible for the project producing a result capable of achieving the benefits defined in the business case.
The team manager’s prime responsibility is to ensure production of those products defined by the project manager to an appropriate quality, in a set timescale and at a cost acceptance to the project board. The team manager is accountable to, and takes direction from, the project manager.
Project assurance covers the primary stakeholder interests (business, user and supplier). The role has to be independent of the project manager; therefore the project board cannot delegate any of its assurance activities to the project manager.
The implementation of the assurance responsibilities needs to answer the question of what is to be assured.
The project board may delegate authority for approving responses to requests for change or off-specifications to a separate individual or group, called a change authority. The project manager could be assigned as the change authority for some aspects of the project (e.g. changing baselined work packages if this does not affect management stage tolerances).
The provision of any project support on a formal basis is optional. If it is not delegated to a separate person or function, it will need to be undertaken by the project manager.
Benefits Management Approach
A benefits management approach defines the benefits management actions and benefits reviews that will be put in place to ensure that the project’s outcomes are achieved and confirm that the project’s benefits are realized.
If the project is part of a programme, the benefits management approach may be contained within the programme’s benefits realization plan and executed at the programme level. Post-project, the benefits management approach is maintained and executed by corporate, programme management or the customer.
A business case is used to document the business justification for undertaking a project, based on the estimated costs (of development, implementation and incremental ongoing operations and maintenance costs) against the anticipated benefits to be gained and offset by any associated risks. It should outline how and when the anticipated benefits can be measured.
The outline business case is developed in the starting up a project process and refined by the initiating a project process. The directing a project process covers the approval and reaffirmation of the business case.
The business case is used by the controlling a stage process when assessing impacts of issues and risks. It is reviewed and updated at the end of each management stage by the managing a stage boundary process, and at the end of the project by the closing a project process.
Change Control Approach
A change control approach is used to identify, assess and control any potential and approved changes to the project baselines. It describes the procedures, techniques and standards to be applied and the responsibilities for achieving an effective issue management and change control procedure.
A checkpoint report is used to report, at a frequency defined in the work package, the status of the work package.
Communication Management Approach
A communication management approach contains a description of the means and frequency of communication with parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bidirectional flow of information.
Configuration Item Record
Configuration item records are created only if required by the project’s change control approach. Their purpose is to provide a record of such information as the history, status, version and variant of each configuration item, and any details of important relationships between them.
The set of configuration item records for a project is often referred to as a configuration library.
A daily log may be used to record informal issues, required actions or significant events not captured by other PRINCE2 registers or logs. It can act as the project diary for the project manager. It can also be used as a repository for issues and risks during the starting up a project process if the other registers have not been set up.
End Project Report
An end project report is used during project closure to review how the project performed against the version of the PID used to authorize it. It also allows the passing on of:
– Any lessons that can be usefully applied to other projects
– Details of unfinished work, ongoing risks or potential product modifications to the group charged with future support of the project’s products in their operational life
End Stage Report
An end stage report is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a project board decision on what to do next with the project.
The project board uses the information in the end stage report in tandem with the next stage plan to decide what action to take with the project; for example, authorize the next stage, amend the project scope or stop the project.
An exception report is produced when a stage plan or a project plan is forecast to exceed tolerance levels set. It is prepared by the project manager in order to inform the project board of the situation, and to offer options and recommendations for the way to proceed.
A highlight report is used to provide the project board (and possibly the other stakeholders) with a summary of the management stage status at intervals defined by them. The project board uses the report to monitor management stage and project progress. The project manager also uses it to advise the project board of any potential problems or areas where the project board could help.
The purpose of the issue register is to capture and maintain information on all the issues that are being formally managed. The issue register should be monitored by the project manager on a regular basis.
An issue report is a report containing the description, impact assessment and recommendations for a request for change, off-specification or a problem/concern. It is created only for those issues that need to be handled formally.
The lessons log is a project repository for lessons that apply to this project or future projects. Some lessons may originate from other projects and should be captured on the lessons log for input to the project’s approaches and plans. Some lessons may originate from within the project, where new experience (both good and bad) can be passed on to others.
A lessons report may be produced to support the lessons log if more information is required. It can be used to pass on any lessons that can be usefully applied to other projects.
The purpose of the report is to provoke action so that the positive lessons become embedded in the organization’s way of working, and so that the organization is able to avoid any negative lessons on future projects.
A lessons report can be created at any time in a project and should not necessarily be delayed until the end. Typically it can be included as part of the end stage report and end project report.
A plan provides a statement of how and when objectives are to be achieved, by showing the major products, activities and resources required for the scope of the plan. In PRINCE2, there are three levels of plan: project, stage and team. Team plans are optional and may not need to follow the same composition as a
project plan or stage plan.
An exception plan is created at the same level as the plan that it is replacing.
A project plan provides the business case with planned costs, and it identifies the management stages and other major control points. It is used by the project board as a baseline against which to monitor project progress.
Stage plans cover the products, resources, activities and controls specific to the management stage and are used as a baseline against which to monitor management stage progress.
Team plans (if used) could comprise just a schedule appended to the work package(s) assigned to the team manager.
A product description is used to:
– Understand the detailed nature, purpose, function and appearance of the product
– Define who will use the product
– Identify the sources of information or supply for the product
– Identify the level of quality required of the product
– Enable identification of activities to produce, review and approve the product
– Define the people or skills required to produce, review and approve the product.
Product Status Account
If required by the project’s change control approach, a product status account is used to provide information about the state of products within defined limits.
The limits can vary. For example, the report could cover the entire project, a particular management stage, a particular area of the project or the history of a specific product. It is particularly useful if the project manager wishes to confirm the version number of products.
A project brief is used to provide a full and firm foundation for the initiation of the project and is created in the starting up a project process.
In the initiating a project process, the contents of the project brief are extended and refined in the PID, after which the project brief is no longer maintained.
Project Initiation Document
The purpose of the PID is to define the project, in order to form the basis for its management and an assessment of its overall success. The PID gives the direction and scope of the project and (along with the stage plan) forms the ‘contract’ between the project manager and the project board.
The three primary uses of the PID are to:
– Ensure that the project has a sound basis before asking the project board to make any major commitment to the project
– Act as a base document against which the project board and project manager can assess progress, issues and ongoing viability questions
– Provide a single source of reference about the project so that people joining the ‘temporary organization’ can quickly and easily find out what the project is about, and how it is being managed.
The PID is a living product in that it should always reflect the current status, plans and controls of the project. Its component products will need to be updated and re-baselined, as necessary, and the end of each management stage, to reflect the current status of its constituent parts.
The version of the PID that was used to gain authorization for the project ispreserved as the basis against which performance will later be assessed when closing the project.
Project Product Description
The project product description is a special form of product description that defines what the project must deliver in order to gain acceptance. It is used to:
– Gain agreement from the user on the project’s scope and requirements
– Define the customer’s quality expectations
– Define the acceptance criteria, method and responsibilities for the project.
The product description for the project product is created in the starting up a project process as part of the initial scoping activity, it is refined during the initiating a project process when creating the project plan.
It is used by the closing a project process as part of the verification that the project has delivered what was expected of it, and that the acceptance criteria have been met.
Quality Management Approach
A quality management approach describes how quality will be managed on the project. This included the specific processes, procedures, techniques, standards and responsibilities to be applied.
A quality register is used to summarize all the quality management activities that are planned or have taken place, and provides information for the end stage reports and end project report. Its purpose is to:
– Issue a unique reference for each quality activity
– Act as a pointer to the quality records for a product
– Act as a summary of the number and type of quality activities undertaken
Risk Management Approach
A risk management approach describes how risk will be managed on the project. This includes the specific processes, procedures, techniques, standards and responsibilities to be applied.
A risk register provides a record of identified risks relating to the project, including their status and history. It is used to capture and maintain information on all the identified threats and opportunities relating to the project.
A work package is a set of information about one or more required products collated by the project manager to pass responsibility for work or delivery formally to a team manager or team member.