Be Careful Managing Project Dependencies

 

By Tim Washington, Point B

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 manage and monitor project dependencies within the portfolio. If left unmanaged, there could be deadly hidden costs of unnecessary workarounds, and 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 actively tracked and managed.

Dependency Types

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

1)    Technical dependency: “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.

2)    Schedule dependency (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.

3)    Resource dependency: “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.

4)    Information dependency: 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:

a.    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 hard 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.

b.    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.

Tactics for Managing Dependencies

Managing dependencies is an iterative process. The more complex the organization, the more dependencies will occur between projects, and the more effort required to manage the dependencies. In order to successfully establish the process for managing dependencies some preliminary questions need to be answered:

1) What data needs to be captured? (DATA)

The amount of data collected will vary from company to company and will be based on the maturity of the organization collecting the data. Lower maturity organizations may simply want to know that a dependency exists and not go any deeper. More mature organizations may go further to understand the type and severity of the dependency as well as workarounds, cost of workarounds, timing, etc.

2) Who is going to capture it? (ROLE)

The timing, quality, and amount of data collected will help determine who is responsible for the data. In the early phases of a project, a business analyst may be very capable of collecting all of the necessary data. However, if technical information and costs are needed, a technical analyst or solution architect may need to be involved. If dependency information is not used until later in the project lifecycle, a project manager may be the right person to collect and manage this data. Getting the right people (role) involved at the right time is an important part of proactively managing project dependencies.

3) How and when will it be captured? (PROCESS)

These questions relate to the process of collecting dependency data. The right people need to be involved, but they also need to understand the process for collecting data so that senior leaders consistently have the right information at the right time for making better decisions. The process may require face to face meetings at the initiation of a project, or it may be written in as part of a business case based on data gleaned from an existing system. The quantity and quality of the data may change during the project lifecycle.

4) Where will the data be stored? (TOOL)

Managing dependency data in a central IT system will reduce maintenance costs, increase visibility, improve quality, and raise the likelihood that the data will be available when needed. However, data may be stored in various systems or tools at different times in the project lifecycle. For instance, at project initiation, the initiator may only have limited data available and enter this information into the project proposal form. Perhaps at the next phase, it is entered into a matrix for further analysis, but entered into a central IT system for general consumption.

Although the dependency data will be stored in a system, do not rely on technology for identifying dependencies. Some ongoing form of meetings will be required to discuss project dependencies, and face to face communication is the best form of communication to accomplish this. In the portfolio planning phase, subject matter experts, senior business analysts, or solution architects, may be needed to do preliminary analysis to identify potential dependencies. Once a project has been approved, a project manager and/or a program manager will be responsible for managing the dependencies.

Steps:

1) Identify potential dependencies—a matrix of all active and potential projects should be created to help capture the initial dependency data. If the matrix is too large, then grouping projects into smaller portfolios will help make the matrix more manageable.

2) Identify dependency types—further analysis is required to understand the specific type of dependency. Subject matter experts, senior business analysts, or solution architects should be able to understand and identify the type of dependency.

3) Impact assessment—understanding the impact assessment further enables the portfolio management team and program manager (if applicable) to sequence projects appropriately. Projects that have numerous upstream dependencies have a much higher risk, whereas projects that affect multiple downstream projects will probably have a higher priority (thus receiving more resources and more attention) so as not to disrupt the downstream projects. For steps 1-3 see the example below.

4) Get clarity and negotiate the dependency—identifying and assessing the dependency is only the first step. Project teams must fully understand the details of the dependency in order to make it actionable. Negotiation is an important part of the process and requires strong project leadership because one side may not agree that a true dependency exists.

5) Build the dependency into the project plan—this makes all of the previous steps actionable and allows the project teams to monitor the status of the dependencies. In some instances, the project managers may put this information into the project schedule. Others may track the dependencies through a risk management log or other reporting vehicle. Very mature organizations may build a hard dependency into the project schedule between projects so that if the upstream project slides, the downstream project’s schedule will reflect the schedule slide (I don’t generally recommend this, so use with discretion).

After the information is compiled, additional summaries can be created to depict the relationships around a given project. Such information can be useful to senior management in project status meetings and portfolio reviews. In the example below, we can quickly see the all of projects impacting and being impacted by the given project and the type of dependency between projects. Other key information such as stakeholders, affected systems and processes, and current priority ranking can be included to further enhance decision making.

Summary

Managing project dependencies is an important component to successful portfolio planning. Proactive management of project dependencies will not only help ensure you have a successful portfolio, but also mitigates against some portfolio risks. A strong PMO will have ongoing discussions among Project and Program managers to manage dependencies, but senior leadership should have a clear understanding of the key relationships among projects when making a number of portfolio related decisions.

 

Leave a Reply

Your email address will not be published. Required fields are marked *