Applying Real-World Business Management By Exception
One of the key principles for project management success is ensuring that the PM’s responsibility must be matched by equivalent authority. The PM can’t be made responsible if they don’t have the ‘clout’ to make things happen.
Each individual on the project, and that includes the project manager, must be provided with a clear understanding of the Authority, Responsibility, and Accountability given to them so that their work can be accomplished.
The Solution Lies In Design Of The Project Organization
When designing the Project Team, start with standard roles such as User representative, hardware engineer, and so forth. Sit down and agree with the individual on what responsibilities they will have, and what levels of authority for carrying out their work. Make sure that these balance. Beware of giving someone (especially yourself!) lots of responsibility but not enough authority to carry out their responsibilities.
A useful one-on-one technique I have used in the past to generate quick agreement is to take a flip chart and draw a vertical line down the middle. At the top of the left column write “This is what I expect of You” and on the right-hand column “This is what You can expect of Me”
Do it in any way that feels comfortable (I usually like to do all the writing and let the other person freely give me their thoughts). It’s a contract for working well together.
But here’s the thing.
You MUST also do it for management above you. As the Project Manager, you are responsible for delivering the project on time, at cost, and quality – but senior management has their responsibilities to the project as well. And these need to be agreed.
Here are some examples:
Who ‘owns’ the Business Case – it’s not the Project Manager! Who is responsible for agreeing to the User Requirements and signing acceptance of the project deliverables – it’s not the Project Manager!
Who owns the resources – it’s not the Project Manager! Who has the authority to approve Requests For Change or Off Specifications – it’s not the Project Manager! Who approves all Plans and ‘underwrites’ the project – it’s not the Project Manager!
Also, beware of stakeholders who see themselves as ‘passive customers’. Be clear that if they are to be any part of the approval process within a project, they must become Active Participants. And that means getting involved early and contributing – and having responsibilities!
Each individual within the organization needs to have three key criteria agreed upon. So let me start by nailing down what these mean:
- Authority. The power is granted to a person so that they can make decisions that others are expected to follow. The position or role that a person holds is the usual way that authority is granted.
- Responsibility. The obligation a person has to perform their assignments effectively.
- Accountability. This means that the person is totally answerable for satisfactory completion of a given assignment.
These three attributes are vital if a project and business management is to complete successfully. Oh yes, and don’t forget that the individual chosen should have the commitment and time to carry out their responsibilities!
Starting at the beginning, it must be unrealistic if, after sign-off, the project manager is not allowed to respond to situations. In effect, their hands are tied – how can anyone manage in such as situation?
So the Project Plan is signed off, a budget is agreed upon, and an end date is set. The first mistake senior management make is by stating things such as “I have now approved your plan and I expect you to deliver against it”
So nothing can ever change – the project manager isn’t allowed to react to risks and changes. And of course, the estimates contained within the Plan were perfect, customers never change their minds, problems never occur, the world never changes, and Santa Clause does exist!
But hold on; look on the other side of the coin. Senior Management within the organization is responsible and accountable for some aspects of the business. They are investing in projects to help optimize what they are responsible for. If it was YOUR money – wouldn’t you want to tie the project down?
Luckily there is a middle ground – a way that makes total sense providing organizations are mature enough to use it.
Just suppose that when a Plan was agreed, management gave the project manager some degree of flexibility (in the form of an agreed deviation from the Plan), that management could tolerate. This agreed flexibility would be the PM’s playground that allowed them to do their job.
But what should happen if the PM suddenly forecasts that these deviations will be exceeded? Why of course, they must bring it to the attention of higher management and seek guidance.
But that last paragraph sounds like senior management has abdicated their responsibilities. What I mean is, once the Plan is signed off and the deviation is set – they can disappear off to the golf course until the PM tells them the project is completed.
No, not quite. Senior Management would want a regular report of ACTUAL performance against the plan showing the allowed deviations. It allows them to question and advise the PM should they wish to do so. And they are safe in the knowledge that if, between these regular reports, the PM forecasts a significant deviation, it will be immediately brought to their attention.
Management By Exception
Welcome to Management By Exception. Vital to organizational business management within the project AND central to Management By Exception. That’s the principle – time to get specific.
Depending on your business you may use your own cultural names for the various roles that make up a project management team. Here are mine – feel free to change the role titles appropriate to your organization.
The Project Board is appointed to provide authorization and direction, and the project manager (who reports to the Project Board), is responsible for day-to-day management of the project.
Now, on the project board are three roles, the Executive (owns the Business Case, and has the final say in terms of authority), the User Representative role, and the Supplier Representative role.
Project Manager Tolerance
Having approved the Project Plan, the Project Board needs to set an acceptable deviation – this is called Tolerance.
Now, Tolerance can be time, cost, quality, scope, risk, benefit, in fact, any suitable metric. As a simple example, let’s assume Tolerance figures are given as plus/minus 10% deviation of the budget and project end date.
What this means is that the project manager can manage in the normal way with the AUTHORITY to take any appropriate management action AS LONG AS TOLERANCE IS NOT FORECAST TO BE EXCEEDED.
At the time of the Plan being approved, this Tolerance is set, along with the regularity of reports and their contents from the project manager.
Okay, let’s imagine we are partway through the project, and to our horror, we see that the project is forecast to come in 15% over budget. This triggers the exception process, and the project manager must escalate the situation to the next higher level within the management organization – the Project Board.
Notice that we don’t wait until the deviation has actually happened, because it will be too late for proactive actions to be taken. The Project Manager will inform the board by an Exception Report (this could be given verbally – but I would want it in writing!)
The Exception Report
The Exception Report will contain the following information:
- A description of the cause of forecast deviation from Tolerance.
- The impact or consequences of the deviation
- Available Options to minimize the deviation or remove it completely
- The impact or effect of EACH option on the Business Case, Risks, and Tolerances
- A Recommendation with reasons, for the best option to take
This is sent to the project Board which needs to make a decision on one of the options. Note that one of the options could be to shut the project down prematurely.
The project board level of the organization, will now ask the project manager to draft a new Plan based on the chosen option and this is reviewed by them. A decision is made to approve the new plan (called an Exception Plan), or again prematurely close the project.
Once approved, new Tolerances are set and the project proceeds under the new plan.
Final Thoughts.
Unfortunately, upper management within the project organization, is often suspicious that the project manager may use Tolerance as ‘code’ for padding – and as a safety net for poor estimates and re-work.
But they have missed the point. It is there to give the PM enough authority to carry out their responsibilities. So the tendency to start with, is the Project Board set VERY tight tolerances – with the consequence of the project manager forever raising Exception Reports to bring small deviations to their attention.
Experienced Project Boards (in particular the Executive), will know that Tolerance should be tied back and based on the Business Case. The Executive should ask themselves “What level of Tolerance can I TOLERATE before being bought into the loop and will this level of Tolerance deviation still keep the Business Case VIABLE”.
Remember also, that a Business case should be ‘viable’ (the cost and risks are worth the benefits?), ‘desirable’ (should we/must we do this?), and ‘achievable’ (can we do this?)
Want to know more? Hop on over to my PRINCE2 Masterclass