Inter-Project Dependency Register Template – Free Word Download

Introduction to the Inter-Project Dependency Register

In the solitary world of a single project, the Project Manager is king. They control the resources, the schedule, and the scope. However, in the interconnected world of a Program or Portfolio, the Project Manager is merely a node in a network. The success of one project is inextricably linked to the delivery of another. These links are called dependencies. If they are not managed with forensic precision, they become the fault lines along which the entire program will fracture.

The Inter-Project Dependency Register is the specific artifact used to track these “handshakes” between projects. While the previous template (Program Dependency Identification) focused on the high-level philosophy and discovery process, this template is the tactical execution log. It is the database, spreadsheet, or system record that holds the “Truth” about who owes what to whom, and when it is due.

Many programs fail because they track dependencies loosely. They rely on email threads, hallway conversations, or vague mentions in meeting minutes. This approach is catastrophic. When a critical date slips, the receiving project manager often claims they were not informed, while the providing project manager claims they sent an email three weeks ago. The Inter-Project Dependency Register eliminates this “he said, she said” ambiguity. It serves as the single source of truth. It records the agreement, the date, the owner, and the status of every cross-project interaction.

This template is designed to help you construct a robust, audit-proof register. It defines the specific data fields required to track dependencies effectively. It establishes the “rules of the road” for how dates are negotiated and updated. It ensures that every dependency has two parents: a Provider (who gives) and a Receiver (who gets). By completing and maintaining this register, you are building the central nervous system of your program, ensuring that signals about delays or risks are transmitted instantly to the people who need to react.

Section 1: Register Architecture and Metadata

1.1 The Philosophy of Data Granularity

The first step in creating your register is defining the columns. If you have too few columns, you lack the data to make decisions. If you have too many, the register becomes a burden that no one updates. You must find the balance that allows for “Management by Exception.”

Guidance for Completion:

Do not simply open a blank spreadsheet and start typing. You must structure your data types. Decisions made here will determine your ability to filter and report later. For example, will you use specific dates (12/10/2023) or broad windows (Q4 2023)? (Recommendation: Always use specific dates for tracking).

1.2 Core Data Columns

Your register must contain the following mandatory fields to be functional.

1. Unique ID (Key Identifier)

Every dependency needs a number (e.g., DEP-001). This allows you to reference it in Risk Registers, Issue Logs, and Change Requests without re-typing the description.

• Guidance: Use a smart numbering convention if helpful, such as “DEP-PROJ-A-001” to indicate the source project.

2. Dependency Description (The “What”)

This must be detailed. “API Delivery” is insufficient.

• Drafting Rule: “The description must define the deliverable and the acceptance criteria. Example: ‘Customer Database API (v2.0) released to the Staging Environment with Swagger documentation included.'”

3. The Provider (The “Give”)

Who is doing the work?

• Project Name: [Name]
• Owner: [Name of the specific PM or Lead responsible].
• Guidance: Do not accept “IT Department” as an owner. You need a specific human being who can be held accountable.

4. The Receiver (The “Get”)

Who is waiting for the work?

• Project Name: [Name]
• Owner: [Name of the specific PM or Lead].

5. Dependency Type

Classify the nature of the link.

• Technical: Code, Hardware, Infrastructure.
• Resource: A specific person moving from Project A to Project B.
• Business: A decision, approval, or business process change.

Section 2: Date Management and Variance Analysis

2.1 The “Three Dates” Rule

A common mistake is to have a single column called “Date.” This hides the risk. To manage dependencies effectively, you need three distinct date columns.

1. Required Date (The Need)

This is the date the Receiver needs the item to avoid delaying their own project.

• Context: This is driven by the Receiver’s schedule.

2. Agreed/Committed Date (The Promise)

This is the date the Provider has promised to deliver.

• Context: This is driven by the Provider’s schedule.

3. Forecast Date (The Reality)

This is the date we currently think it will happen, based on the latest progress.

• Context: This changes weekly based on reality.

Guidance for Completion:

Create a calculated column called “Variance” or “Gap.”

• Formula: Required Date minus Forecast Date.
• Interpretation: If the result is negative, you have a problem. The Receiver will get the item later than they need it. This automatic calculation allows you to sort the register by “Risk” instantly.

2.2 Handling Float and buffers

Sometimes the Receiver needs it on Monday, but the Provider can’t give it until Friday. Does this break the project? Not always.

The “Slack” Column:

Include a column for “Receiver Slack.” This indicates how long the Receiver can wait before the delay hits their Critical Path.

