The Learning & Collaboration Value For Developers

Our research made one thing very clear: developers are managing far more than one development process at a time, particularly in the context of data center development.

Internally, there may be separate workstreams for power, water, permitting, environmental review, planning, community engagement and communications — often led by completely different teams.

However, the public does not experience a proposed data center as six separate workstreams. They see one project.

They want to know how much power it will use, where the water will come from, what happens during drought, what the generators mean for air quality and noise, how much construction traffic there will be, who will ultimately operate the facility, what the community receives in return — and whether all those answers fit together. When information emerges at different times or from different organizations, an entirely legitimate development process can still begin to look fragmented or opaque.

This is one of the areas this conference is specifically designed to help developers solve, fostering developer collaboration.

Bringing The Workstreams Back Together

Rather than discussing power, water, permitting and community engagement as separate disciplines, the agenda deliberately brings them together around the complete development proposition.

You will hear not only from other developers but also from hyperscalers, colocation operators, utilities, regulators, municipalities and other stakeholders who ultimately influence whether a development is approved, delivered, operated and able to grow.

The objective is to help development teams create a more coherent proposition — both internally and externally — and understand where one decision may create consequences somewhere else.

Why Apparently Viable Projects Are Still Failing

Another strong theme in the research was the degree of surprise among developers at how quickly the environment has changed.

Projects that appeared commercially viable, technically viable and capable of securing the required resources have nevertheless become delayed, redesigned, politically vulnerable or unable to proceed.

One representative research response put the learning need very simply: "I would want to hear, in quite an unvarnished way, why apparently viable projects lose public and political support."

The conference will therefore not simply present successful engagement case studies. We will examine the actual sequence of events.

What was known when the site was selected? What was still unknown? When did power or water first become a potential constraint? What did the local authority believe it was approving? When did residents first hear about the project? When did technical assumptions change? Which issue changed the public narrative? And where were the moments when a disclosure, redesign or independent assessment might realistically have changed the trajectory?

Dealing With Confidentiality Without Creating Suspicion

This is another area where the research showed the issue is more complicated than simply saying, "developers should disclose more."

At an early stage, you may know the likely campus envelope, land requirement, broad power demand and cooling philosophy — but not the final customer, rack density, phasing or exact operating profile. Some information is genuinely commercially sensitive. Some may be restricted by customer confidentiality. That does not automatically mean a developer is trying to hide something.

The more challenging question is: How do you explain what is known, what is provisional and what legitimately cannot yet be disclosed without creating the impression that confidentiality is being used to conceal material impacts?

The agenda has been built around practical answers to that problem — what should be disclosed early, what should be updated at defined decision points, what needs independent verification and what can reasonably remain confidential.

Designed Around The Developer–Operator–Customer Lifecycle

The sessions have also been deliberately tailored to the relationship between developers, hyperscalers and colocation operators.

Developers make many of the original design choices and approval commitments. Operators inherit them. Customers can later change the density, cooling requirements, power profile or expansion needs that determine whether those original assumptions still work.

That means the handover cannot simply involve drawings and technical documentation. It needs to carry across the development context — entitlement conditions, water assumptions, noise limits, generator conditions, utility arrangements, community commitments and why particular decisions were made in the first place.

As one research participant put it: "Don’t just give operations drawings. Give them the development context." Equally, operators and customers need to communicate future requirements early enough that developers can design for them rather than discovering during expansion that the original site proposition no longer works.

This event is therefore designed to help developers do something much more fundamental than simply “engage earlier.” It is about learning how to:

Bring separate development workstreams into one coherent proposition; Understand why apparently viable projects become vulnerable; Sequence disclosure, technical studies, confidentiality and engagement more effectively; Learn directly from regulators, utilities, communities, hyperscalers and operators rather than only from other developers; Carry development assumptions and commitments properly into operation.

And ultimately: Build projects that are not only technically and commercially viable — but genuinely executable, durable and capable of surviving approval, handover, operation and future growth.