P2: L., more F not really PM
For information sharing within projects, we mainly use PowerPoints, project plans shared via email, and Teams channels. Teams has made things a bit better — you can invite externals and put everything in one place — but it’s not very transparent either. If I create a channel, my colleague just has to know it exists. Internally, we do try to share lessons learned. We have intervision sessions from time to time, though it’s a bit voluntary — dependent on who likes to bring something in. We used to have a more structured ‘enrichment carousel’ where colleagues would pitch their projects, but it started to feel like defending your project rather than enriching it, so that didn’t stick. Now we look at completed projects in our portfolio and try to feed back what worked and what didn’t. It’s a bit made-do, not super strict.
P3: L., not really PM
Knowledge sharing within the network goes surprisingly well — better than you might expect given that businesses are also each other’s competitors. In the battle for the labour market they’ve realised they really have to do it together. That long-term, responsible entrepreneurship mindset is genuinely characteristic of this region. With the innovation expedition outcomes we did explicitly check whether participants were comfortable sharing — and in general they were very willing.
P4: L., more F
we track the failures equally carefully — things that went wrong in practice are just as instructive. A green parking area once failed completely because a contractor left a material outside that must not get wet. It rained, nobody understood why it wasn’t working, and everyone was angry. These are things you want documented, because the lesson is very practical and not obvious. Failures are just as important to share as successes — and we share them far too little in general.
P5: S., PM RWS
There are many collaboration networks out there — Bouwcampus, Next Generation Infrastructure, Topsector Bouw en Infrastructuur — and I think we’d all benefit from mapping what’s being worked on across those programmes and being able to exchange with each other. That’s potentially an interesting opportunity. IP agreements are almost always made at the start of a project — distinguishing what is proprietary and what can be published, and who becomes the owner of certain data. But what I notice in practice is that even when you’ve made those agreements upfront, you have to stay alert throughout the whole process and revisit them regularly as things become more concrete. It’s a continuous point of attention, not just a starting condition. Knowledge sharing reluctance is more of a thing in our sector than in others. You see a clear difference between larger and smaller parties. Larger companies are often happy to show what they’re working on, even at an early stage. Smaller parties — especially startups and real inventors — are often more cautious, afraid that larger parties will run off with their ideas before agreements are in place. In infrastructure that’s particularly complicated because there’s a dependency relationship: we work with large contractors who are used to operating within certain chains. And patents — which work well in other sectors — are often counterproductive for us. If you patent something in infrastructure, you can be fairly certain it will never be applied.
P6: M., PM Novum
Important lessons are captured in status updates and incorporated into reports. In addition, they work with a “working deck” — a living document in which innovation designers and business members record results and processes from canvases and other tools.
He acknowledges that the system is still immature. Knowledge is currently findable primarily through reports and the working deck, but this only works well if people update it consistently. A bigger problem is the dependency on people: when someone leaves the organisation, it becomes difficult to retrieve information and to make sense of it.
He would like a smarter database that makes lessons more searchable — for example, to quickly surface relevant experiences from recent years when starting a new AI project. The main goal is to prevent duplication of effort in future projects. That point, however, has not yet been reached.