What is the best way to manage stakeholder engagement across multiple large infrastructure projects?
The best way to manage stakeholder engagement across multiple large infrastructure projects is to centralise every stakeholder record in one system, apply a consistent engagement methodology across all projects, give teams visibility of each other's activity, and build audit-ready reporting from day one. A purpose-built stakeholder management platform makes this possible; spreadsheets and general CRMs cannot.
Organisations that do this are in a much better position to show that their engagement was coordinated, evidenced and defensible when it is examined.
The UK is in the middle of the most ambitious infrastructure build programme in a generation. UK Infrastructure: A 10 Year Strategy, published in 2025, has accelerated delivery across energy, water, transport, and grid connections. The result is that in many parts of the country, the same communities are now being engaged by several project promoters at once.
In Lincolnshire alone, the volume of offshore wind farm connections making landfall means that local landowners, parish councils, and community groups are being approached by several different development teams, each running their own consultation process, on their own timelines, using their own systems.
That is the core problem with managing stakeholder engagement across multiple large infrastructure projects. It is not just a question of scale. It is a question of coordination. And most of the tools organisations reach for (spreadsheets, shared inboxes, general-purpose CRMs) were never built to solve it.
The five things that separate organisations that manage this well
Organisations that consistently deliver good stakeholder engagement across multiple infrastructure projects share five characteristics. They do not happen by accident and they are hard to retrofit once a programme is underway.
1. One record per stakeholder, not one record per project
The most common failure mode is building stakeholder records inside individual projects. A landowner in a project area ends up as three separate entries in three separate spreadsheets, each managed by a different project team, each unaware of what the others have said to that person. When something goes wrong or when a regulator asks for the engagement history, nobody has the full picture.
The right approach is to maintain a single stakeholder record that travels across projects. Every interaction, from every project, is logged against that record. The stakeholder's history, their concerns, their preferred contact method, and their sentiment all sit in one place. When a new project touches that stakeholder, the team starts with context rather than starting from scratch.
Organisations like Anglian Water, and SSEN coordinate engagement at scale across concurrent programmes. Anglian Water works with more than 13,000 stakeholders across day-to-day operations and three major capital programmes, including the Cambridge Wastewater Treatment Plant Relocation, a Nationally Significant Infrastructure Project, and the Lincolnshire and Fens reservoirs, alongside a £10 billion investment programme spanning five years. SSEN has gone from 15 users to more than 200 since 2018 on the same pattern. A centralised record is not just good practice for them; it is the only way the operation can be run at all.
2. Cross-project visibility for teams
Related to the above but distinct: team members working on one project need to be able to see what is happening in others.
Not to do each other's work, but to avoid contradictions. If one team has told a local councillor that a substation will be screened by planting, and another team later contacts that same councillor about a different project without any knowledge of that prior conversation, the result is a stakeholder who feels like they are dealing with an organisation that does not know its own mind.
Cross-project visibility also matters for escalation. If a stakeholder has been a persistent objector on one project, that flag needs to be visible when they appear in the stakeholder list for a new one. A system that keeps projects siloed, or a collection of tools that never talk to each other, makes it impossible to carry that intelligence forward.
3. A consistent methodology applied across every project
Large programmes often involve multiple teams, sometimes from different parts of the same organisation or from external consultancies working alongside in-house staff. Without a shared methodology, the quality and format of engagement records vary enormously between projects. That creates two problems:
-
First, it makes cross-project reporting unreliable. If one team logs interactions in detail and another records only that a call took place, the programme-level data is meaningless.
-
Second, it creates vulnerability. In a Development Consent Order process or a regulatory review, inconsistent records are exactly the kind of thing that gets picked apart. The government’s own project delivery standard files this under planning and control rather than communications: chapter 26 of the Teal Book sits alongside scheduling and risk.
A consistent methodology means a shared definition of what gets logged, at what level of detail, by whom, and when. It means standard categorisation for issues and stakeholder types. And it means the same approach to escalation and sign-off across every project in the programme.
4. Reporting that is built in, not assembled at the end
Infrastructure programmes generate enormous volumes of engagement activity. Thousands of interactions, hundreds of issues logged, multiple consultation phases, regulatory submissions, planning examinations. The organisations that manage this well do not treat reporting as something that happens at the end of a phase. They treat it as a live output of the system they are running.
That means every interaction logged contributes to a report that could, in principle, be pulled at any moment. It means the numbers are available in real time rather than compiled by hand every time someone asks: how many stakeholders reached, how many issues raised and resolved, and what sentiment trends look like across the programme.
SP Energy Networks, Northern Gas Networks, and Electricity North West use Tractivity to generate the engagement reports that feed into their regulatory submissions. Having that data structured correctly from the start means the reporting burden at the end of a cycle is a fraction of what it would otherwise be.
5. A purpose-built platform, not a workaround
This is the point where the tools question becomes unavoidable.
Spreadsheets struggle at scale because consistency has to be enforced by people rather than by the tool, cross-project visibility has to be assembled by hand, audit-ready records have to be reconstructed after the fact, and the whole arrangement depends on whoever currently maintains it. General-purpose CRMs were built for sales pipelines and marketing campaigns. They can be customised to manage stakeholder data, but the customisation required to make them work for multi-project infrastructure engagement is significant, so the question to ask is who owns that build, what it costs and how it is maintained through platform upgrades.
Purpose-built stakeholder management platforms are structured around the specific demands of infrastructure engagement: multi-project architecture, stakeholder records that persist across programmes, issue tracking with audit trails, consultation response management, and regulatory reporting. The difference is not just convenience. It is the difference between an engagement record that holds up under examination and one that does not.
Engagement through construction, not just to consent
Managing stakeholder engagement during the construction phase of a major infrastructure project means tracking every commitment made at consent through to delivery, giving complaints and enquiries one route in with a date-stamped response, and keeping the engagement record live for the whole build, which on a major scheme runs 10 to 15 years rather than months.
Consent changes the shape of the engagement load rather than reducing it. Construction brings a different set of stakeholders and a different tempo: landowners with access agreements, residents affected by traffic management and working hours, statutory undertakers coordinating diversions, and the commitments given at examination that now have to be delivered and evidenced.
Three things matter here on a multi-project programme. Commitments made during consultation need tracking to completion, with an owner and a date against each one, because a commitment register that stops at consent is where most disputes start. Complaints and enquiries need a single route in and a date-stamped response, categorised by phase, issue and sentiment, so a pattern in one corridor is visible before it becomes a pattern across the programme. And the record has to outlast the team that created it, because the people answering questions in year eight are rarely the people who ran the consultation in year one.
EDF has used Tractivity to log around 30,000 stakeholder issues at a 100% response rate across the Hinkley Point C and Sizewell C programme, which is the order of volume a nuclear new-build generates over a build measured in decades. More on what comes next is in our guide to stakeholder engagement after the consultation closes, and on keeping that record lawfully in our guide to GDPR-compliant stakeholder databases.
How Tractivity is used to manage multi-project infrastructure engagement
Tractivity is a stakeholder management platform used by infrastructure organisations and regulated utilities across energy, water, transport, and the public sector. It is built around the assumption that stakeholders do not belong to projects. They exist independently, and projects intersect with them. That architecture is what makes it suited to multi-project environments.
In practice, this means:
-
A single stakeholder record shared across all projects in an organisation's portfolio, with full engagement history regardless of which project generated it
- Cross-project dashboards that show engagement activity, issue status, and sentiment at both project level and programme level
- Consistent issue logging and categorisation enforced across teams, so that data is comparable whether it comes from an internal team in Birmingham or an external agency in Edinburgh
- 150+ pre-built reports plus configurable dashboards that turn engagement activity into structured output without manual compilation, with AI Sentiment and AI Summarise available on top
- A complete, timestamped audit trail across stakeholder records and engagement activity, used by clients as evidence in DCO examinations, Ofwat and Ofgem regulatory reviews and planning inquiries
EDF has used Tractivity to log around 30,000 stakeholder issues at a 100% response rate across the Hinkley Point C and Sizewell C consultation programme. National Grid took a different approach to scale: deploying Tractivity to over 400 users through a phased rollout strategy, achieving a 90% user retention target at 12 months. Regulated water and gas network operators, including SGN, Severn Trent Water, Southern Water, and SP Energy Networks, use it to manage engagement across concurrent capital programmes. It is also used in higher education and research and nuclear infrastructure for complex multi-stakeholder programmes.
The Midland Metro Alliance, which brings together West Midlands Combined Authority and a consortium of design and construction partners, has used Tractivity since 2016 to run multiple metro extension projects in parallel across the West Midlands, with more than 2,500 stakeholder engagements logged through the platform.
‘With it affecting multiple numbers of residents and businesses, it was key that before any work started, our stakeholder engagement was done in a way that was effective, comprehensive and allowed us to engage thoroughly. Tractivity allowed us to lay the foundations for the projects before we started in earnest.’
Rose Rees, Head of Engagement and Skills, Midland Metro Alliance
If you are managing stakeholder engagement across multiple infrastructure projects and your current approach is straining under the load, get in touch for a demonstration.
Key takeaways
- The core challenge of multi-project infrastructure engagement is coordination, not just scale. The same stakeholders appear across multiple project teams who often have no visibility of each other's activity.
- Centralised stakeholder records that travel across projects, rather than records built inside individual projects, are the foundation of getting this right.
- A consistent methodology across all projects is what makes programme-level reporting reliable and keeps the engagement record defensible under scrutiny.
- Reporting should be a live output of the engagement system, not a manual exercise at the end of a phase.
- Spreadsheets and general-purpose CRMs were built for other jobs. A purpose-built stakeholder management platform is the option that ships with a multi-project stakeholder record, consultation response management and programme-level reporting as standard, rather than as a configuration project.
Frequently asked questions
The same stakeholders appear across multiple projects and most teams have no visibility of each other's activity. A community group being engaged on a grid connection in the same area as a water infrastructure project may be receiving communications from two separate teams within the same organisation, with no coordination between them. That creates contradictions, duplication, and a stakeholder experience that undermines trust. It also creates evidential gaps if the engagement record ever needs to be produced for a regulator or planning examiner.
CRMs can store contact records and log interactions, but they are not structured for the specific demands of infrastructure stakeholder engagement. Salesforce and Microsoft Dynamics both publish extensive customisation, custom object and audit capability, and Microsoft publishes customer-selectable UK and EU data regions. What neither publishes as a standard feature set is a stakeholder record that spans several projects, consultation response management, or the reporting formats used in DCO examinations and Ofwat and Ofgem submissions, so those are configuration projects. The practical questions to put to a CRM vendor are how a single stakeholder's full history across five concurrent projects is stored and exported, and how long that export takes.
As early as the project concept phase. For nationally significant infrastructure projects going through the Development Consent Order process, pre-application consultation is a legal requirement, but best practice means engaging key stakeholders before the formal process begins. Where communities and statutory consultees have been involved in shaping a project from early stages, promoters generally arrive at examination with fewer unresolved objections on the record and a clearer account of how comments were taken into account. The same principle applies to regulated asset programmes: organisations like water and energy companies that maintain continuous stakeholder relationships between AMP cycles have a much easier time when the next cycle of investment begins.
Public consultation is typically a formal, time-bounded process with a legal or regulatory basis. It requires a defined period during which representations can be made, a structured process for recording and responding to those representations, and a published report of how responses have been considered. Stakeholder engagement is broader and continuous. It covers the ongoing relationships with communities, landowners, elected representatives, regulators, and other interested parties throughout the full lifecycle of a project, not just during formal consultation windows. Good infrastructure projects do both, and the ongoing engagement work makes formal consultation significantly easier to manage.
Stakeholder fatigue is a real risk in areas with high concentrations of infrastructure activity, and it is one of the arguments for a coordinated approach. Organisations that can see across their full project portfolio can identify when the same stakeholder is being contacted too frequently, stagger communications to avoid clashes, and consolidate updates where it is appropriate to do so. Some infrastructure promoters in high-activity areas have also moved toward shared community liaison approaches, where a single point of contact manages relationships on behalf of multiple workstreams. This requires careful governance but significantly reduces the burden on communities and improves the quality of the engagement record.
Good reporting at programme level shows total stakeholder reach across all projects, the volume and type of issues raised and how they have been resolved, sentiment trends over time, and engagement activity by project phase and stakeholder group. At project level, it shows the same metrics in more granular detail, with a complete audit trail of individual interactions. For regulated organisations, reporting also needs to align with the specific formats required by Ofwat, Ofgem, or the Planning Inspectorate. The key test is whether the report could be handed to a regulator or planning examiner tomorrow and withstand scrutiny. If assembling it takes days of manual compilation, that is usually a sign the underlying data is not being captured in a reportable structure.
Track every commitment made at consent through to delivery with an owner and a date against each one, give complaints and enquiries a single route in with a date-stamped response categorised by phase and issue, and keep the record live for the whole build. On a major scheme that is 10 to 15 years, so the record has to outlast the team that created it.
Long enough to evidence delivery of the commitments made at examination, which on a major scheme means the whole construction period and beyond. Retention still has to be justified under UK GDPR, so set a retention period per record type and document the reasoning rather than keeping everything indefinitely. Our guide to GDPR-compliant stakeholder databases covers the detail.
