The progress theme facilitates the evaluation of actual project progress against what was planned. This is achieved by comparing two sets of management products: plans, which articulate the expected input, in terms of effort, resources, cost, and time, and reports, which identify the actual values for each of these variables. By monitoring the information captured in reports against the expectations contained with the plans, the project manager is able to minimize the variation between anticipated and actual progress.
Progress is thus concerned with control, i.e. making sure that the project remains viable regarding its business case, that it achieves its intended results (by generating products that fulfil the specified criteria), and that it remains within its designated constraints.
Each level in the project management team reports to the next level up. For example, the project manager authorizes work to team managers who report progress via regular checkpoint reports to the project manager. In turn the project manager takes direction from the project board and reports progress via highlight reports.
So what control mechanisms are required in practical terms? Examples include: monitoring project progress and comparing the results to project plans; reviewing plans and considering other options; identifying risks; taking corrective action; authorizing the release of resources; and authorizing the beginning of each new management stage.
Controls, as reports, can be triggered by events (e.g., the exception report, which is generated in response to an exception) or by time (e.g., the highlight report or the checkpoint report, which occur on a regular basis). However, within the PRINCE2 framework the majority of controls/reports are triggered by events.
PRINCE2 concepts for monitoring and control
The three key concepts that underpin the PRINCE2 model for monitoring and controlling the progress of a project involve setting boundaries for responsibilities (‘management by exception’), for project activities (‘management stages’), and for variables on a project (‘tolerance’).
Management by exception
One of the PRINCE2 principles is that the project board, although bearing ultimate responsibility for project success, and wielding ultimate authority in project management decisions, is not involved in the day-to-day management of the project. This is the role of the project manager, who has independent responsibility for planning, scheduling and allocating work, and dealing with issues and risks, so long as progress does not deviate from the tolerances of the management stage (we will deal with these tolerances in greater detail below).
If a project is forecast to, or actually does deviate from its stage tolerances, then there is an exception, and the project manager must refer the situation to the project. This management style—delegation until an exception occurs—is therefore known as ‘management by exception’.
PRINCE2 recommends two basic controls to ensure that the project board can efficiently and effectively keep track of project progress: the highlight report, which is time driven, and the exception report, which is motivated by events (i.e., exceptions).
The PRINCE2 concept of management stages limits the duration of the project manager's independence in managing a project. At the end of each stage, the project board will perform an end stage assessment, in order to ensure that the project remains viable and that it is meeting its targets (i.e., the control mechanism of comparing actual against planned progress), and decides whether to authorize the next stage. A management stage this becomes a “Go/No Go?” decision point.
One advantage of an approach based upon managing a project in stages is that it is a less risky approach to taking investment decisions because the investment in resources only happens one stage at a time. However, this does not mean that ‘the more management stages the better’. On the contrary, an excessive proportion of management stages can result in high project management overheads, time-wasting, and obstruction of project progress. It is important to work out the ideal number and length of management stages on the individual PRINCE2 project.
The basic rule is that each PRINCE2 project must have at least two stages: the initiation stage, where the fundamental management products and structures are developed, and at least one stage in which the specialist products are developed. It is further suggested that management stages can be effectively aligned to key decisions points, in order to maximize the effectiveness of this control mechanism. Other factors that must be considered include the planning horizon (i.e., how far in advance you can reliably plan in detail), the level of project risk, and the likelihood of project success.
The notion of tolerance is crucial to PRINCE2. It is impossible to forecast project variables with the kind of accuracy that the project board and external stakeholders might appreciate. Cost and time can rapidly spiral through unexpected hiccups, and even aspects such as benefits (i.e., the positive improvements the project is expected to deliver) and product quality are often subject to at least minor variations.
In order to allow for effective monitoring of these tolerances, without the project grinding to a halt every time the project manager oversteps the budget by a miniscule amount or turns in a product an hour later than planned, it is crucial that each level of project management set tolerances for the management level below. Thus, the project board defines the tolerances for the project manager, who in turn defines those of each team manager. These tolerances articulate the acceptable degree of variation within each of the targets set in the plan. Even if project progress deviates from its target values, the plan may continue to be implemented for as long as these deviations remain within tolerance levels. If the tolerances are (forecast to be) breached, then the manager refers the situation (an ‘exception’) to the next highest level of the project management team.
Tolerances are defined in each plan, together with the objectives that they relate to. Cost and time are the most prominent variables that require tolerance levels, but there are four further elements that PRINCE2 recognizes: risk, benefit, scope, and quality.
Risk tolerance defines the level of risk that the project can sustain. Benefit tolerance describes how much variation is allowed with regard to the project’s expected benefits before the project ceases to be viable. Quality tolerance is the acceptable difference between the product’s quality, and the baseline quality specification e.g. the report must be between 100 and 120 pages.
Scope tolerance refers to what the project will deliver: ‘scope creep’, for example, gradually increases what is expected of the project; at other times, the scope must be reduced to ensure that the project fulfils its most importance acceptance criteria within the cost and time tolerances—balancing these two demands is the function of scope tolerance.
Scope tolerance is often specified in the form of a prioritised list of requirements i.e. those requirements which “must be delivered”, those which “should also be delivered”, and those which “could be delivered providing we still have time and money left”. Finally, there might be some requirements which “won’t be delivered” because they do not contribute to the benefits in the business case. The difference between these must, should, could and won’t have requirements is what is meant by scope tolerance.
Project board controls
The PRINCE2 concept of management stages facilitates the introduction of three control mechanisms specific to the project board.
At key points in the project (such as the end of each management stage) the project board decides whether to authorize continued investment in the project. In order to grant authorization, the project board reviews and approves important management products (such as the project brief, the business case, and the stage plan). This review involves evaluating the progress of project to date (e.g., through the end stage report), and confirming that baseline management products remain valid.
In order for the authorization controls to be effective, it is crucial that the project board only issues authorization if there is continued justification for the project. If business justification is not sufficient, baseline management products appear invalid, or the project is not making adequate progress, then the project board must decide whether to make changes to the project, or to trigger premature closure.
The project board also need to authorize project closure, by reviewing the end project report. This allows them to ensure that the project is indeed complete, and has fulfilled all of the necessary expectations.
In order for the project board to keep track of project progress, the project manager needs to submit regular reports, including time-driven controls (e.g., highlight reports) and event-driven controls (e.g., end stage reports). This minimizes the need for time-consuming face-to-face meetings.
Exceptions and changes
Whenever the stage tolerances are anticipated to go into exception, the project manager refers the situation to the project board through an exception report. The project board then makes a decision about the exception. In response to this, the project manager writes an exception plan and submits this also the project board. Once the project board has authorized the exception plan, corrective action can be undertaken. This multi-step approach to managing exceptions on a project enables the project board to remain in control of changes to baseline products and objectives.
Project manager controls
It is also important that the project manager is able to monitor and control the work of teams within each management stage, in order to ensure that the required products are generated within the set tolerance levels. Similar control mechanisms to those of the project board can be implemented by the project manager, as part of the controlling a stage process.
The project manager authorizes each work package, which is the document which outlines what the team managers must achieve (i.e., the specialist products to be created, the necessary quality methods, constraints, and reporting requirements).
The team manager’s equivalent of the highlight report is the checkpoint report, which provides information about team progress at specified intervals. Event-driven controls are also applied in, for example, the form of a project issue (discussed below). The team manager will also enter data into the quality register, following the relevant quality activities, so that the project manager has access to several measures of stage progress.
Issues and risks
Through regularly updates project registers and logs, the project manager is able to keep an eye on the progress of the project, and to identify possible issues or risks. If a tolerance level set for the work package is anticipated to be breached, then the team manager refers this to the project manager as a project issue.