Begrijpen hoe je waarde genereert – binnen tijd en budget

Gepubliceerd op: 15 september 2020

Auteur:

René Raaijmakers

Technisch schrijver, auteur, algemeen directeur

Lees meer over René Raaijmakers

Expert:

Luud Engels

Trainer

Lees meer over Luud Engels

Deel

---

Als projectmanager, systeemarchitect en crisismanager in de hightechindustrie heeft Luud Engels de reputatie om geen blad voor de mond te nemen. Naast zijn consultancywerk is hij onlangs begonnen als systeemarchitect(en)-trainer bij High Tech Institute. “Duidelijke communicatie is essentieel in complexe ontwikkelomgevingen.”

Je wilt niet met Luud Engels beginnen over hoe ruimdenkend en communicatief we in de Nederlandse hightech zijn als systeemarchitect. Hij zal krachtig reageren en benadrukken hoe hypocriet het is om dat te geloven. “Hier in Brabant zijn we helemaal niet zo open. Ga maar bij een koffieautomaat staan en luister. We praten niet met je, maar over je.”

Als het aankomt op directe communicatie – of beter gezegd confrontatie – heeft Engels een reputatie. Een paar maanden geleden werd hij de laan uitgestuurd nadat hij – volgens zijn klant – duidelijk had gemaakt wat er mis was binnen het bedrijf. “Ik ben ervan overtuigd dat je op het juiste moment alles tegen iedereen kunt zeggen – of het nu in een teamvergadering is of een discussie tussen twee mensen. Natuurlijk doen de meeste Nederlanders dat niet. Maar ik schijn er ook niet in uit te blinken, want ik zeg dingen soms zo bot dat mensen tegen me zeggen dat ik moet oprotten.”

Engels’ waardering voor feitelijke en heldere communicatie komt voort uit zijn jarenlange ervaring als projectmanager, systeemarchitect, crisismanager en lid van het managementteam bij ingenieursbureau TMC. Zijn advies voor ontwikkelomgevingen: “Zeg wat je denkt. Ook over persoonlijke zaken. Het is prima om iemand te vertellen dat zijn blauwe shirt je stoort. Maar uitspraken als ‘Microsoft zuigt en Apple is goed’ helpen niet. Maak het feitelijk: gaan we objectgeoriënteerd of procesgeoriënteerd werken? Gaan we glas of titanium gebruiken? Wat zijn de voordelen? Wat zijn de nadelen? Als we het over glas hebben, hoef ik niet de hele geschiedenis van de glasblazerij te kennen. Ik wil de vijf belangrijkste criteria – in getallen, niet in positieve en negatieve. Als je de belangrijkste parameters kent, weet je ook hoe je ze moet meten en kunnen we afspraken maken over de eerste ontwikkelingsstappen om de metingen mogelijk te maken.”

Engels benadrukt dat bij de ontwikkeling van hightechsystemen meerdere wegen naar Rome leiden en dat het belangrijk is om bij de gemaakte keuze te blijven. “Zorg ervoor dat het hele team op zijn minst op dezelfde weg zit, in plaats van eindeloos te zoeken naar de enige juiste oplossing – die per definitie niet bestaat.”

Maar soms kunnen zelfs de eenvoudigste dingen misgaan. “Een keer, na een positief gesprek met een klant, ontving ik het rapport in spreektaal Nederlands. Ik vroeg of de vertegenwoordigers van de klant de tekst hadden goedgekeurd. Dat hadden ze natuurlijk niet. Dus stond ik erop om het in het Engels op te schrijven, het aan de klant voor te leggen en om goedkeuring te vragen. Het gaat tenslotte vaak om beslissingen met verstrekkende gevolgen. Toch bleek de synchronisatie met de klant een hele klus.”

De wetten van Luud

• Als de financiële mensen het overnemen, wordt het technische belang secundair; als de ingenieurs de leiding nemen, gaat het financieel kapot
  (Over het in evenwicht brengen van techniek en geld in hightech OEM’s)
• De klant die vraagt om een crisis af te wenden is voor de helft de boosdoener of onderdeel van de crisis in kwestie (Over crisismanagement)
• Ik geloof heilig in de kracht van de buitenstaander (Over de crisismanager)
• We praten langs elkaar heen: de een praat in Newton per vierkante meter, de ander in bits per seconde (Over communicatie en samenwerking in hightech)
• Een crisis verdwijnt niet door de mensen weg te sturen die de vinger op de zere plek leggen (Over gestrande ontwikkelingsprojecten)

