Managing Project Execution Without Becoming the Bottleneck
There is a particular kind of busy that tells you a project is being managed badly. The project manager is in back-to-back conversations, every one of them useful, and the work is still waiting. Approvals sit in an inbox. A supplier cannot start because a question asked on Tuesday has not been answered. The team is capable and idle in patches. Nobody is doing anything wrong, and the project has slowed to the speed of one person's calendar.
Managing execution means keeping the work moving and the decisions flowing at the level where they belong. It does not mean being present for each of them. The project manager who is party to every choice has not gained control; they have become the constraint, and the cause is almost never workload. It is that nobody ever wrote down which decisions were theirs.
How the queue forms behind you
Escalation is the default behaviour of a capable team that has not been told where its authority ends. Faced with a choice carrying any consequence, a sensible person checks. Checking is cheap for them and expensive for you, and it accumulates: forty small confirmations a week, none of which needed your judgement, each of which cost somebody half a day of waiting.
The work of steering delivery once it is under way sits at Section 2.1.6 of the PMBOK® Guide as Manage Project Execution, and the word carrying the weight in that title is manage. Coordination, alignment to the agreed approach, dealing with what arrives unplanned: all of it is about keeping a system running, and a system in which one node must touch every transaction is a system with a known throughput problem.
The signal to watch for is not your own workload, which will always be full. It is waiting. Where people are waiting for you more than occasionally, the design is wrong, however hard you are working.
Decision rights, written down
The fix is unglamorous and takes about an hour. Sort the decisions your project actually generates into three groups and tell people which is which.
Decisions you must take are the ones that commit money beyond a stated figure, change a baseline, alter what has been promised to a stakeholder, or carry legal, safety or compliance consequence. Name the figure. A threshold of twenty thousand pounds is a decision right; "significant spend" is an invitation to ask you about everything.
Decisions you must hear about are the ones the team takes and you need to know happened, because they change your picture of the project. A supplier's engineer substituting a component, a sequence changing on site, a test being deferred to the next cycle. The team decides and tells you, and the telling is a line in a log, not a meeting.
Decisions you never need to see are everything else, and the list is longer than most project managers expect. How the work is sequenced within a week. Which tool is used. Who does what inside the team. Handing these back is usually the largest single improvement available to a struggling project.
A university was fitting out a new research building while the faculty it was built for continued operating in the old one. The estates project manager had been running it for five months and was the single point through which everything passed, because the programme touched live research space and she had decided early that she should see anything affecting it. Deliveries were arriving faster than she could confirm where they went, and crated equipment had begun lining the corridors of the building.
What broke the jam was a page. She wrote down that the facilities manager could direct any delivery into any space already handed over, without asking; that she took decisions touching occupied research areas or any spend above fifteen thousand pounds; and that everything else sat with the site team, reported weekly. The corridors cleared in nine days. Her calendar halved. The one decision she had genuinely needed to make all along, about ventilation shutdown windows across the live labs, finally got her attention for an afternoon instead of eleven minutes between other things.
What you actually need to know
Delegating decisions does not delegate accountability, and the way a project manager stays accountable without taking the decisions back is by being deliberate about information. Two kinds are worth having. The first is exception information: the things that have gone outside an agreed boundary, which should reach you quickly and by an agreed route. The second is pattern information: a regular, dull view of flow, spend and quality that lets you notice drift before it becomes an exception.
Anything beyond those two tends to be reassurance, and reassurance has a cost. A daily report that nobody acts on consumes the time of the people producing it and trains you to skim. Where a report exists because it once answered a question that has since been answered permanently, stop it. Judging which controls are load-bearing and which have become habit is a recurring governance call, and a structured PMP exam preparation course puts that proportionality question in front of you in setting after setting.
For a PMP® candidate, the point to hold is that governance exists to make good decisions happen quickly at the right level, scaled to the risk and complexity in front of you. A situation where a project manager is personally approving low-consequence choices is a governance design problem wearing the costume of a workload problem, and the response worth reaching for changes the design.
The check takes a few minutes and is slightly uncomfortable to run. Look back at last week and count the decisions that came to you. For each one, ask what would have happened if you had been unreachable that day. Where the honest answer is that somebody capable would have decided it correctly, that decision did not need you, and the only thing your involvement added was delay. Most project managers doing this for the first time find that between half and two-thirds of their week is recoverable, and that the project moves faster the moment they hand it back.
Interested in going further?
Setting decision rights at the right level, and holding them once a nervous sponsor starts asking to see everything, is a governance skill that rarely gets taught and gets tested on every project. Omega's PMP® Exam Preparation works through delegation, thresholds and escalation as design decisions with consequences you can trace.
Manage Project Execution and the governance processes around it are described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What’s the Difference?
A092: How Projects Create Value Through Governance
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
