Grip op projecten middels ketenregie

Dat we binnen de ict en ook de business moeite hebben om grote projecten te beheersen en deze projecten tot een goed einde weten te brengen is wel gebleken uit de resultaten van de commissie Elias met betrekking tot het onderzoek naar grote ict-projecten binnen de overheid.

Het rapport benoemt onder andere een aantal zaken, te weten:

De rijksoverheid heeft de ict-projecten niet onder controle.
De politiek beseft het niet, maar ict is overal.
De rijksoverheid heeft onvoldoende zicht in de kosten en baten van de ict.
Ict-kennis schiet te kort.
Het ict-projectmanagement is zwak.
Ict-aanbestedingstrajecten bevatten perverse prikkels.
Het contractmanagement bij ict-projecten is onprofessioneel.
Het ontbreekt de rijksoverheid aan lerend vermogen op ict-gebied.

Is dit uniek? Nee, dit komt helaas in verschillende branches voor en is zeker niet beperkt tot de overheid.

Een van de maatregelen die de commissie voorstelde was de oprichting van het bureau ict-toetsing (BIT). Het bureau BIT heet een leidende rol in de toetsing van ict-projecten van groter dan vijf miljoen euro. Ieder voorstel wordt getoetst aan de hand van een vooraf opgesteld kader en het advies gaat via de minister naar de Tweede Kamer. Het bureau BIT is in 2015 van start gegaan en de eerste resultaten komen beschikbaar.

Grip op ict-projecten

De vraag is of deze maatregelen voldoende zijn om echt grip op ict-projecten te krijgen en falen te voorkomen. Wil je ict-projecten echt succesvol laten zijn dan is ict een belangrijke component maar slechts een van de vier basiscomponenten voor het realiseren van succesvolle projecten. Bewust noem ik projecten omdat er meerdere componenten van belang zijn voor het behalen van een goed resultaat. Naast ict moet ook aandacht worden geschonken aan de betrokken organisaties, de betrokken mensen en het bedrijfsproces (de keten) waarin de ict moet functioneren. Al deze stukjes moeten precies in de puzzel passen om uiteindelijk tot het gewenste c.q. noodzakelijke resultaat te komen waarbij voldaan wordt aan de benodigde kwaliteit.

Daarnaast heeft het bureau BIT beperkte bevoegdheden in de uitvoering. De angel zit ‘m vaak niet in het opschrijven van het plan, maar veel meer in het goed uit voeren. Het goed opzetten en uitvoeren van grote projecten is een veel bredere professie dan alleen maar een goed plan opstellen. Het laten toetsen van het plan verbetert het proces en het gedrag van de organisatie niet.

Regievoering en ketenregisseur

Een duidelijke regievoering is daarbij noodzakelijk. Regievoering die verder gaat dan traditioneel projectmanagement. Regievoering over de totale keten heen waarbij de kwaliteit voorop staat om alle puzzelstukjes in elkaar te laten vallen. De commissie Elias benoemt regie wel, maar is niet duidelijk in de invulling van regie. Het bureau BIT sluit daarbij aan. Het gaat dan ook verder dan toetsen, je moet echt de regie in handen nemen om projecten integraal succesvol te maken. Hoe pak je dit dan aan? Hoe kun je echt regievoeren?

Een belangrijke rol hiervoor is weggelegd voor de ketenregisseur. Maar wat is dat voor iemand? Enerzijds moet hij druk kunnen leveren, enthousiasmeren en aanzetten tot actie. Anderzijds moet hij respect kunnen opbrengen voor de tempoverschillen, maar ook het respect genieten van alle betrokken partijen. Hij moet enerzijds analytisch en scherp zijn om de ketens goed te kunnen doorgronden, anderzijds empathisch, mensgericht en met gevoel voor politieke verhoudingen. Zonder directe hiërarchische invloed instaat zijn om de keten te beïnvloeden.

Kracht zonder macht

Kracht zonder macht legt een verbinding tussen de vakgebieden ketenregie, kwaliteitszorg en verandermanagement waarmee managers en professionals in staat worden gesteld een optimale ketenregie in te richten en zo succesvoller te worden dan de concurrentie.

Ketenregie aangevuld met de doelstellingen van het bureau BIT kunnen leiden tot (meer) succesvolle ict-projecten die werkelijk bijdragen aan de doelstellingen van de overheid of het bedrijfsleven. Dan moet er echter wel over een drempel worden heengestapt en worden doorgepakt om nog meer verspillingen te voorkomen.

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!