Project Interdependencies: A Reality You Cannot Afford to Overlook in Your Portfolio

A Saint-Hyacinthe distributor kicks off its ERP replacement in January. In March, logistics starts a transportation optimization project with a different vendor. Nobody notices that the second depends on the first's data until the day both teams claim the same test environment, the same two business-line experts and the same go-live date.

Six months of delay, two revised budgets.

The figures cited come from public international studies and serve as indicative benchmarks: the real size of overruns depends on portfolio size, governance and the maturity of your project management office.

According to the McKinsey and University of Oxford study of more than 5,400 IT projects, large projects run 45% over budget and 7% over schedule on average, while delivering 56% less value than predicted.

Why do project interdependencies derail schedules?

Project interdependencies derail schedules because no control tower watches for collisions between projects: each manager flies their own aircraft, and overlaps are discovered mid-flight, when they cost the most.

Imagine you are flying an airliner. Your primary responsibility is to get your passengers to their destination, but you know there are other aircraft in the sky, at various distances. Staying alert and avoiding any collision is part of the job, even with air traffic controllers on watch.

In project management, there is no real control tower. Yet the risks of collision, overlap and interdependency are very real. The project manager has to identify them quickly and stay alert from start to finish, like a pilot following the flight plan.

Project management has professionalized over the past fifteen years, but this aspect remains poorly understood. It appears neither in the business case nor in the charter. It appears in the final invoice.

How does competition for resources create interdependencies?

Competition for resources creates interdependencies because business experts, technical environments and certain rare skills are shared between projects, often without any of them having planned for it.

Business resources are the hardest to secure. To implement a new order-taking system, you have to requisition specialists who are already scarce. If two business-line experts are assigned to the project, their manager must keep the department running with the rest of the team, which creates tension.

Then a marketing project demands the same expertise, and the first project has to share what it thought was secured. Interdependencies bring their share of uncertainty, and it falls to the manager to adapt and find solutions.

Technical and material resources are the second bottleneck. Testing before implementation requires disk space, servers and environments. The infrastructure is often saturated and projects fight over the same environments, a reality we describe in Project environments.

Some technical skills are just as rare. Finding specialists in legacy systems that are 30 or 40 years old is a feat. Yet most IT projects consist of replacing those very systems, so the situation comes up all the time.

How do you anticipate integrations between projects running in parallel?

You anticipate integrations by mapping, at the preliminary analysis stage, which project supplies data or interfaces to which other, then aligning their go-live dates before the two schedules get approved separately.

Back to the ERP replacement example. Planning covers financial, commercial and logistics data. In parallel, the company wants to optimize transportation. That second project cannot go into production before the first, because it depends on its data. It has to integrate with the ERP, and their integration dates must line up.

Can the project management office, where one exists, or the enterprise architect prevent these difficulties? In theory, yes. In practice, unlikely. These interdependencies hide in details that are outside the PMO's remit. And once budget approval is granted, detailed planning still has to be done: that is where the project manager discovers them.

A few benchmarks to size the stakes:

• 45% average budget overrun and 7% average schedule overrun for large IT projects (McKinsey and University of Oxford, 2012).
• 56% less value delivered than predicted for those same projects (McKinsey, 2012).
• 15% additional cost overrun for every extra year of duration (McKinsey, 2012).
• 17% of IT projects go badly enough to threaten the company's existence (McKinsey, 2012).
• More than 3 months of delay and more than US$8 million in costs for a bank whose finance department got involved only a few months before go-live (McKinsey, 2012).
• 9.9% of every dollar invested in projects wasted through poor performance (PMI, 2018).

Interdependencies do not hide in the business case or the project charter: they hide in the details, and they surface in the invoice.

The bank example cited by McKinsey is instructive. Finance arrived late, a new performance management system had just been introduced, and the accounting modules had to be changed at the last minute. Two projects, one unanticipated integration, a delay of more than three months.

An IT Project Plan: How to Build a Realistic, Complete and Engaging Plan names those dependencies in black and white.

What must the project manager do to stay alert?

The project manager must detect the potential for conflict or overlap at the preliminary analysis or feasibility stage, then continuously monitor what is happening in the other projects, IT and business alike, to eliminate blind spots.

This state of permanent watch is not always understood or appreciated by sponsors. It looks like time spent on other people's projects. It is nonetheless essential to bring all the passengers home safely, and it costs less than any schedule revision.

Harvard Business Review described initiative overload and its multiplier effect in 2018: every project added increases the load on all the others. The first defence remains an exact count of the initiatives under way. The second, a manager who looks up from their own plan.

To go further on putting an ERP in place, read How to successfully implement an ERP system?

Frequently asked questions

What are project interdependencies?

Project interdependencies are the links that make one project depend on another to move forward: shared human or technical resources, data or interfaces supplied by another project, go-live dates that must line up. These links are rarely visible at business-case time. They surface during detailed planning and become expensive when discovered too late.

What are the two main pitfalls of project interdependencies?

The first pitfall is competition for resources: business-line experts, test environments, servers and rare technical skills, such as those tied to legacy systems. The second is integration between parallel projects, when one project depends on another's data and their go-live dates must line up without having been planned together by anyone.

Can the project management office prevent interdependencies?

In theory yes, in practice rarely on its own. Interdependencies hide in details outside the PMO's remit, and detailed planning begins after budget approval. It is the project manager who discovers them at that stage. The PMO remains useful for keeping count of initiatives and arbitrating shared resources across the portfolio.

How much do IT project overruns cost according to McKinsey?

According to the 2012 McKinsey and University of Oxford study of more than 5,400 IT projects, large projects run 45% over budget and 7% over schedule on average, while delivering 56% less value than predicted. Every additional year adds 15% to the overrun, and 17% of projects go badly enough to threaten the company's existence.