
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.
Practical notes on leading a team, sharing responsibility and turning a discussion into a decision people can use.
Record the next decision →

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.