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 and 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 does deviate from its stage
tolerances, then there is an
exception, and the
project manager must refer the situation to the
project board. 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).
Management by exception
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 review, 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 thus 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.
Tolerance
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.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.
Authorization
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. 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.
Progress updates
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 project 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 processAuthorization
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).
Progress updates
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.
