Overslaan en naar de inhoud gaan

‘Op naar minder efficiënte ICT­projecten’

‘Op naar minder efficiënte ICT­projecten.’ Dat lijkt een onvoorstelbare opmerking in deze tijd van krapper wordende budgetten, minder mensen en meer overwerk. Toch is het iets waar we naar zouden moeten streven. Juist door die krappere budgetten en het vele overwerk.
Tech & Toekomst
Shutterstock
Shutterstock

We leven in een cultuur die de nadruk legt op efficiëntie. Sterk de nadruk zelfs. Zo sterk dat de effectiviteit er onder lijdt. Eerst het verschil tussen efficiëntie en effectiviteit. Efficiëntie is het zo snel en goedkoop mogelijk laten verlopen van een bepaalde activiteit. Dus intern gericht. Gericht op het proces. Effectiviteit is extern gericht. Gericht op wat het proces toevoegt aan de omgeving. Door effectiviteit kan vaak veel meer worden bespaard dan door efficiëntie (zie kader ‘helpdesk’). Het kan dus nuttig zijn efficiëntie in te leveren voor meer effectiviteit. De sterke gerichtheid op efficiëntie is echter onderdeel van onze manier van werken. Veelal onbewust. Hierdoor beseffen we vaak niet hoe weinig effectief iets is. De oorzaak hiervan heeft veel te maken met de opbouw van onze maatschappij. Met de industrialisatie, het economisch denken, de moderne wetenschap. Het voert te ver om dat allemaal te bespreken. Ik wil me beperken tot een aantal praktische punten. Punten die een sterke rol spelen bij ICT­(project)management. Eigen belang De interne gerichtheid komt voort uit het economische marktdenken en de individualisering. Het komt erop neer dat iedereen opkomt voor zijn eigen belangen. Het idee dat wanneer iedereen zijn eigen activiteiten zo efficiënt mogelijk uitvoert, het resultaat optimaal is. Het voorbeeld van de helpdesk (zie kader) laat zien dat dit niet altijd het geval is. Bij de tweede helpdesk ligt de nadruk op de belangen van de ander. De werkelijke besparingen (minder problemen) worden gerealiseerd bij de klant. Pas via een omweg (minder gesprekken) komen de besparingen weer terug. Het principe dat het project, de opdrachtgever en alle overige betrokken partijen hun eigen belangen verdedigen, leidt dus lang niet altijd tot het gewenste resultaat. Het gaat veel meer om het begrijpen van de problematiek van de ander en het van daaruit werken. Waar verschillende disciplines samenwerken is dit vaak niet eenvoudig. Toch is juist hier veel aan effectiviteit te winnen. Het doel: niet meer doen dan voor de omgeving nuttig is. De gerichtheid op modellen komt voort uit de wetenschapsontwikkeling. Zowel in de ICT als in de managementtheorie zijn er modellen te over. TQM, Itil, Prince 2, DSDM, maar ook werkprocessen, workflow en balkenplanning zijn daar voorbeelden van. De ICT heeft van nature een sterke neiging naar modellen en modelmatig werken. Je kunt alleen iets automatiseren wanneer je het in een model kan vatten. Dit model wordt dan omgezet naar computercode. Modellen zijn sterk efficiëntiegedreven. Wanneer situatie x zich voordoet dan is y de beste aanpak, zegt een model. Effectiviteit is helaas niet generiek maar situatie­afhankelijk. Situatie x doet zich nooit exact voor. Tijdgebonden omgevingsfactoren zijn sterk bepalend. Deze zijn nooit te vatten in een algemeen model. Het doel: niet meer regels en overhead dan in die situatie noodzakelijk is (zie kader ‘website’). Functiescheiding Techniek wordt steeds complexer. Iemand kan niet meer alles weten. We zien dan ook een sterke functiescheiding. De (project)manager is voor het proces, niet voor de inhoud. Daar zijn deskundigen voor. Zoals we hierboven hebben gezien kan men met een procesmodel alleen maar sturen op efficiëntie. Juist de projectmanager zou moeten sturen op effectiviteit. Hij is als geen ander in staat de vertaling te maken tussen de, veranderende, eisen en wensen van de omgeving en de minimale inspanning die het project moet leveren om deze in te vullen. Dit betekent zeker niet dat de projectmanager een deskundige moet zijn. Bij voorkeur niet zelfs. Dit vergroot namelijk het risico dat de projectmanager het ‘beter weet’, op de stoel van de ander gaat zitten en niet meer luistert. Basiskennis is wel noodzakelijk maar veel meer een open houding. Willen weten wat er gebeurt. Willen weten wat de ander nu echt bedoelt en bezighoudt. Het doel: scherp waarnemen wat er in die specifieke situatie effectief is (zie kader ‘systeem’). Zoals we hebben gezien kan effectiviteit veel meer voordelen opleveren dan het efficiëntieverlies dat er soms tegenover staat. Effectiviteit is echter situatiespecifiek. Het is dan ook niet eenvoudig te leren op een training of uit een boekje. Het vergt een continue afstemming tussen project en omgeving, niet alleen op basis van modellen maar ook inhoudelijk. Het is een voortdurend zoeken naar de gewenste effecten en naar de minimale middelen om die te bereiken. Steeds kijken naar wat hetgeen we doen bijdraagt. Maar, we moeten het kind zeker niet met het badwater weggooien. Zonder de efficiëntie van Henry Ford met ‘T­Fords in alle kleuren als het maar zwart is’ zou de moderne auto­industrie niet zijn wat ze nu is. Toch zien we zelfs in deze, zeer sterk door efficiëntie gedreven, industrie een beweging naar meer effectiviteit. De hoogste tijd dus om ook ICT­projecten iets minder efficiënt maar vooral effectief uit te voeren. Het zal een besparing in werkdruk en kosten opleveren. Jan Baljeu is werkzaam als zelfstandig project­ en interimmanager (jan.baljeu@pracsens.nl).Effectieve bezuinigingenHelpdesk uitbesteden In het kader van een algemeen kostenbesparingstraject moeten de ICT­helpdesks besparingen realiseren. De eerste helpdesk wordt uitbesteed aan de goedkoopste aanbieder. Deze wordt betaald per gesprek en nog eens sterk onder druk gezet om kostenbesparingen te realiseren. Uiteindelijk blijkt het op deze manier mogelijk een besparing van ruim 10 procent te behalen. De tweede helpdesk pakt het anders aan. Men investeert meer tijd per gesprek. Er worden, na toestemming, vragen gesteld over de situatie waarin het probleem zich voordoet. De gesprekstijd neemt dan ook met ongeveer 10 procent toe. Door de extra informatie is het echter beter mogelijk de, vaak generieke, oorzaken van problemen te achterhalen en op te lossen. Na verloop van tijd neemt het aantal gesprekken met bijna 20 procent af. De tweede helpdesk is dus minder efficiënt maar veel effectiever en daardoor goedkoper. Website bouwen De bestaande website moet worden vervangen. Hiervoor wordt een project gestart. De aangetrokken projectmanager stelt een activiteitenplanning op, maakt werkschema’s, wijzigingsprocedures enzovoort. Het project loopt prima. De ontwikkelaars kunnen goed doorwerken en liggen op schema. Toch ontstaat er frictie. De opdrachtgever wil in staat zijn om meer tussentijdse wijzigingen door te voeren. De projectmanager is van mening dat dit te verstorend werkt op het proces en dat daardoor planning en budget in gevaar komen. De frictie loopt zo hoog op dat de projectmanager per direct vertrekt. De nieuw aangetrokken projectmanager volgt een andere aanpak. In plaats van planningen en procedures werkt hij met een overzicht van alle componenten. Ontwikkelaars gebruiken dit om te bepalen welke componenten er nog gebouwd moeten worden. Wanneer men niet verder kan met een bepaalde component gaat men verder met een ander. Het overzicht wordt ook gebruikt om wijzigingen op aan te geven. Wijzigingsprocedures worden aanzienlijk versoepeld. Uiteindelijk is het complete project, ondanks de wisseling van de wacht en een aanzienlijke hoeveelheid wijzigingen, met een zeer beperkte uitloop opgeleverd. Dit tot volle tevredenheid van de opdrachtgever. Er zijn minder componenten gebouwd dan origineel gepland maar het eindresultaat was beter. Meer naar de wens van de opdrachtgever. Het project verliep in de tweede fase dus minder efficiënt maar veel effectiever. Systeem vervangen Voor de vervanging van een transactieverwerkend systeem wordt de bouw uitbesteed aan een derde partij. De projectmanager stuurt op het proces. De projectleider van de derde partij is veel meer technisch inhoudelijk betrokken. Op regelmatige basis doet hij dan ook voorstellen voor inhoudelijke aanpassingen en verbeteringen. Deze hebben echter direct gevolgen voor de planning. De projectmanager is dan ook niet snel bereid ze door te voeren. Hij acht het risico op uitloop te groot. Desondanks valt de voortgang erg tegen. De opleverdatum is in gevaar en de kosten lopen op. Dit alles komt de relatie tussen beiden niet ten goede. De testmanager brengt uitkomst. Hij maakt de vertaalslag tussen de technisch inhoudelijke vraagstukken, de processturing en de eisen en wensen van de opdrachtgever. Hij bekijkt per situatie wat noodzakelijk is. Vanuit het oogpunt van de projectmanager verloopt het project nu minder efficiënt, minder strak volgens planning, onzekerder. De voortgang en tevredenheid van de opdrachtgever verbeterden echter aanzienlijk.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in