Project slippage is almost never sudden. It accumulates in small increments: a missed check-in, a task sitting in “In Progress” for nine days, a dependency nobody followed up on. By the time it surfaces as a crisis, the warning signs were visible for two weeks. A 15-minute weekly review is the practice that catches those signs before they compound.
What to scan: the four-layer check
The review is not a full project audit. It is a scan for four specific signals. Each one points at a different kind of problem and suggests a different response. Run through all four before taking any action.
- At risk. Any project or task where the deadline is within two weeks and the current velocity suggests it will not be ready. Look for tasks that have not moved in four or more days. Look for milestones approaching with dependencies still open.
- Blocked. Work that cannot proceed because something external has not arrived: client assets, a decision, a credential, a sign-off. Blocked tasks should be flagged explicitly, not just sitting in “In Progress” with no activity.
- Due this week. Everything with a due date in the next seven days. Check that each one has an owner and that the owner knows it is due this week.
- Waiting on others. Tasks or decisions you have sent outbound and have not heard back on. These are different from blocked tasks: the ball is in someone else’s court, but they may not know there is a deadline attached.
In a healthy week, the at-risk and blocked layers will be short. When they are long, the review is doing exactly what it is supposed to: surfacing accumulating problems early enough to do something about them.
The three questions to ask of every project
After the scan, ask these three questions for each active project. Not each task. Each project as a whole. This is where judgment enters, beyond what the data shows.
- Is the current week's target achievable? Look at the tasks due this week against what you know about the team’s capacity and any complications that arose last week. If the target is not achievable, it is better to adjust scope now than to report a miss on Friday.
- Is anyone on this project overloaded? Look at the task count per person. A team member with eight due-this-week tasks and one blocked item waiting on their response has a workload problem, not a motivation problem. The review is the place to spot and redistribute this.
- Has anything changed that the client or stakeholder needs to know about? If a timeline is shifting, a deliverable is changing scope, or a dependency is delayed, the client or stakeholder should hear it from you proactively. The review is when you catch these so you can communicate them Monday, not wait until they ask on Thursday.
Who runs it and how to keep it to 15 minutes
The review should be run by the project lead or operations manager, not by everyone simultaneously in a group meeting. A group review of five projects with eight people in the room takes 90 minutes. A solo review of five projects takes 12 minutes.
The group meeting is a status theater. Everyone performs attentiveness for 80 minutes to get 10 minutes of relevant information. Replace it with an async written summary and individual follow-up on the specific issues each person needs to act on.
Here is how to run a solo 15-minute review without it expanding.
- Block the time as a recurring event. Monday morning, 15 minutes, no invite list. Unscheduled reviews get pushed by the first urgent task of the week.
- Open one view, not multiple tabs. Your review surface should show all active projects in one place. If you have to navigate between five different boards, the review takes 40 minutes before you have even started thinking.
- Use a written checklist, not memory. A short review checklist (at-risk, blocked, due this week, waiting on others) keeps the scan consistent. Without a checklist, you will spend 10 minutes on the one noisy project and miss the quiet one that is actually at risk.
- Stop at 15 minutes and log the rest. If you hit 15 minutes and still have notes to take, log them and continue in the next available gap. A 15-minute review that runs to 45 minutes will not be a standing habit.
Turning the review into assigned actions
A review that produces no actions is just an audit. The output of the review should be a short list of specific actions, each with a name and a due date. Not aspirations. Concrete next steps.
| Signal found | Action | Owner |
|---|---|---|
| Task blocked waiting on client asset | Send follow-up email referencing original request date | Account lead, by Monday noon |
| Team member with 9 tasks due this week | Move 3 lower-priority tasks to next week, notify stakeholder | Project lead, by Monday EOD |
| Milestone in 8 days with 3 open dependencies | Check each dependency owner's status, update project forecast | Project lead, by Tuesday |
| Decision waiting 5 days with no response | Escalate to senior contact, set 48-hour response deadline | Account lead, by Monday noon |
The actions list should be shared with the team before 10 a.m. Monday. Not as a formal report. A two-line Slack message per action is enough: “Project X: blocked on logo files from client since Wednesday. I’m following up this morning. If no reply by Wednesday I’ll escalate.” The team knows what is happening, nobody has to ask.
For teams using Studio Craft, actions from the review can be logged directly as tasks on the relevant project, assigned to the right person, and visible to the whole team without a separate communication step.
The async version for distributed teams
If your team spans time zones or works primarily async, the solo review structure works even better. The project lead runs the review at their own Monday morning, then posts a brief async update to the shared channel with the output.
The async update format keeps it readable. One section per project, maximum three lines: current status (on track, at risk, or blocked), the key action this week, and one specific ask if something is needed from the team.
Ask each team member to reply with a thumbs-up or a flag emoji if something they see does not match their understanding. This is not a meeting. It is a shared record that everyone has been briefed. Replies surface discrepancies before Tuesday.
For fully remote teams, a short Loom of the review screen walk (five minutes, not published, just sent to the channel) lets people see the actual board rather than reading a text summary. Video adds context that bullets lose.
Key takeaways
- Scan four signals every week: at risk, blocked, due this week, and waiting on others.
- Ask three questions per project: is this week’s target achievable, is anyone overloaded, and does anything need proactive communication?
- Run the review solo, not in a group meeting. Group status meetings are theater. Solo review plus async summary takes a third of the time.
- Every review produces a short list of actions with names and dates. Actions without owners are noise.
- For async teams, a Monday written or video summary with a flag-or-thumbs system surfaces discrepancies before they become surprises.
Common questions
What if the review consistently finds the same projects at risk every week?
That is a resourcing or scoping problem, not a review problem. The review is correctly identifying a structural issue. The response is not to review more carefully. It is to have a direct conversation about capacity, timeline, or scope.
How do we handle projects that only update once a week and the review happens to fall on a no-update day?
Add a “last updated” timestamp to every project record. If a project has not been touched in more than four days, treat it as a potential risk to check. No update is itself information.
Should the review happen on Monday or Friday?
Monday is preferable for most teams because it sets the week’s actions while there is still time to act. A Friday review is useful for closing out the week but produces actions that often wait until Monday anyway. Run the planning review Monday, and use a two-minute Friday close to mark completions.
What if I manage 20-plus projects? 15 minutes is not enough.
At 20-plus active projects, the review needs tiering. Group projects into tiers: active and client-facing (scan weekly), in-progress but not client-facing (scan every two weeks), and parked (scan monthly). Not every project needs the same review frequency.
