Taking Project Alliances to the Next Level: Via the Moon to Rails and Towards Program Alliances

A major, multi-organization cooperation project has finally been completed. The “Lessons Learned” event has been held and the employees are returning to their home organizations. They have perhaps a couple of weeks or months of calm at head office before new challenges await. New project, new patterns, and reinventing the wheel. Sure, you might know it already, but the representatives of the other companies haven’t got a clue what it’s all about. So let’s start from the beginning, reinvent the wheel, and co-develop before reaching that big finale again, when the project’s been finished off and everything starts afresh in the next project. The wheel starts spinning again.

This oversimplified example probably sounds familiar to many project-based (business) operations veterans. This kind of lack of continuity is probably one of the most fascinating things about projects, and it’s also what motivates some people. New working environments, new challenges, tangible results, it’s easy for an individual to get hooked on these things when seeking out new experiences.

From an economic perspective, and in particular in terms of labor productivity, however, this really doesn’t make much sense, as so-called set-up costs, i.e., finding shared working practices and establishing the common tone at the beginning of the project take up a significant proportion of the production resources. Naturally, when working towards a unique end-product of a project, it’s rarely completely possible to achieve the kind of standardization that comes with a production line. One valid question, however, is whether things can be done more efficiently?

How can we generate cross-project cumulative benefits such as those of NASA’s Apollo program?

In my previous piece, ‘The tragedy of common projects’ I looked at collaborative and relational project models (e.g., the project alliance) as one solution for the efficient management of large-scale projects. The key element of the alliance model when it comes to increasing productivity stems from the harmonization of different operators’ inherently diverse incentives, so that everyone is working for the common good of the project, rather than taking an opportunistic approach to maximize their own benefit. This is achieved by defining the objectives of the project, or at the very least corresponding indicators, through cooperation between all of the project alliance members. This will then mean that everyone is prepared to commit to the objectives, rather than feeling as if the goals have been dictated from above.

The model really does work, in particular in large, multifaceted projects."

Empirical research shows that the model really does work, in particular in large, multifaceted projects, where the planning and administrative costs the alliance entails can be better weighed up against the savings coming from a higher-quality end product and more efficient implementation phase. Naturally, not all projects are as well suited to an alliance.

However, the alliance model “only” resolves projects’ internal incentive issues, and at the same time, as I emphasized in my previous piece, is based on shaping project-specific objectives and indicators. That is to say, the wheel has to be reinvented again at the start of every project. And what about the cumulative benefits across projects? No, we haven’t forgotten about those, but here the focus needs to be raised from the projects to a higher level, often known as a “program”, i.e., a series of linked projects.

The most famous program is probably the US space agency NASA’s Apollo program, which reached its peak exactly 50 years ago with the first successful manned flight to the moon. The Apollo program is one of the most significant manifestations of the arms race of the Cold War, and started in the early 60s with attempts to achieve a clear objective (to put a man on the moon), which was broken up into all numerous subprojects featuring of both technical entities (e.g., rocket technology) and change projects developing the organization’s competitiveness (e.g., development of the astronaut training program). In all its grandeur, the Apollo program is probably the black swan of programs. We may never see another one in the history of the world, but programs themselves have not disappeared.

The competitors in the Melbourne alliance program shared innovations to benefit the entire industry sector

The so-called alliance program—a series of linked alliance projects— can be seen as one of the latest developments in this area. This slightly unusual arrangement stems as far as we know from birthplace of the alliance model, in Australia, where it has been used, amongst other things, to organize a multi-billion dollar objective of removing 50 level crossings classified as dangerous in the Melbourne metropolitan area by 2022.

Depending on who you ask, the project is either known as the Level Crossing Removal Project or by its official abbreviation, Australians loving as they do to shorten names, of LXRP. The public organization, Level Crossing Removal Authority (LXRA), founded specifically for this purpose, is responsible for the realization of the program, including program management, as well as serving as the buyer for each of the program’s individual alliance projects.

What makes the LXRP program interesting is that alliance characteristics have been introduced at program level."

The aim of the individual alliance projects that make up the program is to remove a number of adjacent level crossings, and thus these projects consist largely of the LXRA buyer team, a rail operator, and designer-contractor consortium chosen through tendering. These alliance parties organize their project using the standard alliance model doctrines, i.e., defining the technical solution, its implementation, and target outturn cost (TOC), as well as an incentive scheme and commercial framework based on key performance areas.

What makes the LXRP program interesting is that alliance characteristics have been introduced at program level. In practice, this means that in terms of the program objectives, key result areas and key performance indicators have been formed that are used as incentives in the individual projects.

These aren’t just linked to the main goal of removing level crossings cost-effectively, but instead they also feature sharing of innovations (between subprojects) and indicators relating to the development of the entire infrastructure sector (e.g., new workforce training). In other words, in addition to project-specific key result areas, the individual alliance projects are being incentivized to meet the targets associated with program-level indicators.

Private businesses sat around the same table, sharing their best practices with their competitors."

It wasn’t enough for the project staff to create an innovation that would help remove individual level crossings cost-effectively; the innovation also had to be shared at program level with other projects. A special coordination group was established for this very purpose, allowing the alliance project managers to meet on a regular basis and share their experiences. So in practice, this meant that private businesses sat around the same table, sharing their best practices with their competitors, something that wouldn’t necessarily have even been conceivable without specific incentives, even though the end result would be a development that would drive the entire sector forward.

Currently, the LXRP program can be considered to be experiencing reasonably strong tail winds, and almost 30 of the original 50 level crossings have been removed over the last four years. Furthermore, the State of Victoria has proposed 25 further level crossings for removal in the period 2022–2025.

How can we draw out features of the program alliances for our own project management?

A program alliance could rightly be considered to be the next level of a project alliance, but both experiences and research are still in short supply. As neither project alliances or program alliances can be applied just anywhere, certain features for practical project management could be considered instead. Below I’ve set out four perspectives for advancing your own thinking:

1. Think about when fulfilment of your objective requires program-level thinking. It’s not just a matter of semantics; ask yourself, for example, whether new subprojects need to be launched in order fulfill the overall objective of your project? If the answer is yes, you can keep calling it a project, but you may need some program management thinking.
2. Think about what the key aims of the program (or main project) are, and how they would look at the level of individual subprojects. Try to come up with so-called key result areas for these objectives, as well as sensible performance indicators, in collaboration with your most important stakeholders.
3. Try to find ways of implementing these program-level indicators in the incentive schemes for individual projects (or agreements). However, set separate more contextualized objectives for each subproject, as well as indicators, incentives and key result areas to support them, in cooperation with the project parties.
4. Develop practices that can help spark conversation between subprojects. For example, regular information sharing events, with participation tied to the subprojects’ incentive schemes.

Juri Matinheikki, D.Sc. (Tech.) is a post-doctoral researcher based in the Logistics Research Group at Aalto University School of Business.He provides tuition on programs including the Aalto PRO Diploma in Project Management, a comprehensive project management and project leadership training program. The program provides the best practical tools and methods, effective leadership practices and the latest research ideas to benefit your company’s project activities. Read more about the program.