Project Interdependence: A Reality You Cannot Ignore in Your Portfolio

A Saint-Hyacinthe distributor launches an ERP replacement in January. In March, the logistics department starts a transport optimization project with a different vendor. No one notices that the second project depends on the first one's data until the day both teams claim the same test environment, the same two business experts, and the same go-live date.

Six months behind schedule, two revised budgets.

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

According to a McKinsey and University of Oxford study of over 5,400 IT projects, large projects go over budget by an average of 45% and over schedule by 7%, while delivering 56% less value than expected.

Why does project interdependence derail schedules?

Project interdependence derails schedules because there is no control tower monitoring collisions between projects: each manager is flying their own plane, and overlaps are discovered in mid-air, when they are most costly.

Imagine you are flying a commercial airliner. Your primary responsibility is to get your passengers to their destination, but you know there are other planes in the sky at varying distances. Staying vigilant and avoiding collisions is part of the job, even with air traffic controllers watching.

In project management, there is no real control tower. Yet, the risks of collision, overlap, and interdependence are very real. The project manager must identify them early and remain on high alert from start to finish, just like a pilot following a flight plan.

Project management has become more professional over the last fifteen years, but this aspect remains overlooked. It doesn't appear in the business case or 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 skill sets 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 in short supply. If two business line experts are assigned to the project, their manager has to run the department with the rest of the team, which creates tension.

If a marketing project then demands the same expertise, the first project will have to share what it thought it had secured.

Technical and material resources form the second bottleneck. To test before implementation, you need disk space, servers, and environments. The infrastructure is often saturated, and projects end up fighting over the same environments—a reality we describe in Project Environments.

Certain technical skills are just as rare. Finding specialists for 30- or 40-year-old legacy systems is a feat. Yet, the bulk of IT projects involve replacing these systems, so the situation arises frequently.

How can you anticipate integrations between projects running in parallel?

You anticipate integrations by mapping out, during the preliminary analysis, which project provides data or interfaces to which other, and then aligning their go-live dates before both schedules are approved separately.

Let’s go back to the ERP replacement example. The planning covers financial, commercial, and logistics data.

At the same time, the company wants to optimize transport. This second project cannot go live before the first, because it depends on its data. It must integrate with the ERP, and their integration dates must match.

Can the project management office, if one exists, or the enterprise architect prevent these difficulties? In theory, yes. In practice, it’s unlikely. These interdependencies are hidden in details that fall outside the scope of the project management office. And once the budget is approved, the detailed planning still needs to be done: that is when the project manager discovers them.

A few key figures to put the stakes into perspective:

• Large IT projects go over budget by an average of 45% and over schedule by 7% (McKinsey and University of Oxford, 2012).
• 56% less value is delivered than expected for these same projects (McKinsey, 2012).
• An additional 15% cost overrun for every extra year of duration (McKinsey, 2012).
• 17% of IT projects perform so poorly that they threaten the company’s existence (McKinsey, 2012).
• More than 3 months behind schedule and over $8 million USD in costs for a bank whose finance department was involved only a few months before go-live (McKinsey, 2012).
• 9.9% of every dollar invested in projects is wasted due to poor performance (PMI, 2018).

Interdependencies don’t hide in the business case or the project charter: they hide in the details, and they show up on the invoice.

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

An IT Project Plan: How to build a realistic, comprehensive, and engaging schedule spells out these dependencies in black and white.

What should a project manager do to stay alert?

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

This state of constant vigilance is not always understood or appreciated by stakeholders. It can look like time spent on other people’s projects. Yet, it is essential to get everyone to the finish line, and it is less costly than any schedule revision.

The Harvard Business Review described the overload of initiatives and its multiplier effect in 2018: every project added increases the burden on all the others. The first line of defense remains an accurate count of ongoing initiatives. The second is a manager who looks up from their own plan.

To learn more about implementing an ERP, read How to successfully implement an ERP system?

Frequently asked questions

What is project interdependence?

Project interdependence refers to the links that make one project dependent on another to move forward: shared human or technical resources, data or interfaces provided by another project, or go-live dates that must align. These links are rarely visible at the business case stage. They appear during detailed planning and are costly if discovered too late.

What are the two main pitfalls of project interdependence?

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

Can the project management office prevent interdependencies?

In theory, yes; in practice, rarely on its own. Interdependencies are hidden in details that fall outside the project office's scope, and detailed planning begins only after budget approval. It is the project manager who discovers them at this stage. The project office remains useful for tracking initiatives and arbitrating shared resources.

According to McKinsey, what is the cost of IT project overruns?

According to a 2012 study by McKinsey and the University of Oxford of over 5,400 IT projects, large projects go over budget by an average of 45% and over schedule by 7%, while delivering 56% less value than expected. Each additional year adds 15% to the overrun, and 17% of projects threaten the company's existence.