<!--  
LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

The interdependency register records the relationships between the components
of a program, portfolio, or project, in the specific sense that one cannot
proceed, or cannot proceed on its own dates, until another delivers
something. It is a forward-looking record: it is what tells the reader what
will have to be true before the plan works.

The intent behind separating internal dependencies from external ones is that
they behave differently and are governed by different people. An internal
dependency can usually be renegotiated by asking; an external one often
cannot, and a register that mixes them invites the reader to treat an external
commitment as though it were a request to a colleague.

Alignment: the interdependency register should be aligned and consistent with
the following documents: Portfolio roadmap, Program charter, Project management
plan, Schedule management plan.

Writing guidance:

*   Name the specific deliverable or condition being waited on, not the other
    project. "Waiting for Project B" cannot be actioned when Project B is
    delayed, because nobody knows what to chase; "waiting for the signed data
    migration specification from Project B" can.

*   Record the date the dependency must be satisfied by, which is the
    successor's requirement, rather than the date the predecessor expects to
    deliver. Where the two differ, the gap between them is the risk, and it
    belongs in the register rather than in somebody's memory.

*   Record the dependency type. Finish to Start is the common case, and it is
    the only one that needs no explanation; the other types arise where two
    projects must move together, and without the type a reader cannot tell a
    hard sequencing constraint from a preference.

*   Record who agreed the dependency, and when. A dependency that was assumed
    rather than agreed is the one that will be disputed at the moment it
    becomes inconvenient.

*   Record the status as a value from a fixed set. A free-text status cannot be
    filtered, and a register of forty dependencies that cannot be filtered is
    a document nobody reads when they need to answer a question about one of
    them.

Tailoring Notes:

*   The register may be maintained at portfolio level, covering all
    interdependencies between initiatives, or at program level covering only
    those between components. The form should say which, because the two
    answer different questions.

*   Where the organisation runs a dependency log in a planning tool, the
    register may be an extract rather than the source of truth. If so, record
    that, so a reader does not treat the extract as authoritative.

*   Add or remove rows as needed. Where two projects have a reciprocal
    dependency, record both directions rather than one row with both names, so
    each direction can be tracked and agreed separately.

*   The external dependency section may be maintained separately by a
    procurement or vendor governance function, in which case cross-reference
    it rather than duplicating it.

Column guidance, by column:

Internal dependency rows:

*   **ID:** The identifier for the dependency, used in the change log and in
    reporting so a threatened dependency can be referred to unambiguously.

*   **Predecessor:** The project or component that must deliver first, named
    and identified so the row can be joined to the portfolio roadmap.

*   **Successor:** The project or component that is waiting. Where the same
    predecessor is needed by several successors, record a row for each, because
    the required dates and the impacts differ.

*   **Deliverable or Condition:** What specifically is being waited on, stated
    so that it can be confirmed as delivered or not. A dependency stated as a
    general state of readiness cannot be closed, because no one can say when
    it has been reached.

*   **Dependency Type:** Whether the relationship is Finish to Start, Start to
    Start, Finish to Finish, or Start to Finish.

*   **Required By:** The date by which the successor needs the deliverable.
    This is the successor's requirement, and recording the predecessor's
    forecast here instead hides the gap between the two.

*   **Agreed Date:** The date the predecessor has committed to, so the gap
    against the required date is visible in the register itself.

*   **Status:** Where the dependency currently stands against the fixed set
    used in this register.

*   **Impact if Late:** What happens to the successor if the predecessor misses
    the required date, in schedule, cost, or scope terms. A dependency with no
    stated impact cannot be escalated, because nobody can say what is at risk.

External dependency rows:

*   **ID:** The identifier for the external dependency.

*   **External Party:** The organisation outside the program the dependency
    runs through, named with the role it plays rather than the individual, so
    the row survives a change of contact.

*   **Dependency Description:** What the external party is expected to provide
    or approve, and by when.

*   **Contractual Basis:** Whether the dependency is covered by a contract, a
    memorandum of understanding, or nothing in writing. This is the column
    that decides whether the dependency can be enforced, and a register that
    omits it cannot tell a reader which rows are at risk.

*   **Required By:** The date the program needs it.

*   **Status:** Where the dependency stands against the fixed set.

