
When a project is cancelled, tell the team which work must still be closed
Cancelling a project does not automatically close its orders, access and obligations. Give the team a short, explicit plan for the remaining work.

Cancelling a project does not automatically close its orders, access and obligations. Give the team a short, explicit plan for the remaining work.

Define when a project issue needs escalation, who receives it and what information helps them make a decision.

Identify project dependencies by naming the input, owner and acceptance condition, then distinguish them from ordinary tasks that can proceed independently.

Use a meeting parking lot to preserve off-agenda questions with an owner and review route, instead of letting deferred issues disappear after the call.

Prevent two teams from owning the same live queue by agreeing a cutover time, a shared work list and a route for late updates.

Calling a decision reversible is useful only when the team knows how to reverse it. Define the scope, review point and exit cost before experimenting.

Use leading indicators to examine activities that may influence results, while keeping the actual outcome visible and avoiding easy-to-game targets.

Use a premortem to surface specific project risks, then turn the useful concerns into owners, early signals and practical responses.

Span of control counts direct reports, but team complexity and management duties determine what that count demands from a leader.