• Example: “The Required Date is Jan 1st. The Committed Date is Jan 10th. However, the Receiver has 2 weeks of slack in their testing phase. Therefore, the status is Green, despite the gap.”

Drafting Text:

“All dependencies must explicitly document the ‘Impact Logic.’ If the dependency is late, does it delay the Go-Live immediately (Critical Path), or does it simply eat into a buffer? This distinction prevents false alarms.”

Section 3: Status and Health Indicators

3.1 RAG Status Definitions

You must define what Red, Amber, and Green mean in the context of a dependency. Ambiguity here causes arguments.

Standard Definitions:

• Green: The Forecast Date is equal to or earlier than the Required Date. (Or within the allowable Slack).
• Amber: The Forecast Date is slipping. It is close to the Required Date, but still achievable. Management attention is needed to prevent a breach.
• Red: The Forecast Date is later than the Required Date (plus Slack). The Receiver’s project is now officially delayed/impacted. Escalation is required.
• Blue/Completed: The handshake is done. The deliverable has been accepted by the Receiver.

Guidance:

“Do not use ‘Grey’ or ‘Unknown’ status. If a dependency status is unknown, it is effectively a risk. Mark it as Amber until the data is clarified.”

3.2 The “Handshake” Status

Before a dependency is active, it must be agreed upon. You can track this lifecycle state.

Lifecycle States:

1. Proposed: Receiver has asked for it, but Provider has not agreed.
2. Accepted: Provider has agreed to the scope and date. (Contract is signed).
3. Active: Work is in progress.
4. Delivered: Provider says it is done.
5. Closed: Receiver confirms it works.

Tip:

Many dependencies get stuck in “Delivered” but not “Closed” because the Receiver hasn’t tested it yet. This leaves the Provider on the hook. Enforce a rule: “Auto-close after 5 days if no objection is raised.”

Section 4: Logical Relationships and Constraints

4.1 Dependency Logic (Predecessors/Successors)

While usually tracked in the scheduling software (MS Project/Primavera), it is helpful to note the logic type in the register for non-technical stakeholders.

The Four Types:

• Finish-to-Start (FS): Project A must finish before Project B starts. (90% of cases).
• Start-to-Start (SS): Project A must start before Project B starts. (Parallel alignment).
• Finish-to-Finish (FF): Project B cannot finish until Project A finishes.
• Start-to-Finish (SF): Rare and usually best avoided.

Drafting Guidance:

“For the purpose of this register, we assume a Finish-to-Start relationship unless explicitly noted otherwise. This means the ‘Provider’ must complete their task 100% before the ‘Receiver’ can consume the output.”

4.2 Hard vs. Soft Dependencies

Include a column to indicate if the dependency is mandatory or discretionary.

• Hard: Physical or Technical constraint. (e.g., Cannot install software without hardware).
• Soft: Preferential constraint. (e.g., Prefer to have the training manual written before training starts, but could do it with draft notes).

Why track this?

When the program is in trouble, Soft dependencies are the first things you “break” or de-scope to save the schedule. Knowing which ones are soft allows for rapid replanning.

Section 5: Impact Assessment fields

5.1 The “So What?” Column

If dependency DEP-001 fails, what happens? The register needs a narrative field for Impact.

Drafting Text:

“Impact Description: If the Security Audit (Provider) is not completed by Nov 15th, the Go-Live (Receiver) cannot proceed due to regulatory compliance. This will result in a minimum 2-week delay to market and a $50k penalty.”

5.2 The Mitigation Plan

Don’t just list the problem; list the Plan B.

Example Entries:

• Plan A: Provider delivers on time.
• Plan B (Mitigation): If Provider is late, Receiver will use a “Mock Service” or “Stubbed Data” to continue testing, accepting a lower quality assurance level until the real data arrives.

Guidance:

“Every ‘Red’ or ‘Amber’ dependency must have a populated Mitigation Plan field. A status of Red without a plan is not a status report; it is a cry for help.”

Section 6: Governance and Update Cadence

6.1 The Weekly Handshake Meeting

A register that is not updated is dead. You need a ritual to keep it alive.

The Protocol:

“The Program Management Office (PMO) hosts a weekly ‘Dependency Sync’ call. Attendance is mandatory for all Project Managers. During this call, we review all dependencies due in the next 30 days (The Lookahead).”

The Rules of Engagement:

1. Provider Updates: The Provider owns the Forecast Date. The Receiver cannot change the Provider’s date.
2. Receiver Updates: The Receiver owns the Required Date. The Provider cannot tell the Receiver when they need it.
3. Conflict: If Provider Date > Receiver Date, a conflict is flagged.

6.2 Change Control