*   **Owner:** Who is accountable for the relationship with the external party,
    which is normally not the person who needs the deliverable.

Escalation rows:

*   **Dependency ID:** The dependency the escalation concerns, so it can be
    joined back to the register.

*   **Trigger:** What caused the escalation, whether a missed date, a stated
    refusal, or a change on the predecessor's side.

*   **Escalated To:** Who it was escalated to, named rather than described.

*   **Action Agreed:** What was decided, which is what stops the same question
    being escalated again next cycle with no progress.

*   **Date:** When the escalation happened, and when it will next be reviewed.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Portfolio_or_Program_Name}} - {{Governance_ID}}</h2>
<h1 dir="ltr" align="center">INTERDEPENDENCY REGISTER</h1>

| **Date Prepared:** {{Current_Date}} | **Program Manager:** {{Program_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Register Basis
<!-- What this register covers and how current it is meant to be. Record the
 level at which it is maintained, because a portfolio-level register and a
 program-level one answer different questions and are compared against
 different plans. Record the review cycle, because a register nobody refreshes
 is a register that describes a portfolio as it once was. And record whether
 this is the source of truth or an extract from a planning tool, so a reader
 does not treat an extract as authoritative and act on a stale date. -->

**Register Scope and Level:** [ Add details... ]

**Programs or Projects Covered:** [ Add details... ]

**Source of Truth or Extract:** [ Add details... ]

**Review Cycle:** [ Add details... ]

**Register Owner:** [ Add details... ]

**Last Updated:** [ Add details... ]

---

## 2. Internal Interdependencies
<!-- Between projects and components the program controls. Name the specific
 deliverable or condition being waited on, not the other project: "waiting for
 Project B" cannot be chased when Project B slips, because nobody knows what to
 ask for, whereas "waiting for the signed data migration specification from
 Project B" can. Record the required date, which is the successor's
 requirement, alongside the agreed date, so the gap between what is needed and
 what has been promised is visible in the register rather than discovered
 later. Where the same predecessor serves several successors, record a row for
 each, because the required dates and the impacts differ. Add or remove rows as
 needed. -->

| ID | Predecessor | Successor | Deliverable or Condition | Dependency Type | Required By | Agreed Date | Status | Impact if Late |
| :---: | :--- | :--- | :--- | :--- | :--- | :---: | :---: | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 3. External Interdependencies
<!-- On organisations outside the program, which behave differently and are
 governed by different people. The column that matters most here is
 Contractual Basis, because it decides whether the dependency can be enforced:
 a commitment taken in correspondence and a commitment written into a contract
 look identical in every other column and are not remotely the same. Name the
 external party by role rather than by individual, so the row survives a change
 of contact, and record who is accountable for the relationship separately from
 the person who needs the deliverable. Add or remove rows as needed. -->

| ID | External Party | Dependency Description | Contractual Basis | Required By | Status | Owner |
| :---: | :--- | :--- | :--- | :--- | :---: | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 4. Escalations and Agreements
<!-- What has been done about the dependencies that are not holding. Record the
 trigger, so a reader can tell an escalation caused by a missed date from one
 caused by a refusal, because the remedy differs. Record what was agreed,
 since an escalation that concludes nothing is repeated the following cycle
 with the same result. Add or remove rows as needed. -->

| Dependency ID | Trigger | Escalated To | Action Agreed | Date |
| :---: | :--- | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 5. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Program / Portfolio Manager** | {{Program_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Delivery / Component Lead** | {{Delivery_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **PMO Lead** | {{PMO_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> Interdependency Register | <strong>Ref:</strong> PMO-00.03 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-00.03.schema.json",
  "title": "Completed Interdependency Register Data Contract",
  "description": "Additive structural schema validating completed Interdependency Register artifact data payloads (PMO-00.03).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-00.03"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "project_name": {
          "type": "string",
          "minLength": 1
        },
        "project_code": {
          "type": "string"
        },
        "date_prepared": {
          "type": "string",
          "format": "date"
        },
        "project_manager": {
          "type": "string",
          "minLength": 1
        },
        "prepared_by": {
          "type": "string",
          "minLength": 1
        },
        "version": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "draft",
            "baselined",
            "in_review",
            "approved"
          ]
        }
      },
      "required": [
        "project_name",
        "date_prepared",
        "project_manager",
        "prepared_by"
      ]
    },
    "register_basis": {
      "type": "object",
      "properties": {
        "register_scope_and_level": {
          "type": "string",
          "minLength": 1,
          "description": "What this register covers and at what level it is maintained, whether portfolio-wide, program-level, or project-level. The level decides which plan the register is compared against, and a portfolio register read against a project schedule produces conclusions that are true of neither."
        },
        "programs_or_projects_covered": {
          "type": "string",
          "minLength": 1,
          "description": "The programs, projects, or components whose mutual dependencies are recorded, by name and identifier so the list can be joined to the portfolio roadmap. A register that names no components cannot be checked for completeness, and an incomplete register reads as a complete one."
        },
        "source_of_truth_or_extract": {
          "type": "string",
          "minLength": 1,
          "description": "Whether this register is the authoritative record or an extract from a planning tool. Record which, because a reader who treats an extract as authoritative will act on a date that has since moved, and the error is invisible until the dependency is missed."
        },
        "review_cycle": {
          "type": "string",
          "minLength": 1,
          "description": "How often the register is reviewed and by which forum. The cycle is what makes two versions comparable, and a register refreshed on no cycle describes the portfolio as it once was rather than as it is."
        },
        "register_owner": {
          "type": "string",
          "minLength": 1,
          "description": "The single role accountable for the register as a whole, which is normally not the owner of any one dependency in it. Where this is left blank, the register has contributors but no one who notices that a row has gone stale."
        },
        "last_updated": {
          "type": "string",
          "minLength": 1,
          "description": "The date the register was last reviewed, and against which version of the portfolio roadmap. Without it, a reader has no way to tell a current register from an abandoned one, and the two look identical on the page."
        }
      },
      "required": [
        "register_scope_and_level",
        "programs_or_projects_covered",
        "source_of_truth_or_extract",
        "review_cycle",
        "register_owner",
        "last_updated"
      ]
    },
    "internal_interdependencies": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the dependency, used in the escalation section and in reporting so a threatened dependency can be referred to without ambiguity."
        },
        "predecessor": {
          "type": "string",
          "minLength": 1,
          "description": "The project or component that must deliver first, named and identified so the row can be joined to the portfolio roadmap. \"Project B\" is not a predecessor; the component's own identifier is, because that is what survives it being renamed."
        },
        "successor": {
          "type": "string",
          "minLength": 1,
          "description": "The project or component that is waiting. Where the same predecessor is needed by several successors, record a row for each rather than listing them together, because the required dates and the impacts differ and one date cannot serve all of them."
        },
        "deliverable_or_condition": {
          "type": "string",
          "minLength": 1,
          "description": "What specifically is being waited on, stated so that it can be confirmed as delivered or not. \"Waiting for Project B\" cannot be chased when Project B slips, because nobody knows what to ask for; \"waiting for the signed data migration specification from Project B\" can be chased, and can be closed."
        },
        "dependency_type": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the relationship is Finish to Start, Start to Start, Finish to Finish, or Start to Finish. The type determines how much float the successor has, and Finish to Start is the only one needing no explanation; the others arise where two projects must move together and cannot be read from the names alone."
        },
        "required_by": {
          "type": "string",
          "minLength": 1,
          "description": "The date by which the successor needs the deliverable. This is the successor's requirement, and recording the predecessor's forecast here instead hides the gap between what is needed and what has been promised, which is the only figure worth watching."
        },
        "agreed_date": {
          "type": "string",
          "minLength": 1,
          "description": "The date the predecessor has committed to. Kept beside the required date so the gap between the two is visible in the register itself; where the agreed date is later than the required date, that gap is the dependency's risk, and it is usually found out by being overrun rather than by being read."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Where the dependency currently stands against the fixed set agreed for this register, such as On Track, At Risk, Breached, or Agreed. A free-text status cannot be filtered, and a register of forty dependencies that cannot be filtered is a document nobody consults when they need to answer a question about one of them."
        },
        "impact_if_late": {
          "type": "string",
          "minLength": 1,
          "description": "What happens to the successor if the predecessor misses the required date, in schedule, cost, or scope terms. A dependency with no stated impact cannot be escalated, because nobody can say what is at stake, and an escalation that cannot state the stake is usually declined."
        }
      },
      "required": [
        "id",
        "predecessor",
        "successor",
        "deliverable_or_condition",
        "dependency_type",
        "required_by",
        "agreed_date",
        "status",
        "impact_if_late"
      ]
    },
    "external_interdependencies": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the external dependency, so it can be referred to in reporting and joined to any contract or correspondence that covers it."
        },
        "external_party": {
          "type": "string",
          "minLength": 1,
          "description": "The organisation outside the program through which the dependency runs, named by the role it plays rather than by the individual, so the row survives a change of contact and remains readable to someone who has not met them."
        },
        "dependency_description": {
          "type": "string",
          "minLength": 1,
          "description": "What the external party is expected to provide, approve, or decide, and by when. State it as something that can be confirmed as done, since a dependency described as ongoing support cannot be closed and will therefore never show as satisfied."
        },
        "contractual_basis": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the dependency is covered by a contract, a memorandum of understanding, a formal letter, or nothing in writing. This column decides whether the dependency can be enforced, and a commitment taken in correspondence and one written into a contract look identical in every other column while being entirely different in practice."
        },
        "required_by": {
          "type": "string",
          "minLength": 1,
          "description": "The date the program needs this, which for an external dependency is usually a hard commercial or regulatory date rather than a date the program chose. Record where the date comes from, because an external date the program did not set is a date it cannot move."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Where the dependency stands against the fixed set. For external dependencies record separately whether the external party has confirmed it, since the program can know its own position accurately and the other party's only by asking."
        },
        "owner": {
          "type": "string",
          "minLength": 1,
          "description": "Who is accountable for the relationship with the external party, which is normally not the person who needs the deliverable. Separating the two is what stops the urgency of a need being communicated through whoever happens to have the contact."
        }
      },
      "required": [
        "id",
        "external_party",
        "dependency_description",
        "contractual_basis",
        "required_by",
        "status",
        "owner"
      ]
    },
    "escalations_and_agreements": {
      "type": "object",
      "properties": {
        "dependency_id": {
          "type": "string",
          "minLength": 1,
          "description": "The dependency the escalation concerns, so the row can be joined back to the register. An escalation recorded without this reference cannot be traced to the thing it was about, and the next cycle repeats it."
        },
        "trigger": {
          "type": "string",
          "minLength": 1,
          "description": "What caused the escalation: a missed agreed date, an explicit refusal, a change on the predecessor's side, or a commercial dispute. The remedy differs in each case, and an escalation that does not distinguish them tends to produce a general escalation that resolves nothing."
        },
        "escalated_to": {
          "type": "string",
          "minLength": 1,
          "description": "Who it was escalated to, named rather than described, so the reader knows whether the person holds the authority to decide. An escalation to somebody who cannot decide records the disagreement without recording a resolution."
        },
        "action_agreed": {
          "type": "string",
          "minLength": 1,
          "description": "What was decided or agreed, which is what stops the same question being escalated again next cycle with the same outcome. Where nothing was agreed, record that explicitly, because a blank action and an unresolved escalation look identical once the register has been read a few times."
        },
        "date": {
          "type": "string",
          "minLength": 1,
          "description": "When the escalation happened, and where relevant when it will next be reviewed. An escalation without a date has no position in the sequence, and the register becomes a list of grievances rather than a record of decisions."
        }
      },
      "required": [
        "dependency_id",
        "trigger",
        "escalated_to",
        "action_agreed",
        "date"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "register_basis",
    "internal_interdependencies",
    "external_interdependencies",
    "escalations_and_agreements"
  ]
}

