The Multi-Project Conflict Spotter: A Worksheet for Finding Where Two Projects Compete for the Same Week
Published
You're running two active projects at the same time. Both have milestones landing in the next few weeks. At least one person — maybe a developer, a designer, or a key reviewer — is named on both. And right now, you have no single view that shows where the weeks collide.
That's the gap this worksheet fills. In under 20 minutes, you'll map both projects side by side, week by week, and surface the exact points where they compete for the same owner, the same dependency window, or the same slice of someone's capacity.
The result isn't a plan. It's a short list of collision points — the specific weeks where you need to make a scheduling decision before a deadline makes it for you.
Why a side-by-side map catches what a single-project view misses
Most scheduling tools and deadline checklists are built around one project at a time. That works fine when your projects live in completely separate worlds. But when two projects share even one person or one upstream dependency, a single-project view hides the real risk.
The risk isn't that Project A is behind. The risk is that Project A and Project B both need the same person to deliver something in the same week — and neither project's schedule reflects that.
Some practitioner discussions describe exactly this kind of invisible overlap as one of the harder parts of managing multiple concurrent projects. A side-by-side week map makes it visible in a way that two separate status updates rarely will.
Three types of conflict the worksheet is designed to find
Before you fill anything in, it helps to know what you're looking for. Conflicts between concurrent projects tend to fall into one of three categories.
1. Shared-owner conflicts
The same person has a committed deliverable on Project A and a committed deliverable on Project B in the same week. Both project schedules assumed that person was available. Neither schedule accounted for the other project.
2. Overlapping dependency windows
Project B can't move forward until it receives output from a step that is also feeding Project A. If Project A's work takes longer than expected, it delays the shared input — which then delays Project B, even though Project B's own schedule looked fine in isolation.
3. Capacity collisions
No single deliverable looks impossible on its own. But when you add up what a person or a team is expected to produce across both projects in the same week, the total is more than one person or team can reasonably do. The conflict is invisible until you look at both rows at once.
What you need before you start
Gather these four things. The worksheet won't take long, but it's only useful if the inputs are real.
- A list of the next four to six weeks by calendar date
- The key commitments for Project A in each of those weeks — deliverables, reviews, handoffs, or dependency hand-receives
- The same list for Project B
- The name of every person who appears on both project schedules
You don't need a perfect schedule. A rough list of what each project expects to happen each week is enough to start. You can refine as you go.
The five-column worksheet
The worksheet has one row per week and five columns. Here's what each column captures.
- Week: The calendar week, written as a date range (for example, 14 Jul – 18 Jul).
- Project A commitment: What Project A expects to happen or deliver this week. Include the owner's name in brackets.
- Project B commitment: What Project B expects to happen or deliver this week. Include the owner's name in brackets.
- Shared owner or resource: Any person, team, or upstream dependency that appears in both the Project A and Project B columns for this week. If nothing is shared, write "none."
- Conflict signal: A short note on what type of conflict this is — shared owner, overlapping dependency, or capacity collision — and how urgent it feels. Use a simple scale: High (needs a decision this week), Medium (needs a decision before the week arrives), or Low (worth watching but not urgent yet).
A filled example
The two fictional projects below are called Harbour (a product launch) and Ridgeline (an internal platform migration). Both are live. Both share a developer named Priya and a QA reviewer named Tom.
| Week | Harbour commitment | Ridgeline commitment | Shared owner or resource | Conflict signal |
|---|---|---|---|---|
| 14 Jul – 18 Jul | Priya completes API integration; Tom begins QA pass | Priya finalises data migration script; Tom on standby for smoke test | Priya, Tom | High. Shared-owner conflict. Priya has full delivery commitments on both projects in the same week. Tom's QA start on Harbour depends on Priya finishing, but Priya is also committed to Ridgeline. A scheduling decision is needed before this week begins. |
| 21 Jul – 25 Jul | Harbour QA complete; stakeholder sign-off requested | Ridgeline migration dry run; Tom leads review | Tom | High. Capacity collision. Tom is expected to complete Harbour QA and lead the Ridgeline dry run in the same week. If Harbour QA slips from the previous week, both tasks land simultaneously. |
| 28 Jul – 1 Aug | Harbour launch prep; no Priya dependency this week | Ridgeline go/no-go decision requires completed migration report (from external vendor) | External vendor report (shared upstream input) | Medium. Overlapping dependency window. If the vendor report is late, Ridgeline's go/no-go slips. That slip would push Tom's availability back into the week when Harbour needs final sign-off. Worth confirming the vendor delivery date now. |
| 4 Aug – 8 Aug | Harbour launch day | Ridgeline cutover window opens | Priya, Tom, and the on-call support rotation | High. Capacity collision. Both projects reach their highest-stakes moment in the same week. All shared owners are at peak demand simultaneously. This week needs explicit capacity allocation before it arrives, not during it. |
The blank worksheet
Copy this into a spreadsheet, a shared doc, or print it. Fill in one row per week for the next four to six weeks. You only need to complete the Shared owner column and the Conflict signal column for weeks where something actually overlaps — but scan every row before you skip it.
| Week | Project A commitment | Project B commitment | Shared owner or resource | Conflict signal |
|---|---|---|---|---|
What to do with what you find
When you finish, you'll have a short list of weeks marked High, Medium, or Low. Start with the High rows.
For each High conflict, ask one question: What decision, made today, would remove or reduce this collision? That might mean shifting a delivery date, splitting a shared owner's week explicitly between the two projects, or confirming an upstream dependency date before it hardens into an assumption.
You don't need to resolve every conflict right now. The goal is to make each one a conscious choice rather than a surprise.
A few things that can help once you've spotted a collision:
- If a High conflict involves a dependency date you haven't confirmed, the Dependency Timeline Stress-Test walks you through validating that date before you build a schedule around it.
- If the conflict is primarily about one project's deadline risk rather than the cross-project collision, the 30-Minute Deadline Risk Audit gives you a single-project view of where that project is most exposed.
- If the conflict is really about a shared owner's capacity rather than a date overlap, the Capacity-Aware Meeting-to-Execution Worksheet helps you map what that person is actually being asked to produce across their full week.
Running this exercise more than once
The worksheet is designed to be fast enough to repeat. Try running it at the start of each planning cycle, or any time a milestone shifts on either project. A shift on one project can quietly create a new collision on the other — and it won't show up unless you look at both rows together again.
The exercise works best when both project schedules are written down somewhere accessible. If your commitments live in separate documents, separate tools, or separate people's heads, the first step is simply getting them into the same place so you can compare them. Some practitioner discussions about multi-project coordination point to exactly this — the difficulty of comparing schedules that were never designed to be seen side by side.
How Tindlo makes this view continuous
The worksheet approximates something manually: a shared time axis where both projects are visible at once. Tindlo is built around exactly that idea.
Tindlo's multi-layer workspace separates teams, projects, and work types into parallel layers on a shared time axis — Day and Week views — so you can see what's happening across projects without switching between separate schedules. Its Google Calendar integration pulls your existing calendar events into the same view, so meetings, reviews, and external commitments sit alongside project work rather than hiding in a separate tool.
That means the side-by-side comparison you're doing manually in this worksheet becomes something you can see on an ongoing basis, not just when you sit down to run the exercise.
If you're managing two or more concurrent projects and want to try that kind of shared operational view, Tindlo is free to start.