Tolerances are an important part of being able to work autonomously as a project manager. You need to have the authority and freedom of action to be able to change the direction the work is going in.
However, the project sponsor is the person responsible for decisions that affect the project budget and the schedule, where making a change would deviate from the agreed plan.
So how do you balance your need to make small changes on a regular basis and the sponsor’s role of being the ultimate decision-maker about changes?
The answer is that you don’t.
Welcome to the wonderful world of project tolerances.
What is a project tolerance?
A tolerance is a performance range you will keep to. The project tolerance definition I use in my book, Project Manager, is this:
Tolerances are how much you can flex within your project without having to go back for approval.
A project tolerance provides a boundary for the area of the project in which you can make changes without having to ask your sponsor’s approval.
They define your zone of responsibility. Essentially, the sponsor delegates authority to you to make small changes within a range of impact. You can change the dates or the budget as long as you don’t go outside the zone.
Having a tolerance means you can be over a bit or under a bit and not have to continually go back to your project sponsor and get any variation approved.
It gives you some slack to manage things in the best possible way and to be a professional about how you deliver projects.
Which level of management sets the project tolerances?
Tolerances can be set for the project, for a stage and also at work package level, so they can become very detailed.
The overall project tolerances should be agreed with the sponsor at the start of the project, so you know what parameters you are working to.
They form part of the ‘contract’ you have with the sponsor – and getting this clear up front will make managing the project (and the sponsor) a lot easier as the project gets going.
How are tolerances set?
Talk to your sponsor. Discuss how much wiggle room you think is appropriate. A good starting point is +/-10% of the already-agreed timescales.
They might want to set a lower figure for budget tolerances: project sponsors in my experience aren’t keen to go 10% over budget and not know about it.
What kinds of tolerance are there on a project?
Positive tolerances (the amount by which you can go over) are the most common.
A positive tolerance is expressed as a positive percentage. It reflects how much more time/money/etc you can incur without having to ask permission to do so.
Negative tolerances are less common, but you can still use them. I think the general feeling is who cares if you are significantly under against budget or come in three months early?
Actually, negative tolerances are just as important. Coming in under budget means you have tied up company funds unnecessarily for a length of time, and in the current economic climate no sponsor will thank you for that.
That isn’t to say that you should spend company money on random items just to stay within tolerance, but once you drop below your tolerance levels it would be a good time to reforecast your project budget and free up any spare cash that you won’t be using.
The 6 Tolerances in PRINCE2
The two most frequently used tolerances are budget and time, although PRINCE2 offers you a choice of six tolerances: time, cost, scope, risk, quality and benefits.
Let’s look at those individually.
A time tolerance is the amount to which you can be over or under against your project schedule dates.
For example, if the tolerance is 2 weeks you can deliver 2 weeks earlier or 2 weeks later without it having an impact. If you are too early you will have created a problem for another project; too late and you have missed the final deadline.
Cost tolerances are applied as either a percentage or a cash amount against the planned budget.
For example, on a £100k project with a 10% tolerance you can spend up to £110k before having to ask for approval for more spend.
Scope tolerance is slightly odd, because it is a lot harder to quantify a percent variation to scope.
Scope tolerance is measured as an agreed variation from the product description, and any potential variation should be documented in the product breakdown structure.
Think priority listing for scope tolerance. MoSCoW prioritization will give you a list that provides potential for variation in delivery.
Each risk should have an impact attached to it, and risk tolerance in project management covers the aggregate impact of the project’s risk portfolio.
For example, let’s say the financial value of all the project risks should not exceed 5% of the project budget. You can track that and at the point that the financial value of risks is going to exceed 5% you’ll know to escalate the issue. Perhaps the project needs to be taking a less risky approach.
You can also set a tolerance per risk, like ‘only two days of downtime permitted for any operational service’. Risk tolerances give you an idea of which risks you should be escalating to the Project Board.
Quality tolerances are targets that define acceptable quality criteria and performance for a product, and are documented in the product descriptions.
An example would be that a software product must have a response time of between 0 and 0.5 seconds when a user hits ‘Submit’.
It’s hard to think of a scenario where you would want to cap the project benefits, so in my experience this type of tolerance is rarely discussed or used at the positive end of the scale.
You probably will find it useful to have a conversation about how much of the benefit you can lose before the project becomes unfeasible.
Benefit tolerances are defined as a range and will be part of the project’s business case. For example: ‘Achieve minimum savings on the cost of electricity of 6% for each of our shops, averaging 8% across all shops’. You would document that in a benefits management template .
- Have a conversation with your project sponsor during the Project Initiation phase so you know what your acceptable freedom of action zone is.
- Document the tolerances agreed so you have a record.
- Track and monitor project performance against those tolerances so you can escalate when the project looks like it will go out of tolerance for any reason.