De buitenstaander

Engels’ uitgebreide technische carrière begon met een studie elektrotechniek, waarna hij in dienst trad bij Sattcontrol, een Zweedse specialist in industriële automatisering. Hij programmeerde PLC’s voor eiersorteermachines, zuivelfabrieken en geautomatiseerde magazijnen. Later stapte hij over op Fortran voor PDP- en Vax-minicomputers.

Na vijf jaar stapte Engels over naar Cap Volmac (later Cap Gemini), waar hij projecten deed. Hoewel hij voornamelijk in engineering werkte, lag de kern van Cap bij bedrijfsautomatisering. “Ik heb veel geleerd over het ontwikkelen van computersystemen en software volgens de regels.”

Engels begon voor Cap bij ASML, daarna werkte hij aan snelwegsignalering bij Rijkswaterstaat en nam uiteindelijk leidinggevende functies op zich. Later kwamen daar audits bij. Hij schat dat hij ongeveer twintig projecten heeft beoordeeld. “Na een dag rondlopen weet je wat er aan de hand is en waar het project fout is gegaan”, zegt hij. Lachend: “En zeker niet omdat ik zo slim ben, of omdat ik zoveel gezien heb, maar vooral omdat ik een buitenstaander was.”

Engels gelooft heilig in de kracht van de buitenstaander. “Je komt bij bedrijven waar het helemaal mis is gegaan en dan mag je rondlopen en met 5-10 mensen praten. Ze hebben allemaal een mening over het crisisproject. Je krijgt het hele verhaal te horen. Mensen willen hun hart uitstorten. Je hoort wat er mis is en vooral: wat anderen niet mogen zeggen.”

De eigenwijze technicus

Technici zijn een koppig, eigenwijs type – en Engels kan het weten, want hij past zeker in dat plaatje. “We zijn ingenieurs, nietwaar? We denken zo: ‘Ik ben een elektrotechnisch ingenieur en volgens mijn berekeningen is het 5 volt. Als je het niet snapt, leg ik het nog een keer uit, maar de uitkomst blijft 5 volt. Jij bent gek, niet ik.’ Terwijl het in projecten vooral gaat om effectieve samenwerking. Dat is het moeilijke deel. De een praat in newton per vierkante meter, de ander in bits per seconde. De één praat over het doel, de ander over de oplossing. De hightech is één grote toren van Babel. Dat begint bij de requirements en loopt door tot het ontwerp, de integratie en het testen. Net zo goed: als ik een project zelf doe en er komt een buitenstaander, dan schiet die er ook gaten in.”

Luud Engels leidt half november de System Architect (Sysarch) training in Leuven (België).

Engels komt het liefst tussenbeide als de crisis op zijn dieptepunt is. Neem het Fusion-project dat eind jaren negentig bij Philips liep. Het ambitieuze doel was om één platform te gebruiken voor de mechanische, elektrische en softwareconstructie van medische diagnosesystemen. Het idee was dat kostenbesparingen door hergebruik de omvangrijke operatie zouden rechtvaardigen. “De directeur schetste zijn probleem als volgt: elke maand kwamen er dertig nieuwe ontwikkelaars bij en elke maand vertelden ze hem dat de oplevering weer twee maanden vertraging opliep.”

Engels paste opnieuw de kracht van de buitenstaander toe. “De buitenstaander mag spreken. Hoe dieper de crisis, hoe ontvankelijker men is voor berichten van buitenaf. Meestal hebben andere mensen er al naar gekeken. Maar vaak legden ze de vinger op zere plekken die ze niet mochten aanwijzen en moesten ze uiteindelijk vertrekken. Ze vroegen me om de huidige projectleider te vervangen omdat hij de vertraging niet kon inhalen. Maar een crisis verdwijnt niet als je de mensen wegstuurt die de vinger op de zere plek hebben gelegd. In plaats daarvan ging ik de zittende projectleider helpen. Samen hielden we de crisis binnen de perken door de scope aan te passen en te werken met vroege feedback. Een van mijn wetten is: de klant die vraagt om een crisis af te wenden, is voor de helft de boosdoener of heeft er op zijn minst een dominant aandeel in.”

Is het tunnelvisie?

