Tendering for case-oriented working (ZGW) under Common Ground: pitfalls to avoid

The Association of Dutch Municipalities (VNG) identified the need for a modern information architecture that makes data exchange easier and more flexible. This need led to the Common Ground agreement. As a municipality, this means you must review and adapt your IT infrastructure to comply with Common Ground. But what should you watch out for when tendering such a large transition? In this blog, we highlight the three biggest pitfalls to avoid when setting up your Common Ground tender.

Common Ground in a nutshell

The goal of Common Ground is to help municipalities address societal challenges in a simpler, faster, and smarter way. This is achieved by decoupling data from processes and applications. The previously used ZDS API standard (Zaak and Document Services) is replaced by the ZGW API standard (case-oriented working).

The key shift is moving away from silo-based thinking toward an IT architecture built on modular connection points that can easily be connected and disconnected. Another essential principle is that systems should be developed using open source technologies.

When preparing a tender for the transition to case-oriented working under Common Ground, there are many aspects to consider. Below are the most common pitfalls to avoid.

Pitfall 1: Making the Common Ground tender too large

Changing your way of thinking does not happen overnight. A common mistake is to immediately create a large and all-encompassing tender. Municipalities are used to tenders that require extensive preparation, time, and effort, which often leads to the assumption that it is better to include everything in a single tender.

In a Common Ground transition, this approach causes two major problems. First, the project becomes so large that only the biggest IT vendors can participate. These are often the same vendors municipalities have worked with for years, many of whom still operate with a silo-based mindset and struggle to support truly decoupled systems.

Second, such a tender often takes years to complete because all responsibility ends up with a single supplier.

Our tip: avoid this pitfall by splitting the work across multiple tenders. Outsource the development and maintenance of integrations to an integration specialist and do the same for components such as the front end and back end. This allows each specialist to work in an agile way within their area of expertise and deliver the best possible solution.

Pitfall 2: Shifting the vendor lock-in

When you issue a large tender or place multiple tenders with the same major vendor, there is a high risk of shifting the vendor lock-in rather than eliminating it. Large vendors often work with “as a Service” contracts, where you pay a fixed monthly fee and the supplier delivers according to their own methods.

In this setup, you have limited ownership of both the product and the way it is developed. This increases the risk of creating new silos, as multiple components are intertwined within one supplier’s ecosystem and data becomes embedded in applications. If you later want to switch suppliers, extracting your data from multiple systems becomes extremely difficult. This results in a new vendor lock-in, precisely what Common Ground aims to prevent.

Our tip: always ensure that data is processed within an integration layer and decoupled from applications. This is exactly how we approach it with the Frank!Framework. By separating data from applications, you can replace or disconnect systems as needed without losing data. This significantly reduces the risk of vendor lock-in.

Pitfall 3: Looking for a partner but ending up with an SLA

In many tenders, the focus is still primarily on requirements that are then formalized in a Service Level Agreement. However, municipalities are often looking for a true partner who actively thinks along, understands the municipal context, and is committed to building the most effective solution possible.

Modern IT architectures require close collaboration. An agile partnership makes it possible to continuously improve solutions and adapt to changing needs. When an SLA becomes the central element of the relationship, collaboration is often reduced to meeting predefined contractual obligations rather than jointly working toward the best outcome.

Our tip: design your tender in a way that emphasizes collaboration, involvement, and shared responsibility, rather than making the SLA the central focus.

Getting started with Common Ground

Ready to move toward case-oriented working under Common Ground? Before starting your tender, take a look at our checklist, “What works best for your municipality: replacing the case system first or task applications first?”. This checklist helps you determine the most suitable route for your municipality when beginning the transition to ZGW.