Elk implementatieproject kent twee sporen. Het bestuurlijke spoor: contracten, stuurgroepen, budget, planning. En het technische spoor: architectuur, koppelingen, datamodellen, omgevingen. In de meeste projectplannen zijn dat twee nette kolommen met elk een eigen trekker.
Bij een lopende CRM-implementatie kwam het technische spoor dit voorjaar zonder trekker te zitten. De koppelingenlijst groeide, de ontwerpbesluiten stapelden zich op en de leverancier wachtte op antwoorden die niemand gaf. Ik heb dat spoor er toen als projectmanager bij genomen. Niet omdat ik de beste architect in de kamer ben, maar omdat een spoor zonder eigenaar duurder is dan een eigenaar die moet bijleren.
Wat ik in die weken heb geleerd, is dat het technische spoor geen andere discipline vraagt dan het bestuurlijke. Het vraagt dezelfde discipline, toegepast op andere onderwerpen.
Tien koppelingen zijn geen lijst, het is een volgorde
Ons integratielandschap telt ruim tien koppelingen: identiteiten, studentinformatie, financiën, een productcatalogus, marketingtooling. De eerste versie van de planning behandelde ze als een boodschappenlijst. Allemaal even belangrijk, allemaal "in fase 1".
Dat werkt niet. Koppelingen hebben afhankelijkheden. Zonder identiteiten geen accounts, zonder accounts geen klantrecord, zonder klantrecord geen enkele andere koppeling die iets nuttigs doet. De eerste echte klus was dus geen bouwen maar ordenen: welke koppeling moet er staan voordat de volgende kan beginnen?
Sindsdien hanteren we drie vaste vragen per koppeling:
- Wat is de bron? Eén systeem is eigenaar van elk gegeven. Bij onze productcatalogus bleek dat besluit nooit formeel genomen. Die discussie alsnog voeren kostte een week. Haar niet voeren had maanden gekost.
- Wat is de richting? Eenrichtingsverkeer is goedkoper, robuuster en makkelijker te testen dan synchronisatie in twee richtingen. Twee richtingen moet je verdienen met een goede reden.
- Wie accepteert? Elke koppeling krijgt een functionele eigenaar die tekent bij oplevering. Geen eigenaar, dan bouwen we hem nog niet.
Een ontwerpdocument per koppeling, hoe klein ook
Voor elke integratie maken we een kort ontwerpdocument voordat er iets wordt gebouwd: bron, doel, richting, frequentie, foutafhandeling en de verantwoordelijke aan beide kanten. Twee tot drie pagina's, meer niet.
De waarde zit niet in het document zelf maar in het gesprek dat het afdwingt. Elke keer dat we zo'n concept rondstuurden, kwamen er vragen terug die anders pas tijdens de bouw waren gesteld. Welke omgeving? Welke velden precies? Wat gebeurt er bij een storing om drie uur 's nachts? Elke vraag die vóór de bouw wordt gesteld, is een factor tien goedkoper dan dezelfde vraag erna.
De vergadering die techniek en bestuur verbindt
De grootste verandering was niet technisch maar ritmisch. We hebben een vast technisch afstemmingsoverleg ingericht waarin de engineers van beide kanten elkaar wekelijks spreken, met een vaste agenda: ontwerpbesluiten, blokkades, volgende oplevering.
Belangrijker nog: de uitkomsten landen in dezelfde registers als de bestuurlijke punten. Een technische blokkade is gewoon een issue. Een ontwerpkeuze met budgetgevolg is gewoon een wijziging. Zodra techniek een eigen schaduwadministratie krijgt, in mailwisselingen en chatkanalen, verlies je als projectmanager het zicht precies daar waar het geld wordt uitgegeven.
Moet elke projectmanager dit kunnen?
Nee. Maar elke projectmanager moet het gesprek kunnen voeren. Je hoeft geen API te kunnen bouwen om te vragen wat de bron is, wie accepteert en wat er gebeurt als het stuk gaat. Dat zijn bestuurlijke vragen in een technisch jasje.
Wat niet werkt, is het technische spoor behandelen als een zwarte doos waar je elke twee weken een statusrapport uit ontvangt. Techniek die niet wordt bestuurd, bestuurt zichzelf. En zichzelf besturende techniek kiest altijd voor interessant boven af.
Bij House of Data combineren we daarom bewust beide profielen: architectuur- en engineeringkracht voor de inhoud, en projectleiderschap dat die inhoud kan uitdagen. Niet twee werelden met een rapportagelijn ertussen, maar één team.
← Terug naar alle artikelen