De meest mondige teams vegen vaak het best hun eigen stoepje schoon

In de integratiefase van complexe machines wil het nog weleens knetteren, althans dat zag ik vaak in mijn eigen loopbaan. Velen van jullie zullen het herkennen: het team krijgt het systeem niet aan de praat en collega’s gaan naar elkaar wijzen. De ontwikkeling kan dan in een impasse raken. Gelukkig bestaat er een goede aanpak om de boel weer op de rit te krijgen. Het draait daarbij niet eens zozeer om de harde techniek, maar vooral om de menselijke maat.

Integreren lijkt eenvoudig, maar is in praktijk lastig. In deze fase van de machineontwikkeling komen verschillende systeemfuncties bij elkaar. Deze zijn individueel getest onder (hopelijk) bekende testcondities. Maar eenmaal bij elkaar gebracht, werkt het niet. In de praktijk valt systeemintegratie vaak bitter tegen.

Zelf maakte ik ooit een ontwikkeling mee waarin het niet lukte om met een combinatie van regelaar en motor de juiste positioneernauwkeurigheid voor een productdrager te halen. De motorleverancier verkocht de motor al jaren en beweerde dat de problemen waar we tegen aanliepen nog nooit waren voorgekomen.

Het team dat de productdrager ontwikkelde, stelde dat het goed naar de motoreisen had gekeken en met goede redenen voor deze motor had gekozen. Het hardwareproject selecteerde een regelaar van de plank. Deze was vaker probleemvrij toegepast.

Waar denk je dat de oorzaak werd gezocht? Juist, in software. De regeltechnieksoftware was immers specifiek voor dit project ontwikkeld. Het softwareteam verweerde zich: de applicatie was weliswaar nieuw, maar de software was hergebruikt en slechts van nieuwe parameters voorzien.

Ziedaar de impasse: geen van de vier partijen vond dat het probleem bij hen lag. Niemand nam het eigenaarschap, iedereen wees naar elkaar. Stellingen werden ingenomen, niemand bewoog meer. Voor het afgesproken budget was het beloofde werk immers uitgevoerd en klaar.

Het eigenaarschap om dit technisch integratieprobleem op te lossen, ligt per definitie op de plaats waar opleveringen samenkomen: bij de overkoepelend projectleider. Zeker in een groter project heeft hij of zij bij dit soort integratiediscussies te weinig tijd en bovendien te weinig technische detailkennis.

Dat betekent delegeren, maar aan wie? Een integratieleider aanstellen als rechterhand van de projectleider werkt dan het beste. Voordeel is dat deze persoon boven de partijen staat. Profiel: technicus die geen genoegen neemt met halve antwoorden en een goed gevoel heeft voor menselijke verhoudingen. Iemand die vragen stelt als: wat is er door wie in het project of in het verleden al gespecificeerd, berekend, gebouwd en getest? Onder welke condities was dat, en zijn die wel echt dezelfde als in het onderhavige project?

De integratieleider deelt ook technisch huiswerk uit aan teams als hun verhalen niet sluitend zijn. De meest mondige teams brengen niet altijd de beste inhoud, maar vegen wel steeds het eigen stoepje schoon.

Dat brengt ons weer op de menselijke dimensie. Het softwareteam kreeg door alle andere teams de zwartepiet toegespeeld. In dit geval was de software ontwikkeld door jonge mensen met weinig integratie-ervaring en met enig ontzag voor de senioren in de andere teams. Je ziet ze voor je: de motorverkoper die al twintig jaar in het vak zit en zich overal uitpraat, de ervaren constructeur waar de arrogantie vanaf spat en die nooit iets fout doet.

Menselijkerwijs was het project niet in balans en de integratieleider moest de zwakkere teams in zo’n geval helpen door op basis van technische informatie een inhoudelijke analyse uit te voeren en zo samen de oorzaak van de ontbrekende performance vinden.

In het specifieke project bleek de combinatie van motor en belasting toch niet goed gekozen, waardoor een andere motor nodig was. Met als gevolg dat ook de regeltechnieksoftware moest worden aangepast, ondanks het feit dat daar niet de oorzaak van het probleem lag.