In the early afternoon hours of 9 February, 2025, a small meeting room overseeing heavily protected System Control Centre inside Vilnius headquarters of Litgrid, Lithuanian power transmission system operator (TSO), was quite unusually packed. Despite it being Sunday, a flock of dignitaries including the minister of energy, the Prime Minister, and two European commissioners were intently watching two wildly rotating arrows on a oscilloscope-like screen, until at one point at 2:05 pm, they suddenly stuck together, someone exclaimed: “Yes!”, and the room exploded in applause.

It was exactly at that time when Lithuanian, Latvian, and Estonian power systems transitioned from the island mode, which was established a day ago after disconnecting power lines to Russia and Belarus, to synchronous connectivity with the region’s another neighbour, continental Europe. 
This event, followed by popular celebration everywhere in the Baltics, was an apt culmination of a six year-long collaboration of the Baltic States, Poland as its primary regional partner, European Commission and the community of European TSOs with the objective to decouple the Baltic power grid from Russian-managed system IPS/UPS and to reconnect it to the wide and considerably more friendly Continental European Synchronous Area, a feat that was long overdue since accession of the region to EU in 2004.

As Synchronisation Programme Manager at Litgrid, Lithuanian system operator, I had a privilege to witness and understand the inherent and vast complexity of the effort firsthand. This complexity is one of the things that is all but inevitable in any project programme, defined in ICB4 as “temporary organization of interrelated programme components managed in coordinated way to enable the implementation of change and the realization of benefits”. Try to let this last sentence sink in. What exactly makes projects “interrelated”?

1. Dependencies in the nutshell

Enter the world of cross-project dependencies, when our ability to deliver one project within constraints of the plan depends on how another project is designed, planned, and implemented. We talk about three types of typical dependencies:

Here you see the definitions of schedule, design, and resource types of dependencies, explaining how each affects project timelines, outputs, and resource availability. Presence of such dependencies is what drives “interrelatedness” of projects in programmes and makes life of programme managers so much more exciting.

Also, you could classify dependencies based on the cause:

I will try to formalize what a typical cross-project dependency by starting with some project, which we call Project 1 or “impacted project”. This project, for most of its lifecycle, has an implementation plan, which can succeed only if some specific requirements for another project (we call it Project 2 or “impacting project”) are met.

We call those requirements “Zero impact conditions”, or ZIC, because, if they are met by Project 2, the Project 1 will continue on track, within its budget, with full scope, and with all other important parameters remaining as planned.

On the other hand, if Project 2 fails to meet the requirements written down in ZIC, not only Project 2  is in trouble, but also Project 1, which could include impacts to cost, schedule, scope, quality, etc.

The important part to remember is that dependencies within a programme can translate into risks or issues for the impacted project and, by association for the programme at large:

• If zero impact conditions are violated, immediate issues arise requiring swift action. 
• If zero impact conditions are currently met but could be breached later, these represent risks that must be proactively identified and managed. This highlights the dynamic nature of dependency-related challenges. 

My journey with dependencies started years ago with previous programmes, but it was Synchronisation Programme that allowed and required that this aspect is turned into a properly managed practice.

2. The Challenge of Synchronisation

It is said that largest machines created by the man are power systems. In each of these systems all substations, generators, power transformers and wall sockets in millions of kitchens operate in step, powered by the alternating voltage and self-healing any deficiencies to return to stable operating frequency, thanks to genius of Nicola Tesla and many others who built up such systems across the world. The largest of them all is the Continental European Synchronous Area, or CESA.

For 65 years, Lithuania, Latvia, and Estonia were a part of Soviet-era electricity system IPS/UPS, and we stayed there even after realigning our economies to European Union and severing almost any other political or economic connection to Russia and its satellites. Already in 2007, the Baltics strongly promoted the idea of cutting off Russians and connecting to CESA, instead. 

There were many structural, geopolitical, and geographical challenges that had to be overcome by extensive studies and unorthodox technical design for the Baltics. But it was diplomatic, financial and political support from European Union that sealed the deal in the end, when governments of the Baltic States and Poland and the European Commission agreed on the political roadmap, including the proposed technical approach, in 2018.

This also set in motion the master objective of the project, which was to prepare electricity transmission infrastructure and systems in the Baltics for desynchronization from IPS/UPS and synchronization with CESA by 2025. My job from 2019 was limited to coordinating a programme in Lithuania that involves 20 projects spanning from 2011 to 2030 but still keeping the target of 2025 to prepare for the transition to CESA. As you know already from introduction, this did happen back on 9 February.

