The best way to manage stakeholder engagement across multiple large infrastructure projects is to centralise all stakeholder records in a single system, maintain a consistent engagement methodology across every project, ensure cross-project visibility so that teams can see when different workstreams are engaging the same stakeholder, build in audit-ready reporting from day one, and use a purpose-built stakeholder management platform rather than spreadsheets or a CRM.
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. The Ten-Year Infrastructure 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 multiple project promoters simultaneously.
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 manage tens of thousands of stakeholders across concurrent programmes. A centralised record is not just good practice for them; it is the only way the operation can be managed at that scale.
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 (or yet a collection of tools) that keeps projects siloed 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.
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 engagement metrics - how many stakeholders reached, how many issues raised and resolved, what sentiment trends look like across the programme - are available in real time rather than requiring a manual compilation exercise every time someone asks for them.
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.
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 and AI-powered dashboards that turn engagement activity into structured output without manual compilation
- 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 ~30,000 stakeholder issues at a 100% response rate across the Hinkley Point C and Sizewell C consultation program. 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, Northumbrian 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.
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.
