What is PRINCE2 Tolerance?

Mastering PRINCE2 Tolerance - the management missing link!

Whenever the PRINCE2 term ‘Tolerance’ is mentioned most of the human species thinks “give them an inch – and they’ll take a mile!” So tolerance is often issued out like a miser giving to charity…

If so, novice PRINCE2 project board members and project managers have not grasped the significance of tolerance, the thinking needs to be entirely different.

You see, tolerance is a control and should be treated as a friend to those who state it. Instead of viewing tolerance as the extreme end of what is acceptable, see it as the level at which YOU are insisting to be involved to use your influence and decision-making.

A good trainer will say, “this is what I want you to do, get back to me if you have any problems”

But a better trainer will say “this is what I want you to do, get back to me if you (set tolerance criteria here)”

That way the trainer is not used as a crutch for every small learning/development problem, but allows the learner to make small mistakes and learn to fix them…but know when to escalate to the tutor when their learning has reached a 'log-jam'.

Tolerence

Tolerance is a really is a powerful technique that is built into PRINCE2 under the management by exception technique.  It is powerful but simple to comprehend; a plus and minus limit is placed around a management control limit such as cost for example, with the project manager giving the regular highlights reports to the project board.

As long as the project or stage remains within tolerance and no action or decision has to be made.

But directly the project manager forecasts that tolerance is to be exceeded then this triggers the raising of an exception report. The project manager uses the process escalate issues and risks to create the exception report and bring it before the Project Board.

This of course means that the project board must place trust in the regular highlight reports and assume that they contain accurate information.  But this is where project assurance can play an important part by auditing and checking the information.

The tolerance limits for positive and negative ranges do not need to be the same, and frankly are normally different (think of your family budget - is the overspend limit where you need to take action, the same as the underspend limit where you need to suggest use of available funds? Probably not...)

Project level tolerance is first set in the starting up a project process. and influences both the project approach and the content of the project brief.

Although not stated in the PRINCE2 Manual, I believe that all tolerances must emanate originally from the Business Case, and I will discuss in this article that time, cost, scope, quality, risk and benefits all have an impact in the business case, and hence this vital document should be used as the start point for any tolerance decisions.

There is a temptation by novice project boards to set tight tolerances as they do not trust the project manager, but this is a mistake since tight tolerances are easily triggered by small deviations causing many exception reports to be raised and hence increasing involvement by the project board.

Tolerance Application

The most common tolerances are time and cost (and we will cover the other types later in this article).

Here is a helpful diagram showing a graph of time and cost tolerance:

Note that a forecast of any value that deviates outside of the tolerance ‘box’ will trigger the need for the creation of an Exception Report sent to the next level of management. The following diagram shows just four examples of where this would be true:

It is a common human problem that once a project is underway, individuals will be over optimistic about such aspects as time and budget spend.  In particular, at a mid-point within a stage, if spending has been higher than originally planned, for the forecast to be reduced so that the original time and cost limits can still be met.

What happens at each reporting period is that the team successively reduce the remaining time/cost in the mistaken and optimistic belief that they can ‘make-up/reduce ’ the overspend/delay and thus keep the forecast within tolerance bounds. The project manager uses the process report highlights to create the highlight report and include the status on both tolerance levels and forecasts.

As the end of the stage approaches the actual spend shows that tolerance has been exceeded. It is now too late to fix the problem root causes...

The problem here is not in the PRINCE2 method of tolerance but the application of allowing optimism and wishful thinking on behalf of the team, in that they always ‘believed/hoped’ that the final time-part of the stage would underspend or come in early (“Hey! Surely we are getting more efficient?”) and so keep the stage within tolerance bounds.

The PRINCE2 Manual describes how a tolerance corridor can be shown graphically, so that at any given point if it is forecast that the tolerance corridor is to be exceeded (even though the stage is still predicted to complete within tolerance), an exception report is raised.

The following diagram demonstrates this principle:

When stating a tolerance corridor at the start of a stage, problems can arise from the fact that the corridor is very narrow at the start of the stage (see above) and so it can be very easy to deviate outside it - causing unnecessarily high frequency of exception report/regular and inappropriate project board involvement.

The way to get around this is to agree to introduce it (say) one-third through the stage, or (better in my opinion), to use only the end tolerance as a trigger for (say) the first third of the stage and then introduce the time corridor.

NOTE: PRINCE2 advises that in addition to a stage budget, that a change budget and a risk budget MAY also be set.

Be clear. The stage budget is what you are applying tolerance against.

The change budget is a separate ‘pot’, and is only be used to fund any changes. Such spending will need the agreement of the project board, or a change authority if one has been agreed and set up. Tolerance is NOT applied here. IF you have no changes, then the change budget is returned. It is not used to fund any ‘deviations’!

In a similar way, this budget is only available to deal with risk actions and management. If it is not used, then it is returned. Tolerance is not applied here.

It is worth reminding ourselves of the different levels that tolerance can be set within a typical PRINCE2 project:

• Project level tolerance
• Stage level tolerance
• Work package level tolerance (optional)

Corporate/Programme Management will set and agree the project-level tolerance, and the Executive will be held to account for such tolerance. They will then ‘manage by exception’ with the project board and have very little involvement – safe in the knowledge that if such tolerance is forecast to be exceeded, the Executive will bring this fact to their immediate attention.

