12
Progress
This chapter covers:
•measuring progress and the achievement of objectives
•PRINCE2’s requirements for the progress theme
•tolerances, controls and management by exception
•progress evaluation and peer review
12 Progress
Key message
The purpose of the progress theme is to:
•establish mechanisms to monitor and compare actual achievements against those planned
•provide a forecast for the project’s objectives and continued viability
•control any unacceptable deviations.
Progress is the measure of the achievement of the objectives of a plan. Controlling progress is central to project management, ensuring that the project remains viable against its approved business case. Progress control involves measuring actual progress against the performance targets of time, cost, quality, scope, benefits and risk. This information is used to make decisions such as whether to approve a management stage or work package, whether to escalate deviations and whether to prematurely close the project, and to take actions as required. Progress can be monitored at work package, management stage and project level.
Of PRINCE2’s seven principles, manage by exception is particularly important to the progress theme. An exception is a situation where a deviation beyond agreed tolerance levels can be forecast.
Tolerances are the permissible deviation above and below a plan’s target for cost and time without escalating the deviation to the next level of management. There may also be tolerances for quality, scope, benefits and risk.
12.2 PRINCE2’s requirements for the progress theme
To be following PRINCE2, a project must, as a minimum:
•define its approach to controlling progress in the PID
•be managed by stages (PRINCE2’s manage by stages principle)
•set tolerances and be managed by exception against them (PRINCE2’s manage by exception principle)
•review the business justification when exceptions are raised (PRINCE2’s continued business justification principle)
•learn lessons (PRINCE2’s learn from experience principle).
Key message
PRINCE2 does not prescribe a particular or detailed approach to managing progress. Any approach that meets the requirements described can be said to be following PRINCE2.
PRINCE2 provides progress control through:
•delegating authority from one level of management to the level below it
•dividing the project into management stages and authorizing the project one management stage at a time (PRINCE2’s manage by stages principle)
•time-driven and event-driven progress reporting and reviews
•raising exceptions (PRINCE2’s manage by exception principle).
The project’s controls should be documented in the PID.
In PRINCE2, the project is managed by exception against six types of tolerance, as shown in Table 12.1.
Table 12.1 The six tolerance types by level
a Quality tolerances are not summarily defined at the stage or work-package level but are defined per product description within the scope of the plan.
b The scope of a plan is defined by the set of products to be delivered. Scope tolerance (if used) should be in the form of a note on or reference to the product breakdown structure for the plan. Scope tolerance at the stage or work-package level is of particular use if applying a time-bound iterative development method such as agile.
c More specific stage-level risk tolerances may be set by the project board when authorizing a stage or by the project manager when commissioning work packages, especially from external suppliers.
The allocation of tolerances is outlined in Figure 12.1 and should be in line with the following:
•Corporate, programme management or the customer sits outside the project but sets the overall requirements and tolerance levels for the project. The three levels of management within the project (responsible for directing, managing and delivering) will manage and implement within these tolerances and escalate any forecast breaches of project tolerance.
•The project board has overall control at a project level, as long as forecasts remain within project tolerance, and will allocate tolerances for each management stage to the project manager. The project board has the ability to review progress and decide whether to continue, change or stop the project. During execution of the project plan, if any forecasts indicate that the project is likely to exceed the agreed project tolerances, then the deviation should be referred to corporate, programme management or the customer by the project board in order to get a decision on corrective action.
•The project manager has day-to-day control for a management stage within the tolerance limits laid down by the project board. During execution of a stage plan, if any forecasts indicate that the management stage is likely to exceed the agreed management stage tolerances, then the deviation should be referred to the project board by the project manager in order to get a decision on corrective action. This would be done by raising an issue and an exception report.
•The team manager has control for a work package, but only within the work package tolerances agreed with the project manager. During execution of the work package, if any forecasts indicate that it is likely that the agreed tolerances will be exceeded, then the deviation should be referred to the project manager by the team manager in order to get a decision on corrective action. This would be done by raising an issue.
PRINCE2 provides two types of progress control throughout the life of a project:
•Event-driven controls These take place when a specific event occurs. This could be, for example, the end stage assessment at the end of a management stage, the completion of the PID or the creation of an exception report. It could also include organizational events that might affect the project, such as the end of the financial year.
•Time-driven controls These take place at predefined periodic intervals. This could be, for example, producing monthly highlight reports for the project board or weekly checkpoint reports showing the progress of a work package.
Monitoring and reporting requires a time-based approach, whereas control (decision-making) is an event-based activity.
The following sections describe the management products that are used to establish and execute event-driven and time-driven controls.
12.2.2.1 Baselines for progress control
It is only possible to control progress at the level of detail in the plans; for example, if weekly checkpoint reports are required, the stage plan will have to include what is to be achieved week by week.
The following management products assist the project manager in establishing baselines for progress control:
•Project plan Includes the project-level performance targets and tolerances. Threats to the project-level tolerances need to be escalated to the project board, which will seek advice from corporate, programme management or the customer for corrective action.
•Stage plan Forms the basis of the day-to-day control of the management stage and detail stage-level tolerances.
•Exception plan May be requested by the project board after considering an exception report during the directing a project process.
•Work package Forms an agreement between the project manager and team manager as to the work to be completed within defined tolerances.
Appendix A (sections A.16 and A.26) provides product descriptions and suggested content for these products.
As part of controlling a stage, the project manager will regularly review the progress of work through checkpoint reports and maintain the project registers and logs. The project manager will use this information to update the stage plan with actual progress achieved. The format and frequency of checkpoint reporting will depend on the needs of individual work packages.
It is also useful to look at trends to get a view of the overall ‘health’ of the management stage. For example, the management stage may seem to be progressing well in terms of the products being completed against the schedule. However, the issue register may reveal an increasing number of issues which are not being resolved and which may be a cause for concern. Similarly, a high number of outstanding items against a product in the quality register may show design issues with that product.
The following management products assist in reviewing progress:
•Issue register Contains details of all formal issues raised during the project.
•Product status account Provides a snapshot of the status of products within the project, management stage or a particular area of the project.
•Quality register Records all planned and implemented quality activities.
•Risk register Records identified risks.
Appendix A (sections A.12, A.18, A.23 and A.25) provides product descriptions and suggested content for these products.
In addition, a daily log is a useful tool for recording actions. Project actions may arise from many sources and small actions may simply be recorded on the daily log and marked off when completed. The daily log can also be used to record informal issues and any other notes or observations that are not captured by any other registers or logs. The daily log is a useful way of recording individual observations that on their own may seem insignificant, but when collated may alert the project manager to a new issue or risk.
12.2.2.3 Capturing and reporting lessons
The lessons log is used for capturing and reporting lessons when reviewing progress. One of the principles of a PRINCE2 project is that the project management team learns from experience, which means that lessons are sought, recorded and actioned throughout. It is often in the reviewing of progress that lessons are identified. Lessons could include information about management or specialist processes, products, techniques or procedures that either made a contribution to the project’s achievements or caused a problem. Examples might include the performance of the project management team, the success of tailoring PRINCE2 to the project, or the analysis of quality statistics and measurements. Larger projects are more likely to make use of a lessons report as part of this process, where more detail would be helpful.
Tip
Although lessons may be identified and recorded during a project, learning lessons involves taking action to implement improvements. These actions may apply to the current project, in which case they should be incorporated into the appropriate plans and work packages, or they may be relevant to different projects.
Appendix A (sections A.14 and A.15) provides product descriptions and suggested content for the lessons log and lessons report.
The frequency of reporting should reflect the level of control required, and this is likely to vary during the project. For example, if the team is highly experienced then less frequent reporting may be appropriate, whereas for an inexperienced team the project manager may wish to increase the frequency of reporting until sufficient confidence has been gained on the capability of the team.
The following management products are used for progress reporting:
•Checkpoint report Provides the project manager with details of progress against the work package and is typically produced by the team manager.
•Highlight report Provides the project board with details of progress for the whole project and/or management stage. The project manager produces this report.
•End stage report Provides the project board with details of progress towards the end of each management stage (except the final stage), including information on the progress to date, the overall project situation and (together with the next stage plan) sufficient information to ask for a project board decision on what to do next with the project. The report is produced by the project manager.
•End project report Provides the project board with information needed to evaluate the project and authorize closure. It is produced by the project manager towards the end of the project.
Appendix A (sections A.4, A.8, A.9 and A.11) provides product descriptions and suggested content for these products.
The output from reviewing progress is a decision as to whether the work package, stage plan or project plan remain, or are forecast to remain, within agreed tolerances:
•Work-package-level exceptions Having agreed work package tolerances with the team manager, the project manager should be kept informed of progress through regular checkpoint reports. If a work package is forecast to exceed its tolerances, the team manager should inform the project manager by raising an issue. The project manager will advise of any corrective actions required.
•Stage-level exceptions If the stage is forecast to exceed its tolerances, the project manager should produce an issue report to capture and analyse the details of the deviation and then provide an exception report for the project board. Based on information in this report, the project board may request that the project manager produces an exception plan to replace the plan that was forecast to exceed tolerance. The project board may also remove the cause, accept and adjust tolerance, or request more time to consider or reject the recommendations. If an exception plan is requested, the project board will conduct an exception assessment, similar to the end stage assessment, to review and approve the exception plan.
•Project-level exceptions If the forecast is for project tolerances to be exceeded, the project board no longer has the authority to direct the project and must refer the matter to corporate, programme management or the customer for a decision. The project board may request the project manager to produce an exception plan for the project.
12.2.4 Progress responsibilities in PRINCE2
Responsibilities for managing progress in PRINCE2 are set out in Table 12.2. As described in Chapter 7, if roles are combined then all the responsibilities in this table must still be undertaken.
Table 12.2 Responsibilities relevant to the progress theme
Role |
Responsibilities |
Corporate, programme management or the customer |
Provide project tolerances and document them in the project mandate. Make decisions on exception plans when project-level tolerances are forecast to be exceeded. |
Executive |
Provide management stage tolerances. Ensure that progress towards the outcome remains consistent from the business perspective. Make decisions on exception plans when management-stage-level tolerances are forecast to be exceeded. Recommend future action on the project to corporate, programme management or the customer if the project tolerance is forecast to be exceeded. |
Senior user |
Ensure that progress towards the outcome remains consistent from the user perspective. |
Senior supplier |
Ensure that progress towards the outcome remains consistent from the supplier perspective. |
Project manager |
Authorize work packages. Monitor progress against stage plans. Produce highlight reports, end stage reports and the end project report. Produce exception plans and reports for the project board when management-stage-level or project-level tolerances are forecast to be exceeded. Maintain the project’s registers and logs. |
Team manager |
Agree work packages with the project manager. Inform project support of completed quality activities. Produce checkpoint reports. Notify the project manager of any forecast deviation from work package tolerances. |
Project assurance |
Verify the business case against external events and project progress. Verify changes to the project plan to see whether there is any impact on the needs of the business or the business case. Confirm management stage and project progress against agreed tolerances. |
Project support |
Assist with the compilation of reports. Contribute specialist tool expertise (e.g. planning and control tools). Number, record, store and distribute issue reports and exception reports. Assist the project manager in maintaining the issue register and risk register. Maintain the quality register on behalf of the project manager. |
12.3 Guidance for effective progress management
12.3.1 Aligning with corporate governance processes
A starting point for any project in an organization will be to identify the timing of corporate, programme management or the customer governance processes from which the project will require decisions or authority. It is usually advisable to design the project’s control processes to align with corporate, programme management or the customer timings.
12.3.2 Programme and portfolio controls
If the project is part of a programme or portfolio, then the programme or portfolio will usually mandate the progress controls for the project. This will typically include defining common controls, processes, tolerances and timings.
12.3.3 The project’s delivery approach
It is important that the approach to managing progress works with, and supports, the project’s chosen delivery approach rather than against it. For example, in agile it will typically be more appropriate to focus on tracking how much of the requirement is being delivered as opposed to time and cost overruns as tolerances would have been set in accordance with this. In agile, the frequent delivery of products that meet their acceptance/quality criteria is a primary source of progress information and provides the basis for forecasting future progress.
12.4 Techniques: progress evaluation and peer review
12.4.1 Progress evaluation techniques
Examples of progress evaluation techniques
Milestone chart
This is a graphical chart showing key planned and actual milestones in a management stage.
S-curve
This is a graph showing cumulative actual figures (e.g. costs or hours) plotted against time. The curve is usually shaped like the letter ‘S’, reflecting the fact that a project typically consumes fewer resources and costs at the start and end of the project, and more in the middle. The steeper the curve, the more resources are required. When planned and actual figures are shown on the same chart, this can be used to identify potential overspend or forecast areas where tolerances may be exceeded.
Earned value management
This is a technique to measure the scope, schedule and cost performance compared with plans, by comparing the completed products and the actual cost and time taken against their schedule and cost estimates. PRINCE2’s approach to product-based planning provides information to support earned value management.
Burn charts
This is a technique for showing progress (e.g. such as during a timebox) where work that is completed and work still to be done are shown with one or more lines, and the chart is updated regularly/daily. This is one of the most popular techniques when using an agile approach and burn charts come in two forms: burn-down charts and burn-up charts. Burn-down charts are the most well-known and they show how much work remains whereas burn-up charts are slightly more complex and they show how much work has been done.
Kanban board
Kanban is a term that covers the use of Kanban systems, which are visual management systems that limit the number of work items in circulation. A Kanban board is a tool used in Kanban to visually display the work in the system (or timebox). It is usually made up of a series of columns and possibly rows where work items move from left to right as they move through various states in order to be completed. A Kanban board acts like a dashboard and enables the team to see blockers and areas where the flow is not smooth.
Measuring the progress of a management stage involves looking backward at the progress made against plans, and forward at what still needs to be completed with what time and resources. There are many techniques available to measure project progress.
A peer review is where people experienced in project management but outside the project management team are asked to evaluate the project. There are many peer review techniques and the quality management approach should identify the technique(s) appropriate to the project.
Example of a peer review technique
The OGC Gateway™ Process
OGC Gateway reviews examine projects prior to key decision points in their lifecycle to provide assurance that they can progress successfully to the next stage. The process is used in UK central government, the health sector, local government and defence, and has been adopted by numerous other countries.
OGC Gateway reviews are ‘peer reviews’ in which independent practitioners from outside the project use their experience and expertise to examine the progress and likelihood of the successful delivery of the project.
The reviews take place at different points in a project’s lifecycle and are as follows:
•OGC Gateway review 0: strategic assessment
•OGC Gateway review 1: business justification
•OGC Gateway review 2: delivery strategy
•OGC Gateway review 3: investment decision
•OGC Gateway review 4: readiness for service
•OGC Gateway review 5: operations review and benefits evaluation.
OGC Gateway reviews 0 and 1 happen prior to the project being authorized to start. Reviews 2 and 3 happen during the investigative stages prior to a full business case being approved. Review 4 happens prior to any new operations or services being launched. Review 5 is equivalent to a PRINCE2 post-project benefits review.
An OGC Gateway review is not the same as a ‘gate’ or decision point (such as the end stage assessment), but a means of providing added assurance as input to the decision on whether the project is likely to meet its objectives. The cost and time of conducting gateway reviews should be included in the project plan and stage plans.