Why “Management by Exception” is dangerous on projects

In principle it appears fine, in practice, it can be very destructive:

One thing we need to be clear on at the start. We are not advocating that Project Managers sit on the shoulders of team members every day so that they see progress and issues. Some will refer to that as micromanagement. At the same time, we are referring to a working environment that uses and encourages practices that highlight issues, risks and progress as early and as quickly as possible.

It suppresses early disclosure of bad news

Some project management methods encourage ‘management by exception’ (MBE).  The term can mean many things to many people, but in a project environment, this can lead to both culture and practice where information on issues and performance is slow to emerge. Even hidden at times (and yes we are saying that information is deliberately withheld, as we describe later in this post.)

Why it never suits a project environment:

So, moving back to MBE – how does this work?  Management by exception typically ‘expects’ process performance to be normal, and only exceptions need to be highlighted and reported etc.  This applies to any form of steady-state operation, but, the question has to be asked, how can this be relevant and appropriate for a project environment? Projects could not be more different to ‘normal’.  At the highest levels of a project (around reporting etc), there may be a focus on top issues, top risks etc, but applying that principle all the way down the project structure is a major mistake.

Projects are about the future, developing something new, and even discovery at times. We have to expect bad and good news and be ready to handle both.

And let’s look at the real consequences of tolerance:

Management by exception is often combined with the concept of tolerance in relation to the plan. Firstly, the concept of tolerance has some place, for example if a Purchase Order comes in fractions over its estimated value, there should be flexibility or ‘tolerance’ in the management processes to accommodate this, with the minimum of fuss.  However, applying the principle of tolerance across the whole project, often leading to the use of ‘thresholds’, can be very dangerous.  It can even lead to behaviours where data is manipulated (yes we have witnessed this first-hand on many occasions and across dozens of projects) so that team members stay just the right side of the tolerance line, and avoid unwanted attention from ‘on high’.  In the UK, certain industries suffer from this in particular, leading to an absence of real data and information on a project, until it is too late to reverse or mitigate what is by then set in stone.

In some methods exceeding tolerance is called an “exception”, and when this occurs it is formally reported or flagged up, sometimes to higher levels for decision-making.  Some might say, a little late.  Some might also say, this can result in a very slow process, at a time when the opposite is required. Furthermore, stating that senior people only need to get involved when an ‘exception’ has already happened, is nonsense – unless you are happy with a very slow development environment.

Tolerance is perfectly suitable for measuring and managing process performance where a process is mature and stable, such as in Manufacturing.  The nature of projects could not be more different and hence using ‘tolerance’ can be very destructive.  Even in a well-planned project, we must expect there to be issues, regularly.  Our willingness and ability to deal with these make the biggest difference to the final project outcome.  When projects go wrong, they can and do so in spectacular fashion, even bringing down a whole business from time to time.

So what should we have?

Projects are successful when project management is evident in the daily practices of project teams so that Project Managers and others have a clear (and early) view of progress, risk and issues.

When there are significant issues on a project, Project Managers must want to know as soon as possible, giving them the maximum chance to mitigate the impact on the project’s goals. All of them, not just the technical solution.

Projects are delivered well (and by this statement, we mean the whole project scope, not 65% of it), and have some chance of being delivered on time and within budget, when:

• There is a good plan in place and people are working as a team.
• There is complete transparency around progress, issues risks – the good the bad and especially the ugly.
• The whole team is constantly aware of goals and performance in relation to the plan throughout the project life cycle.
• The project manager and team are very aware of this information and act upon it swiftly and effectively, and interaction with stakeholders and sponsors happens whenever required.

Our next post will cover how to do this and avoid other common pitfalls.