The Project Board (and ultimately the Executive) will set stage level tolerances at each end stage assessment. This uses the authorize a stage or exception plan process. This is a ‘contract’ with the project manager to manage the stage on a day-by-day basis.

The project board will then ‘manage by exception’ with the project manager and have very little involvement apart from reading the regular Highlight Reports issued by the project manager– safe in the knowledge that if such tolerance is forecast to be exceeded then the project manager will bring this fact to their immediate attention.

During the controlling a stage process the project manager will monitor, manage and control the stage within tolerance bounds.

Optionally, the project manager can set a tolerance at work package level, and this is then a ‘contract’ of understanding between the project manager and the team manager/team member(s) using the authorizing a work package process and the accepting a work package processes.

The project manager will state the tolerance in the work package itself, and when the team accept it they will create the specialist products issuing a Checkpoint Report to the project manager at a frequency laid down in the work package.

Note that if tolerance is forecast to be exceeded, the team manager raises this as an Issue on the issue register, bringing this to the attention of the project manager, who will now consider the deviation within the bigger remit of the stage and decide on the next steps to take.

Whatever the level of tolerance, once it is forecast to be exceeded and an Exception Report is created, this will include a list of options for recovery and a recommendation from the report creator.

There are many potential decisions that may be taken, but the following is a reasonable list of potential responses to the Exception Report:

• Accept and request implementation of one of the Exception Report options
• Upon reading, request implementation of their own (additional) option
• Delay a decision until a later time point
• Delay a decision pending further requested information
• Reset a (higher) level of tolerance and continue as before
• Escalate it to the next level to first receive advice/guidance
• Prematurely close the project (the Project Board only)

Consideration must be given at the appropriate planning time for the type and deviation amount of each tolerance set

But of course, there is another set of variables here – and probably the most important of all, the type or control areas of tolerance used…

The Six Types of Tolerance (ALL should be considered when planning)

Any one or more in combination may be used.

Time

Most commonly used; as many projects are end-date driven. If a key and real end date is set, the project manager would want to produce a plan that showed an earlier start time and/or total duration, so that the planned finish time is before the driven end-date and a positive time tolerance showing an on-date project completion.

If this is not done, then a positive time tolerance of zero must be used, and this should be entered into the risk register as a risk with appropriate actions and proximity data for timely resolution if needed.

Cost

Time and cost are often naturally linked, for example taking longer leads to additional resource costs.

Project Boards are often mesmerized by ‘budgets’ and set miserly tolerances to protect themselves rather than digging into the Business Case. They should be looking at profit margins, doing best case/worst case scenarios and then looking at sensitivity analysis.

This will help build up a clear picture of the plus and minus zone where they need to get involved.

Using these control metrics rather than ‘what is the worst we can tolerate’ – by then it’s too late, will move them forward to sensible cost tolerances.

Scope

This needs careful thought and is often a more sensible tolerance choice than cost or time. As an approximation, consider scope as similar to functionality or requirements. It also has a knock-on effect on quality, for example if the wall needs to have a smooth plaster finish, then the scope includes plastering….

So in summary, scope tolerance relates to what products are ‘must have’, and what are ‘nice to have’ (using the ‘MOSCOW’ approach), but it also relates to what activities the project plan includes.  For example, you might agree that ‘plastered wall’ is an included product, but the plan may include consultation with wall plastering specialists…

It is worth mentioning DSDM Atern or Agile projects, where by design; the team are driven to deliver what they can within a given time limit. This by definition infers that the deliverables will be de-scoped if need in order to deliver what they can within a time box.

Put simple, scope tolerance infers setting the limits within the choice of a minimum to include the ‘must haves’ and a maximum of the ‘nice to haves’

Quality

 Setting tolerances by quality will be defined in the product description quality tolerance, or in allowable deviations within the Project Product Description. Be clear. Quality tolerance does NOT mean ‘poor quality’. A simple analogy might be preparing a meal for your friends. Fresh produce may be criteria, or the choice of a vegetarian option, or it might be the selection choice of several dishes.

None of these options include poor raw materials, inept cooking techniques or sloppy presentation.

For the above reasons, quality can be synonymous with for the old classic “fitness for purpose” which immediately suggests a range that can be used for quality tolerance.

Risk

The two main parameters of a risk are the probability and its impact upon the project meeting the project objectives. Two other parameters which may come into play in defining risk tolerance is a risk’s severity and proximity.

So it makes sense to set risk tolerance along these lines, where a plus and minus value for the above can be used.

It might be a more blunt approach where a named risk or set of risks cannot be tolerated if their probability or impacts rise above a pre-set value.

Consider entering a new market place whose project represented a large financial commitment and a major player was also thinking about entering the same market.

If it looks greater than (say) 50% that they will enter (market intelligence could be used here), then the project may have to be re-scoped (to include added value functionality so that you have improved competitive sales revenue), or that you withdraw and cut your losses.

Benefits

These are the business benefits laid out in the Business Case and the Benefit Realization Plan.

This is one of the main reasons why I talked of the business case being a prime driver for tolerance.

A PRINCE2 Business Case MUST include the benefits (and dis-benefits) in terms of tolerance bounds derived from best-case and worst-case scenarios. These will provide the key tolerance control metrics where the project board must be involved so that they may make informed choices.

Again, don’t set these metrics at the best or worst case point – it will then be too late!