PRINCE2 Progress Reviewing

reviewing progress on a prince2 projectReviewing progress on a PRINCE2 project

There are two types of progress controls that are used, and these are event- driven and time-driven controls.  Event driven controls are triggered when a particular event occurs, for example at the end of the stage or completion of a major deliverable.  They also triggered by the creation of an exception report.  Such triggers may occur outside of the project by key milestone events such as an organisational audit.

By way of contrast, Time-driven controls are curved at predefined periodic intervals, and to examples of these are the highlight report being produced during a stage for the project board, or regular checkpoint reports giving the project manager who is reviewing progress of a particular work package and the products being created within it.

There is typically a sequence of actions the project manager would want to take when considering the progress within the stage and project.  Using the stage plan as an example, this can be referred to at a given point in time to ascertain planned progress on the creation of the products.  This is then compared against actual progress.

If there is a variation between the two, then corrective action needs to be taken.  Consideration of such corrective action is given by acknowledging what work has still yet to be done and the availability of resources to carry that out.

The control of reviewing progress can only occur if there are other reference plans against which to compare actual progress.  These of course, are the project baselines and are used for reviewing progress control:

Reviewing Progress – Project Plan.  The PRINCE2 project plan includes the performance targets (typically time, cost, quality, and risks), as well as tolerances set at project level.  Any forecast deviation of such tolerances will need to be escalated to the project board via an exception report.  This will then need to be escalated by seeking advice from corporate or programme management for corrective action.

Reviewing Progress –Stage Plans.  These are used by the project manager for day to day control of the stage, and will contain the activities, there timescales, and the resources to carry them out.  The project manager will use the information within the stage plan to carry out any corrective action should that be necessary, or to escalated to the project board via an exception report if stage tolerances are under threat.

Reviewing Progress –Exception Plan.  This may be requested by the project board have been considered an exception report, and if authorized will replace the plan that would have no longer delivered within its tolerances.  The directing a project process will be used by the project board to carry out such authorization was it they believe it necessary.

Reviewing Progress –Work packages.  The control here is that work cannot commence during the stage unless and until the project manager has authorized a work package covering that work.  The team manager or a specialist team member must accept this work package before work commences.  Optionally, tolerances may be set at work package level.  A work package may be carried out formally or informally, and may be given to internal staff or third parties such as contractors.  Progress against each work package is reported back to the project manager via the regular checkpoint reports.

Reviewing progress at project and stage level

The Controlling A Stage process is used here, and the project manager will review work package progress on a regular basis via the regular checkpoint reports.  In addition, the project manager will have various registers and logs to help ascertain and controlled progress.  The project manager will also want to keep an eye on trends to ensure that the future forecast for the remainder of the stage will complete within tolerance bounds.

Here is the list of the registers and logs that will be used by the project manager:

Reviewing Progress – Daily Log.  This is used to record any small action and can be marked of when completed.  Sources for such actions may include checkpoint reports, quality review outcomes, or any ad hoc conversations.  Small and seemingly inconsequential actions may be missed and could become issues or risks if allows to continue unheeded.  The daily log will help stop this from occurring.

The daily log can also be used to record in for issues and any other concerns, observations all notes.  Any significant actions however, should be entered into the stage plan, and a note of this entered in the daily log if that was the source of such actions.

Reviewing Progress – Issue Register.  This is used whenever any issues are to be treated formally and would either be a request for change, of specifications or problems/concerns.  Again, trends in the raising of such issues can provide evidence of progress problems.

Reviewing Progress – Risk Register.  The project manager will want to regularly review the risk register as part of reviewing stage status as it is a record of all identify risks.  As the project progresses through the various stages risks should gradually decrease as the amount of uncertainty within a project will naturally diminishes.  Particular attention should be paid to the aggregated level of risks as this may cause problems for the future progress within the stage and project.

Reviewing Progress – Quality Register.  The quality register is a record of all plans quality activities, and as such should be regularly reviewed to determine that the outstanding quality activities are progressing to plan.  An example here is that if products are failing their quality reviews or considerable rework is being undertaken then this can lead to progress problems.

Reviewing Progress – Product Status Account.  This is in fact a report and typically can be requested by the project manager, project assurance, or members of the project board.  It’s provides a snapshot of the status of products within the project, a management stage or a particular aspect within the project.  The product status account shows planned and actual dates for key points within the creation, review and approval of products within the plan.  It is derived from the configuration item records.

There are many techniques available to measure project progress, but three are particularly useful and worth mentioning here.

Reviewing Progress – Milestone chart.  As the name suggests this is a graphical chart showing that he planned and actual milestones within a stage, and plotted against an appropriate time scale.  There are variations on this such as the waterfall chart plotting planned and actual milestones against a time frame.