However, back in 2019, the task of planning 20 projects in Lithuania alone was far from straightforward, even with the high-level technical approach already in place. Dependencies had a major role in it for two reasons.

First, interconnectivity of the grid means that when you construct or reconstruct a line or substation, it impacts the lines and substations near it. We had a substation construction project that had to be coordinated with a line project near it, because when it comes to acceptance testing, the lines only can be tested in connectivity with a substation. In other words, timing and design dependencies matter a lot.

Second, the grid operates with N-1 principle, which says that at any time, there should be no critical node or line that could disconnect consumers or producers if disabled. There should always be a redundant line or substations to cover for outages. 

To support coordination of outages, the operator maintains a special outage schedule, which, if you look at it, seems always very tight and interconnected. If my project is off track while on outage, the impact could propagate to up to 10 other projects.

What it boils down to is three key problems we needed to solve at our Lithuanian synchronisation team: 

• identifying and tracking dependencies accurately, so that important dependencies are neither missed nor forgotten,

• allocating responsibility for managing the dependency registry and individual entries and having a system that rewards prudent behaviour from all responsible. What we do not want is the system when the impacted project team is left alone without authority or means to resolve the dependency.

• effectively mitigating dependencies before they are critical risks or issues, which is the expected outcome of doing nothing.

What we ended up back in 2021 was an approach that balances responsibilities among the programme management, the impacting project team and the impacted project team, with a help of a defined process.

3. The innovative approach to dependency management

The lifecycle of a dependency at Litgrid involves four key stages:

There are some ground rules, such as that programme management sets up and owns the dependency registry, and each entry is a kind of a contract we call „Dependency agreement “.

Note that while impacted projects are typically within the programme, impacting projects that can be within the programme or from the wider portfolio.

3.1 Identifying dependencies

Identifying dependencies is never straightforward, because of inherent asymmetry and shortage of information that crosses boundaries of individual projects. It is challenging, but possible for a project manager to assess what factors stemming from nearby projects would affect critical planning assumptions in her project. But it is nearly impossible to do it from the other end, trying to evaluate impact of some project on the rest of the programme.

What we need is a big picture, and this is where programme management steps in to help not only in figuring out existing dependencies, but also in maintaining the open dialogue that allows to accurately assess extent and gravity of the dependency, which are important parameters if we want to mitigate it. In doing so, we also take stock of another important technique, which is assumption management.

The identification sequence is organized as follows:

Step 1, all project managers capture design and planning assumptions, highlighting assets and infrastructure, assets, resources or systems used. This could be a substation, a line, a human or contractor resource, an IT system or component, some unique machinery.

In Step 2, programme management reviews those assumptions in collaboration with project managers and highlight those that are also used or worked on by another project. At this point a possibility of dependency is established, but it still needs to be proven. What we already have is preliminary identification of projects as „impacted“ or „impacting“.

Step 3 is mostly used to establish whether the dependency is real by talking to both impacted and impacting project managers, determining the Zero Impact Conditions and setting up the formal Dependency Agreement, in which both project managers and the programme manager are the parties.

3.2 Documenting dependencies

Now, this is how the dependency agreement looks like.

The first part of it describes:

• The details of the dependency itself,
• The zero impact conditions, or what requirements the impacting project should meet at the very least not to interfere with the impacted project. It would be, for example, „what is the longest possible outage that the impacting project can incur before it starts delaying the impacted project?“ These conditions are stated by the impacted project manager. He or she might say, for example, that the latest when the impacting project must come out of outage on Line 265 is 10th October.
• The current estimate by the impacting project manager of what is expectation of the parameter quoted in zero impact conditions. 
• References to identified issues or risks are added to the agreement.
• Finally, as its name implies, the dependency agreement requires the parties to commit to something, and they do commit to three points:

1. To inform each other of known changes in stated parameters

2. Work to mitigate the dependency on each end to reduce its effect on the „impacted project“ (basically that means mitigating the risk or resolving the issue).

3. Revisit the agreement according to the established review cycle, which is set up by the programme manager.

3.3 Reviewing dependencies

This brings us to the review ritual that we have established to make sure that the updates are clearly communicated.

It starts with the impacted project revisiting its zero impact conditions and stating if there are any changes to it. In a hypothetical case, PM says „My project will proceed on time if your project delivers milestone X on Date A.“

