Mending a broken innovation process

A study of the interactions in the innovation process to improve the implementation of innovation by design

More Info
expand_more

Abstract

Within the Dutch Ministries, implementing agencies receive the request to execute specific policies. To do this, they often need a (technical) product/service/platform which enables them to fulfill their job. With new types of technology coming to the market, the implementing agencies explore these new options to see if and how they can add value to their organization and make, e.g., executing a policy easier or more reliable. Therefore, the implementing agencies engage themselves in innovation projects. DICTU supports the implementing agencies with IT solutions such that they can create the product/service/platform to execute the policy. Currently, the innovation process in this context runs across multiple organizations and several departments, and there is little consideration of the various stakeholders; there often is a delay, the final product does not always solve the initial problem, or it occurs that the final product is not (correctly) implemented in the organization. This dissection of the innovation process leaves it broken and unwholly. This graduation project aims to create a designerly interaction between DICTU and its client to positively influence and contribute to a more successful implementation of innovation. Through literature and field research, a schematic overview of the current innovation process is created in which the various stakeholders and interactions are displayed. The two most important findings are that the implementing agencies have little trust for DICTU and that there is no moment in the innovation process where all stakeholders come together.

From a design point of view, there is value in involving the different stakeholders throughout the project to create a good solution for an existing problem by synchronizing the various parties. For this purpose, the Zegiswijzer is created. It is a tool that helps structure an additional interaction on the interface between DICTU and their client to make a smooth transition between the different organizations to synchronize their languages. This is done in a workshop by (1) defining the problem and the relevant stakeholders and their connections and by stating the ambition (2) by defining success and illustrating the solution. The next step is to reflect (3) on the first two steps, is the problem definition still accurate? Does the proposed solution indeed solve the problem? Or is it necessary to reframe the problem and/or solution? After this reflection, the path (4) is defined to go from problem to solution and state the expected risks and needed resources. With this step, not only the start of the project and the go-live of the product are considered, but also the phase after the go-live. What is needed to implement the product? And how will the organization adopt the product? Then, a collaborative decision (5) on how to continue is made. Based on the combined perspectives of the stakeholders, a well-informed decision can be made on whether to accept the project, adjust it, or don’t accept the project.

The implementation and development of the Zegiswijzer is captured in a roadmap. A future is envisioned in which valuable products/services are created, developed, delivered, and implemented in the Ministry of EZK/LNV by organizing the projects around close inter- and intra-organizational collaboration to create a profound understanding of the context facilitated by DICTU makes use of the Zegiswijzer. This future is realized by first using the Zegiswijzer on the interface between DICTU and its client to challenge the status quo of silo working. Then, DICTU should proactively engage in activities to create a profound understanding of the client’s business and gain legitimacy and trust for their position. The last step is for DICTU to take the role of partner, which leads to the realization of the vision. Future research should investigate the effect of following this designerly interaction on the interface between DICTU and the client and the implications it has on the implementation.