When several projects approach their delivery dates, I would not begin the review by sorting their status colours. I would first look for the people, decisions and assets that more than one project depends on. A shared dependency can make several green rows less secure than they appear.
My proposed review uses a fictional portfolio: an insurance explainer, a mining induction update, an agricultural training series and a construction progress film. These are illustrative coordination examples. They do not imply that I have delivered those engagements or that I hold specialist authority over their subject matter.
The point is to understand how commitments interact. Each project needs its own appropriate reviewers and delivery requirements, but the same editor, camera kit or production slot might support several of them.
I map the shared resources before debating priority
I would list the next meaningful commitment for each project and the dependencies that could prevent it. For the explainer, that might be approved wording from a specialist. For the induction update, it might be access to the current procedure and a qualified subject reviewer. The field-based projects might depend on access windows and usable conditions.
I would then identify the shared resources. If two projects require the same editor on the same day, the conflict should be visible even if the individual task lists both look reasonable. The same applies to a reviewer who appears against several approvals.
I would keep the map small enough to discuss. The first version needs the dependencies that can move a commitment, not every minor relationship in the project history. Detail can be opened when a specific decision requires it.
I distinguish a dependency from an assumption
A confirmed dependency has an owner and enough evidence to explain its status. An assumption may be plausible but unconfirmed. I would show the difference rather than let an assumed access slot look like a booking.
In the fictional agricultural series, I would record that the filming window is provisional until the location contact confirms it. I would identify when that confirmation is needed and who follows it up. The schedule can then show the risk honestly.
For the insurance explainer, I would not treat a previous version's approval as proof that changed wording is accepted. The current asset and its review scope need their own decision. Coordination should make specialist review easier to track, not substitute for it.
I ask what moves if the dependency slips
For each important dependency, I would trace the immediate consequence. If the script decision moves by a day, does recording move too? Can the editor work on another approved asset, or will the delay create idle time followed by an overload?
I would avoid promising a precise new finish date before checking the receiving resource. Moving one task to Thursday does not establish that the editor is available on Thursday. The consequence needs to be tested against the rest of the portfolio.
My review would include a short alternative where practical. If a location becomes unavailable, perhaps an approved screen demonstration can be edited while field filming is rearranged. The alternative still needs to meet the brief; it is not permission to replace required material with something convenient.
I prioritise the decision that protects the next commitment
A project with the nearest headline deadline is not automatically the only priority. Another project may need a decision today to protect a scarce production window next week. I would bring that consequence into the discussion.
I would ask the responsible people to compare the options using agreed criteria: delivery consequences, readiness, contractual commitments where relevant, available capacity and the effect on other work. I would document the chosen sequence and the assumptions behind it.
I would not make this a competition between the loudest stakeholders. A clear dependency map gives the discussion a common basis. It can also reveal that the useful intervention is a small approval or access decision, rather than a wholesale change in project priority.
I limit work that cannot move forward
Starting more work can make a portfolio look active while increasing the number of unfinished items competing for attention. I would check whether a new task can genuinely progress or whether it will simply join a waiting queue.
The Kanban Guide discusses defining the workflow and using measures such as work in progress to support decisions. My portfolio review applies that general concern to a particular fictional set of shared resources; it is not a complete portfolio-management framework. The Kanban Guide.
Where work is waiting, I would identify what can be completed with the capacity available. Finishing an approved asset and recording its handover can be more useful than opening another partially ready task. The appropriate choice depends on the actual commitments, not a universal rule to stop starting work.
I leave the review with a short decision record
The output I want is a small set of agreed actions: the dependency, the owner, the decision or information needed, the consequence of waiting and the next check date. I would update the shared schedule so the decision does not remain only in meeting notes.
I would also record what remains uncertain. If the location or reviewer has not confirmed availability, the portfolio should still show that uncertainty after the meeting. A confident summary is not a substitute for confirmation.
For me, a useful year-end review connects the individual projects to the real resources behind their dates. It makes the next decisions visible and gives the team a credible sequence for the work that remains.
Research and example note
Retrospective series date: 30 October; research cutoff: 2 November 2026. The four sector examples are fictional and make no claims of client delivery, specialist approval or guaranteed outcomes. The actual publication timestamp must remain separate from the series date.
