PRINCE2 Practitioner Masterclass 
PRINCE2 Issue Management 
APM PMF Project Management Fundamentals 
All Access PRINCE2 7th Edition Progress Practice
The purpose of the PRINCE2 7th edition progress practice 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 deviations causing an exception.
A key component of project management is controlling the project’s progress, which ensures that the project remains viable against its approved business case.
Progress control involves measuring actual progress against the performance targets of benefits, time, cost, quality, scope, sustainability, and risk.
This information is used to make decisions, such as whether to approve a stage or work package, whether to escalate deviations, or whether to close the project prematurely and to take actions as required.
Progress can be monitored at the work package, stage, and project level.
Progress: the measure of the achievement of the objectives of a plan
Forecast: a prediction made by studying historical data and past patterns
Exception: a situation where it can be forecasted that there will be a deviation beyond the tolerance levels agreed between the project manager and the project board (or between the project board and business layer).
Guidance for effective progress management
The progress management practice is based on an overarching plan-do-check-act cycle (also known as the Deming cycle or Shewhart cycle), also bringing in the control aspects of the other PRINCE2 practices, such as risk management.
Effective progress management includes:
- defining management levels and tolerances for progress control
- applying two types of control (event-driven and time-driven)
- reviewing progress and lessons
- reporting progress and lessons
- forecasting remaining work
- escalating
- using data
Management levels and tolerances for progress control
The project is managed by exception between four management levels against tolerances for seven performance targets
The business layer, outside the project team, 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 if forecasts remain within project tolerance and will allocate tolerances for each stage to the project manager.
The project board can review progress and decide whether to continue, change, or stop the project. When executing 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 the business layer by the project board. This is to decide the corrective action.
The project manager has day-to-day control of a stage within the tolerance limits established by the project board.
When executing a stage plan, if any forecasts indicate that the stage is likely to exceed the agreed stage tolerances, then the deviation should be referred to the project board by the project manager to decide the corrective action.
This would be done by raising an issue and an exception report.
The team manager has control over a work package, but only within the work package tolerances agreed with the project manager.
When executing 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 to decide the corrective action.
This would be done by raising an issue.
1 Quality tolerances are not summarily defined at the stage or work package level but are defined as per product description within the scope of the plan.
2 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 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 an iterative-incremental development method such as agile.
3 More specific stage-level risk tolerances may be set by the project board when authorizing a stage or by the project manager when authorizing work packages, especially from external suppliers.
4 More specific stage-level sustainability tolerances may be set by the project board when authorizing a stage or by the project manager when authorizing work packages, especially from external suppliers.
Types of control
Effective project control is delivered through the accurate, timely, and regular measurement of actual progress and comparing it with the planned progress at that stated point in the project or stage and taking any necessary corrective action.
The PRINCE2 method provides two types of progress control throughout the life of a project: event-driven controls and time-driven controls.
Definitions
Event-driven control: a control that occurs when a specific event occurs. For example, this could be the end of a stage, the completion of the project initiation documentation, or the creation of an exception report.
It could also include organizational events that may affect the project, such as the end of the financial year.
Time-driven control: a management control that occurs at predefined periodic intervals. For example, this could be producing highlight reports for the project board
or checkpoint reports showing the progress of a work package.
Monitoring is a time-based activity, control (decision-making) is an event-based activity, and reporting is both time-based and event-based. The use of event-driven controls drives efficiency as it means project management team do not meet unnecessarily or too frequently, but when most needed.
Reviewing progress and lessons
As part of the controlling a stage process, the project manager will regularly review progress through checkpoint reports and will maintain the project log. The project manager will use this information to update the stage plan with the actual progress achieved.
The format and frequency of checkpoint reporting will depend on the needs of individual work packages. 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 needs to be achieved week by week.
It is also necessary to analyse the project data for trends to get a view of the overall health of the stage. For example, the 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 that are not being resolved and may be a cause for concern. Similarly, the quality register may reveal several products have failed a test and have not yet been recorded as having been re-tested in the quality register.
Actions may arise from many sources and small actions may simply be recorded on the daily log and marked 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 management product.
The difference between a formal issue and an informal issue is that a formal issue will be captured in the issue register as an open forum. There, it will then be monitored and reviewed due to its material impact on the project or stage.
An informal issue is one that either does not have a material impact or requires handling in a suitable manner where open access would be inappropriate.
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.
The product register also provides data on the status of the products that are complete, currently in progress, and awaiting development.
The data from this register may be compared with the physical status of the products to provide assurance of the project’s progress.
A principle of a PRINCE2 project is that the project management team learns from experience. Therefore, the project team actively seeks, records, and incorporates relevant lessons throughout the life of the project, applies them to the remaining work and shares them for future projects.
It is often in the reviewing of progress that lessons are identified. The project log includes a lessons log, which is used for capturing lessons and is accessed when reviewing progress.
Reporting progress and lessons
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 or project board may wish to increase the frequency of reporting until sufficient confidence has been gained in the capability of the team.
PRINCE2 does not define the composition, format, or presentation for reports, which should consider the quality management, risk management, and issue management approaches.
If part of a programme, the information should also consider the programme’s monitoring and control requirements.
Reports may take the form of an electronic dashboard, which has aggregated and summarized data from an integrated system.
These dashboards may be available to the respective stakeholder audience, such as for the directing, managing, or delivering levels of the project.
These are based on the access and availability stipulated in the digital and data management approach.
Additionally, an information snapshot of the status of products within the project, stage, or a particular area of the project to support the findings of a progress review can be found in the product register on a self-service basis.
Data for this snapshot may be found within a system rather than in a manually generated document or spreadsheet.
Capture and apply lessons
A lesson is information to facilitate the future of the project or other projects and actively promote learning from experience. The experience may be positive, as in a successful test or outcome, or negative, as in a mishap or failure.
Recording lessons during a project is good for the organization, project team, and other existing and future projects. Lessons are documented information that reflects both the positive and negative experiences of a project.
Lessons can be captured:
- during any meetings throughout the project (you do not have to wait until a post-project review to share lessons)
- via PRINCE2 management products like checkpoint reports or highlight reports
- by performing retrospectives
- when issues occur during stakeholder one-to-one meetings
- using electronic workspaces where data and information are shared
- during a post-project review
The analysis of a lesson should answer five questions in the following order:
- what did we expect to occur?
- what actually happened?
- what worked well and why?
- what did not work and why?
- what needs to be done differently or what needs to be repeated?
Document management systems or team collaboration systems are useful tools for sharing and reporting knowledge from lessons. It should be noted that systems and data play a major part in reviewing progress.
Any reports, registers, or logs mentioned above may originate from a system where the data is integrated and accessible. This would be by the digital and data management approach and presented electronically with drill-down capabilities to access more detail.
The reporting of lessons could include information about the development of a product or the project management practices, processes, procedures, techniques, or tools used that either contributed to the project’s achievements or caused a problem.
Examples might include the performance of the project management team, the methods used, or the analysis of quality data and measurements. Larger projects are more likely to utilize a lessons report as part of this procedure, where more detail would be helpful.
Forecasting
A fundamental component of the manage by exception principle is forecasting. An exception is defined as a situation where it can be forecasted that a deviation beyond the agreed tolerance levels will occur.
It is not necessary, and indeed not helpful, to wait until that deviation has occurred.
Therefore, forecasting within projects is essential because it helps to identify responses to project risks, predict project outcomes, and help ensure overall project success.
It is important to consider the performance of the project so far and other projects inside or outside the organization.
Although time and cost are often stated as the key metrics to track, all seven PRINCE2 performance targets should be considered.
The collected data is then sifted, collated, and analysed to provide the project manager with sufficient information on past performance to predict future risks and outcomes, as well as determine whether the project retains a continued business justification.
Again, the data may be held in an integrated system, which may also allow for ‘what if’ scenario forecasting, to ease the forecasting workload for project managers.
The digital and data management approach will describe what systems and data will be used by the project to assist with forecasting. This may involve using data from outside the project or the business, for example, from a data trust as a reference class to enable predictive data analytics to be used.
Escalating
The output derived from reviewing progress is a decision as to whether the work package, stage plan, or project plan will remain within or exceed the agreed tolerances.
If they exceed or are forecast to exceed the agreed tolerances, then they are an exception.
Work package level exceptions
After agreeing on the work package tolerances with the team manager, the project manager should be kept informed of progress with 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 for the attention of the project manager. 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 data behind the deviation and then provide an exception report for the project board.
Based on the information in this report, the project board may request that the project manager produce an exception plan to replace the plan that was forecast to exceed tolerance.
The project board may also remove the cause, accept or adjust the tolerance, or request more time to consider the recommendations. If an exception plan is requested, the project board will review and either approve or reject 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 the business layer for a decision. The project board may request the project manager to produce an exception plan for the project.
Use of data and systems in progress management
Data and technology help manage projects more accurately by supporting progress tracking and decision-making.
Project data may be in the form of project documentation, correspondence, project log, and records. It includes both internal and external data, as well as digital and non-digital formats.
The collection of data within projects has evolved dramatically with the introduction of digital technology to plan and schedule projects. These systems will capture, validate, and present data against the plans and milestones for ease of understanding progress.
Data analytics is the means of using and analysing data to support effective decision-making or to bring efficiency through the automation of tasks.
Progress reviews are not confined to looking backwards. After having secured and stored the data through systems, past performance can be used to predict future performance.
To ensure clarity, this information can then be presented in the stakeholders’ preferred format and style.
The project management team must decide what they require from the reporting and forecasting procedures. Then, they should select a solution to fit both the requirements and the level of maturity of the business and the organizations that are involved in the project.
The business may already have established systems through a centralized programme or project office, or the nature of the project may require new systems to be designed, (possibly) procured, and established.
For example, the use of digital twins and building information modelling (BIM) in construction projects.
The project’s digital and data management approach will explain what digital technology will be used to support project management and project work as well as how the data will be used and which systems will be used for data analytics.
For example, the use of sentiment analysis to understand team performance or stakeholder engagement.
The management products used for checking the baselines, reviewing progress, capturing, and reporting lessons, reporting progress, or forecasting are frequently recognized by the project manager as a combination of disparate sources.
Automation, for example, the use of artificial intelligence is removing the need for a manual approach, enabling project professionals to focus on far more value-added tasks rather than administration.
Due to home working and globalization, project teams are more likely to be distributed across multiple locations rather than co-located.
Therefore, the use of digital systems can help to communicate and transfer data or information.
If the team and the data are up-to-date, information management is more reliable and easier to administer in an automated system.
PRINCE2 technique for exception management
PRINCE2 includes a six-step exception management technique
An alternative procedure can be used instead if desired, for example, if the project is part of a programme that has a programme-wide exception management procedure.
The use of an alternative procedure should be documented as part of the tailoring decisions in the project initiation documentation.
Although this technique mentions reports, this does not preclude the use of systems and data from performing the same function.
Issues are often encountered in the delivery level of the project that will take the stage outside one of the stage tolerances. It may also occur during the managing level for those issues that are not driven by delivery problems.
Step 1
From the work package data, the team manager forecasts that one or more of the products in the work package will take the work package outside one of its tolerances.
At this point, an issue is raised for the attention of the project manager.
Issues are captured in the issue register. For some issues, the detail captured is sufficient to analyse the issue and respond. Other issues may require more detail or may need to be raised and responded to in a more formal way.
In such cases, the issue is captured in more detail in an issue report. If the issue can be resolved by the project manager within the stage tolerances, the resolution will not require an exception report to be created.
However, the issue will be reported in the next highlight to the project board, and a note may be made in the lessons log.
Step 2
If the issue will affect the stage (or project) tolerances to the point that they are forecast to be breached, an exception report is created by the project manager detailing the situation with resolution options and a recommendation.
The exception report is sent to the project board or project executive at the directing level, along with any other relevant data to assist in their decision.
Step 3
The project board or project executive have several options that they could take.
They may:
- reallocate the overall project tolerances to resolve the breach of the stage tolerance
- reprioritize the requirements to bring the stage back within tolerance (de-scoping or re-scoping the product)
- inform the project manager that they require more time to consider their options
- implement the exception report and request an exception plan from the project manager
- implement the exception report by escalating to the business layer for advice and direction, if the exception will take the project outside one or more of its project-level tolerances
- the business layer will provide direction to the project board, which will then direct the project manager accordingly.
Step 4
The project manager ceases the current stage and introduces a stage boundary to create the exception plan and adjust any other related information in the project initiation documentation.
An end-stage report may also be produced where the stage has progressed to a point where this would be useful data for the decision.
Step 5
The project board or project executive will assess the exception plan and may take several options. They may:
- reject the exception plan and request amendments from the project manager
- reject the exception plan and direct the project manager to continue with the stage
- this may require minor adjustments to the current stage
- approve the exception plan and return it to the project manager for further action.
Step 6
The exception plan will be received by the project manager with a direction to implement it as a new stage plan. In effect, the exception plan becomes the new stage plan.
The project manager authorizes the next set of work packages for the delivery level to recommence, taking into consideration the issue that triggered the exception.
Consideration should be given to aligning the new stage end with the old stage end if desirable or feasible. This ensures that the planned end-stage assessments by the project board or project executive do not require rescheduling and are still aligned with the original requirements for a decision at that point in the project.
A product flow diagram can also be used to map progress while at the same time reminding the project board of the dependencies and sequencing of products.
Supporting techniques
Measuring the progress of a stage involves looking backwards at the progress made against plans and forward at what still needs to be completed with available time and resources.
However, effective progress management requires an open and transparent culture with a no-blame attitude to progress reporting.
There are many supporting techniques, and those mentioned below may be used in isolation or combined depending on the needs of the project or team.
For example, the solution developers may use Kanban as a team board to demonstrate progress and hold daily stand-ups for reporting purposes.
Dashboards
A dashboard is a technique to represent vast amounts of decision-supporting information at an amalgamated level using tabular and graphic representation, such as graphs and traffic lights.
Daily stand-ups
Daily stand-ups are daily meetings that are conducted quickly. All team members attend, and although the original meaning of the term implied that this meeting was conducted with everyone standing up, this is now rarely the case, with virtual meetings becoming more common in today’s environment.
The intention is that it makes for a brisk, focused meeting. Progress is reviewed, and every team member declares their next steps, using the three guiding questions which are:
- what have you done since yesterday?
- what are you planning to do today?
- have you encountered any problems or issues?
Part of the value of the daily stand-up is that everyone in the team maintains awareness of what everyone else is doing. This creates an opportunity within an organized, empowered team for one team member to offer timely help or suggestions to another team member.
Earned Value Management
This is a technique to create an integrated project baseline combining scope, schedule, and cost performance by comparing the completed products and the actual cost and time taken against their schedule and cost estimates.
approach to product-based planning provides information to support earned value management.
Peer review
A peer review is where people experienced in project management but outside the project management team are asked to evaluate the project. Peer reviews may also be held between subject matter experts about a particular product.
There are many peer review techniques, and the quality management approach should identify the techniques appropriate to the project.
Burn charts
This is a technique for showing progress (for example, during a timebox), where work that is completed and work still to be done is shown with one or more lines, and the chart is updated regularly (perhaps daily).
This is one of the most popular techniques when using an agile approach.
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 show how much work has been done.
Burn-down charts identify estimation issues early and help viewers understand how much work and effort remains. Burn charts help motivate teams by showing progress toward the project’s outcome.
Retrospectives
A retrospective is a type of progress review that specifically considers the way of working as opposed to looking at what was produced.
Running an effective retrospective is similar to running a successful workshop, and should consider:
- inviting the right people (normally just the team, and possibly project support)
- having an independent facilitator
- focusing on a small number of issues that can be actioned, rather than a larger number that are unlikely to result in action
- different, creative approaches to keep the retrospectives interesting and useful
- visual feedback tools to help people express their ideas.
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.
It usually comprises a series of columns (and possibly rows) where work items move from left to right as they move through the various states 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.
Applying the progress practice
Organizational context
To be fully effective, a retrospective should be planned, structured, and actively facilitated. They can be quite informal, but if they are run as an unstructured meeting, they are likely to become ineffective and not contribute to better ways of working.
A starting point for any project will be to identify the timing of the business layer governance arrangements from which the project will require decisions or authority. It is usually advisable to design the project’s progress controls to align with business layer timings.
Besides providing an objective assessment of past performance, it can be used to forecast total project cost and duration based on historical performance. PRINCE2’s
If the project is part of a programme or portfolio, then the programme or portfolio will usually dictate the progress controls for the project. This will typically include defining common controls, procedures, tolerances, and timings.
Commercial context
PRINCE2 is based on a customer/supplier environment. It assumes that there will be a customer who will specify the desired result and (usually) pay for the project, and a supplier who will provide the resources and skills to deliver that result.
Additional considerations apply if the relationship between the customer and the supplier is a commercial one. The contract between the parties acts as a constraint on a project manager’s or team manager’s degree of freedom when managing the project or work package.
For this reason, it is good practice to ensure that contracts reflect and promote good working relations rather than inhibiting them and that any tailoring to PRINCE2 respects the parties’ contract obligations.
From a supplier’s perspective, the project lifecycle should be defined to consider pre-contract activities, such as qualification, designing and costing the solution, bidding, and negotiation.
It may also consider activities at the end of the project, such as warranty and maintenance periods.
Delivery method
It is important that the approach to managing progress works with, and supports, the project’s chosen delivery method rather than going against it.
For a project using an iterative-incremental delivery method, it will typically be more appropriate to focus on tracking how much of the requirement is being met by the end of the sprint rather than how long it will take to complete the products.
The tolerances would have been set by this. The frequent delivery of products that meet their acceptance and quality specifications is a primary source of progress information and provides the basis for forecasting future progress.
The formality of reporting may differ in an iterative-incremental project using agile techniques such as Kanban and burn-down or burn-up charts.
Checkpoint reporting may be based on a ‘pull’ system, where the project manager reviews the charts maintained by the development teams rather than being sent by them.
By contrast, for a project using a linear-sequential delivery method, the focus may be on when the stage’s products will be complete and for what costs. In this way, the project board can be confident that there is a robust basis to move from the current stage to the next.
Sustainability
Progress management will gather data on those aspects of sustainability recorded in the project implementation document that are critical success factors for the project. This is to check that the project remains within its sustainability tolerances and the parameters established by the business layer.
Some areas of sustainability will fall under legislation, regulation, or business layer policies. Therefore, it will require evidence to support compliance.
Progress management must be able to identify and report on the data required to support this evidence.
The project executive may request an audit of the project if compliance against sustainability regulations is required.
Advice should be sought from the quality assurance function with the business or programme.
Sustainability reporting should not be separate from the agreed reporting requirements but rather integrated into the cyclical analysis of the project data by the project manager, team managers, and project support.
The activities in the plans should consider the data needed to satisfy sustainability
analysis, just as they should for the other tolerances within the project.
This is so that evidential reporting on sustainability is a consequence of progress management and not something that requires additional activities or resources.
Scale
Progress management needs to be applied or tailored to reflect the needs of the project’s scale, risk, complexity, and prominence.
In simple projects where risk and complexity are minimal, the progress practice may lend itself to some simplified data analysis for reporting and forecasting purposes.
Some of the roles may have been combined with a project executive sponsoring the project without a project board. The style may be more relaxed, and this could lead the project manager to report progress in a structured email rather than a formal report, for example.
For simple projects, questions that may be asked are:
- do all the management products need to be used?
- could some of the management products be combined?
- could the data be distributed more effectively and efficiently?
- could access to the data be given to stakeholders following the digital and data management approach?
As the projects become more complex and attract more risk, the project business may include more stakeholders with different reporting requirements.
Under these circumstances, a more formal approach to evaluation and reporting, either through structured reports or through the use of data and systems, will be required to satisfy the stakeholder requirements.
The project executive or project board must agree on the frequency of reporting and have the project manager record their requirements in the project initiation documentation.
This course is DEPRECATED
The old PRINCE2 6th Edition Foundation and Practitioner syllabus was upgraded in 2024. Check out the brand NEW PRINCE2 7th Edition Masterclass, covering all the current syllabus, training material and online exam benefits HERE
Your Route To PRINCE2 6th Edition Practitioner
Study PRINCE2 6 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.
