PRINCE2, as you’ll learn on a PRINCE2 training course, is the world’s most popular project management methodology. It’s composed of 4 integrated elements:
- Principles – the building blocks upon which the method is based
- Themes – the areas of project management to be continuously addressed throughout the project
- Processes – describing who is responsible for doing what and when
- Tailoring – applying PRINCE2 to suit the needs of the project
The articles have not been written as in-depth guides to PRINCE2, but as study guides to prepare you for the PRINCE2 Foundation exam. In this series, we’ll focus on those parts which are most frequently examined on the exam. If you use these articles to study for the exam, then your chances of passing will be much greater. Pay attention to the items highlighted in bold because those are the parts which are most commonly included in questions in the PRINCE2 Foundation exam.
Download PDFProcesses in PRINCE2 are where the principles and themes of PRINCE2 are applied. The processes describe which role from the project management team is responsible for taking decisions, and when those decisions should be taken.
Starting up a project
The purpose is to answer one simple question: “is the project viable and worthwhile?”
- 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 (initiation stage plan) for the work required during the initiation stage;
- To ensure the initiation stage is based upon sound assumptions regarding the project’s scope, timescales, acceptance criteria and constraints.
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 processes) which comes from the highest levels within the customer organization (i.e. ‘corporate or programme management, or the customer’). From now on, we will refer to them as corporate management.
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.
The executive is responsible for creating the outline business case, which will explain how the project fits in with corporate management 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 the project manager must review the lessons log for lessons relating to the project controls to be used during initiation.
Directing a project
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.
To ensure that:
- there is authority to initiate the project, deliver the project’s products, and to close the project
- management direction and control are provided throughout the project’s life
- the project remains viable
- corporate management has an interface to the project
- plans for realizing the post-project benefits are managed and reviewed.
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 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 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 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 management and other interested parties. The communication management approach 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 for the major products to be delivered.
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
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.
To ensure there’s a common understanding of:
- the reasons, timescales, costs, scope, major products, expected benefits, and risks
- the quality requirements and standards
- how baseline products will be controlled
- the communication needs of stakeholders
The main output of this process is the project initiation documentation (PID) which contains the following:
- Project plan - defining what the project must deliver including the costs, resources and timescales
- Detailed business case - containing the business justification
- Communication management approach - describing the information needs of stakeholders
- Risk management approach – describing the project’s approach to risk management
- Quality management approach – describing how quality requirements and standards will be met
- Change control approach – describing how changes and issues will be managed and how baseline products will be controlled
- Project controls – describing how the project will be controlled e.g. dates of stage boundaries, reporting and escalation requirements
- Tailoring – describing how PRINCE2 and any corporate or programme processes will be tailored
A benefits management approach is also created which describes how the benefits will be measured and by whom. It is updated at the project’s end, and is not archived because it remains an active document after project closure and is owned by corporate management.
Managing a stage boundary
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.
- To assure the project board that all products in the current stage plan have been completed and approved
- to prepare the next stage plan
- to review and, if necessary, update the PID
- to provide the information needed for the project board to assess the continuing viability of the project
- to record any information or lessons that can help later stages of this project and/or other projects
- to request authorization to start the next stage
- in an exception situation to prepare an exception plan and seek approval to replace the project plan or stage plan for the current stage with the exception plan
Towards the end of every stage (except the final stage) the project manager performs this process to start planning for the next stage.
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.
The project manager updates the 5 management approaches and the business case and project plan. The project plan is updated by incorporating the actual progress from the stage just finishing, and the 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. The risk register is used to help understand the project’s aggregated risk exposure, and to identify the current key risks that affect the business case.
The benefits management approach is reviewed to check the results of any benefits reviews undertaken during the stage.
In an exception situation, an exception plan is created if the project board asks for one - based on recommendations made in a previous exception report. When this happens, instead of creating the next stage plan, the project manager uses the process to create an exception plan. Just like at the end of a stage however, the project plan and business case are updated and an end stage report is written.
A lessons report may also be created in this process. The different approaches might need to be revised, based upon lessons learned about quality, risk, or issue management or change control during the stage.
Controlling a stage
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.
To ensure that:
- the project management team is focused on delivery within the tolerances
- risks and issues are kept under control
- the business case is kept under review
- the agreed products are delivered to the stated quality standards, within agreed cost, effort, time constraints
- progress is reported to the project board (highlight reports)
- tolerance threats escalated via exception reports
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’.
After the initiation stage, as soon as 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. Thereafter, this process is triggered whenever the project board approves either a stage plan or exception plan.
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.
The project manager allocates work to teams (managed by a team manager) via work packages. Work should not be started without project manager’s authorization. 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 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. If slippages in the work occur the project manager takes corrective action but only for issues that are within stage tolerances. For slippages which will cause an exception, the project manager writes an exception report and sends it to the project board.
Throughout the stage, the project manager sends regular highlight reports to the project board.
The stage plan (or exception plan) is updated during the process with actuals from the current stage, and forecasts for the remainder of the stage. However, 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.
A key part of this process is for the project manager to review the stage at regular intervals and to review the status of issues and risks. For any proposed requests for change the project manager considers the impact the change will have on the project plan, the business case and the risks and checks the communication management approach to ensure the relevant interested parties are informed. The project manager might request a product status account from project support to report the current status of any of the 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
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.
To ensure that:
- work on products allocated to the team is authorized and agreed
- team managers and suppliers are clear as to what is to be produced and what is the expected effort, cost or timescales
- the planned products are delivered to expectations and within tolerance
- accurate progress information is provided to the project manager at an agreed frequency to ensure that expectations are managed.
This process is performed by the team manager. It is not uncommon that the supplier (for whom the team manager 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
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.
- to verify user acceptance of the project’s products has been obtained - this requires that the project’s acceptance criteria have been met
- to ensure the host site(s) is able to support the products when they go operational
- to review project’s performance against its baselines
- to assess any benefits already been realized, update the forecast for the remaining benefits, and plan for a review of all unrealized benefits
- to ensure provision has been made to address all open issues and risks with follow-on action recommendations
The closing a project process 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 where the physical handover of products to the customer occurs (unless it has already happened), but the handover can only occur if acceptance has been obtained.
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.
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 management to address 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 the directing a project process), the project is now history. 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 management approach. This approach is the only management product therefore which is actively used after the project has closed. It is the responsibility of corporate management to ensure that the benefits management approach is executed and actively managed after the project closes.
By now, if you have learned the definitions provided in bold in this article and the other two in the series, you should be well-placed to pass the PRINCE2 Foundation exam with flying colours. Good luck with your exam.