“Let wel: je hebt het over zeer competente mensen met zeer relevante argumenten en tonnen aan kennis. Maar gaandeweg is de oplossing of werkwijze in verschillende silo’s geplaatst. Zeer bekwame mensen slijten paden af en creëren loopgraven die zo diep zijn dat je nauwelijks over de rand kunt kijken. Iedereen heeft zijn loopgraaf en verdedigt die koppig. Je hoort mensen dingen zeggen als: “Hier valt niet over te onderhandelen! Als je dat hoort, wijst het je naar waar het fout is gegaan en waar een mogelijk begin van de oplossing ligt.”

Waar begint de oplossing?

“De eerste wet van crisismanagement is beheersing. Bij Fusion betekende dit dat ze moesten stoppen met het toevoegen van dertig mensen per maand. In plaats daarvan moesten ze er twintig per maand schrappen en de omvang beperken. De diepere oorzaak was volgens mij pure zelfoverschatting. Het platformidee voor software alleen is een grote uitdaging. Maar als je mechanica en elektronica erbij gaat betrekken, voor alle diagnostische producten, wordt het in één keer te veel. Het is al moeilijk genoeg om elektronica, software en mechanica samen te ontwikkelen voor één systeem, maar proberen om in één project één platform te ontwikkelen voor verschillende productlijnen is op zijn zachtst gezegd naïef. In die tijd moesten ze ook samenwerken met ontwikkelaars in Bangalore en wilden ze tegelijkertijd van CCM-niveau 2 naar niveau 3 gaan. Dat moest meteen stoppen. Je moet de reikwijdte van een project in crisis beperken en verbeterinitiatieven op lange termijn uitstellen.”

“Het is vaak zo dat de technici al weten wat er mis is en het management ook. Beiden hebben gelijk, maar samen komen ze niet tot een oplossing. Veel later deed ik een klus bij Philips DPS, waar ik zag dat Philips grote vooruitgang had geboekt. Vingers op zere plekken leggen mocht echter nog steeds niet, helaas.”

Hoe wordt dit op de juiste manier gedaan?

Begin klein, zegt Engels. “Je hebt vroegtijdige feedback nodig, bij voorkeur van een launching customer. Ik heb het Martin van den Brink bij ASML vaak horen zeggen: zet alles in elkaar, laat me zien dat het werkt. Dan daagt hij mensen uit door te zeggen: ‘Je fysica werkt niet.’ Er was veel van dat soort dingen tijdens de vroege integratie. Veel later introduceerde de industrie er mooie woorden voor en noemde het Scrum, Agile en snelle ontwikkeling. Maar het punt is dat je feedback nodig hebt en het is belangrijk om daar in een vroeg stadium mee te beginnen. Het doel moet zijn om elke zes weken iets op te leveren dat echt werkt. Zo niet, dan heb je de middelen om uit te zoeken waarom het mislukte, waarom de fysica niet werkte. Op dat moment moet je misschien accepteren dat je je deadline niet gaat halen. Wat je zeker niet moet doen is meer mensen binnenhalen.”

“Als technici je vertellen dat ze meer tijd nodig hebben om iets te onderzoeken, moet je achterdochtig worden. Van den Brink is ook een meester in het inschatten of uitdagen daarvan.”

Een andere noodzaak: “Maak mensen eigenaar van een probleem. Zeker in omgevingen met complexe ontwikkelingen, waar nog niet eens een begin van een oplossing is en nieuwe uitvindingen nodig zijn, voelt iedereen zich de meester van zijn idee, met zijn persoonlijke inzicht. Wij Nederlanders zijn er ook heel goed in om elke gelegenheid aan te grijpen om hier heel breed over te praten. Maar je moet gewoon de volgende stap zetten. Dat is het enige waar een project baat bij heeft. Dus als je met dertig mensen in een kamer zit en er komen problemen, dan moet de projectmanager, de crisismanager of de systeemarchitect voor elk probleem een verantwoordelijke aanwijzen. Dit geldt ook voor deadlines voor resultaten en beslissingen.”

Volgens Engels zit het wel degelijk in de cultuur van ASML, maar is het daar op een gegeven moment uit de hand gelopen. “Ze stelden overal een eigenaar voor aan en noemden hem projectleider. McKinsey heeft ooit een analyse gedaan bij ASML van projectleiders en projectgroottes. Daaruit bleek dat er gemiddeld 1,2 mensen op elk project zaten, inclusief de projectleider! Dan loop je het risico dat deze eigenaren, deze projectleiders, gaan concurreren om de beschikbare middelen en het onderliggende probleem naar de achtergrond verdwijnt.”

