When an organisation is undertaking multiple programs of work, it is common for a project in one program to enable the outcomes in another. Identifying and communicating inter-project dependencies is complicated by the fact that different programs have different delivery teams that rarely have visibility into the projects and schedules of other programs of work. Inter-project dependencies provide a mechanism of visibility, communication and a reporting conduit between two related but logically separated projects. Successful management of inter-project dependencies allows you to avoid delays by taking corrective action.

How it works

• Each program needs to have a Dependency Manager
• A Project Owner identifies a dependency on another program and submits it to the Dependency Manager.
• Dependency Manager communicates and assigns the dependency to the appropriate project.
• The Project Owners develop a dependency action plan and a workflow confirms their agreement.
• Dependencies appear on the schedule and in RAID registers for management through to completion.

Best Practice Implementation

The following is a fictional scenario that is intended to take you through the best practices for implementation of inter-project dependency management using Amplify.

Scenario Background

The Marketing program in AB & C, Inc is rolling out a new campaign and the Sales program needs to complete an awareness training on the campaign materials. Sales Program is dependent on Marketing to ready their new campaign so that the awareness training project can be started. You can see this illustrated in the below picture. Mr.Jack Harkness handles the Marketing Campaign creation project. Mr.Gavin Cooper is responsible for the Sales Training project. Ms.Bridget Evans is appointed as the Dependency Manager for the Marketing Campaign.

Roles Involved

• Bridget, the Dependency Manager for the Marketing Campaign 
• Gavin, the Project Owner for Sales Training
• Jack, the Project Owner for Marketing Campaign Creation
• Other stakeholders who act as the  approvers of the dependency
  
  

Identifying and Creating the Dependency

Gavin Cooper, the Sales Training Project owner has identified a dependency, he requires the marketing campaign materials before he can begin his training. He creates a Dependency item from the project's RAID register or schedule. Gavin must assign the Marketing program as the predecessor initiative, he also completes the rest of the form to the best of his ability. 

Dependency Manager assigns

Bridget sees the dependency on her dashboard, or email and needs to assign the dependency to Jack Harkness, the owner of the Sales Project generating the marketing material. At this time Bridget can also assign the specific schedule task if it is known. If only the project is assigned, the project owner will be responsible for assigning it to a specific task in their schedule (schedule may or may not be there).

Generation of a Plan

Both parties contribute to the action plan and ensure that it contains the appropriate level of detail to communicate the tasks proceeding and following the deliverables. 

• appropriate name
• action plan
• set review dates
• scheduling

Agreement

The dependency workflow enables Gavin to communicate the action plan to all parties involved in the delivery. 

The workflow can be configured to have different layers of permissions. It is possible to set up a workflow that demands unanimous approval, single consent, or self-approval. Use 'unanimous' approval type to secure agreement from all required stakeholders. 

All participating users agree to the plan and approve the workflow. Dependency becomes recognised and accountable.

Monitoring 

Both project owners regularly view and update the dependency via the Dashboard. The dependency is visible in both RAID registers. It appears on both schedules. The progress flows through from one schedule to the other.  

Delivery

Progress is reported using the schedule progress (of the task) and reaches 100%.

Closing a Dependency

The predecessor task is completed. Jack makes sure that the deliverables are handed over to Gavin and his team as per the action plan. The dependency ends there and one of the parties closes it with final comments using the Edit function.

See also

Defining external dependencies via the Schedule tab
Creating cross-project dependencies using the RAID menu