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.
Exceptions in Project Management cannot be made on daily basis, I like the japanese method, they chalk out a plan circulate amongst all the stake holders get their input and draw out a final plan. They keep a tab on the progress and get the job done in an orderly manner.
However, certain exceptions can be made but only in the case of man or machinery but not in material. I have seen PM making exceptions to appease their bosses infact they are cutting corners in quality.
Your assertion that MBE automatically results in a lack of transparency is incorrect. I agree it can be the case and if that were always true then you would indeed be correct in saying that MBE is a bad thing. It is vitally important that the Project Manager is aware and managing all issues, not just those that exceed tolerance. However, the concept of MBE in PRINCE2 is that the project board will only be involved when the project manager is unable to maintain control of the project within tolerance. Their role as a decision-making body will then be utilised to decide which of the options contained within the exception report is the correct one for the project.
I do agree that there needs to be a mechanism for monitoring trends that will take a project out of tolerance before it actually happens but this is part of standard risk and issue management so is not inconsistent with MBE.
I’m sure MBE is not the governance framework for all organisations and situations and inappropriate use may perhaps be “dangerous” but I think it is unwise to consign it to the dustbin as a bad practice. The UK Government spent rather a lot of time, effort and money on establishing why projects fail and proposing a framework to help prevent this from happening so it would be odd if they came up with a totally flawed concept, especially as so many organisations have adopted it and achieved improved project management governance as a result.
Geoff – my assertion is not incorrect, especially as I do not say that MBE “automatically” results in non-disclosure. What I am saying though, is that when you see the evidence of common human behaviour (when MBE is being used), it very often does. This (whole blog) is a real-world discussion; not the theory proposed in Prince2 training. It is based on real hard evidence where at best, bad news emerges slowly and at worst it is suppressed from any Governance process altogether. Neither do I say that MBE is a bad thing. What I do say is that it is very dangerous and results in the exact opposite of what you want in projects, which is early disclosure of bad news and risks.
As to your comments on the UK Government, I have personally worked with almost every major Government department around projects, and the culture there is the worst I have encountered and is firmly reflected in Prince2 to this day. To use this as a benchmark is a very low bar to set. Their performance and track record regarding the delivery of projects speaks for itself.