I learned PRINCE2 twice.
First from the books, while preparing for certification. And then again in real life, through projects and programmes.
The second time was definitely more interesting.
So I thought it might be worth going back to some of the PRINCE2 principles and looking at them not from the certification perspective, but through situations I have experienced during actual project delivery.
Let’s start with Manage by Exception.
For this reflection, I am mainly looking at projects and programmes delivered within one organisation. Vendors, authorities and multi-company delivery add another layer, which I touched on in the previous Field Note.
By the book, Manage by Exception is one of the fundamental principles of PRINCE2. The idea is actually simple and sweet.
We establish clear boundaries between different management levels and give people room to operate within them.
The Project Board gives the Project Manager a mandate to run the project within agreed tolerances. The PM does the same with Team Managers and delivery teams.
As long as we are operating within those boundaries, we manage. When we forecast that we are going outside them, we escalate.
That’s the theory.
But for me there is much more behind this principle than tolerances and escalation procedures.
There is trust.
There is accountability.
And there is something I strongly believe in.
Ownership.
Do you have a plan?
During a large IT programme, one of our senior IT directors asked a PM colleague a simple question:
“Do you have a plan?”
The PM started running through the details. We performed the analysis, went through the Product Breakdown Structure, gathered the estimates, we have done this, we are working on that…
The director stopped him.
“Do you have a plan?”
The PM, probably a little confused by that point, answered:
“Yes.”
“OK. That’s all I wanted to know.”
And that was it.
The story quickly became kind of viral during our PM coffee breaks.
“Do you have a plan?”
We were saying it to each other for quite some time.
Yep, you could make a funny story out of it.
But giving it a second, deeper thought, I think the message from that senior director was actually about Manage by Exception and the PM mandate we had in our organisation.
For me, it was almost the pure essence of this principle.
The real message from the director was something like:
“You have been given the PM mandate and responsibility for running this project to a successful end. I just want to know if you have a plan, if you are in control. I trust your analysis and judgement. And I also trust that if anything starts falling down, you will ring the bell and let me know.”
You have the mandate. I trust you to use it.
Keep me informed, but don’t bring every project detail to my desk. And when something goes beyond the boundaries of your mandate, ring the bell.
For me, this is Manage by Exception in real project life.
PM mandate
I strongly connect Manage by Exception with the PM mandate.
If I am given responsibility for running a project on behalf of the Project Board, I also need enough room to actually run it. Otherwise, what kind of mandate is it?
There are also situations where what some stakeholders really expect is a PM coordinator rather than a self-driven Project Manager.
Someone to do the project administration.
Run the meetings.
Issue the MoM.
Follow up on actions.
But don’t ask too many difficult questions.
Don’t name the elephant in the room.
And simply follow what the most senior stakeholder wants.
A PM can coordinate a lot of things. But a PM should not be reduced to a coordinator.
For me, this is not running a project.
A PM mandate needs to mean something.
If I am accountable for the project outcome, I need enough independence to challenge, ask uncomfortable questions, raise risks and sometimes simply say that things are not going in the right direction.
Of course, the Project Board provides direction and makes decisions within its authority. That is exactly how it should work.
But there is a difference between taking direction from the Project Board and becoming a project administrator who executes instructions.
There is another side to this independence. A PM mandate also needs enough room to tell the organisation something it may not want to hear.
If the project is red, it is red.
Not amber because red is uncomfortable.
Not green because one vertical doesn’t want to explain the problem.
Red.
And if something is happening that is not aligned with the project objectives, company strategy or organisational values, the PM should be entitled to raise the flag.
This is one of the advantages I see in a mature, centralised PMO. A Project Manager can have a mandate that goes across organisational verticals rather than representing one particular technical area or business function.
For the given project or programme, we operate on behalf of the organisation and under the established Project Board. I think that independence is valuable.
And again, it comes back to mandate.
In a mature project organisation there should be no need for senior management to micromanage the project.
Risks will appear. Issues will happen. Something will be delayed. An estimate will change. A dependency will become more complicated than expected.
That’s project life. Not every problem is an exception.
This is where tolerances come into the picture. Time, cost, quality, scope, benefits and risk all give us boundaries within which we can operate. In practical terms, they tell us where the freedom ends.
A deviation does not automatically mean escalation.
If I can manage the situation within my mandate and keep the project or stage within the agreed boundaries, I should manage it.
That’s what I am there for.
And the same logic works across management levels.
What can be handled by the delivery team should stay with the delivery team. What can be handled by the PM should stay with the PM. And what goes beyond the PM’s mandate moves to the Project Board.
But I should also not wait until everything has already fallen apart before informing the Project Board.
If my forecast tells me that I am no longer going to stay within the agreed tolerance, I need to ring the bell.
Not when the tolerance has already been exceeded.
When I can see that it is going to be exceeded.
That distinction is important.
No news is good news
I sometimes think about Manage by Exception as a kind of “no news is good news” arrangement.
Obviously, not literally.
It doesn’t mean disappearing into a project for three months and coming back with:
“Hello, we have a problem.”
The Project Board still needs visibility.
Depending on the project, we may have weekly, bi-weekly or monthly project health reporting. There will be Project Board sessions. There may be Stage Gates.
We present the condition of the project from schedule, scope, budget, quality and risk angles and bring forward topics where Board direction or decisions are needed.
If there is something urgent, we can always call an ad hoc Project Board session. But we don’t need senior management involved in every daily struggle of running the project.
Actually, I see taking those struggles off their shoulders as part of our job.
Senior managers and VPs need to operate at management level, look across multiple initiatives and drive organisational strategy. Their time is precious.
If every project requires constant senior management attention just to keep moving, something is probably wrong with how we are running projects.
The Board needs visibility.
The PM needs room to operate.
And unless something requires a decision from the next management level, the PM runs the project.
There is also trust behind “no news is good news.”
The Project Board needs to be confident that if something really requires their attention, the PM will tell them.
Not next month.
Not when the problem is already out of control.
When their involvement is needed.
We want trust. Do we give it?
There is another side of this principle which I think is easy for us PMs to forget.
We expect our Project Board to trust us. We want a strong PM mandate. We want room to operate.
We definitely don’t want a senior manager sitting behind us and questioning every project decision.
Fair enough.
But are we giving the same freedom to our own teams?
Manage by Exception works on all levels.
The same way the Project Board gives the PM room to manage, we should give Team Managers, workstream leads and delivery teams room to deliver.
Of course proper management, monitoring and follow-ups are still essential parts of our profession.
I am definitely not saying:
“Here is your work package. See you at Go-Live.”
We need visibility. We need accountability. We need to know where delivery is heading.
But we should also build a culture where people take ownership of their deliverables.
The PM owns the project.
The team owns the deliverables.
For me, the PM should act as a project enabler.
Remove blockers. Connect people. Make sure dependencies are understood. Create the best possible environment for the team to do the work.
Challenge when needed. Escalate when needed.
But also let professionals deliver professional products.
If I try to own every deliverable myself, sooner or later I will become the bottleneck.
And if we expect trust from above while micromanaging everything below us, something doesn’t add up.
Ownership
Ownership is something I truly believe in.
Actually, I think it is one of the main reasons we as PMs are hired.
To get things done.
Not necessarily to personally do everything. Not to make every decision. And definitely not to become the bottleneck through which every piece of information needs to flow.
But somebody needs to own the overall outcome.
Somebody needs to care when a dependency between two teams starts leaking.
Somebody needs to notice that each individual deliverable may look fine while the overall project is moving in the wrong direction.
Somebody needs to connect the dots.
That is ownership.
And ownership does not mean that we need to control everything.
The bigger the project or programme becomes, the more important this becomes.
At programme level, I think the level of trust towards the people reporting to you needs to be even higher.
You simply cannot be tied to everything if you want to stay on top of everything.
That sounds a little contradictory.
But I think it is true.
Manage by Exception, not Manage by Surprise
Of course there is a trap here.
Manage by Exception cannot become Manage by Surprise.
Giving people freedom without boundaries is not delegation. It is just lack of control.
If we want somebody to take ownership, they need to understand what they own.
What can they decide themselves?
What are the tolerances?
When do I expect them to inform me?
When do they need my decision?
When does something need to move to another management level?
This needs to be clear.
And then there is forecasting.
For me this is one of the most important practical parts of the principle.
If I tell my Project Board that the budget tolerance was exceeded last month, I am not really managing by exception. I am reporting history.
The value is in seeing where we are heading.
If we forecast that we are going to exceed the agreed boundaries, we raise the exception early enough for the right management level to actually do something about it.
But I also believe that many project issues and changes can, and should, be resolved at the level where they actually happen.
Very often, technical teams from different verticals can work something out between themselves.
They know the subject. They understand the dependencies. And if they have the right mandate, they may be much better placed to find the solution than somebody several management levels above them.
And again, I see the PM role as helping to create goodwill on both sides, find common ground and work it out at team level.
We should aim for win-win cooperation.
Today I am helping you. Tomorrow you may help me.
In this kind of project environment, we are all working for the same organisation to solve problems, not to create arguments around them.
If it can be properly managed there, let them manage it.
The same applies to the PM. If something can be managed within my mandate, I should manage it.
That’s what the mandate is there for.
But when something genuinely moves outside those boundaries, or requires a decision that cannot be made at that level, we need to ring the bell.
For me, good escalation is not about pushing problems upwards. It is about knowing when a problem needs to move to another management level.
Too early and we risk moving normal project management upwards.
Too late and there may be nothing left to manage.
Getting that timing right requires judgement.
The methodology can give us the framework. Experience teaches us how to use it.
Trust, but with boundaries
The more I think about Manage by Exception, the less I see it as an escalation principle.
For me, it is much more about how we build trust into the way a project is managed.
The Project Board gives the PM a mandate. The PM gives the delivery teams room to operate.
Everyone knows what they own. Everyone knows their boundaries. And everyone knows when to ring the bell.
That gives us freedom without losing control.
It gives senior management visibility without pulling them into every project detail. And it gives our teams space to take real ownership of their work.
Which brings me back to that senior IT director.
“Do you have a plan?”
“Yes.”
“OK.”
No request for another deck.
No deep dive into every activity.
No micromanagement.
Just a very simple question from someone who understood where the PM mandate started and when his own involvement was needed.
Looking back, I think that coffee-break story taught me more about Manage by Exception than I realised at the time.
Over and out.