Beware of Project Dependencies

Managing Project Dependencies

Managing project dependencies are an important part of portfolio planning as well as tactically managing project execution. Unknown dependencies represent a major portfolio risk and in complex environments, inadequate identification of project dependencies can derail projects or programs. Dependencies can be any deliverable, process, standard, technology, or product that is produced by one project team (or work group) but impacts another project or program. Projects that impact other projects may be referred to as upstream projects, predecessors, or givers. Projects that are impacted by other projects may be referred to as downstream projects, successors, or receivers.

Senior leadership needs to proactively manage and monitor project dependencies within the portfolio. If left unmanaged, the negative impact of such dependencies can severely affect schedule, scope, and cost. Schedule slides will be the most common impact when project teams have a technical dependency with another project and need certain deliverables to fulfill the scope of the project, but higher project costs can be incurred when projects are delayed or reworked due to scope changes. When a downstream project is impacted by an upstream project, the dependent project may still be able to move forward with reduced scope or an expensive scope change required to accommodate a work around as a result of the dependency. I have seen expensive work-arounds implemented as temporary (i.e. “throw away”) solutions that would not have been developed had the upstream deliverables been ready on time.

Proactive management of project dependencies can significantly reduce these risks and expenses. Senior leaders should ask the right questions at gate reviews such as, “what is the real impact to this project if upstream project deliverables are not ready in time?” Will it impact the schedule by a week? By a month? Or longer?” “Are workarounds available if upstream project deliverables are not ready in time?” “If yes, what is the cost of the workaround?”

Thorough investigation and planning is needed in order to mitigate against these risks. Good portfolio planning will give decision makers the information they need to launch the right new projects at the right time and sequence the work in the right order to minimize schedule delays, scope change, and budget increases. When it makes sense, a program manager may be needed to oversee the execution of related projects and help manage dependencies between multiple projects. Furthermore, without understanding the relationships between projects, senior management may make a decision regarding one project without understanding the downstream repercussions to dependent projects.  Having this information will also help decision makers make better decisions about in-flight projects. Understanding the impacts of one project on another project is very important, but may be missed unless dependencies are proactively tracked and managed.

The Types of Project Dependencies

There are several types of dependencies that portfolio teams should be aware of:

  • Technical dependencies: “a relationship between two projects that affects the technical outcome of project deliverables”. A technical dependency exists when one project cannot move forward (easily) without a deliverable from another project. This is similar to a finish-to-start relationship common in project schedules, except that it exists between projects. Example: in the IT environment projects may need certain infrastructure to be in place before the project solution can be released. If another project is responsible for setting up the new infrastructure, then there is a hard dependency between the two projects. Having multiple dependencies of this type only compounds the problem and quickly increases the complexity of completing the project on time, within scope, and within budget.
  • Schedule dependencies: (sometimes referred to as a synchronization dependency): “a relationship between two projects where the timing of one project impacts the outcome of another project”. A schedule dependency occurs when project deliverables are needed at the same time in order for both projects to finish. An IT example would be one project decommissioning a system but waiting on another project to complete a data warehouse needed to archive the legacy system’s data. This type of dependency is similar to a finish-to-finish relationship common in project schedules.
  • Resource dependencies: “a shared critical resource between two projects”. A resource dependency only exists when critical resources are shared between projects. This dependency type is often managed at the portfolio level and resource manager level, but project teams should be aware of shared critical resources. If one project is off track and needs additional unplanned effort from critical resources, the other projects may be impacted as well.
  • Information dependencies: this is a less critical relationship, but may be worth noting so that important information is communicated to the impacted projects in a timely way. There are two aspects of an information dependency:
    1. Information shared from one project to another that would impact the latter’s scope or approach to completing the project. An informational dependency commonly exists when there is a known touch point between two projects and is based on changes to engineering standards, operational procedures, architecture, security, etc. For example, one project is working on changes to certain standards and procedures that affects another project. The upstream project team may not yet know what the final deliverable or solution is, but a downstream project knows that the results may impact its project’s design. There may not be a technical deliverable as described above, but changes to standards and procedures could create future re-work, so both project teams need to stay in close communication.
    2. The need to incorporate the capabilities and knowledge gained through another project. In this instance, important information gained from one project team should be passed on to another project team. This may occur more often in engineering environments.

In addition to the various dependency types, it is also important to denote the level of impact for each dependency. This is similar to project risk management where the level of impact varies from risk to risk. Impact could be measured in terms of schedule delays, scope impacts, and cost. Mature organizations may use more sophisticated methods of measuring impact, but less mature organizations can utilize a simple high, medium, low scoring to denote levels of impact. In the next post we will cover the tactics of managing project dependencies.

Read More