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
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
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
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:
Tolerance Range – the acceptable range within which the project manager
(and team) get to operate without outside intervention.
Exception – a breach of tolerance (exit from a tolerance range) that
triggers the escalation process.
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
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
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)