Engels heeft uitgebreide ervaring als projectmanager, systeemarchitect en crisismanager in de hightechindustrie.

De productmanager definieert het product dat goed zal presteren in de markt. Hij bepaalt het beschikbare budget – vaak te weinig – en onderhandelt met de systeemarchitect of het voor dat geld gemaakt kan worden. Engels: “Het is een evenwichtsoefening. Bij volwassen producten werkt het anders, maar bij een eerste ontwikkeling wil je zo snel mogelijk een proof of concept. Of in ieder geval een bevestiging dat je ideeën kloppen en dat je op de goede weg bent.”

In hoeverre moet de systeemarchitect, net als de productmanager, rechtstreeks met klanten praten?

“In hightech staat dat buiten kijf. Daar komen de productmanager en de systeemarchitect samen. Ze moeten wel. De eerste is meer gericht op de business, de tweede kijkt naar de technologie en of het haalbaar is. Het zijn twee kanten van dezelfde medaille. Deze samenwerking tussen de productmanager en de systeemarchitect wordt steeds gebruikelijker. Toch zie ik nog steeds systeemarchitecten die de noodzakelijke afstemming met de projectmanager of het operationeel management bagatelliseren. Je loopt dan het risico dat een oplossing die perfect aan de behoeften van de markt voldoet, uiteindelijk toch mislukt in de realisatiefase.”

Bij kleinere ontwikkelprojecten, met tien tot twintig ontwikkelaars, kan één persoon de rol van zowel projectmanager als systeemarchitect op zich nemen. Bij grotere projecten, met tientallen of honderden ontwikkelaars en enkele tientallen leveranciers, is het belangrijk om je op te splitsen. Engels heeft ervaring in beide rollen. “De projectmanager stelt harde deadlines en een systeemarchitect moet daarmee werken.”

“De projectmanager moet bepalen welke problemen de systeemarchitect nog moet oplossen en met wie. Samen bespreek je de ins en outs, weeg je de voor- en nadelen af, bepaal je de belangrijkste parameters en dan belt de projectmanager de systeemarchitect: eind volgende week nemen we een beslissing! Het draait allemaal om richting, het bedenken van een format waarbij deskundige mensen betrokken zijn om tot gekwantificeerde uitspraken te komen waarmee je echt een beoordeling kunt maken.”

Een systeemarchitect heeft een grote invloed op productontwikkeling, maar heeft vaak een minder zichtbare rol.

“Hij is een ervaren technicus, maar zijn waarde ligt vooral in zijn kijk op de business. Negenennegentig van de honderd keer kent de systeemarchitect de markt waarin zijn product of systeem gaat landen. Dat is nodig om de markt- en producteisen te vertalen naar de systeemeisen en vervolgens het ontwerp te schetsen.”

Er is heel wat ervaring voor nodig om dat niveau te bereiken. Tegelijkertijd merkt Engels op dat het concept van een systeemarchitect aan inflatie onderhevig is. “Tegenwoordig zijn er overal architecten. Een software architect is meestal een senior software ontwikkelaar, een requirements engineer of iemand die verantwoordelijk is voor engineering. Ik wil niets ten nadele van zo’n lead engineer zeggen. Toch is het verschil met de systeemarchitect dat de laatste de business moet kennen, moet begrijpen hoe waarde wordt gegenereerd en dus moet begrijpen waarom het binnen een bepaalde hoeveelheid tijd en geld moet gebeuren.”

“Dit is ook het geval in de bouw. Je architect vraagt je wat je met je toekomstige huis gaat doen en past zijn ontwerp daarop aan. Ga je veel koken of wil je vooral wijn drinken? Daarom doet Van den Brink het zo goed bij ASML. Hij gaat naar klanten toe en legt uit wat voor lithosystemen ze nodig hebben. Hij kent de markt als geen ander. Sterker nog, hij dicteert de markt. Dat betekent dat hij als geen ander de doelen en de timing van chipfabrikanten begrijpt, inclusief hoe hun productieprocessen eruit zien. Als ze het hebben over kritieke afmetingen en overlay, kan hij uitleggen dat zijn machine dat kan en ook onderbouwen waarom.”

Dit artikel is geschreven door René Raaijmakers, tech-redacteur van Bits&Chips.