Reviewing Progress – The ‘S’ curve.  This plots either the plant cumulative cost or work against a time frame.  Actual progress can be added to the graph so that progress against plan can be compared.  It takes its name from the fact that fewer resources will be used at the start and end of a project, and that most of the work will occur during the middle, and hence follows a shallow curve somewhat similar to the letter S.

Reviewing Progress – Earned value management.

PRINCE2 has the product based technique as a starting point for all plans, and by the use of key points where each product is completed; this ties in nicely with the technique of earned value management (EVM).  The technique is powerful because it avoids the ambiguity of merely measuring for example, actual cost against planned cost as any variances are open to interpretation as to whether the project is over spending all behind schedule for example.

Reviewing Progress – The Lessons Log.

One of the seven PRINCE2 principles is that the project management team learns from experience, and this means that any lessons are proactively sort out, recorded and actions throughout the project.  Indeed, by the very action of reviewing progress, valuable lessons may be identified and hence learned.  Such a lessons may be obtained from any aspects including issues, roles and responsibilities, tailoring, quality statistics or performance measurements.

Reviewing Progress – Lessons Report.  Lessons may learns of any decline during the project would actually learning them means that action must be taken to implement such improvements, either to the current project to implement immediately or to future projects.

When reporting progress, the frequency and level of detail should reflect the amount of control required.  The progress information may be less frequent during design stages, all for highly experienced teams, then less frequent reporting may be appropriate.

There are four reports which help in progress control by communicating key information upwards, and at important control points throughout the project:

Reviewing Progress – Checkpoint Report This gives progress of the product creation within a work package and the frequency of such a report will be laid down within the work package itself.  When the project manager receive such reports, they will use these as part of the progress assessment room reviewing the current stage status.

Reviewing Progress – Highlight Report.  At each end stage assessment the project board will determine the frequency of highlight reports for the following stage or for the remainder of the project.  This should be documented within the communication management strategy document.

The Highlight Report is part of the management by exception process and this allows the project board to manage by exception by understanding the tolerances that have been set and our remaining.

Therefore the highlight report should confirm and you confidence of the project board the progress is being made within such tolerances as a now then to make decisions by providing early warning of possible problems that may need their involvement to resolve.

Reviewing Progress – Communication Management Strategy will lay down which other key stakeholders should receive copies of a highlight report, and the project board may also issue the hall all summary of a highlight reports up to corporate or programme management.

Reviewing Progress – End Stage Report.  The project board needs information of the progress to date, then the end stage report is produced by the project manager at the ends of each management stage to provide this information.

The End Stage Report should include not just information on the current stage but also the overall project situation but along with the next stage plan provides sufficient information for the project board to make an informed choice on what to do next with the project.

Reviewing Progress – End Project Report When the final work package has been approved within the final stage, this will trigger the project manager to use the closing a project process to provide the management products to put before the project board so that they can evaluate the project and the authorize closure or otherwise.

As part of reviewing the progress at any point within the project, the management by exception process must be mentioned.  This will normally be set via tolerances at project plan, stage plan, and optionally work package levels.  Whenever any of these are forecast to exceed tolerances, then it must be escalated to the next management level.

Reviewing Progress – Work package level exceptions.  If tolerances are optionally set at work package level, then the team manager must keep the project manager informed of progress via regular checkpoint reports.  If a work package is forecast to exceed its tolerances, then the team manager must inform the project manager via an issue.  After receiving this, the project manager will advise what corrective actions must take place.

Reviewing Progress – Stage level exceptions.  Whenever a stage is forecast to exceed its tolerances, the project manager will enter this on the issue register and raise an issue report, these will analyse the details of such a deviation, and the project manager will provide an exception report for the project board.

The project board will consider such a report and may request that the project manager produces an exception plan or prematurely close the project.  Assuming the former, then the project manager will update the relevant information and present the facts to the project board at an exception assessment.  The project board will either approve this, request some form of rework, or prematurely close the project.

Other options that the project board may take is to remove the cause of the problem, except it and adjust tolerance levels, or request more time to consider or reject the recommendations contained within the issue report.

Reviewing Progress – Project level exceptions.  If the project is forecast to exceed its project tolerances, then the project board no longer has the authority to manage the project and must therefore refer the matter upwards to buy the corporate or programme management for them to make a decision.  In such a case the project board may request the project manager to produce an exception plan for the entire project.

For more information CLICK HERE

About the Author Dave Litten

David spent 25 years as a senior project manager for USA multinationals, and has deep experience in project management. He now develops a wide range of project-related downloadable video training products under the Primer and Projex Academy brand names. In addition, David runs project management training seminars across the world, and is a prolific writer on the many topics of project management.

follow me on: