This research programme interviewed 9 facilitators and 6 portfolio managers / innovation managers between Q4 2025 and Q1 2026, exploring how multi-stakeholder collaboration works in practice across Dutch public-sector innovation programmes.
Facilitators
- F1 (researcher EUR)
- F2 (researcher barca)
- F3 (Digi)
- F4 (Digi-ICTU)
- F5 (PBA)
- F6 (Signalen - VNG)
- F7 (PBA)
- F8
- F9 (Novum)
| Topic | F1 | F2 | F3 | F4 | F5 | F6 | F7 | F8 | F9 |
|---|---|---|---|---|---|---|---|---|---|
| Personas | It varies by partnership. Some have a director and team (almost like an organization). Often it’s lighter: steering committee, operational/implementation team, perhaps advisors. A facilitator isn’t always needed; they can be internal (from one party) or external. Early on an internal broker may work well; when tensions rise, an external broker can help. | Facilitator, a researcher who is always involved—more on content, researching certain topics. Then of course the client. And we have “challenge owners”: people who own specific goals. | In terms of roles, the structure included work package leads, partners, lead partners, a steering committee, and a sounding board for advice. Every partner had an incentive to contribute actively — you had to prove your involvement to receive funding, so nobody could just sit back. Roles were largely standard and assigned at the start, without a separate collaboration agreement. | Key roles in any partnership span three levels: strategic leadership to endorse the overall direction, operational experts to deliver on commitments, and facilitators or support staff to keep communication flowing and handle administration. When there’s no team, the partnership architect fills all the gaps — including the unglamorous ones. | Project owner, community manager… | Depends on partnership and maturity. Bigger organisations will have layers of partnership and programme managers (more like e.g. war child) and they will do a lot of the strategic thinking. For smaller partnerships the senior levels of the stakeholders will decide, facilitator is the connector and operational level will do implementation. When a partnership projects has proven itself to be succesful and starts to mature, slowely more sub projects will emerge. | Project manager for every project | Multiple roles are involved in an innovation project. The client is always internal to SVB, holds ownership of the issue, and must be sufficiently senior in the organisation to be able to make decisions. The Innovation Designer (such as Jeroen) guides the process in terms of content, designs the working methods, and facilitates collaboration between parties. The business employees are the subject-matter experts who do as much of the work as possible themselves — conducting interviews, co-designing — so that they become owners of the solution. The portfolio manager oversees the whole from the outside. In addition, there are sometimes external chain partners (UWV, Tax Authority, municipalities) who join as stakeholders or collaboration partners. For larger decisions, the strategic innovation manager also plays a role, setting the overall direction and making the final calls. What stands out is that the team deliberately tries to keep the number of roles filled by Novum itself as small as possible — the business must lead, Novum facilitates. A project team always includes someone or a team from the business (SVB) who should hold ownership and, after the innovation project, can continue with implementation within the business itself — at which point Novum’s involvement ends. | |
| Facilitator role | It’s about developing partnerships broadly: clarifying the “why” of collaboration and strengthening partners’ capacity to collaborate—mindset, competencies, and attitude. You help collaboration run well (negotiation, conflict management), and you’re also connected to the purpose. You’re independent, but not neutral, because you care about achieving the collaboration’s goal. Facilitators wear multiple hats: meeting facilitation, negotiation, mediation, etc. Over time your role shifts—early on you do research (stakeholder/market research, mapping who should be involved). | The role can shift from one person to another during the partnership. What is important about the role is not so much the formal official role, but rather the informal power and influence. governance shifts as the alliance develops. So the orchestrators’ role role was to keep the communication flow and to facilitate governance shifts, rather than to hold influence or power. | bring a lot of different organizations together. And I try to connect them, guide them, and see how I can best support them to achieve the best result. facilitate sessions as an innovation facilitator, or you work on how different innovation methodologies (which we also have from DigiCampus) can be implemented to get the best result in a session or in a specific part of the project. As a project leader I think you do many similar things, but more across the entire project. So: how do all the pieces come together, how do all the organizations come together, and how can you ensure the whole project reaches the best ending or result. I don’t steer on what we’re going to do, but on how we get there. Once a direction is chosen, I make sure we translate it into concrete plans, stay on the right timeline, and keep the budget in check. My role is to ensure that decisions don’t just get made — they actually get executed. | it’s often a role where you connect different parties. Whether my role is more directing or supportive depends on the situation. A good example: in the “Co-Create Your Research” project on labor-saving technologies, my involvement varied a lot by organization. P-Direkt already had an internal team experienced in working with students, so they could largely guide the process themselves — my role was mostly coordinating to make sure things happened. CAK, on the other hand, had no such experience, so I spent much more time upfront explaining what to expect, and continued supporting and facilitating throughout. Same project, very different roles. | I prefer the term “partnership architect” over facilitator or broker. A facilitator is often seen as someone who helps people communicate in the room, while a broker suggests making connections or reselling — neither fully captures what I do. A partnership architect sets up the structure for the partnership itself. My role is to help organizations come together around a shared objective. In my current role at ISO, I also act as a broker — proactively identifying relevant partners based on the organization’s strategic priorities, mapping their partnering capacity, and structuring a portfolio of partnerships that serve different objectives without creating conflicts between them. | My role, community manager, is essentially that of a linking pin between the community of municipalities and Amsterdam’s product owner. I collect input, facilitate voting on feature priorities, share sprint review updates and newsletters, and make sure questions get answered — either by me or by other municipalities stepping in. The community itself is quite active; it’s not just me posting, others contribute too. I also maintain an overview of all feature wishes, linking them to relevant posts and people so nothing gets lost. Priorities are set based on broad community support and a simple impact-versus-effort logic. Features with little support or high development cost get parked, not dropped — everything gets registered. Beyond the platform itself, I also facilitate reference visits between municipalities and help make connections when one municipality’s solution could be relevant to others. | External facilitator. Facilitator is there to guide communication, manage expectations, transfer insights into narratives and financial reports, but not strategic role. A big part of the role is relationship management. Make sure decisions on strategic level are clearly and understandably transferred to the operational level (simple summaries of meetings), explain decisions and gather feedback in one-on-one meetings with partners, checking in to see if partners need help or have worries and make sure all the different partners are getting out of the partnership what they want (everyone is in essence still pursuing their own goals, not necessarily one shared goal) | my role was essentially to bridge different worlds — connecting municipal staff, private sector partners, and donors, and making sure everyone trusted the process. | Process guide and selects tools from toolbox: he follows the agreed innovation methodology as a framework, but within those boundaries decides for himself which working methods and approaches best suit the specific project. He is the discussion leader in sessions, designs the programme in consultation with the client, and ensures that all those involved come to see the issue in the same way — the “elephant” principle, where everyone sees a different part but collectively works towards the same whole. A core principle is that he lets the business do as much as possible and builds as little as possible himself — you only build in order to learn and validate, not to deliver. He also has a signalling role towards the PM: he spots trends, recognises new issues, and actively brings these forward. His role is therefore directive on process, facilitative on content. |
| project leaders | Depends on the partnership, but I prefer horizontal, as-equal-as-possible structures. Classic structures with steering committees, advisory groups, and operational teams can be quite “boring” and not the essence of collaboration. The key is working with people who truly want the collaboration and developing it while doing it—actionoriented, not designed behind a desk. A facilitator often wears different hats at different moments: meeting facilitator, negotiator, or guiding a steering group through decisions—depending on what’s needed. | We have monthly partners’ meetings, sometimes a bit lighter in the summer, where we are very frank and honest about whether we still have the people to do something or whether we should drop an effort. The decisions are democratic | The group basically makes the strategic decisions, but there is always a check with the client. But it’s really more informing him than anything else. We have a weekly meeting with the client, that is why there is a lot of trust between us. Also seeing each other a lot. Frequent contact is a big part of the trust. About the PL: In practice you work together with the project leader constantly: thinking, talking about what’s best, joining meetings, watching and thinking along—so they’re basically always involved. | The client’s role varies — some give me a lot of freedom and trust my lead, while others are more hands-on. In practice, strategic decisions are usually made together: I lay out my considerations, we discuss them, and the client makes the final call. How decisions flow more broadly depends on the type of project. In advisory work, our advice is often leading. In result-driven projects, you align closely with the client on what the outcome should be. And in larger programs, responsibilities are defined per work package — so within my area, I had final say. | Strategic decisions belong to the partners — they have to own the direction, otherwise they won’t stay in the partnership. My decision-making role is different: I bring a framework and good practice for how to partner effectively, and help partners make their own choices within that. For instance, whether to sign an MOU or keep things informal depends on the situation — but you have to make a deliberate choice either way. On capturing best practices: there’s a role for the architect to share experience and set guardrails early on, but the most meaningful good practices come from the partners themselves working through real problems together. Both matter. | My role stays focused on the substantive side: facilitating input, sharing information, and connecting municipalities with each other. The financial and governance side — formalizing the cooperation structure, setting up a legal framework, handling payments — sits with VNG and the steering group. I’ll chase people who haven’t paid, but calling budget holders isn’t really my place. The transition from Amsterdam as owner to Amsterdam as participant is still being worked out. A key open question is where the development will sit once it leaves Amsterdam, what role VNG will play, and how funding will work long-term — community contributions alone won’t cover it. The steering group currently has no formal mandate — it advises, but Amsterdam could technically still override it. That’s expected to change as governance is formalized. | Keep informed, report to, translate decisions into simple summary for operational layer | The Innovation Designer holds process ownership, while the client remains the owner of the content and the decisions. The PM acts as an intermediary layer: he qualifies the client at the front end and remains the point of contact throughout the project for escalations and steering at management level, allowing the Innovation Designer to focus on process facilitation. | |
| First phase (start) | Many collaborations start with a “coalition of the willing,” but ideally you need a “coalition of the needed”—those required to solve the problem. Coalition of the needed are the parties you truly need to solve the problem. The coalition of the willing are the ones who want to join; they’re not always the same. | identify a purpose and convey it to stakeholders, define some preliminary governance | Collaborations can start in two ways: either a client comes to us with an assignment, or we at DigiCampus identify an opportunity ourselves and then look for funding or an enthusiastic client to take ownership. So it varies. When it comes to where I add the most value, it’s in the connecting role. We work with many different organizations, and naturally, each tends to focus on their own piece — sometimes even keeping their work behind closed doors. I invest energy in breaking through that, making sure everyone collaborates and communicates openly. Bringing those organizations together is what I see as my most important contribution. | At the start of any collaboration, I try to set up a clear governance structure: who is responsible for what, how decisions get made, and how to escalate if things don’t go as planned. What those agreements look like depends on the scale — a few-month project with two partners is very different from a three-year EU-funded program with a consortium of seven. The latter requires nearly a year of preparation before you even start, with KPIs and deliverables already written into a grant agreement. Changes are possible, but require formal approval. | It starts with translating the initiating party’s goals — often framed in their own language and interests — into something all partners can agree on and contribute to. An NGO and a multinational will look at the same objective very differently, so part of the work is finding the version they can jointly own, with each bringing complementary strengths. | In theory they say, build relationship and then do something. In reality you build the relationships by doing something. Until you do something to share your value, it’s hard for the stakeholders to believe this party is actually going to add value instead of just talking about it or doing something they assume would help but is not actually needed. Tend to get further with 1 on 1 conversations. In group there is a lot of hierarchy involved. When a senior partner is invited in the room, the rest won’t say anything anymore. Try to do individual meetings first and have a group meeting later in the process. | At the start of a new project, the Innovation Designer establishes working agreements, role definitions, and a shared understanding of the challenge — he explicitly acknowledges that not everyone sees the problem in the same way, and that bringing those perspectives together is one of the first steps. He does this by designing a programme, always in consultation with the client. The scale and format of that start-up phase varies per project: a session with twenty people requires more preparation than one with four. Furthermore, the start-up phase is already prepared from a portfolio perspective by the PM, who has verified the right people, ownership, and preconditions at the front end before the project actually gets underway. | ||
| second phase (understand) | When a new project starts, goals and ways of working always need to be figured out together — the whole group has to be on board. I can have ideas about what works, but implementing them top-down doesn’t work. The group needs to arrive at their own agreements. A template outlining what to discuss and decide would definitely help speed that process up. A template can set some things as standard — like which tools to use or where to meet — but it’s still worth discussing them together, so the group feels ownership over the decisions. That creates more commitment. Starting with small shared decisions builds trust and a sense of togetherness, which makes it easier to tackle bigger choices later. So it’s important to keep things open rather than fully fixed from the start. | In larger consortia, getting alignment is simply harder — everyone has a vote, and there’s often a steering committee on top of that. The core activities aren’t that different, but there’s more coordination and more risk of people interpreting things differently. In the three-year program, the first year was mainly about getting to know each other, the second about learning from each other, and the third about actually building and creating. Shared language was a painpoint: We eventually created a shared glossary to make sure we were actually talking about the same things. Without that kind of shared language, frustration builds quickly. Keeping everyone aligned physically was managed through monthly full-day meetings early on, which gradually became less frequent. | The biggest investment of time and energy is in the setup phase. Once the framework is in place — shared objectives, clear roles, agreed ways of working — it becomes a management process, which can be hosted in different ways. The least effective model is when one of the partners hosts and controls the whole thing, as the power imbalance tends to undermine genuine collaboration. Governance and alignment are ongoing, not just a start-up activity. It begins with having the right people involved — not just the right level, but the right individuals, since personal compatibility matters. From there, it’s about clear expectations, shared responsibilities and risks, and a structured rhythm of check-ins where everyone knows in advance what will be discussed. Surprises undermine trust. The process itself also needs to be clear: will there be a secretariat, is it a fixed group or growing, is it bilateral or multilateral? Get those things settled early — but make the partners feel like they own the answers. | They often already know each other in her area of international development which makes it easier. However, there is often a role to play to bridge the gap between strategic level and operational level. Often a memorandum Of Understanding / partnership agreement is signed. Problem here is that this gets signed on the high level. Local language, simple summaries are necessary so all the staff knows what they’re signed up to do. Big part of this is in person communicating new information. | I needed a 360-degree view of everything, because what project managers report doesn’t always reflect the full reality. Once you build trust and a shared language, that becomes easier — but you always need access to concrete information from every angle. | After the start-up phase, the Innovation Designer guides the team through the successive phases of the innovation methodology (based on design thinking + lean startup): understand, experiment, transfer, and close. Within that framework, he has his own authority over which working methods and approaches he deploys — he determines, for example, whether more research is needed or whether a different route should be followed. A core principle here is that the business carries out as much of the work as possible itself: in customer interviews, for example, business employees are trained in advance and conduct the interviews themselves, while the Innovation Designer provides guidance. An important requirement within a project is that they want to speak with the people who actually experience the problem. Always work from the perspective of the people you are doing it for, the end users. | |||
| cocreate) | Most of our collaboration happens online — we meet weekly with 10 to 12 people from different organizations. We try to meet in person at least once every six weeks, because that really strengthens the connection. In between, I stay in touch with the various parties through email, calls, or visits. | most time spent within my own work package, making sure we delivered what we were responsible for. That was essentially a smaller project within the larger program, and that’s where the bulk of my daily work lived. | Where the actual work is happening is generaly somewhere else, not in a shared place. | ||||||
| fifth phase (transfer) | New municipalities usually come in through a tender or via VNG, and I give demos together with a colleague. After that, it can go quiet for months before they suddenly go live — they’re not obliged to keep us informed. Sometimes they join through an ecosystem partner, which means the community contribution conversation comes later and the relationship is less clear from the start. | ||||||||
| sixth phase (finish) | the idea is that the group you’ve connected may continue working together, so the facilitator role might be less needed. | On what makes innovation partnerships succeed: the innovation itself is rarely the problem — scaling it is. Most innovations stall because not enough effort goes into scaling. Bringing in impact investors early, particularly those who also provide business advice, can help bridge that gap. | For the longer term, development will continue beyond V2, with things like the shift from machine learning to LLMs already in the pipeline. | ||||||
| Tools used | SharePoint, Teams, Zoom | The framework I use covers six areas: intent, architecture, execution, growth, assessment, and capacity. Every partnership needs to work through each of these, though the answers will differ — no two partnerships are the same, but the questions you ask always are. In theory, you move through them in order; in practice, partnerships sometimes start from an existing relationship and work backwards. That can work, but it’s not ideal. | Connections between municipalities — like which integrations are running where — are tracked in a shared file that everyone can fill in and view. The community is largely transparent; in principle everyone has the same access and can see what’s being shared. | Mostly Whatsapp, Facetime or Signal. Reason: 1) easier acces: When wifi router is down/power is off, you can use (data on) your phone, your phone stays on for longer than your laptop, you always have it with you. 2) Gives them more confidence to answer; Worried about their accent or if English is good enough, need time to hear the question, understand it, work out if they know the answer, ask a friend if they don’t know, then answer. In call can be overwhelming, so messaging is preferred. | no specific tools mentioned that support the facilitator | ||||
| Monitoring progress | Often through agreed KPIs. But in new collaborations KPIs are difficult: they push you into a linear route, while collaboration is not linear. I prefer a “dynamic learning agenda” (DLA): identify barriers that stand between you and the shared goal and work on bridging them. Ideally you combine measurable KPIs with qualitative objectives. The most important thing is the conversation: not whether something is checked off, but why it was or wasn’t achieved—because that learning moves the collaboration forward. | Monitoring progress is important, but it’s not happening as well as it should yet. I spend time calling people for updates, but it would be much easier if progress were quickly and clearly visible — both for reporting to the client and for keeping my own overview. Measuring impact matters too, especially in a one-year project where you need to know whether you’re on track and where to adjust. And since we want to keep running this program with different topics, evaluating how we worked — how effective the process and outcomes were — is essential. The biggest value there is internal: learning how to improve. But it’s useful for the client as well. | Staying informed across work packages happened mainly during the full-day meetings, where each team gave an update. In between, there was little cross-package contact, and almost nothing was documented — notes stayed in people’s heads or on their own computers. With so much staff turnover, that’s a real problem. I always advocate for shared, accessible notes, and we had a shared Teams environment, but sharing notes still wasn’t the norm. When I asked for notes from a meeting I missed, the answer was often “I’ll just brief you” — while I knew they’d been typing along the whole time. Updates to the steering committee happened quarterly, with each work package submitting a short text on progress. That was essentially the only document where updates were consistently visible to everyone. | Progress is monitored both quantitatively, through KPIs, and qualitatively — including internally, by assessing whether your own organisation is actually getting what it needs and whether there are any unintended consequences, like doors being opened or closed. | the roadmap is being built based on community input — municipalities filled in which functionalities they actually use, which helped prioritise what needs to be in the MVP for migration to be possible. That process also helps Amsterdam step outside their own way of working and see how others operate. | Because she is working for small organizations, she does this, but she imagines in bigger organisations, there are specific partnership and programme managers that monitor progress and make strategic decisions based on this. She mentioned that as a facilitator, it is actually important to keep track of all the ‘private’ goals of the various partners. Even though a collaboration has in theory one goal that aligns with all partners, every partner is still going into the partnership wanting their own outcomes. If you’re not keeping track of what everyone’s getting out of it, then things can go wrong. | |||
| Collaboration | Collaboration is built by making connections and relationships. You do that by meeting people, visiting, understanding their context, needs, and priorities, and working toward alignment. It’s always people-work. Partnerships often fail due to people not clicking or due to turnover. There needs to be a “spark”—a click that makes people willing to collaborate and put a higher goal above their own interests. | It’s relational and based on trust built over almost three years. We feel like a good team with a purpose beyond protecting information. During the collaboration the idea is to multiply leadership and create ripple effects, so different people take on leadership roles as needed. | A lot of calling people, talking, seeing them, staying in contact—so everyone feels heard, seen, and involved. In sessions, you have to be sharp so everyone contributes and has space, but also outside sessions. | in-person days were consistently the moments where real connection and understanding happened — the many digital and fragmented meetings in between couldn’t replace that. | Capacity is a continuous consideration — both how many partnerships an organisation can sustain, and how many people are needed within each one. If the people who need to deliver are overloaded, the partnership won’t function. On information and communication: a shared folder is rarely enough. What makes partnerships really work is human interaction — regular meetings, open channels, active information management. Tools like Teams, WhatsApp, and email are useful, but you can’t just depend on them. | The main collaboration channels are a Teams environment with different channels for Signals 2.0 development, product guidance, documentation, and general discussion. The sprint review keeps everyone updated on what’s being built. The sounding board serves a different purpose — it’s where municipalities share experiences, present how they’ve implemented things, and spar with each other about practical challenges. The community aspect is genuinely valued — municipalities don’t just come for the software, they come for the network. Being able to ask other municipalities how they handle certain situations is something you simply don’t get with a regular supplier. That peer exchange happens both in Teams and through reference visits, where municipalities can visit each other in person to see how things work in practice. I help facilitate those connections, matching municipalities of comparable size and context. | mainly face-to-face, big part is relational. | The municipality had little experience taking projects from start to finish, which made engagement difficult at first. Public sector staff often work on isolated parts of a larger whole without ever seeing a full project through — like people designing different parts of a car who’ve never actually assembled one. So we brought in private sector engineers and project managers to fill that gap. What I found is that once municipal staff realised these projects were actually going to happen, they transformed completely. They became internal champions who pushed things forward from the inside. That shift in engagement was one of the most important things to cultivate. | At the start, working agreements are established and roles are divided. Collaboration is always bespoke — every project has a different composition and calls for a different approach. What also emerges is that ownership is a prerequisite for good collaboration: past experience has shown that if people do not feel they have been genuinely involved, they do not regard the outcome as their own solution. Tensions or bottlenecks within the team reach the PM either through the Innovation Designer or through informal channels, whereupon the PM acts as the first point of contact. It also becomes implicitly clear that collaboration can be vulnerable if the right people have not been brought on board from the start. |
| Specific Painpoints | Working with the public sector: They change more often and are less dedicated—not for personal reasons, but because as public functionaries they have multiple roles and limited freedom to choose what they work on. | A common frustration is that this work is always on top of people’s regular jobs. Some get dedicated time from their organization, others don’t — and that creates unequal commitment. How much freedom people have varies more by team than by organization type; it’s rarely bad intent, just a matter of pressure and priorities. In government, even attending a session can require approval, while in companies that’s rarely an issue. Beyond capacity, people sometimes speak different “languages” or have strong, long-held opinions — which creates friction, though it can also be productive. And a frustration shared by many is: when do we stop talking and actually take steps? Though what counts as “action” means different things to different people. | Personnel turnover was a challenge — nearly every organization had changes throughout the three years, making continuity difficult. I was one of the few who was there from start to finish. The biggest pain point overall is understanding each other, especially across disciplines. The word “innovation” alone means something different to everyone. | A key pain point is language: innovators can be so deep in their subject that it becomes hard for potential partners to engage. Another is that entrepreneurs naturally want to move fast and independently, which is fundamentally at odds with the pace and shared ownership that partnerships require. And in certain contexts — like working with governments or the UN — procurement rules add another layer of complexity, requiring creative solutions just to enable the right conversations. | Participation in votes and polls is around a quarter of municipalities, which isn’t bad but could be better. Turnover within municipalities makes consistent engagement a challenge. I try to keep everything as transparent and accessible as possible — sharing agendas, summaries, and outcomes in Teams so that even those who weren’t present can follow along. Staff turnover within municipalities is an ongoing challenge. People change roles or leave, and there isn’t always a good handover. We try to ask departing contacts to add their successor, but a proper onboarding process for new community members doesn’t really exist yet, even though there’s quite a lot to get up to speed on. | 1) Too much pressure on reporting numbers > partners feel as if ‘how’ or ‘what’ they’re doing is not important. 2) Concerns about security of direct messaging platforms + you cannot close out access to all (prior) documents etc in a whatsapp group if someone is not part of the collaboration anymore and is deleted from the group. | The biggest frustration is that all this work — involving hundreds of people and organisations — simply disappears when a project ends. It lives on a hard drive somewhere, and that’s it. A platform could change that in three ways: by keeping pressure on for continuity, by keeping people connected so something new can evolve, and by serving as a permanent record — not a blueprint, but proof that it happened, who was involved, and what was built. | First, there is the risk of working with the wrong people or at the wrong organizational level — experience has shown that when people cannot move forward elsewhere, they sometimes seek out new entry points, which can lead the team to take on a challenge that has already failed multiple times without being aware of this. Second, knowledge retention is a recurring challenge: when team members leave or lessons are not properly documented, valuable experience is lost. Third, building solutions with the wrong team — where Novum itself builds rather than the people who will eventually own and maintain the solution — has historically led to low adoption, reinforcing their principle of building as little as possible themselves. | |
| Room for improvement | We mostly reuse existing method templates from DigiCampus, adapting them where needed. A hackathon, for example, isn’t a new concept — we use it as a tool to move things forward. Designing entirely new methods isn’t the current focus. If something new emerges naturally, we’d want to capture it, but we’re not actively pursuing it. That’s partly because it’s not a priority, and partly a capacity issue — we don’t have as many innovation facilitators as we’d like, so there simply isn’t room for it right now. about using alkemio: We could also set up Alkemio better to create more engagement/community; now it’s used very functionally. Handling meetings takes a lot of time: preparation, the meeting itself, and follow-up—preparation and follow-up can take longer than the meeting. emails sometimes trigger a wave of replies about wording or intent, and email isn’t great for resolving that since input comes in one at a time. Part of the reason is that written agreements feel more binding than verbal ones — once it’s on paper, people want the wording to be exactly right, which can lead to backtracking or clarifications. | There are clear peak moments in terms of workload — midterm reviews and end-of-program reporting, for instance, where you have to deliver reports, financial overviews, and presentations to the European Commission. Those are administratively intense, and good templates would help enormously. But they often don’t exist, so everyone ends up making their own — which shows. A tool meant to create alignment in the consortium was the “mini-contract” — a canvas mapping partners to objectives. In practice, it created more confusion than clarity. It was treated as a required deliverable rather than a genuine alignment tool, never really discussed, and never revisited. Most people, myself included, didn’t fully understand it. | Partners change over time, and that’s something many organizations overlook — they write open-ended contracts when they should be time-bound or tied to specific objectives. That way, when a more relevant partner comes along, or when the work is done, you can part ways without animosity while keeping the relationship intact. What’s still missing is a smarter way to scope for partners. If you have clear criteria for what you’re looking for, being able to quickly identify the most relevant organisations is a real gap — and one where AI and new technology could make a meaningful difference. | Sharing within the community skews towards successes and practical questions rather than failures, though people are generally open about things that aren’t working well. There’s no structured way of capturing lessons learned, and I’d actually like to know more about how community members experience the collaboration — what they feel is missing, what they’d want to see more of — but I wouldn’t know how to organise that right now. | 1)A clear timeline would be helpful as well, with phases of the project. Some don’t like to talk about the deadlines, because they only want to talk about the nice things. The cost of the ‘free’ benefits, is the data. You should have these conversations at the beginning; set expectations and discuss how the data comes in, how we will prove that we’ve done what we said we would do and work this out together. 2) In a partnership it is not that everyone’s going after a single goal, but actually everyone is still holding on to their individual reasons for being in the partnership. If one of the partners is not achieving its own goals, they start to question why they are in the partnership. So keeping track of your partners means keeping track of each organization’s kind of wins against what they all together want to achieve. Insights in this would be very useful to see if there is a partner not getting as much out of the collaboration as everybody else. Helps to see where to put time and attention in order to prevent them to pull away. Now she does this by personally checking in, but that becomes hard if the partnerships are larger and these questions focus on worries and needs, might still lack overview of progress on their goals (compared to other partner goals). | On repetitive tasks where software could help: meeting preparation is an obvious one — briefing participants, maintaining a track record, handling logistics. And more broadly, being able to access how something was done before — even just a few lines left by a predecessor — is enormously valuable and almost never exists. | The Innovation Designer explicitly mentions one area for improvement: better retention and accessibility of lessons learned from previous projects. He describes how valuable knowledge is currently lost when experienced team members leave, and how it is difficult to find and understand what has been done before. | ||
| Platform Requirements | 1. reduce information asymmetry; a platform can be useful in that regard, especially when a small group of high-profile people rely on networks rather than platforms. 2. A platform can help when you have a small group of high-profile people who work via influence, but for some contexts, relationship and influence matter more. Platforms may be less effective when the key drivers are personal networks and executive influence rather than structured dialogue. 3. We aim to map knowledge gaps and use that to guide future work. | getting everyone to see the same information and be able to provide feedback, for example on an “advert” (announcement/vacancy/posting) that has to be sent out. Sometimes we work in Teams so everyone can comment on the document, but some people download it, add comments, and send it back, and then you have to process it. Similar for other documents and presentations. Ideally you’d work simultaneously in one place, but you work with many organizations and not everyone has Microsoft, so you have to involve them differently. Top priority: being able to work on more formal documents and export something you can share externally. Now we often use a screenshot of the whiteboard and put it elsewhere to show what we’re doing. It would be great if you could really get something off the platform to share more broadly and in multiple settings. There are notes/memos where you can type together, but it’s still a memo, not a document. If that were possible, I’d say we wouldn’t need Teams anymore. Government work requires formal documents; that won’t stop soon. Second priority: real collaboration adoption—how to bring along the people who are less quick/ less comfortable digitally. | You also have to be ready for change throughout. Personnel turns over, and external events can shift the direction entirely. Good documentation is essential for continuity — when a new person steps in, there should be a clear record of what was agreed, what’s been done, and why. For digital tools, the most useful categories are: tools to assess an organisation’s overall partnering strategy, tools to evaluate individual partnerships, and information management tools. One area still underserved is partner scoping — using criteria to identify the right organisations, which is where AI could add real value. The real need isn’t more theory — there are already plenty of models and frameworks out there. What’s actually needed is the practical work: taking objectives, finding the right partners, and facilitating their collaboration. In that sense, both words — broker and facilitator — capture something real. Brokering is about finding organisations and convincing them to work together; facilitating is about making that collaboration actually function. Those are the two core needs. | The main tools are Teams for everything community-related and email for the newsletter and steering group updates. In principle everything needed is already there, though it could be better organised. The product owner in Amsterdam largely relies on me to relay what’s happening in the community — he doesn’t look in himself much. | Since she is working with developing countries, there should be some usability when the internet goes down so that it will add the information to the server when you’re back online. Possibility of low data mode for people to use it on their phone. Direct messaging is the main communication tool so should be there as well. | A platform like Alkemio shouldn’t primarily be thought of as a project management tool — its real value is in giving the community ownership of the project and the space to connect and communicate independently. In our projects, people would only come together when we organised something. An online space lowers that barrier significantly. For community members, the added value would be threefold: coordination around shared activities, inspiration and ideas for new initiatives, and — perhaps most importantly — a living history of what has been tried, what worked, and what didn’t. If someone proposes an idea that was already tried and failed, a shared record could prevent that wheel from being reinvented. Reporting to donors always came down to two things: showing exactly where the money went, and demonstrating whether the project was on track. That’s straightforward in a construction project, but much harder when you’re trying to show impact on something like social services. A platform with open access for donors would let them see for themselves — going deeper than any report could. | - |
Portfolio Managers
| Topic | P1 | P2 | P3 | P4 | P5 | P6 |
|---|---|---|---|---|---|---|
| Portfolio manager role | it’s very diverse. If you look at innovation — and especially the multi-actor aspect, where government is one of the actors — there are different combinations. You have government that needs to innovate itself; in that case the government is the portfolio holder. But governments also sometimes have a mandate to innovate not for themselves, but for the market or a particular sector. Then they are more organising innovation. So I recognise the role of innovation manager, and multi-actor is the case almost everywhere. Practically speaking, it’s everywhere: multi-actor challenges where government is one of the players — sometimes as the provider, sometimes as the driver. | We invest in companies with a technology so they can grow and scale. To do that, we scout companies, help them develop their proposition further, and form consortia for technical or business model validation. We also look at which barriers companies run into when they want to grow further — we call those our ecosystem projects. In terms of how we work: we do almost everything ourselves. We signal a problem, set up a program, co-create with companies to understand what they need, secure budget from municipalities, run voucher rounds, build a website, scout companies, help them write applications, set up selection committees with external parties like Medical Delta and TNO — and then we stay involved throughout. We call companies regularly, connect them to the right people, and organize masterclasses when needed. Sometimes we take a different role — we set up a consortium with companies and a university, find a subsidy scheme that fits, and then step out. So it’s roughly half-half. The community manager role is not something we see as ours. But we do sometimes help set one up. we’re also searching for what our role should be as we’ve matured. we try not to become the secretary. It can happen that you suddenly end up always writing the minutes and setting all the agendas, and at some point you have to place that back with the group — they shouldn’t keep leaning on you | With only 2.2 FTE, all roles are very much rolled into one at the moment. I’m the director, we have a programme manager, and a caretaker who handles the technical side. There is no separate facilitator or portfolio manager — it’s all combined. we are both a physical location and a network organisation — connecting pupils to companies, arranging company visits, helping students find the right business for a research project. we’re also programme manager. Relationship management is therefore constant. What really helps is honouring commitments, good agenda-setting, following up on action points, and having a fixed meeting structure at director, team leader, and teacher level. | What also plays a significant role is the informal influence side. If a good innovation gets stuck in a permits department because it doesn’t fit the format neatly, I can simply call the manager directly and say: this needs to happen, something seems to be going wrong. That person speaks to the right department head and it moves forward. That’s something you can’t easily do from within a municipality yourself. I genuinely think that in a large number of our successes, it’s exactly these kinds of things that made it happen. That’s hard to capture in a model, but it’s very real. a large part of what we do is that process of concretisation. The networking element is equally important — connecting people who want to learn from someone who has already done something. Knowledge is very fragmented, and we certainly don’t have all the answers. But I do dare to claim that we often know better than the average municipal employee what has already been investigated, done, applied, and learned. | My role is broadly about making sure innovation within Rijkswaterstaat gets on the map — but not just internally. A big part of my work is getting that organised between stakeholders. That’s also why I work as secretary at TKI Delta Technologie, looking at how you can team up with partners as much as possible, especially in times of financial constraints. If you can create a win-win with knowledge institutions and the business sector, that’s obviously a bonus. My role in all of this is really connecting and accelerating — continuously looking at where the challenges are, who has them, and how we can make a step forward given our limited resources. | The PM has a clearly distinct role in each phase of a project. At the start, he assesses whether a project should be taken on at all: does it fit the innovation methodology, are the right people and the right mandate in place, is there sufficient priority, and is the chance of implementation realistic? He actively brings in the right projects and keeps the wrong ones out. During a project, he largely steps back: he monitors via status updates and automatic notifications, produces progress reports for management, and is the first point of contact when something goes wrong or changes — he flags overlap between projects and intervenes when progress stalls or quality comes under pressure. At the end, he ensures that the outcome actually lands in the right place within the organisation, whether follow-up work is needed and how that should be structured — and he critically evaluates whether a project that did not lead to implementation yields lessons for future decisions. |
| goal of innovation | Most people look at new things and doing things in new ways. But I think a lot already exists, and that it’s more important to stop doing things. That’s the hardest part. Innovation is, in my view, really a behavioural change and an organisational change, where things like digitalisation can be a huge support. But all those actors do have to want to use current capabilities to do certain things better, smarter — and preferably stop doing some things. Because if you don’t do it anymore, you can’t make mistakes; it costs no money and no time. Most innovations are often incremental: very small improvements on the existing system. | We’re very good at saying ‘this isn’t working, let’s start something new’ instead of asking how we can improve things together. | What we saw very early on is that validation in a lab, a computer model, or on paper is simply not enough for public end users like water authorities and municipalities. They need to see things work in reality. That’s why we developed what we call a stepping-stone model — physical experimentation environments that bridge the gap between theory and real pilots. The translation piece is something the public sector is just not very good at. Policy documents are full of ambitious statements — ‘innovation is high on our agenda’, ‘30% of new buildings will be climate-adaptive’, ‘all water authorities will be CO2 neutral by 2050’ — but what does any of that actually mean in practice? I’ve worked with one water authority for 10 years that has had literally one innovation advisor for two days a week and never had a budget. And yet their first line is ‘innovation is high on our agenda.’ That just doesn’t match. With climate adaptation targets, nobody asks: where are we now, what does 30% even mean, how do you measure it? Everyone just nods along. If I said I’m going to run a marathon in April, you’d immediately know what that means for your daily life. But these kinds of policy ambitions — they require everyone to make different choices every day, and that translation simply never gets made. | The distinction between collaboration and steering is important. Collaboration — internally and externally — is about getting an innovation further together. Steering is what you need when collaboration stalls. Those are two different things. | The PM defines the goal of innovation in two ways: on the one hand, scaling up concrete solutions that improve operations; on the other, spreading the innovative way of working itself throughout the organisation. For him, innovation is never “finished”; it is not about a finish line of completed projects, but about a sustained movement towards more innovation and more implementation. In this regard, a proven solution is only successful if it actually lands in the regular organisation — otherwise the project has not achieved its goal. | |
| Decision making | there are two types of portfolio managers. The ones who manage a spreadsheet—and you see a lot of them in big departments with hundreds of small innovation projects. They keep a kind of scoreboard: who is doing what, how much time it costs, and then in that spreadsheet they try to prevent too many people from colliding with each other. And then you have the innovation manager who actually has a mandate—who is more managerial/leading. That person will take a different course: they will focus less on whether everything is administratively recorded on paper, and more on whether it leads to value and whether it’s actually adopted. So I do see two types of innovation managers. And the larger the organization, the bigger the risk that a collection of innovations is called a “portfolio.” But that’s not quite true. If you have a portfolio, you must be able to manage it—meaning you can say: this project and that project conflict; we shouldn’t do both, because that’s waste. That requires a very different role and responsibility. With a spreadsheet you can signal it, but you don’t really have authority over it. | Decisions are made based on financial and time investment. Up to around €10,000 in hours, the team lead decides. Above that it goes to the head of innovation, and above €50,000 it goes to the MT — though mainly when we’re committing co-financing or a significant flow of money is involved. Substantive decisions are trusted to the colleagues who work directly with the companies, tested with the team lead. I’m team lead for Horticulture and Life Science & Health, and within the sector plans we draw up together every few years, I can largely make those calls myself | In terms of deciding which projects to pursue, we work mainly demand-driven. We don’t see a grant and then think up something for it — it’s the other way around. We hear what’s happening in the region, bring parties together, and then find out where the resources can come from. Sometimes a request comes from a school or an external organisation, but very often we are the driving force ourselves. | Over the years the themes have shifted from flooding to drought to water quality, and most recently biodiversity came up — the province came to us after an EU directive and asked what we could test. We don’t decide on those thematic additions alone. I put them on the agenda of the steering group, where dike managers, directors, and aldermen sit, and we discuss together whether it fits what we can do here and whether we’re the right party for it. | When there are different opinions within the organisation, someone needs to have the mandate to say: I’ve heard both sides, and we’re going left. That’s really a thing for us. You genuinely need an owner of an innovation who has the authority to make that call. With the asphalt rejuvenation cream example, the responsible director ran into a problem with a particular unit and simply couldn’t get their capacity — they were stuck with other priorities. That’s why you need things escalated to a high enough level. That’s also the strength of innovation portfolio management: you have a large portfolio, you have to make choices, and you need someone at the top who can be called on when things get stuck. We’re also developing what we call an ‘opgave portfolio’ — a challenge portfolio. The idea is to bring together the top-down strategic priorities and the bottom-up signals from people on the ground who are running into problems right now. If one region keeps hitting a certain issue, and it turns out another region has the same problem, and another part of the organisation does too, then you get a kind of common ground — ‘there’s really something important here, we need to do something with this.’ We try to involve our stakeholders in that too. | Decision-making is layered and shared: the strategic innovation manager sets the overall direction and cuts through uncertainty when needed, while the PM coordinates and prioritises based on that direction (the innovation designer facilitates projects in terms of process). The most important decisions sit at the front end of a project — does it meet the ‘novum innovation method’ requirements, are we going to do this, with whom, and does it fit our way of working? Interim decisions about deviations from the method are made consciously and explicitly, not taken silently. An important insight is that informal decision-making carries at least as much weight as formal: the PM notes that people who have been kept well informed along the way are far less likely to reject a project at a formal decision point — good information provision is therefore itself a steering instrument. |
| Overview of what info | Instead of plans and hours, give me the concrete stepping stones. If you want to inform or show something, then show: which concrete stepping stones have you realized in your innovation? The risk of focusing on hours is: ‘we spent 1,000 hours’—okay, but what did you get out of it? People don’t ask that. I don’t think ‘information’ is the right word in the innovation world. I’d put communication at the center rather than information. In innovation, you’re communicating and aligning with each other on how you will implement change. Reports aren’t the best way to do that. Innovation managers don’t get information, they have to go and collect it, that is something you don’t get from reports | How we make decisions has evolved over the years. In the beginning we just hired people who knew the sector and leaned on their judgment — someone came with a good story and we tried to shoot holes in it. If we couldn’t, we moved forward. Gradually that stopped working, so now we try to be more analytical: how many companies are in this field, where are the problems, how much funding have they raised. But data only tells you so much, so we still substantiate it with interviews and conversations. Ultimately it’s still quite exploratory — we test whether companies actually need what we’re thinking of and whether they’d want to participate, and from that we gauge whether we have enough confidence to move forward. | Impact monitoring is mainly informal. After each hackathon we get together with the working group to evaluate. We also send out evaluation forms to pupils and teachers. But there is no tight structure for that yet. Grant objectives do force you to measure certain things — with Tech Kwadraat, for example, we want to bring 75% of pupils into contact with technology — but you can never really establish cause and effect from a single lesson kit. So the targets are always somewhat arbitrary. What we do track carefully are our own KPIs: how many pupils and classes are we receiving? Right now the priority is simply getting schools to find us in this new building. But it is a balancing act between quality and quantity — I would rather have two groups leave here bouncing off the walls than have twenty classes come through and not really get anything out of it. | We do track our network carefully — in Excel — including all the scale-ups of our innovations across the Netherlands. We report on those annually to the steering group. Right now we have more than 160 locations across the country where an innovation that started here is in use. We find that important to document. | The information I most want to discuss in our monthly meetings comes down to two things: the business case — what is it going to cost and what will it ultimately deliver, especially when resources are limited — and the impact analysis: what does implementing this innovation actually mean for our organisation? Which processes need to be reorganised, what are the legal implications, who needs to be involved? Those are the things that tend to come up around the larger trajectories. We have various inputs for the challengeportfolio — the public helpline where people call with complaints or questions, and our daily internal news digest that tracks how Rijkswaterstaat appeared in the news and how the public reacted. A recent concrete example: a lot of bridges have been struck by ships lately, causing disruptions for both road traffic and shipping. There was a lot of public reaction — can’t something structural be done about this? Internally I found that the same view was shared, and someone at WVL was already thinking about it. We also have a unit that works with students — DOK RWS — so we brought the problem to them to think about creatively from multiple perspectives. That’s how abstract challenges become concrete. | The PM maintains an information overview through a combination of his project management system (Jira), automatic notifications for deviations, monthly status updates from team members, fixed meeting moments, and informal channels. Within that overview, he wants to be able to see at a glance for each project: the current phase, the issue, the assignment brief, the client, the team members, start and end dates, and the most recent status update. His ambition is to develop this further into a system that proactively presents the right information to the right decision-makers at the right moment — not only for himself, but also for management above him. An explicit starting point is that the system must also be pleasant and easy for team members to work in: only if they actually use it will the information remain reliable. The biggest gap remains a searchable knowledge database of previous projects and lessons learned; currently that knowledge is scattered across reports, working documents, and people’s heads, which becomes vulnerable the moment someone leaves. |
| Monitoring progress | The ones who manage a spreadsheet—and you see a lot of them in big departments with hundreds of small innovation projects. They keep a kind of scoreboard: who is doing what, how much time it costs, and then in that spreadsheet they try to prevent too many people from colliding with each other. And then you have the innovation manager who actually has a mandate—who is more managerial/leading. That person will take a different course: they will focus less on whether everything is administratively recorded on paper, and more on whether it leads to value and whether it’s actually adopted. What they need is a platform—a platform to get in touch with people and align. That’s talking, not just receiving information. So you need to meet regularly—physically or online—to establish: where are we? Then you can see progress and whether new opportunities are emerging. Core message: the best way to track progress is through direct, regular contact — not through administrative tracking systems. | We also work with impact mapping. We reason back from a goal — like accessible care — and ask: if we do these activities, what do we actually influence? Things like TRL increase or investor-readiness. We try to measure that, though we don’t do it for every project because it takes a lot of time and we track it all in Excel ourselves. Every quarter, per sector, we review where each project stands and how much capacity we have. That balance is sometimes tricky — once you’re deep in execution, it’s hard to let go, but if you can’t let go, you can’t pick up new things either. | We keep track of progress mainly through our meeting structure — a daily board five times a year, meetings with school directors and team leaders, fixed agendas that also serve as a reminder to check in on things. Grant accountability requirements also force you to monitor carefully. also interim of course. You also just want to know the progress. Or they have a question. we are organising company visits, and other communication varies per person — WhatsApp, Teams, calling, emailing — it can be all sorts of ways, really. We don’t have a fixed system for that with reports or colour codes or anything like that. | We currently have more than 400 innovations in the portfolio. Every six months we ask people for an update to keep the overview current. We started with SharePoint and Excel, but we’re now building a much better application — partly because steering groups got really enthusiastic when they saw what you could do with it. They wanted it back every six months. The new application tracks things like: who submitted it, who is leading it, which partners are involved, what phase it’s in, which Rijkswaterstaat objectives it contributes to, cost-benefit analysis, and when it’s expected to move toward production. It’s primarily for internal use, which is also a deliberate choice. We work a lot with the private sector, and there’s intellectual property involved — companies don’t want everything about what they’re working on to be publicly visible. So at a higher abstraction level we might signal that we’re working on many types of sustainable asphalt, but the 40 specific variants underneath — that stays internal. | The PM monitors progress through defined project phases in which projects are actively tracked, supplemented by automatic notifications when a phase runs on too long or when no new work has been scheduled under a project for an extended period. Team members provide a brief monthly status update on where they stand, potential bottlenecks, and anything noteworthy. In addition, he reviews all ongoing projects together with the team in a three-weekly portfolio meeting. An explicitly mentioned wish relates to trend research. This is currently included in the portfolio, but not yet in a way he is satisfied with. They have discovered that trend research also follows a phased approach. He wants to incorporate the phasing of this trend research into his portfolio and make the interim decision points more concrete. This is, however, a matter of priority and time, and they intend to take it further at a later stage. | |
| Sharing learnings + knowledge | 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. | 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. | 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. | 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. | 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. | |
| relations within community | Innovation managers bring people together. And then they say: ‘That’s interesting—now we see new connections between these two projects. You can work on things together and avoid duplication.’ They don’t only make the plan from outside-in… they also talk with people on the work floor, and with customers; they talk with competitors; they talk with suppliers and partners. They are very active. | On the health of a partnership, we don’t have formal tools, but we do pick up on it — and precisely because we’re more independent, we can make things discussable. If a university is being too dominant and the companies are just hanging along, we can say: this is skewed, it’s supposed to be give and take. How well we do this does depend on the person though — one colleague is very sensitive to group dynamics, another just looks at whether the project is making technological progress. | What we are firm about is that everything should be very regional in character — down-to-earth, talk less do more, not too much high-minded language. You need local knowledge and a feel for the culture to pull that off. What’s very characteristic of our region is that 80% of businesses are SMEs. You can’t just send an email and expect it to be picked up. You have to make it as easy as possible, filter carefully who you approach with what, and get ambassadors working for you — people in our network who naturally make the connection. | In terms of how we collaborate within the community, we have a core group with representatives from all our partner organisations — water authorities and municipalities. Each partner sends a diverse mix: a maintenance manager, a policy advisor for climate adaptation, and so on. That group comes together physically four times a year, very often at the Green Village to see new things, but sometimes also at a partner’s location or alongside an event. Then we have the steering group, which meets twice a year at management level to discuss progress and put forward new themes. On top of that I have very frequent contact with every partner — daily, really. I don’t think a week goes by without being in touch with someone from Delfland, Den Haag, the province, or elsewhere. And they come here often too — different departments visiting to look around the test garden. We’ve also built some of that contact into structural routines. so I also just cycle over every now and then — you need that to hear what’s really happening. Because if you wait for them to come to you with a question, you can sometimes wait a long time. | My day-to-day visibility into how collaborations are actually progressing is limited. The portfolio managers of specific focus points have more insight into that. If an innovation really stalls or there are serious problems, I usually hear about it through our monthly meetings with the focus points, where we go through the main issues and also look at where there are cross-overs between focus points. But we don’t go very deep on individual innovations every time. | Communication within the project community is a mix of formal structures (stand-ups, portfolio meetings, monthly status updates) and informal channels that are at least as important — signals often come in through personal contact before they become formally visible. The PM acts as a central pivot with a broad relationship network, both internally and with chain partners. A crucial condition for good collaboration is that the right people are at the table: someone with genuine ownership and decision-making authority. A notable vulnerability is that much relational knowledge is person-dependent — when people leave, a gap opens up that is difficult to close through systems alone. |
| Systematizing collaboration (replicating structural approach) | it’s important to have an approach upfront. you can explain that it’s smart to connect to BOMOS, which is an open standard approach offered by Logius. So BOMOS can be used as an approach—but it’s still a very high-level one. if you procure every time, you lose all the knowledge you had. the single-budget approach is extremely helpful to stimulate innovation— suggesting a structural financial model that enables continuity rather than restarting each time. | At a higher level, we manage a project portfolio with four phases: signaling, exploring, accelerating, and then either execution or saying goodbye. In terms of tooling, we’re actually quite limited. A lot of knowledge sits in people’s heads. We have a CRM system, but it doesn’t really work well. We track which companies are linked to which projects, but broader ecosystem mapping is hard. We sometimes commission a sector analysis from an external party, but we don’t have the software or the structural setup to do proper network mapping ourselves. We’re still too much organized as an hours factory — it all sits on skills and relationships, and we miss that broader infrastructure. | The innovation process rarely follows a neat funnel — it’s much more often chaotic than a tidy step one through ten. What I think is really decisive is knowing how to find the right people in the network. The people who enjoy working with us at a municipality or water authority are already a particular type — people who care about sustainability, about innovation, about change. And we tend to gather the people who dare to take action and who will bring others along within their own organisation. There is a certain repetitiveness to what we do, even as themes change. The whole cycle of scouting, testing, monitoring, sharing, asking for feedback, developing further, and setting up first pilots — we ran that entire cycle for flooding, and we’re now essentially running it again for biodiversity in the city. The structure is a bit the same — but on a different theme with completely different people. | One concrete area is the scaling-up process — we’re trying to streamline that so it goes faster. Part of the reason it takes long is legitimate: if you have an asphalt innovation, you need to test it thoroughly for durability before you put it on a road, because otherwise you get safety problems. But sometimes it takes unnecessarily long because of all kinds of hiccups in the process, and that’s something I’m actively working on. We do have a methodology for the innovation process — what we call IUP: innovate, uniformise, and produce. When I arrived, everyone was doing the uniformisation phase in their own way, so we standardised that fairly well. The steering part is still a real point of attention, and we’re trying to address that in the new knowledge and innovation strategy. | Novum works according to a fixed methodology (design thinking + lean startup) with defined phases, but applies it deliberately with flexibility — every project is bespoke. The PM actively monitors whether new projects fit within that structure, and exceptions are only made with well-founded reasons; when such exceptions recur, they become a new “flavour” in the portfolio (such as the AI experiment track). | |
| Role in the Innovation process | we go and figure that out: is it simply a matter of matchmaking, or is there a deeper disconnect? Once there’s a shared language and a clear problem definition, we can usually step out again. That said, it doesn’t always go smoothly. With Robocrops in agri-tech, for example, we’ve been at it for years. The idea was to create an intermediary organization to bridge growers and technology companies. But we haven’t found a model that works well yet — it still costs a lot of time and support from us, and at some point you have to ask yourself: do we give this up, or do we push for another year? What partners generally want from us is project management, communication, visibility — being on stage, access to new customers. And of course funding, but we don’t have project financing ourselves, so that always requires collective effort. | My own role is very varied. A lot of it is pushing — keeping parties moving, because for both businesses and schools this often feels like an extra job on top of their day-to-day work. Day-to-day building management, communications, PR, onboarding new partners, keeping local councillors and municipal civil servants informed — and that times seven municipalities, each with their own layers of management. | The Green Village is that: a real mini village right on our campus, with streets, squares, buildings, permanent residents, an energy grid, a heat network, solar panels — everything. But with a fence around it. Inside that fence we have a special status that lets us experiment with building techniques, materials, paving, water capture — things that aren’t allowed elsewhere. And we monitor everything carefully, because at heart we are engineers and scientists. What that setup allows us to do is involve water authorities and municipalities very early in the process. When someone comes with a new type of nature-friendly bank, we share the plan with them immediately and ask for their initial concerns. Then we install it, monitor it, and come back after a year or two with results. After more than 10 years we’ve gotten much better at understanding how municipalities and water authorities work and what you need to think about when you want solutions actually implemented. | The innovation loket — our innovation desk — is the intake point for ideas coming in from the market. They check whether something is a priority and link it to the relevant focus point. On the one hand we’re genuinely happy when companies proactively bring ideas. On the other hand, sometimes we say: lovely that you’re bringing yet another variant of asphalt, but we already have so many in development — not right now. And occasionally a company comes in with something we hadn’t even thought of yet, running ahead of us, and then we get genuinely enthusiastic. | The PM safeguards the quality and feasibility of incoming projects at the front end — his core question is always: the right people, the right issue, the right conditions? Once a project is underway, he largely steps back and monitors from a distance through automatic notifications, status updates, and informal channels. He only intervenes when there are bottlenecks or changes. His role is therefore explicitly facilitative and coordinating, not content-driven — he describes himself as the person who arranges the preconditions so that the team can do its work, and who ensures at the end that results actually land within the organisation. | |
| Tooling needs | In terms of tooling, what would really help us is better network mapping and clearer overviews of the ecosystem — which companies are there, how long have they been around, what phase are they in. I often get asked what this region is better at than others, or what the top ten fast growers are, and every time it costs us time to dig that out. We know the sector well by now, but making that visible to others — or to people who are new — is still hard. | In terms of tooling, we don’t have a proper CRM yet — just Excel overviews. With only 2.2 FTE, there’s a real vulnerability: if someone drops out, how do you pass on what they know? What we’d ultimately like is a login environment on our Techles website where teachers can download lesson materials but also share their own projects with each other — so that a real community of teachers develops and they start learning from each other. Because we provide the facilities, but we are not teachers ourselves. There are a huge number of follow-up actions involved, and a lot of that could probably be automated with a proper CRM system. We don’t have one, so it’s either in your head or on a list somewhere. The same goes for information management more broadly. Teams has become a jungle — files everywhere, channels nobody can find anymore, and in the end people go back to emailing. Bringing some order to that would benefit everyone. It is on our wish list, but not something we are going to tackle right now. | In terms of documentation and visibility, we go well beyond Excel sheets and heads. We produce a programme report every year with photos, figures on planned versus actual scale-ups, visitor numbers, student involvement, and an overview of all new innovations. We also make a scale-up map showing where all those installations are across the Netherlands — and often the people we speak to don’t even know they’re already doing all those things. We share infographics of our partner network, our targets, research collaborations, knowledge sessions — all of that goes out to partners. Making that visible is important to us. | On the question of what kind of platform or tool could add value: from a Rijkswaterstaat perspective we already have something organised internally, but from my role at TKI Delta Technologie I’m genuinely curious about tools that can support collaboration between different organisations. What I notice is that there are many collaboration networks out there — Bouwcampus, Next Generation Infrastructure, Topsector Bouw en Infrastructuur — and it would be really valuable if you could see what’s being worked on across all of those programmes side by side and exchange between them. That’s where I think there’s a real opportunity. On ecosystem analytics specifically — being able to type in a topic and find out which companies or parties could play a role there — we actually did a pilot with something called the Innovatiespotter, which does exactly that. That might be worth looking into for what you’re building. | The PM needs tooling that does three things: proactively prepare information without constantly burdening people (filled as automatically as possible), flag in a timely manner when projects are stalling or going off track, and provide decision-makers at various levels with the right information at the right moment. A specific unmet need is a searchable knowledge database of lessons learned, so that when starting new projects he can quickly retrieve what has been done before. What he explicitly does not want is a system that serves only him — tooling must also work well for team members, so that they actually use it and the information remains reliable. | |
| Time lost | One thing we haven’t really touched on yet is the time we spend aligning national policy with the region. With something like defense, everyone is suddenly shouting about it nationally, but translating that into something concrete for regional SMEs is incredibly hard. Try getting someone at the Ministry of Defense to actually meet with an small company. So we spend a lot of time helping companies understand what new regulations or priorities actually mean for them in practice — and pushing ministries to not just launch challenges, but also ensure development funding and actual procurement follow.Bridging that national-regional gap takes a lot of capacity, and if we’re too deep in execution projects, we can’t free that up. So it really is one leg in the policy meeting cycle and one leg with the companies, trying to build that bridge — ideally through a concrete project or program. | keeping municipal civil servants informed and the network up to date— and that times seven municipalities, each with their own layers of management. I don’t have the illusion that you can keep your entire network continuously well informed, because it’s simply too much. We use a newsletter, LinkedIn, Instagram, personal contacts, the local newspaper — but you’re always operating multi-channel and you can’t reach everyone all the time. What takes disproportionate time is grant administration — tracking hours, co-financing forms, Chamber of Commerce numbers on everything. | In terms of finding the right partners for new innovations, that’s more the role of our knowledge field trackers and the people responsible for specific innovation portfolios — like someone who manages the bridges portfolio. They look at what’s already out there. We also have a department for international contacts and a department for knowledge relationships with account managers at TU Delft, TU Eindhoven, Wageningen, TNO, Deltares and others — we ask them what’s already known in a given area. It’s always a bit of a search process, and I’m not sure it’s always done equally well. That’s also where the innovation portfolio is really useful — you can search on a keyword and immediately see everything we’re working on internally. In a large organisation of 10,000 people, you simply don’t know what’s all going on otherwise. | The PM spends a considerable amount of time assessing and qualifying incoming projects — his first question is always whether the right people, conditions, and priority are in place. A notable time drain is retrieving knowledge from previous projects: without a proper knowledge database, he has to search through files and conversations to find out what has been done before. Finally, he spends time on reports for management and the strategic innovation manager, for which he has to bring together information from multiple sources. |
Insights
Synthesised insights derived from the interviews above.
| Insight | Source | Innovation Type |
|---|---|---|
| PM role: Selection and alignment | P6 | Organisation driven |
| PM role: Administrative focus without strategic mandate | — | Programme driven |
| No portfolio management layer in issue-driven collaboration | F5 | Issue driven |
| Innovation is fundamentally about changing how people work | P1 | — |
| An innovation only counts when it lands and scales | P6 | Organisation driven |
| Scaling requires someone with the mandate to decide | P5 | Organisation driven |
| Most consequential choices happen at the front end | — | — |
Source: Interview analyses.xlsx