{
  "_llm_instructions": "Fill in the 'project_title' and 'date_prepared' properties, and the 'value' property of each field, based on the provided project context. Reference parameters.md for global project variables.",
  "form_name": "Interdependency Register",
  "document_reference": "PMO-00.03",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_Register_Scope_and_Level": {
      "section": "Register Basis",
      "label": "Register Scope and Level",
      "guidance": "What this register covers and at what level it is maintained, whether portfolio-wide, program-level, or project-level. The level decides which plan the register is compared against, and a portfolio register read against a project schedule produces conclusions that are true of neither.",
      "value": ""
    },
    "f02_Programs_or_Projects_Covered": {
      "section": "Register Basis",
      "label": "Programs or Projects Covered",
      "guidance": "The programs, projects, or components whose mutual dependencies are recorded, by name and identifier so the list can be joined to the portfolio roadmap. A register that names no components cannot be checked for completeness, and an incomplete register reads as a complete one.",
      "value": ""
    },
    "f03_Source_of_Truth_or_Extract": {
      "section": "Register Basis",
      "label": "Source of Truth or Extract",
      "guidance": "Whether this register is the authoritative record or an extract from a planning tool. Record which, because a reader who treats an extract as authoritative will act on a date that has since moved, and the error is invisible until the dependency is missed.",
      "value": ""
    },
    "f04_Review_Cycle": {
      "section": "Register Basis",
      "label": "Review Cycle",
      "guidance": "How often the register is reviewed and by which forum. The cycle is what makes two versions comparable, and a register refreshed on no cycle describes the portfolio as it once was rather than as it is.",
      "value": ""
    },
    "f05_Register_Owner": {
      "section": "Register Basis",
      "label": "Register Owner",
      "guidance": "The single role accountable for the register as a whole, which is normally not the owner of any one dependency in it. Where this is left blank, the register has contributors but no one who notices that a row has gone stale.",
      "value": ""
    },
    "f06_Last_Updated": {
      "section": "Register Basis",
      "label": "Last Updated",
      "guidance": "The date the register was last reviewed, and against which version of the portfolio roadmap. Without it, a reader has no way to tell a current register from an abandoned one, and the two look identical on the page.",
      "value": ""
    },
    "f07_ID": {
      "section": "Internal Interdependencies",
      "label": "ID",
      "guidance": "The identifier for the dependency, used in the escalation section and in reporting so a threatened dependency can be referred to without ambiguity.",
      "value": ""
    },
    "f08_Predecessor": {
      "section": "Internal Interdependencies",
      "label": "Predecessor",
      "guidance": "The project or component that must deliver first, named and identified so the row can be joined to the portfolio roadmap. \"Project B\" is not a predecessor; the component's own identifier is, because that is what survives it being renamed.",
      "value": ""
    },
    "f09_Successor": {
      "section": "Internal Interdependencies",
      "label": "Successor",
      "guidance": "The project or component that is waiting. Where the same predecessor is needed by several successors, record a row for each rather than listing them together, because the required dates and the impacts differ and one date cannot serve all of them.",
      "value": ""
    },
    "f10_Deliverable_or_Condition": {
      "section": "Internal Interdependencies",
      "label": "Deliverable or Condition",
      "guidance": "What specifically is being waited on, stated so that it can be confirmed as delivered or not. \"Waiting for Project B\" cannot be chased when Project B slips, because nobody knows what to ask for; \"waiting for the signed data migration specification from Project B\" can be chased, and can be closed.",
      "value": ""
    },
    "f11_Dependency_Type": {
      "section": "Internal Interdependencies",
      "label": "Dependency Type",
      "guidance": "Whether the relationship is Finish to Start, Start to Start, Finish to Finish, or Start to Finish. The type determines how much float the successor has, and Finish to Start is the only one needing no explanation; the others arise where two projects must move together and cannot be read from the names alone.",
      "value": ""
    },
    "f12_Required_By": {
      "section": "Internal Interdependencies",
      "label": "Required By",
      "guidance": "The date by which the successor needs the deliverable. This is the successor's requirement, and recording the predecessor's forecast here instead hides the gap between what is needed and what has been promised, which is the only figure worth watching.",
      "value": ""
    },
    "f13_Agreed_Date": {
      "section": "Internal Interdependencies",
      "label": "Agreed Date",
      "guidance": "The date the predecessor has committed to. Kept beside the required date so the gap between the two is visible in the register itself; where the agreed date is later than the required date, that gap is the dependency's risk, and it is usually found out by being overrun rather than by being read.",
      "value": ""
    },
    "f14_Status": {
      "section": "Internal Interdependencies",
      "label": "Status",
      "guidance": "Where the dependency currently stands against the fixed set agreed for this register, such as On Track, At Risk, Breached, or Agreed. A free-text status cannot be filtered, and a register of forty dependencies that cannot be filtered is a document nobody consults when they need to answer a question about one of them.",
      "value": ""
    },
    "f15_Impact_if_Late": {
      "section": "Internal Interdependencies",
      "label": "Impact if Late",
      "guidance": "What happens to the successor if the predecessor misses the required date, in schedule, cost, or scope terms. A dependency with no stated impact cannot be escalated, because nobody can say what is at stake, and an escalation that cannot state the stake is usually declined.",
      "value": ""
    },
    "f16_ID": {
      "section": "External Interdependencies",
      "label": "ID",
      "guidance": "The identifier for the external dependency, so it can be referred to in reporting and joined to any contract or correspondence that covers it.",
      "value": ""
    },
    "f17_External_Party": {
      "section": "External Interdependencies",
      "label": "External Party",
      "guidance": "The organisation outside the program through which the dependency runs, named by the role it plays rather than by the individual, so the row survives a change of contact and remains readable to someone who has not met them.",
      "value": ""
    },
    "f18_Dependency_Description": {
      "section": "External Interdependencies",
      "label": "Dependency Description",
      "guidance": "What the external party is expected to provide, approve, or decide, and by when. State it as something that can be confirmed as done, since a dependency described as ongoing support cannot be closed and will therefore never show as satisfied.",
      "value": ""
    },
    "f19_Contractual_Basis": {
      "section": "External Interdependencies",
      "label": "Contractual Basis",
      "guidance": "Whether the dependency is covered by a contract, a memorandum of understanding, a formal letter, or nothing in writing. This column decides whether the dependency can be enforced, and a commitment taken in correspondence and one written into a contract look identical in every other column while being entirely different in practice.",
      "value": ""
    },
    "f20_Required_By": {
      "section": "External Interdependencies",
      "label": "Required By",
      "guidance": "The date the program needs this, which for an external dependency is usually a hard commercial or regulatory date rather than a date the program chose. Record where the date comes from, because an external date the program did not set is a date it cannot move.",
      "value": ""
    },
    "f21_Status": {
      "section": "External Interdependencies",
      "label": "Status",
      "guidance": "Where the dependency stands against the fixed set. For external dependencies record separately whether the external party has confirmed it, since the program can know its own position accurately and the other party's only by asking.",
      "value": ""
    },
    "f22_Owner": {
      "section": "External Interdependencies",
      "label": "Owner",
      "guidance": "Who is accountable for the relationship with the external party, which is normally not the person who needs the deliverable. Separating the two is what stops the urgency of a need being communicated through whoever happens to have the contact.",
      "value": ""
    },
    "f23_Dependency_ID": {
      "section": "Escalations and Agreements",
      "label": "Dependency ID",
      "guidance": "The dependency the escalation concerns, so the row can be joined back to the register. An escalation recorded without this reference cannot be traced to the thing it was about, and the next cycle repeats it.",
      "value": ""
    },
    "f24_Trigger": {
      "section": "Escalations and Agreements",
      "label": "Trigger",
      "guidance": "What caused the escalation: a missed agreed date, an explicit refusal, a change on the predecessor's side, or a commercial dispute. The remedy differs in each case, and an escalation that does not distinguish them tends to produce a general escalation that resolves nothing.",
      "value": ""
    },
    "f25_Escalated_To": {
      "section": "Escalations and Agreements",
      "label": "Escalated To",
      "guidance": "Who it was escalated to, named rather than described, so the reader knows whether the person holds the authority to decide. An escalation to somebody who cannot decide records the disagreement without recording a resolution.",
      "value": ""
    },
    "f26_Action_Agreed": {
      "section": "Escalations and Agreements",
      "label": "Action Agreed",
      "guidance": "What was decided or agreed, which is what stops the same question being escalated again next cycle with the same outcome. Where nothing was agreed, record that explicitly, because a blank action and an unresolved escalation look identical once the register has been read a few times.",
      "value": ""
    },
    "f27_Date": {
      "section": "Escalations and Agreements",
      "label": "Date",
      "guidance": "When the escalation happened, and where relevant when it will next be reviewed. An escalation without a date has no position in the sequence, and the register becomes a list of grievances rather than a record of decisions.",
      "value": ""
    }
  }
}