Your Project Is Already Delayed — You Just Don't Know Which Dependency Will Prove It

You are a project manager helping build a dependency register for a complex IT program.

Below is the task list for our cloud migration program (8 teams, Azure target platform).
[paste your task list — Jira export, spreadsheet rows, or plain bullet points]

For each task:
1. Identify any other tasks it is likely dependent on (predecessors)
2. Identify any tasks that are likely dependent on it (successors)
3. Flag any tasks that share a resource, infrastructure layer, or data entity with another task
   — even if the dependency is not explicitly stated

Output format:
- Dependency register table: Task | Depends On | Blocking | Shared Resource/Risk
- Highlight (bold) any cross-team dependencies — where predecessor and successor belong
  to different teams
- Flag the top 5 highest-risk dependencies: longest lead time or widest blast radius
  if delayed

You are a program manager reviewing task descriptions from 8 teams in a cloud migration program.

Below are the task titles and descriptions from each team's backlog:
[paste the task list with team labels — e.g., "TEAM: Data Engineering | TASK: Pipeline readiness
validation | DESC: Ensure ETL pipelines are validated against production data volumes before cutover"]

Your job:
1. Identify pairs of tasks from DIFFERENT teams that appear to reference the same
   deliverable, resource, or milestone — even if described using different terminology
2. For each identified overlap: explain the likely shared dependency, and suggest which
   team should own the coordination checkpoint
3. Flag any task where the description implies a handoff (e.g., "once X is ready",
   "after the Y team completes", "pending Z approval") — list these as informal
   dependencies that should be formalized

Output: table with columns — Team A Task | Team B Task | Likely Overlap | Recommended Action

You are a project coordinator helping maintain a RAID log for an 8-team cloud migration program.

Here are this week's meeting notes and team status updates:
[paste raw notes — can be messy, transcription, or bullet points]

Extract all dependency-relevant information and update the Dependencies register:

For each dependency identified:
- Dependency ID (auto-assign: DEP-001, DEP-002...)
- Description: what is dependent on what
- Owner team (who needs to deliver) and Dependent team (who is waiting)
- Agreed handoff date
- Current status: On Track / At Risk / Blocked
- Required action: what needs to happen this week to keep it on track

Also flag:
- Any dependency where the handoff date is within 2 weeks and status is uncertain
- Any dependency that was mentioned last week but has not progressed

Output: updated RAID log — Dependencies tab, markdown table format.

You are a project risk analyst helping assess the impact of a scope change on a cloud migration program.

Current dependency register:
[paste your dependency register from Step 1 — or a summary of the top 10 dependencies]

Scope change: [describe the change — e.g., "The security team's network segmentation
milestone has been pushed 3 weeks due to a vendor delay"]

Analyze:
1. Which tasks in the dependency chain are directly blocked by this change?
2. Which teams are affected and what is the earliest realistic impact on their timelines?
3. What is the revised critical path — which sequence of tasks now determines the
   project end date?
4. What mitigation options exist? (parallel work, fast-tracking, scope reduction)
5. What decisions does the program manager need to make in the next 48 hours?

Output: impact brief, max 1 page. Ready to share with the steering committee.

You are a program manager running a handoff readiness check before the start of Phase 2
(Integration & Testing) of a cloud migration program.

Dependencies that should be resolved before Phase 2 begins:
[paste the predecessor list from your dependency register — what Phase 1 must deliver
for Phase 2 to start safely]

For each dependency:
1. Is it marked as complete? (yes / no / partial)
2. If partial or incomplete: what is the gap, and is Phase 2 blocked or can it start
   conditionally?
3. What is the risk if Phase 2 starts with this dependency unresolved?
4. What is the minimum "good enough" threshold that allows Phase 2 to proceed safely?

Output: handoff readiness matrix. Flag any dependency where starting Phase 2 without
resolution would create a HIGH risk to the delivery date. These are the items for the
go/no-go meeting agenda.

You are a senior PM helping create a dependency register for a complex IT program.

Task list (from Jira/spreadsheet export):
[paste your task list]

Build a dependency register:
1. For each task: identify likely predecessors (what must be done before it can start)
2. Cross-team dependencies: highlight any where the blocking task belongs to a different
   team than the dependent task
3. External dependencies: flag any task that depends on a vendor, third party,
   or infrastructure component outside the team's control
4. Risk score each dependency: Low / Medium / High based on lead time and blast radius
5. Recommend the top 3 dependencies the PM should actively manage this week

Format: markdown table. Include a "Dependency Health" summary at the top:
total count, cross-team count, external count, high-risk count.

You are a project risk analyst helping evaluate a change request's dependency impact.

Proposed change: [describe the change in 2–3 sentences]

Current project dependency register:
[paste the relevant section — or the full register if compact]

Analyze:
1. Which existing dependencies does this change affect directly?
2. Does this change introduce new dependencies that don't currently exist?
3. What is the earliest this change could be implemented without disrupting the critical path?
4. What is the "hidden cost" — the coordination work, rework, or re-testing triggered by
   this change beyond the obvious task itself?
5. Your recommendation: approve now / approve with conditions / defer — with one-sentence rationale

Output: 1-page change impact brief. Plain language. Suitable for a sponsor who is
not interested in the technical details, only the schedule and budget implications.

You are a project coordinator synthesizing weekly dependency status from team communications.

Below are this week's relevant messages, Slack threads, and status updates:
[paste the raw communications — names can be anonymized if needed]

For each open dependency in our register:
[list your current open dependencies — DEP-001 through DEP-N with brief descriptions]

1. Identify any update, blocker, or progress indicator mentioned in the communications
   that relates to each dependency
2. Update the status: On Track / At Risk / Blocked / Resolved
3. Extract any action items or commitments made this week relevant to dependencies
4. Flag any dependency where no update was received — these need a direct follow-up

Output: dependency status table (Dependency | Status | Latest Update | Action Required)
+ a short "PM attention required" list of the top 3 items needing immediate follow-up.

You are a scrum master / PM running a pre-sprint dependency clearance check.

Sprint backlog (planned for next sprint):
[list the stories/tasks planned]

Known dependencies (from your RAID log or dependency register):
[paste or summarize relevant open dependencies]

For each story in the sprint backlog:
1. Does it have an open predecessor dependency that is not yet resolved?
2. If yes: is the dependency expected to resolve before the story needs to start
   (sprint day 1–3)?
3. Risk: if the dependency does NOT resolve in time, is the story blocked (cannot start)
   or constrained (can start but cannot complete)?
4. Recommended action for each blocked story: defer to next sprint / accept risk and
   monitor / split the story so the unblocked part can proceed

Output: Sprint Readiness Matrix — Story | Dependency Status | Risk | Recommendation
Include a sprint health summary: how many stories are fully clear vs. at-risk vs. blocked.