It is well known that teams work best when they are empowered to self-direct and given freedom to self-organize. Yet striking the balance between providing this autonomy with responsible project oversight to ensure things do not go off track can be a tricky proposition. We want to create empowered teams, but we also need to know if the project is going awry and when to intervene. Unlikely as it sounds, but a great source for creating empowered team environments can be found in the prescriptive process of PRINCE2.

Edwards Deming, a major inspiration for Toyota’s lean approach, said there were two classic mistakes a manager can make. The first is intervening when common cause variation occurs. Common cause variation is the natural variance we see in process. For example some three day tasks will take four days to complete and this is just the way things are – common cause variation, managers need to accept the odd instance of this. The second classic manager mistake is not intervening in special cause variation, which is variation that is new, unanticipated, emergent or previously neglected. For example if project scope changes significantly (new and unanticipated) or velocity trends indicate the project will not get done within schedule (emergent).

So what we really want is a protective bubble for the team that insulates them from micro-management and outside interference – like a giant hamster ball, and also some guard rails and an occasional guiding hand to keep the giant hamster ball on track towards the project goals. I realize that picturing high-performing teams as hamster balls sells them short in terms of their intelligence, insight, commitment and dedication, but it fits with my guide rails metaphor. I was going to use the analogy of a state or province governed by its own local laws, but overseen by a government or federal body. It can self manage for most things, but not revolt, declare war on outside groups, or change direction. However my time living in Canada has taught me this metaphor is as likely to upset just as many people so let’s leave it open – a hamster ball run by the hamsters or a state/province governed locally, you choose - to many people they are not that different.

 As project managers we need to establish the boundaries for our team’s independence within which we have control over how we operate (definitions of common cause variation) and the mechanisms for detecting going off track (indicators of special cause variation).  This is where a concept from PRINCE2 can help. When starting a PRINCE2 project we establish Project Tolerances and Exception Processes. These set the boundaries within which the project manager / team can control project variation and what circumstances trigger an exception and escalation to a steering committee or project board.

Tolerances are established at the beginning of the project, agreed with project stakeholders and written into the project charter. They can be created for a variety of metrics such as time, budget, scope, risk, quality and represented as a simple range such as the budget tolerance as shown below:

 

There are three components to the Tolerance / Exception process: 

1. The Tolerance Range – the acceptable range within which the project manager (and team) get to operate without outside intervention.
2. An Exception – a breach of tolerance (exit from a tolerance range) that triggers the escalation process.
3. The Escalation Process – an agreed process that describes who will be contacted and what actions will be taken should an exception (breach of tolerance) occur.

In the figure below we can see that the blue spend line has exceeded the Projected Budget +10% upper tolerance range and so an exception is raised as per the escalation process for this measure.

Tolerances can be also be more subjective such as a sponsor confidence score and tracked, say, monthly or bi-weekly.

For an agile project, all this talk of documentation in a project charter can sound like more procedural overhead than we want to get into. Plus, scope may not be fully defined and so a more emergent process may be suitable for an uncertain project.  Yet we can take the tolerance idea and recast it in a lighter weight version, with appropriate metrics for an agile setting.

While there may be a less formal charter, most projects get launched with some approving document or discussion. Whether this is a project vision document or a kick-off meeting, this is the time to establish the team’s autonomous environment. Then, providing the project is on track (velocity and spend are OK, demo’s are showing progress, business is happy with quality and engagement) the team is empowered to self-organize provided no tolerances are breached or forecast to be breached.

By discussing the bounds of self-governance and describing what would trigger an exception stakeholders are more likely to let the team self-manage safe in the knowledge that provisions for being alerted are in place. The process of discussing tolerances and agreeing the escalation process allows teams to gain autonomy which improves morale, increases performance, and creates a virtuous cycle. As opposed to suspicious oversight that micro manages, leading to demotivated teams, and a self-fulfilling prophecy of skepticism.

Times of issue escalation are not the best moments to establish resolution processes, since people are concerned and emotional. Like having an evacuation plan for a building, if an event occurs when you need to use it, you want it already established rather than having to make it up during a real fire. The same goes for projects, it is much better to have an escalation process in place and then just execute it “We said we would convene a committee meeting if average velocity indicated we would not get all the “Must Have” work done with remaining funds. This is where the current projections show us and the options we have are… ”. This is preferable to having to invent some new process in the midst of a project issue.

Agile tolerances can be created around most observable measures that the project community cares about. They can be internally facing such as defect cycle time, that might trigger some special retrospective focus.

 

Or externally facing such as User Satisfaction that could trigger a steering committee meeting..

The real point is that borrowing a process such as Tolerances, Exceptions and Escalations from PRINCE2 actually creates more freedom for teams to operate. Agile teams spend a lot of effort agreeing on a common definition of “Done”, by spending a little time to build a common understanding of “Concerned” we can all go faster knowing consensus on the definition and resolution process is in place.

Of course it is no silver bullet; on PRINCE2 projects we sometimes call the tolerances how much rope we give the project manager. Too much and they can hang themselves, too little and they are always coming back with approvals for minor adjustments. So, like everything it has to be applied intelligently, yet it can be a useful tool to have in your toolbox when starting up a project and looking to strike that balance between buffering stakeholders from common cause variation and alerting them to special cause variation. Autonomy creates freedom for the team to perform, while tolerances provide assurances to concerned parties who might otherwise be tempted to interfere too much.

(This post first appeared on www.ProjectManagement.com here)