What happens if the Provider wants to move the date?

Strict Governance Rule:

“A Provider cannot unilaterally change a Committed Date in the register if it negatively impacts the Receiver. This action requires a formal Change Request (CR). The register will show the ‘Baseline Date’ (original promise) and ‘Forecast Date’ (new reality) to highlight the slippage. The Variance must be explained.”

Section 7: Visualizing the Register

7.1 The Swimlane View

While the register is a table, it is often best presented visually.

Description of Visualization:

Imagine a chart where the X-axis is Time.

• Row 1: Project A (Provider).
• Row 2: Project B (Receiver).
• The Line: An arrow acts as the dependency line connecting a milestone in Row 1 to a milestone in Row 2.
• Color: The arrow is colored Red, Amber, or Green based on the status in the register.

Drafting Text:

“For the Monthly Executive Board, the detailed register (Excel) will be converted into a ‘Program Dependency Map’ (Visio/PowerPoint). This high-level view only shows ‘Critical’ dependencies that cross major workstreams.”

7.2 The N-Squared Matrix

For complex programs, use a grid.

Structure:

• List Projects 1-10 on the Y Axis (Givers).
• List Projects 1-10 on the X Axis (Receivers).
• The intersection shows the count of dependencies.
• Analysis: If Project 4 has 50 dependencies flowing out to other projects, Project 4 is a “Critical Node.” If Project 4 fails, half the program collapses. This helps focus management attention.

Section 8: Quality Assurance and Auditing

8.1 The “Orphan” Check

Regularly scan the register for logic errors.

Common Errors to Fix:

1. The Orphan Give: A Provider is building something, but no Receiver Project is listed. Action: Check if this is actually needed. If not, de-scope it.
2. The Orphan Get: A Receiver is waiting for something, but no Provider is assigned. Action: This is a critical risk. Find an owner immediately.
3. The Past Due: The date is in the past, but the status is still “Active.” Action: Update the status to Delivered or Late.

8.2 Data Integrity Rules

Set rules for data entry.

Guidance:

“All descriptions must be intelligible to a stranger. Do not use acronyms that are specific to one team. Do not use ‘TBC’ (To Be Confirmed) in date fields for active dependencies. If a date is TBC, the dependency is still in the ‘Proposed’ state.”

Section 9: The Dependency Register Template Structure

9.1 The Master Table Columns

This section provides the exact layout for the user to copy into Excel or SharePoint.

Column	Description	Owner
ID	Unique Identifier (e.g., DEP-001)	PMO
Status	Red / Amber / Green / Blue (Complete)	PMO
State	Proposed / Agreed / Active / Closed	PMO
Description	Detailed definition of the deliverable (Input/Output)	Receiver
Provider Project	The project doing the work	Provider PM
Receiver Project	The project needing the work	Receiver PM
Receiver Milestone	The milestone that requires this input	Receiver PM
Required Date	When the Receiver needs it	Receiver PM
Committed Date	When the Provider promised it	Provider PM
Forecast Date	When it is currently expected	Provider PM
Variance	Committed Date minus Forecast Date (Days)	Calculated
Slack/Buffer	Days of float available before impact	Receiver PM
Impact	Consequence of failure (Time/Cost/Scope)	Receiver PM
Mitigation	Plan B if the date is missed	Both
Comments	Recent updates and context	Both

Conclusion – Inter-Project Dependency Register Template – Free Word Download

The Inter-Project Dependency Register is the unsung hero of program management. It is a document that requires discipline, honesty, and constant maintenance. It is the place where the optimistic plans of individual project managers collide with the messy reality of shared resources and integrated timelines.

By completing this template, you are creating a “Contract of Cooperation” between your project teams. You are moving from a culture of vague assurances (“I’ll get that to you soon”) to a culture of specific commitments (“I will deliver v1.2 on Tuesday the 14th”). This clarity reduces stress. When everyone knows exactly what is expected of them and when, the team can focus on execution rather than politics.

Remember that the register is only a tool. Its value comes from the conversations it triggers. If you see a dependency turning Red, do not just update the spreadsheet; pick up the phone. Use the data in this register to facilitate the difficult but necessary conversations about prioritization, resource allocation, and scope trade-offs.

Ultimately, a well-maintained Dependency Register is an insurance policy. It ensures that when one part of the program shakes, the rest of the program doesn’t collapse, because the connections are visible, measured, and managed.

---

Meta Description:

A detailed Inter-Project Dependency Register template for tracking cross-project deliverables, defining data columns, managing dates, and ensuring program-level alignment and accountability.

---

Discover More great insights at www.pmresourcehub.com