Dutch
English
Building software for the government after the Elias committee: what do we do differently?
The results of the Elias Committee were recently announced. This committee has conducted a parliamentary inquiry into the ICT projects in government. We were very curious about these results because, in addition to our consultancy work, we have been working for the government as an ICT service provider for ten years now. Products such as Boogie, DGM, the Virtual Acoustic Advisor and SPERoN are examples of this. We recognise the sketched out problems. Over the years we have developed our own vision and working method to carry out projects on-time and on-budget. So how do we do that? Take a look in our kitchen.
For us, a project is successful if the (government) customer gets a product that is actually used to solve a problem or carry out a process more efficiently. As a supplier, we feel really responsible for the usability of the end result. It may sound logical, but our customers have told us that this is not self-evident.
We actively involve our customer. By interacting with the customer, we have a better understanding of what is going on, the purpose of the product, and how the product will be used. We prefer to use the planning game for this. In a joint session, our developers and the end users (often not the same as the client) make a realistic overview of the functionality to be achieved and the planning of the development process. The end users determine what they need and what it should look like. Our developers provide a realistic picture of the effort required for this, and where the risks lie. With that insight, the customer can then decide what is important.
We develop the software in an iterative process so we can periodically deliver a working software product that the customer can test. The customer can then also decide whether the project is going in the right direction. As a result, the developers receive direct feedback on the usefulness of their efforts. This prevents problems becoming visible at the end of the project. Adjustments can be made much earlier and therefore cheaper.
We are not afraid of change. If our customer wants to adjust the end result through progressive insight, we will do what we can to make it happen. It is certainly not an excuse for us to start waving additional work offers around. We simply try to implement the change within the existing quotation. And yes, we really differ from the average ICT service provider. And it also works both ways: we also have progressive insight during the development process. Sometimes functionality is cheaper to achieve and sometimes things can disappoint. We make agreements about this with our customers in advance.
We believe our developers should understand the processes and issues for which they are developing the software. We have therefore deliberately chosen to limit ourselves in terms of software development to the core themes of M+P: noise, vibrations, air quality and building physics. Our developers are also all active working as consultants. What this means for our customers is that they can easily talk directly to our developers on a substantive level and that everything does not have to be specified in detail, reducing the possibility of any errors.
Mutual openness and transparency between us and the customer is very important to us. The customer can come and see into our kitchen any time. We clarify where our efforts are being made, and therefore what the customer is paying for. The pinnacle of transparency is when developers from the customer participate in our development team. Our experience is that this is a good situation in which you can learn a lot from each other.
Does this vision and working method appeal to you? I would like to tell you more about it.
