This article is the last in a series of three. The other two articles cover the PRINCE2 principles and the PRINCE2 themes. The articles are available as e-books to download and share. They cover a lot of the content you will learn about on one of our PRINCE2 courses.
In this article we’re going to focus on the 7 PRINCE2 processes. In particular, we’re going to focus on those elements which most frequently are examined on the PRINCE2 Foundation exam.
There are 7 processes in PRINCE2, and for the Foundation examination you need to know the purpose and objectives of each of them. Rather than provide the exact quotation for the PRINCE2 manual, we will paraphrase the purposes and highlight them in light grey. Those items highlighted in bold are the ones most commonly included in questions in the PRINCE2 Foundation exam.
So, what is a process in PRINCE2? Well it’s a description of what must be done, who is responsible for doing, and when they should do it. The processes form a description of how the 7 PRINCE2 themes are applied both before and during the project. As such, it would be useful for you to read the other 2 articles in this series.
Starting Up a Project
Purpose
The purpose is to answer one simple question: “is the project viable and worthwhile?”
This process is a pre-project process. The process is about filtering out the badly-conceived projects from the good ones. After, all it’s only sensible to initiate the good ideas for projects and to discard the bad ones before any serious time and money is wasted.
The trigger for the project is a project mandate (a trigger is an event or decision which “triggers” one of the 7 processes).
The project mandate (at a minimum) should provide the reasons for undertaking the project and should also identify the prospective Executive of the Project Board.
Before the project is commissioned (initiated) key roles and responsibilities for doing the work during the first stage (known as the initiation stage) must be resourced and allocated – i.e. it must be identified who is going to write the Business Case and the Project Plan.
Objectives:
- To appoint those who will work during the initiation stage and those who will take significant project management roles in the project;
- To ensure there is a plan for the work required during the initiation stage (Initiation Stage Plan);
- To ensure the initiation stage is based upon sound assumptions regarding the project’s scope, timescales, acceptance criteria and constraints.
The Executive is responsible for creating the outline Business Case, which will explain how the project fits in with corporate and/or programme objectives and how (i.e. from which budget) the project will be funded. The Executive is responsible for securing this funding.
The 2 main outputs are:
- Project Brief – this ensures that the project has an agreed and well-defined start point.
- Initiation Stage Plan – this covers all the work to be done during the initiation stage (the first stage of the project) and when developing it, the Project Manager must review the Lessons Log for lessons relating to the project controls to be used during initiation.
Directing a Project (DP)
Purpose
The purpose is to enable the Project Board to make key decisions and exercising overall control over the project, whilst delegating the day-to-day management of the project to the Project Manager. This enables the Project Board to be accountable for the project’s success.
This process starts after the Starting up a Project process has completed and is triggered by a request to initiate the project.
The Project Board is responsible for assuring that there is continued business justification (one of the 7 PRINCE2 principles). There is no need for regular progress meetings between the Project Board and the Project Manager because the Project Board “manages by exception” (another of the 7 principles). The Project Board is kept informed of progress by the reports given to them by the Project Manager.
The Project Board also acts as a communication channel or interface with corporate/programme management.
The Executive is the decision maker on the project and the Project Manager should defer to the Executive if the Project Board cannot agree on something. In other words, the Project Board is NOT a democracy controlled by votes. The Senior Supplier and Senior User roles on the Project Board will help and support the Executive to take sensible decisions.
The Project Board is responsible for Project Assurance, but the Project Board members may appoint persons to perform Project Assurance on their behalf e.g. to undertake some of the reviewing and assessing actions such as reviewing plans.
The Project Board performs 5 activities:
1. Authorize initiation - ensure that the project investment is worthwhile and notify corporate or programme management and other interested parties. The Communication Management Strategy includes any information about these stakeholders’ information requirements.
2. Authorize the project – approve the Project Initiation Documentation (PID) but only if the Project Board is satisfied that the firm foundations for the project are in place i.e. that we know the project scope, costs, times, risks, benefits, who will take decisions, how progress will be monitored and reported, how risks, issues and quality will be monitored and controlled, and who needs information and when.
3. Authorize a Stage or Exception Plan – review the performance of the current stage and approve the next Stage Plan (or Exception Plan) if the business justification still exists, and commit the required resources.
The Project Board also reviews Lessons Reports and agrees on who should receive them. The Project Board approves Product Descriptions which involves: the Senior User because they (the users) will use the products; the Executive because they will fund the products’ creation; and the Senior Supplier because they will deliver the products.
4. Give ad-hoc direction – review Highlight Reports, Issue Reports and Exception Reports from the Project Manager and take decisions about Project Issues, risks and changes.
5. Authorize project closure - review and approve the End Project Report (and Lessons Report) if it is satisfied that there is nothing more for the project to do.
Initiating a Project (IP)
Purpose
The purpose is to put in place the solid foundations for the management and control of the project, enabling the customer to understand the work, time and money required to deliver the project’s products before it commits to a significant investment.
The objective is to ensure there’s a common understanding of: why we’re doing the project; timescales and costs; scope; major products; expected benefits; risks; quality requirements and standards; how baseline products will be controlled; the communication needs of stakeholders. The above information is contained within the Project Initiation Documentation (PID) which also describes how and whether any Corporate (or programme’s) project management methods will be tailored for the project.
The PID contains the following:
- Project Plan - defines what the project must deliver and ensures an understanding of how the objectives will be achieved, before the Project Board commits the resources (money, people, etc.);
- Detailed Business Case - (derived from the outline Business Case) containing details of timescales, costs, business options, benefits and risks;
- Communication Management Strategy - describes the information needs of stakeholders e.g. those who need to be informed of new risks, or that the project is about to close;
- Risk Management Strategy – describes the project’s general approach to risk management;
- Quality Management Strategy – describes how quality requirements and standards will be met;
- Configuration Management Strategy – describes how changes and issues will be managed and how baseline products will be version-controlled;
- Elements from the Project Brief (the project definition and project approach) are also included in the PID;
- Project controls – describes how the project will be controlled e.g. dates of stage boundaries and reporting and escalation requirements;
Initial Configuration Item Records are created for baseline management products already created and any pre-existing project documentation that needs to be controlled, e.g. feasibility study, request for proposal etc..
A Benefits Review Plan is created which plans for the measurement of benefits during and after the project. It is updated at project end, and is not archived because it remains an active document after project closure and is owned by corporate/programme management.
Managing a Stage Boundary (SB)
Purpose
The purpose is to provide the Project Board with an updated view of the project so it can review the achievements of the current stage, approve the next Stage Plan, review the updated Project Plan, and confirm the project is still justified and that the risks are still acceptable.
Towards the end of every stage (except the final stage) the Project Manager performs this process to start planning for the next stage. This process overlaps with the other processes active at the time.
The ‘manage by exception’ principle means that the Project Board only meets with the Project Manager at the end of a stage (known as an End Stage Assessment). At this point the Project Manager must provide the necessary information for the Project Board to make an informed decision about continuing with the project.
In this process the Project Manager updates the various products including the project management team required for the next stage; the 4 management strategies; and the Business Case and Project Plan. The Project Plan is updated by incorporating the actual progress from the stage just finishing, and revised time and cost forecasts for the remainder of the project.
As the Executive is responsible for the Business Case, the Project Manager should consult with the Executive when reviewing and updating the Business Case in preparation for Project Board approval and assess the project’s risks using the Risk Register to ascertain the aggregated risk exposure for the project and identify the current key risks that affect the Business Case.
The Benefits Review Plan is reviewed to check the results of any benefits reviews undertaken during the stage.
An Exception Plan is created when the Project Board asks the Project Manager to create a new plan, based on recommendations made in an Exception Report. In this situation, instead of creating the next Stage Plan, the Project Manager uses the process to create an Exception Plan. The other 3 activities of the process remain the same however, namely: Update the Project Plan, Update the Business Case, and Report stage end.
A Lessons Report may also be created in this process. The Quality Management Strategy might need to be revised, based on quality activities during the stage just finishing.
Configuration item Records are created or updated for products due to be delivered in the next stage.
Controlling a Stage (CS)
Purpose
The purpose is to assign work to teams, monitor the work, manage issues and risks, report progress to the Project Board, and take actions to ensure that the stage remains within its tolerances.
The process covers the day to day management of a stage by the Project Manager whilst, at the same time, the Project Board manages by exception (hence no need for regular progress meetings).
Once the Project Board has approved the project, and the next Stage Plan (or Exception Plan), the Project Manager can proceed with the next stage by issuing instructions about work to teams.
The process focuses on the delivery of the stage’s products. Any deviation away from the Stage Plan agreed before the stage commenced is monitored and corrective actions taken.
Work is allocated to teams (managed by a Team Manager) via Work Packages. Thus work should not be started without Project Manager’s authorization. Various events will trigger a Work Package, including the authorisation of an Exception Plan. A team executes a Work Package in the Managing Product Delivery process, and ensures that specialist products are approved as part of that process before handing the products back to the Project Manager.
As part of the Work Package authorisation, reporting and problem handling arrangements must be agreed, and the Risk Register updated to include any new risks.
Once the work is under way, the Team Manager sends regular Checkpoint Reports (a time-driven control) to the Project Manager. The Project Manager collects and reviews progress information from these reports and assesses the estimated time and effort to complete any remaining work.
The Project Manager sends regular Highlight Reports (a time-driven control) to the Project Board.
The Project Manager takes corrective action only for issues that are within stage tolerances. NOTE: This process is linked to the Progress theme, in which the concept of tolerances is explained.
Whilst the Stage Plan is updated during the stage, to keep it current with stage actuals, the Project Plan and Business Case are NOT updated during this process. Instead they are updated within the Managing a Stage Boundary process at the end of the stage.
Configuration Item Records are updated whenever the status of a product changes e.g. when it has undergone its quality controls, or has been approved.
The Project Manager reviews the stage at regular intervals and reviews the status of issues and risks. For any proposed Requests for Change the Project Manager needs to consider the impact the change will have on the Project Plan, Business Case and risks and will check the Communication Management Strategy to ensure the relevant interested parties are informed. The Project Manager might request a Product Status Account from Project Support, which reports the current status of one or more products.
NOTE: In complex projects where some planning work is delivered through the use of Work Packages, the Project Manager could use the Controlling a Stage and Managing Product Delivery processes during the initiation stage.
Managing Product Delivery (MP)
Purpose
The purpose is to control the link between the customer and supplier by placing formal requirements on the Team Manager for the work to be done. The Team Manager(s) is responsible for coordinating an area of work that will deliver one or more of the project’s products.
This process is performed by the Team Manager. It is not uncommon that the supplier (for whom the Team Manger works) does not use PRINCE2, and in many cases may not know much about it. This is not a problem because this process provides a statement of the interface required between the Team Manager and PRINCE2 which is being used by the Project Manager.
In PRINCE2, work should only be started once the Project Manager has authorised a Work Package.
When a Work Package is accepted, the Team Manager also agrees to the tolerances set for it by the Project Manager. The Team Manager makes a (optional) Team Plan, which the Project Manager and/or Senior Supplier will authorise. Note: It may not be possible or appropriate for a Project Manager to authorise a Team Plan for commercial reasons, in which case agreement about delivery dates and costs will suffice.
Team Managers must provide the Project Manager with accurate progress information via Checkpoint Reports. They will also maintain the interfaces (people and specialist products) identified in the Work Packages.
Once products are complete, the team gains their requisite approval from the authorities identified in the Product Description.
NOTE: If a Team Manager forecasts a deviation beyond Work Package tolerances he/she raises a Project Issue with the Project Manager (i.e. the Team Manager does not write an Exception Report).
Closing a Project (CP)
Purpose
The purpose is to provide a fixed point at which it is confirmed that acceptance for the project product has been obtained, to review whether the objectives set out in the original Project Initiation Documentation have been achieved and that there is nothing more for the project to do.
NOTE: Closing a Project is NOT a separate stage performed at the end of the project but is a process performed towards the final delivery stage (the Controlling a Stage and Managing Product Delivery processes are still being performed at this time).
This process is triggered towards the end of the final stage, when all the work has nearly been completed. Closure activities should be planned and resourced when the stage plan for the final stage is created.
The objectives of this process are:
- To verify that the users have “accepted” the project’s products. This requires that the project’s acceptance criteria have been met;
- To review the performance of the project against its baselines;
- To assess any benefits that have already been realized, to update the forecast of the remaining benefits, and to plan for a review of the unrealized benefits.
This process also ensures there is a clear end to the project. This has several benefits to the customer:
- The operational regime can now take over the products from the project;
- The project management team can be disbanded;
- No more project costs should be incurred.
It is common to find at the end of a project a number or things which perhaps were never completed – e.g. Requests for Change which never got implemented, or there might be operational risks. These are examples of things which need to be documented in the form of follow-on action recommendations which forms part of the End Project Report.
A Lessons Report is prepared, documenting both the good things and bad things which happened on the project along with any associated recommendations for corporate or programme management to address these things on future projects, or as part of business-as-usual.
Finally, the Project Manager prepares a draft project closure notification and sends it to the Project Board for approval. After the project closure is authorized by the Project Board (in Directing a Project), the project is now history and the specialist products which were delivered by the project are now being used by users as part of the everyday business as usual activities of the customer organization.
All management products used during the project must be archived securely, in case an audit is performed at a later date.
Since the project has now finished, and the project management team no longer exists, the project’s products are now used by users (and the operational/support teams) to realize the benefits which were specified in the Business Case.
As and when the benefits are realized they are recorded in the Benefits Review Plan. This plan is the only management product therefore which is actively used after the project has closed. It is the responsibility of corporate/programme management to ensure that the Benefits Review Plan is executed and actively managed after the project closes.