Background and Objective
 

A common requirement in portfolio and program management is to manage dependencies between tasks in otherwise separate projects, referred to as “Inter-Project Dependency Management” (as distinct from “Intra-Project Dependency Management which manages dependencies between tasks within a single project).  NB:  the project with tasks dependent on deliverables from another project is referred to as the “downstream project”, with the project that must provide the deliverable, or “resolve the dependency”, referred to as the “upstream project”.  

The overall objectives of Inter-Project Dependency Management is to:

  1. Prevent delays to the critical path and key milestones of the downstream project, and 
  2. Minimise additional effort required from both the downstream and upstream projects.

Some programs have encountered this requirement, specifically having critical path tasks dependent upon deliverables from projects external to the program itself (referred to collectively herein as “boundary projects”).

The purpose of this document is to describe the method by which these dependencies are managed to protect the program's critical path, without adding unnecessary and duplicated effort on either the program nor boundary project teams.

 

Practice Definition: Inter-Project Dependency Management

 

The Program Management Office(PMO) will initially identify dependencies with upstream boundary projects and include the resultant milestone list in the appropriate location in the program’s integrated workplan.   

Only material dependencies that have a significant schedule impact should be captured and only at WBS level 1 or 2. Capturing boundary project WBS level 3 or greater in the integrated workplan would create unnecessary administrative effort.

PMO will utilize other personnel in conducting this identification including boundary project: project managers (PMs), leadership and PMO team(s).

PMO will:

  • Identify and document in the integrated plan any material dependencies on upstream boundary projects, including the date by which the dependency needs to be satisfied and the critical path impact, if any, if the dependency is not realized
  • Agree the dependency, delivery date, and critical path impact with the upstream PMs PMO and leadership as appropriate.
  • For dependencies with a Medium or High critical path impact, enter and track the dependency as a WBS level 1 or 2 milestone in the integrated program workplan.
  • Obtain periodic updates from upstream PMs on progress to meeting dependency delivery dates, with required frequency depending on critical path impact (higher impact requiring more frequent updates, typically weekly) and proximity to the dependency delivery date (frequency increasing closer to delivery date).    
  • Specifically these updates will include a forecasted delivery date compared to baseline delivery date with any forecasted delays clearly highlighted along with recommended recovery actions to prevent the delay.   NB: the project management methods and tools used by the boundary projects should properly be considered a “black box”, as long as the boundary projects reliably meet these information requirements.
  • In the case of forecasted delays, PMO raises a formal risk with appropriate probability and impact reflecting critical path impact.  
  • As the impacted program, the owner of the risk is the program, specifically the workstream lead(s) impacted by the potential delay), and the risk participants are relevant PM/workstream leads from the upstream project.   I.e The RACI is:
    1. Program is Accountable for the risk, and sometimes also jointly Responsible if mitigation actions require its participation – see below),
    2. Boundary project is Responsible (for the mitigation actions they must enact) and Consulted, 
    3. Program and boundary project leadership are Informed as appropriate.   
  • PMO direct the respective parties to resolve the risk using standard risk management practice, i.e. the respective parties conduct a risk workshop to determine appropriate mitigations, which are then enacted by the due date.  
  • Importantly, the PMO team define and direct the risk management process to be followed however they do not resolve it as per the RACI description above (the operative principle in such cases is “PMO define, project teams execute”).
  • In determining appropriate mitigations the respective parties should consider options in addition to adding extra resources/working hours and/or delaying a milestone date. 
  • This method minimizes effort by not requiring a regular “Dependency Management” meeting involving large numbers of upstream and downstream project members.  The dependency reporting as above identifies any risks to the Program's critical path with only the upstream and downstream personnel specifically involved required to mitigate.
  • The method further minimizes effort by not requiring upstream and downstream teams modify or even have visibility of each other’s detailed workplans.