Professorale overpeinzingen 6

Sommige van deze studenten volgen ook mijn vakken. In de colleges hebben we het regelmatig over de verschillen tussen klassieke technologische projecten, zoals jullie die kennen uit de praktijk, en dit soort studentprojecten, die je af en toe in de krant of online tegenkomt. Het grote verschil zit in de manier van coördineren. De teams werken vrijwel altijd toe naar een keiharde deadline: het moment waarop het innovatieve product in een container moet voor verscheping naar Australië, op een aanhanger moet voor een racebaan in Duitsland, achter in de bus moet voor een testtrack in Veendam of naar een lanceerplek in de middle of nowhere. Tot die deadline werken ze met z’n allen in een hal of schuur, waar verschillende subteams letterlijk naast elkaar aan hun onderdelen werken.

De truc met die teams is natuurlijk dat niemand echt alleen maar zijn ding zit te doen. De onderlinge coördinatie zit ingebakken in de gezamenlijke uitdaging: een raket lanceren, een hyperloop laten zweven of een zonnewagen laten rijden. Daardoor leggen teamleden elkaar voortdurend uit waar ze mee bezig zijn, hoe het zich verhoudt tot het oorspronkelijke plan en of alles nog op elkaar aansluit en werkt. 

In mijn onderzoek is dit altijd een centraal thema geweest: hoe organiseer je de flexibiliteit die sommige projecten nodig hebben? Het klassieke antwoord is formeel change management, maar dat begint vaak vanuit een “no-change mindset”. Echt flexibel is dat meestal niet. Bij deze studenten zien we juist een mierenhoop van slimme mensen met een uitgesproken “change mindset”. Zonder zware formele structuren ontwikkelen zij extreem innovatieve oplossingen. Tegelijkertijd hebben ze te maken met complexe integratievraagstukken, die ze oplossen door elkaar scherp te houden, voortdurend vragen te stellen en elkaar steeds weer te helpen.

In de projecten in de industrie waar ik onderzoekend bij betrokken ben, zie ik vaak mensen rondlopen die dat eigenlijk ook willen: samen de problemen oplossen. Maar contracten, afspraken, verantwoordelijkheden en processen creëren verantwoordelijkheden en grenzen, en veel is erop gericht om alleen verantwoordelijk te zijn voor dat wat je direct kan beïnvloeden: jouw stukje van de puzzel en niets meer. Want als er iets misgaat dan is het vinden van de verantwoordelijke inmiddels vaak belangrijker dan het oplossen van het probleem. De belangen zijn nu eenmaal groot. Maar ook in die context gebeurt het soms dat een clubje zich toch weer gaat gedragen als een DreamTeam, liefst met steun van hoger management, samen snel de problemen oplossen door elkaar op de vingers te kijken, te blijven bevragen en te helpen. Als je ooit in zo’n team hebt gezeten, dan weet je hoe tof het voelt. Ik wens het iedereen toe eens in die situatie te zitten.

Daar ligt de uitdaging: hoe bouw ik een governance voor projecten waarin dat oplossend vermogen gerealiseerd wordt, terwijl duidelijk mag zijn dat we uiteindelijk ook mensen, teams en organisaties moeten kunnen aanspreken op hun eigen verantwoordelijkheid, hun specifieke bijdrage aan het geheel. Als je naar de literatuur op het gebied van projectmanagement kijkt, dan valt er best veel in dat bakje: samen problemen oplossen en toch verantwoordelijkheid kunnen blijven toewijzen. DreamTeams lijken het te kunnen, maar hoe het te schalen, dat lukt nog maar zeer matig. Meer onderzoek blijft als altijd nodig.

Wijnand Veeneman

-------------

In Delft (and elsewhere at universities), young men and women doing something truly remarkable: they join a student team that takes on an exciting technological challenge together. One of them you’ve probably heard of—the Nuna solar car, with which groups of students repeatedly travel to Australia to compete against their friends from Twente, racing from north to south of that country powered solely by sunlight. Often with great success. We usually call them DreamTeams.

These students also take my courses, and in lectures, we often discuss the differences between “classic” technological projects—like the ones you’re all familiar with—and their kinds of projects, the ones you sometimes come across in newspapers or online. And the big difference is how coordination happens. The young men and women usually face a hard deadline: the exact moment when the innovative creation—say, the car—has to go into a shipping container bound for Australia, be loaded onto a trailer for a racetrack in Germany, packed into a bus for testing in Veendam, or taken to a launch site somewhere in the middle of nowhere. But until that deadline, they’re all together in a hall or workshop, each “doing their thing,” often just a few meters apart.

Of course, the trick is that no one in these DreamTeams is really just doing their own thing. The coordination among them is embedded in their shared challenge of getting a rocket to launch or a hyperloop pod to levitate. So, they continuously explain to one another—implicitly or explicitly—what they’re working on, how it relates to the original plan, and whether everything still fits and functions.

This has always been a central theme in my research: how do you organize the flexibility that some projects need? The formal answer, of course, is “change management”—and that starts with a no-change mindset. It turns out to be not all that flexible. But with these students, we see a hive of clever people working with a change mindset, managing to do incredibly innovative things without rigid formal structures. At the same time, they face complex integration challenges, which they solve by constantly observing each other’s work, asking questions, and helping each other along.

In the industrial projects I’m involved in as a researcher, I often see people who actually want the same thing: to solve problems together. Yet contracts, agreements, responsibilities, and processes tend to focus on being accountable only for what one can directly control—their piece of the puzzle, and nothing more. When something goes wrong, finding out who’s responsible often becomes more important than solving the problem itself. The stakes are high, after all. And in that context, it sometimes happens that a group starts behaving like a DreamTeam again—ideally with senior management’s support—solving problems together by watching each other’s work, asking questions, and offering help. If you’ve ever been part of such a team, you know how rewarding that feels. I wish that experience for everyone at least once.

That’s where the challenge lies: how do we design governance structures for projects that enable this collective problem-solving capacity, while still making sure that people, teams, and organizations can be held accountable for their responsibilities and specific contributions to the whole? If you look at the project management literature, you’ll find plenty on this topic: solving problems together while preserving the ability to assign responsibility. DreamTeams seem to pull it off—but scaling that up has proven difficult so far. As always, more research is needed.

Wijnand Veeneman