The Execution Phase
Execution is where the calendar goes and where the reputation is made. It is also the phase people describe most vaguely — “we just do the work” — which is exactly why so many projects go quiet for two months and then arrive late with an explanation.
In short
- Execution is a control loop, not a stretch of pure doing: observe, compare to the plan, decide, act, repeat.
- “Percent complete” is self-reported and systematically optimistic. Pair it with something an outsider can verify.
- The project manager’s real output here is decisions and unblocking, not status collection.
- Change is normal. Change without a record is what turns into a dispute at the end.
Execution is a loop, not a stretch
The planning phase produced a set of predictions. Execution is the process of continuously comparing those predictions to what is actually happening, and adjusting one or the other. Four steps, running on a weekly or daily cadence depending on the project:
- Observe. What has actually finished, what is genuinely in progress, what hasn’t started.
- Compare. Against the baseline, not against last week’s mood.
- Decide. Absorb the variance, re-plan, cut scope, add people, or escalate. Doing nothing is also a decision — it just needs to be one.
- Act, and tell people. A decision nobody heard about will be re-litigated next week.
A team that skips step two is busy. A team that skips step three is reporting. Only teams that do all four are managing a project.
The measurement problem
Here is the trap that catches almost every project at least once. Someone asks “how’s it going?”, gets a number, and the number is wrong in a specific, predictable direction.
The blue line is dull, lumpy and honest. It moves only when something is finished and someone other than the person who built it agrees. That is the whole difference: it has an external check.
You don’t need to abandon percentages. You need one measure alongside them that can’t be adjusted by optimism — deliverables accepted, tests passing, environments live, users migrated. Pick whichever is natural for your work, and make sure it appears in the same report.
What a project manager actually does during execution
If the phase feels like chasing people for updates, something has gone wrong — that’s the tool’s job. The scarce, human work is:
Removing blockers
Most delay is waiting, not working: for an approval, an environment, an answer, a review. Waiting is invisible in effort-based reporting and enormous in elapsed time. Ask “what are you waiting on?” before “how far along are you?”
Making decisions quickly
A decision that takes a week to make costs a week regardless of how good it is. Decide at the level you can, escalate the rest immediately, and write down what was decided.
Protecting the team’s attention
Every extra reporting ritual, ad-hoc request and “quick question” is drawn from the same budget as the work. Fewer, better checkpoints beat continuous interruption — see 1.3.
Keeping the outside informed
Stakeholders who hear nothing assume the worst or, worse, assume everything is fine. Regular, boring, honest updates buy credibility you will need on the day you have to deliver bad news.
Change during execution
Something will change. A requirement was misunderstood, a dependency shifted, the market moved. This is not a failure of planning — it’s the discovery the plan existed to enable.
What matters is the shape of the response. A healthy change has four parts, and they take about five minutes:
- What’s changing, in one sentence.
- What it costs — time, money, or something else that now won’t happen. “Free” changes are the expensive ones, because their cost lands on the team silently.
- Who approved it — a name, not a meeting.
- Where it’s recorded, so the baseline and the reality don’t quietly diverge.
Skip the cost line and you get scope creep — a project that grew forty percent through forty small favours, each individually reasonable. 6.2 Issue and Change Management covers the mechanics.
The pitfalls with the highest cost
| Pitfall | Why it happens | What to do instead |
|---|---|---|
| Status meetings that only collect status | The tool isn’t trusted, so people re-read it aloud | Fix the tool; use the meeting for decisions and blockers only |
| Bad news arriving late | Raising problems has felt costly before | Respond to early warnings with help, visibly, the first time |
| Silent absorption | The team quietly works longer to hide a slip | Ask what was given up, not just whether it’s done |
| Working the easy tasks first | They feel productive and show progress | Order by the critical path and by risk, not by comfort |
| Everything in progress at once | Starting feels like helping | Limit work in progress — see 5.2 Kanban Boards |
| No record of decisions | It was obvious at the time | One line per decision, with a date and a name |
The second row deserves emphasis. Whether people bring you problems early is not a personality trait of the team — it is a direct consequence of what happened the last three times somebody did. This is the one lever in execution with an outsized effect on outcomes, and it is entirely in the hands of whoever reacts.
How this looks in AB
Execution is the phase where AB Projects earns its keep:
- Progress → the progress % and status fields on each task roll up to the project dashboard, and the Calendar shows what’s due this week without anyone writing a report. Treat these as the orange line above — useful, but not the whole picture.
- Issues → tasks typed “Bug” or “Issue” sit alongside delivery work, so problems aren’t kept on a separate list nobody updates.
- Communication → Adaptive Cards in the linked Teams or Slack channel announce status changes; mentions ping the right person on the right task; the change-history tab keeps an audit trail without manual logging.
- Decisions → comments live on the task they concern, so the reasoning stays next to the work rather than in a thread nobody can find in month five.
- AI assistance → assistants connected through the MCP server can read open tasks, post comments, change status and create subtasks, which takes routine updates off the critical path of your attention.
One habit worth adding: pick a small set of tasks that represent accepted deliverables — the blue line — and make sure completing them requires someone other than the author to close them. It costs nothing and it’s the difference between a dashboard that reports and one that warns.
Terms used on this page
- Execution
- The phase in which planned work is carried out and steered — observing, comparing to the baseline, deciding and communicating. Usually the longest phase by calendar. More →
- Variance
- The gap between what the plan said and what actually happened, in time, cost or scope. Variance is information, not blame; hiding it is what makes it expensive. More →
- Blocker
- Anything preventing work from continuing that the person doing it cannot resolve alone. Waiting time is invisible in effort-based reporting and huge in elapsed time. More →
- Change request
- A recorded proposal to alter scope, schedule or cost, with its impact stated and someone named to approve it. The mechanism that keeps change from becoming creep. More →
- Scope creep
- Work added after scope was agreed without a matching change to time or budget. Rarely one big addition; usually many small favours nobody costed. More →
- Escalation
- Passing a decision or problem to someone with the authority to resolve it. Fast escalation is a sign of a healthy project, not a failing one. More →
- Work in progress (WIP)
- The number of items started but not finished. High WIP feels productive and finishes nothing; limiting it is one of the cheapest interventions available. More →
Related reading
6.0 Progress Tracking
The full treatment of measuring a project honestly, and reporting it without ceremony.
6.2 Issue and Change Management
How to let a project change without losing track of what it was supposed to be.
5.2 Kanban Boards
Making work in progress visible, and why limiting it makes everything finish sooner.