Welcome to this year’s feature spot. Each month I will have an insight into the world of PRINCE2 – news, opinion or, like today, a spotlight on a particular aspect of the methodology.
Tolerances are a key part of being able to work autonomously as a project manager. 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.
A tolerance is a performance range to which you will keep. Positive tolerances (the amount by which you can go over) are the most common. 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 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 completion 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 % 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 prioritisation will give you a list that provides potential for variation in delivery.
Each risk should have an impact attached to it, and risk tolerance covers the aggregate impact of the project’s risk portfolio. For example, financial value of all the project risks should not exceed 5% of the project budget. 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 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 normally benefit tolerances are set to the lowest levels. 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’.
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.