Then the baton goes to the impacting project manager stating her revised estimate that allows us to identify if there is any slack and how much we have.

In this case, it‘s „I estimate that I will deliver milestone X 10 days before the date A.“
The programme manager, as moderator in this review, states that:

1. The dependency is still intact, but slack is down to 10 days.
2. There is a risk of severity 2 of overlap into both projects, 
3. And he sets the next review in N days.

3.4 Mitigating dependencies

Of course, it makes little sense to identify a dependency if you are not planning to do so something about it. We‘ve talked a bit about the mitigation, or response action on dependencies, so I will try to give you an overview of options available to the team.

First, the best thing that you can do about the dependency is to make it disappear, or what we call „disentangling “. Basically, it makes two interrelated projects become less interrelated. You can do it by one of these ways:

• If you have a resource dependency, you resolve it by adding more resources (unless, of course, your key resource is unique, in which case we need commoditization, to which I will come back in a while).
• You can update the technical design of one or both of the projects in such a way that eliminates the dependency. For example, you might have wanted to use the water supply from another building, but due to massive reconstruction in that building, opted to build your own one.
• Sometimes you can just administratively move the impacted task or part of the project into the scope of the impacting project, which eliminates a cross-project dependency in favour of the internal dependency inside the impacting project.

Another approach is to weaken dependency on unique, scarce inputs, systems, or resources, and here we also have various strategies:

• Standardization or commoditization strategy seeks to replace any unique, scarce resource with something standard and easily available,
• One technique we employed to protect us from resource dependencies was to have standby resources, or specifically, standby contractors, who would be able to jump into action should the principal contractor fail,

Schedule changes are also a powerful technique in schedule dependencies.

On one hand, you can look for ways to increase slack, i.e., give more safety to the impacted project by the rearranging activities in the impacting project.

Another approach is to switch the order of projects working on the same infrastructure, thus making sure that the project that can move faster gets the upper hand, while a stuck project may use more time to resolve its problems. This has happened a lot of times in situations with outages, when it is not important which project claims grid outage. What matters is that it is the only one, so the order can be arbitrary.

Finally, a big part of what we can do is to detect and remove artificial dependencies that are here often because there is an internal bureaucracy that requires many things to be done in sequence simply because it does not trust them to be done in parallel. Hence gate reviews, approvals, committees, authorizations, forms, forms, forms. Some of decisions to serialize work are driven by risk aversion, sometimes without comparing a potential loss due to a risk to actual loss due to a delay. Ability to recognize and challenge such hurdles is one of superpowers of a potent programme manager.

In all these cases, especially in large, consequential projects, courage and authority is needed to challenge status quo and agree on making partial or conditional decisions instead of massive gate reviews that often block you from moving forward on formal and minor transgressions.

3.5 Closing dependency

One outcome of the review is that one of the linked tasks or milestones, whether on impacting or impacted side, has actually already happened, or there is no longer any physical linkage between events in both projects, which can lead to the closure of dependency. 

4. A handful of takeaways

Here are a few key success factors for effective dependency management that I would like to share.

See the whole picture: And not just programme management, which can quickly become a bottleneck. Keep every project manager on board well informed about other projects vying for the same resources, or working on the same infrastructure.

If your programme manager is not technical enough to recognize the technical dependencies from the assumption logs, I suggest to have something of a Chief Technical Officer in the programme (we do), who will maintain the technical bird‘s-eye view on key developments and underlying dependencies.

Second, you want to have a robust and stable process to avoid misinterpretation of inputs in dependency management. Training and documentation on the process is important, and even more important is to follow the rituals without deviation, because simply switching the speaking sequence in the review ritual may lead to confusion and misinterpretation.

Finally, manage dependency management itself as a process, with KPIs and improvements, see what works and what does not work for you, make necessary course adjustments.

Accountability and motivation: As I have mentioned before, dependency agreement IS an agreement, and it has to be committed to by the parties, including the impacting project team, which needs to treat the impact to other projects as their own, and that is no small feat. Nevertheless, each project manager, impacted or impacting, is interested to see this process working and supported, and this might be a strong motivator going forward.

Employ technology to harness efficiency improvements in dependency management, such as ability to track complex chains of indirect schedule dependencies using your project management software, or using AI to identify dependencies based on project documents. 

If properly employed, the process is not supposed to replace your risk management, but supplant it with additional tools and insights, reduce the workload on the programme management and increase the success chances of the programme in general.