ICT-projecten staan erom bekend dat ze altijd uitlopen. Het is nooit op tijd klaar en plannen is blijkbaar lastig. Toch geloof ik dat ICT-projecten – en ICT-taken met een langere doorlooptijd – veel beter planbaar zijn dan veel gevallen gedacht wordt. Daarom maar eens wat aandacht voor de planning van de grotere ICT-taken.

 Eerst even de feiten. Het klopt dat het neerzetten van niet-standaard ICT-oplossingen een creatief proces is. En dat het daardoor lastig om in te schatten hoeveel tijd iets kost. Tot zover is ICT – voor zover het niet standaard is – lastig te voorspellen. Maar dat is dan ook echt het enige waarin ICT niet planbaar is.

 In principe mag je verwachten dat elke professionele ICT’er globaal kan inschatten hoeveel tijd iets kost om te realiseren. En de meeste ICT’ers kunnen dat ook. De meeste ICT’ers kunnen prima inschatten of iets een kwartier, een uur, een dagdeel of een paar dagen kost. En voor langere trajecten moet je het werk in kleine brokjes verdelen. En dan kan dat ook – zij het met een bepaalde marge – ingeschat worden. Tot zover prima. Maar dan moeten er wel een aantal randvoorwaarden ingevuld worden.

 Als je ICT’ers vraagt naar deze randvoorwaarden zul je deze vaak ook krijgen. En als je niet duidelijk is wat de randvoorwaarden zijn of waarom dat randvoorwaarden zijn, vraag dan net zo lang door tot het wel duidelijk is. ICT’ers weten over het algemeen prima welke randvoorwaarden ingevuld moeten zijn om hun werk kunnen uitvoeren.

 De eerste randvoorwaarde die ingevuld moet worden is een aanspreekpunt om invulling te geven aan allerlei keuzes die in het creatieve proces gemaakt moeten worden. Omdat ICT-projecten altijd bedrijfsprocessen ondersteunt, is er iemand nodig uit dat bedrijfsproces om daarin de juiste keuzes te maken. Ook kan dit aanspreekpunt hem of haar voorzien van allerlei informatie die nodig zijn om het systeem met de juiste informatie te vullen. In Agile- en Scrum-achtige werkwijzen wordt dit aanspreekpunt ook wel Product Owner genoemd.

 Daarnaast is het belangrijke dat de betreffende ICT’er ongestoord zijn werk kan doen. Hoe je dat oplost heb ik in dit artikel beschreven.

 De laatste stap die je moet zetten om tot een planbaar geheel te komen is afspraken maken. Als alle randvoorwaarden ingevuld zijn, rest er niets anders dat het werk gewoon uit te voeren. Daar zal de gemiddelde ICT’er ook geen enkel bezwaar tegen hebben. Prima!

 Met die afspraken kun je vervolgens een leercurve opstarten, waarmee je planning steeds betrouwbaarder wordt. Vraag een ICT’er waarom hij een een planning niet gehaald heeft, en leer daaruit.

 Door de afspraken vervolgens te monitoren komt je drie dingen op het spoor:

1. Elke ICT’er heeft een bepaalde (constante) factor waarmee hij of zij het werk te optimistisch inschat (of te pessimistisch, maar dat komt minder voor). Voor de volgende keer kun je die factor eroverheen zetten waardoor je planning steeds betrouwbaarder wordt.
2. Verstoringen. Ze zullen blijven voorkomen. En door ernaar te vragen kom je ze op het spoor. En kan je maatregelen treffen om het aantal verstoringen steeds verder terug te dringen.
3. Verkeerde inschattingen. Ook hier kan je een leercurve inzetten.
   Vraag een ICT’er waarom hij een een planning niet gehaald heeft, en leer daaruit.

 Door bovenstaande toe te passen kun je vaak binnen 2-5 slagen komen tot planningen die tot wel 80% betrouwbaar zijn. En dat is vele malen beter dan wat de gemiddelde ICT-afdeling heden ten dage presteert! Ga jij voor ICT-ontwikkeling?

 Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.

Lang openstaande meldingen. Het is het probleem van vrijwel elke ICT-afdeling. Meldingen die 2, 3 maanden openstaan zijn geen uitzondering. Bij een van mijn recente opdrachtgevers stond de oudste melding zelfs 2 jaar (!) open. En dat terwijl het probleem van lang openstaande meldingen vrij eenvoudig op te lossen is. Het kost wat discipline en uithoudingsvermogen. Meer niet.

Daarom leg ik hieronder uit hoe je het probleem van lang openstaande meldingen oplost. In de hoop dat gebruikers voortaan minder lang op het verwerken van hun melding hoeven te wachten en dus tijd kunnen besparen. Allereerst leg ik het waarom meldingen zo lang open blijven staan. Als we dat eenmaal begrijpen volgt de oplossing van het probleem daar vrij logisch uit.

Lang openstaande meldingen. Waarom staan ze open?

Als we kijken naar de reden waarom sommige meldingen zo lang openstaan komen we steevast de volgende oorzaken tegen.

De belangrijkste oorzaak is dat voor het oplossen nét even meer tijd nodig is dan gebruikelijk. Er is bijvoorbeeld navraag bij iemand anders nodig. Er moet een mailtje voor gecomponeerd worden. Of er is goedkeuring van iemand nodig. Hele simpele, eenvoudige dingen, maar lang genoeg dat er iets anders (urgenter, belangrijker, of soms gewoon makkelijker: ach, laat maar) tussendoor komt. En het rendement daarvan is altijd hoger dan dat van die ene melding. En vervolgens verdwijnt de melding naar onderop de stapel om pas veel later weer boven te komen drijven. Niet moeilijk, zeker begrijpelijk, maar erg vervelend voor de gebruiker in kwestie.

Prioriteiten

Een andere oorzaak is dat er altijd andere prioriteiten zijn. Er staat iemand voor je bureau, deze melding moet van de baas echt even voor, of er is iets uitgevallen waardoor een of meerdere gebruikers niet verder kunnen. Kortom: andere meldingen gaan op een of andere manier altijd voor. En dus verdwijnt de betreffende melding weer naar onderop de stapel en duikt pas veel later weer op.

Communicatie

Een derde, ook veel voorkomende oorzaak is gebrek aan communicatie. Voor het oplossen van de melding is net even wat meer informatie nodig. En die moet bij de betreffende gebruiker – of iemand anders – opgehaald worden. Vervolgens kan het op veel plekken misgaan: de betreffende ICT’er wordt verstoord door een urgentere melding (baas, prioriteit of gebruiker aan bureau); de persoon met informatie is niet bereikbaar, belt niet terug, is op vakantie, ziek, of ziet de mail over het hoofd; het mailtje terug komt bij een ICT’er die net afwezig is of de mail mist; enzovoorts, enzovoorts. En zo blijft de melding openstaan. Wachtend op het antwoord dat nooit komt.

Het was (even) druk op de afdeling. Ook een belangrijke oorzaak om onder op de stapel te belanden. En dan kan het dus zomaar 2 jaar duren voordat een melding wordt opgepakt. Of helemaal niet. Want als iets zo oud is, “zal de gebruiker vast wel een nieuwe melding hebben ingeschoten” als het echt belangrijk was. Of niet soms? Maar jij bent net die fatsoenlijke gebruiker die wel netjes wacht een geen nieuwe melding inschiet.

Soms kost een melding gewoon echt meer tijd. Moet ervoor overlegd worden, is er een afhankelijkheid van een andere afdeling of derde partij. Het zijn simpele dingen, maar ondertussen loopt de tijd gewoon door. En staat uiteindelijk de doorlooptijd niet meer in verhouding tot de eenvoud van het oorspronkelijke verzoek.

Is dat alles? Ja, vaak is dat alles. Zo eenvoudig kan het zijn. Maar je zult maar net die ene gebruiker zijn die op de behandeling van je melding zit te wachten. En je denkt: wat is daar nou ingewikkeld aan? Hoe moeilijk kan het zijn? En gelijk heb je! Het is relatief eenvoudig. Maar niet eenvoudig genoeg.

Hoe kunnen we dat oplossen?

Nu we de oorzaken weten waarom meldingen en zo lang openstaan, begrijpen we dat er net genoeg aandacht (focus) moet zijn om dat ene drempeltje wel over te gaan. En erachter komen wat er moet gebeuren. De IT’ers snappen ook wel dat het eigenlijk heel weinig moeite is. Maar in de dagelijkse hectiek is er vaak geen tijd om daar over na te denken.

De eerste stap daarin is om meetbaar te maken hoe lang meldingen openstaan. Dit kan een eenvoudig lijstje zijn met langst openstaande meldingen. Een top 10. Of het aantal meldingen dat langer dan X dagen openstaat. En dat dan met een trend over de afgelopen week bijvoorbeeld. Iets dat de focus legt op die te lang openstaande meldingen. En iets dat motiveert om de cijfers gunstiger te krijgen. Hang die – bijgehouden – rapportage dus zichtbaar op. Of hang een voor iedereen zichtbaar scherm op waar dat voortdurend getoond wordt. Vaak is dit al voldoende om net dat ene zetje te geven om een melding wel op te lossen.

Geef het de tijd

Voor de wat taaiere meldingen is de oplossing ook eenvoudig. Zorg dat elke melding de tijd krijgt die ervoor nodig is. Organiseer een wekelijkse meeting om de langst openstaande meldingen te bespreken. Begin met de oudste en vraag per melding welke actie(s) uitgevoerd moeten worden om de melding op te lossen. En spreek af wie die actie gaat uitvoeren. En meer niet. Stop ook als de eindtijd van de meeting bereikt is. Of je nou bij melding 3 of melding 10 bent. Volgende keer een nieuwe poging. En begin op dezelfde manier. Spreek mensen niet aan op het niet uitvoeren van een actie. Daar is vast een goede reden voor. Probeer in plaats daarvan te achterhalen waarom iets nog niet is uitgevoerd. Wat iemand belemmerde om de actie uit voeren. Wat hij of zij nodig heeft om de actie deze week wel uit te voeren. En concentreer je op het wegnemen van die drempels.

En dat is het. Meer is er niet voor nodig.

Conclusie

Met bovenstaande acties zijn vrijwel alle oorzaken van lang openstaande meldingen op te lossen. Op die paar uitzondering na, die prima uit te leggen zijn. Het enige wat je hoeft te onderzoeken, is wat er nodig is om de melding wel op te lossen en daarin te voorzien. En de discipline om elke week – maar dan ook echt elke week – de lijst met openstaande meldingen door te akkeren. Structureel. Zonder onderbreking.

Het oplossen van welbekende problemen in de ICT kan soms echt heel eenvoudig zijn. Lang openstaande meldingen zijn daar een voorbeeld van. Je moet alleen even weten hoe. En rekening houden met de mensen die het werk moeten uitvoeren. Want die bedoelen het echt gewoon goed. Soms hebben ze net dat beetje extra nodig om het werk echt goed uit te voeren. Focus, structuur en mensen. I love it.

Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.

We lopen er allemaal tegenaan, een planning maken in ICT. Het is ook het probleem van vrijwel elke ICT-afdeling: planningen die niet gehaald worden. Het gevolg is ook al even voorspelbaar: teleurgestelde afdelingen die ergens op wachten, de ICT-afdeling weggezet als onprofessioneel, en mogelijk schade door niet nagekomen beloftes, weglopende klanten of zelfs boetes tot gevolg. Alle reden dus om te kijken hoe dit soort problemen te voorkomen. In dit artikel noem ik een aantal voorbeelden.

Allereerst leg ik uit waarom planningen in veel gevallen niet gehaald worden. Als we dat weten volgt daar namelijk vrij logisch uit wat we moeten doen om de planningen te halen.

Waardoor worden ICT planningen niet gehaald?

Oorzaak één

De belangrijkste oorzaak waarom planningen niet gehaald worden bij ICT, is dat er voortdurend andere prioriteiten zijn. Werk met een planning kan namelijk ook morgen uitgevoerd worden En vaak ook volgende week of zelfs pas volgende maand. Een storing moet altijd nu opgelost worden. Net als die gebruiker die niet kan werken of wiens Word het even niet doet, net nu hij vanmiddag voor de deadline zit. En “had ie maar beter moeten plannen” is dan niet het antwoord waar hij of zij op zit te wachten. Dus ander werk en andere prioriteiten gaan altijd voor.

Oorzaak twee

De tweede oorzaak waarom planningen niet gehaald worden zit hem in afhankelijkheden. Een ICT-systeem staat nooit op zichzelf en heeft altijd afhankelijkheden van anderen. Vaak zijn er koppelingen met derden, waarmee afstemming nodig is om het gewenste te realiseren. En die moeten dan precies beschikbaar zijn op de momenten dat er (zie boven) wel tijd is voor de gewenste oplevering.

Oorzaak drie

De derde oorzaak zit hem in optimistische planning . Ook dat komt helaas veel te vaak voor en moet voorkomen worden. ICT-werk is net als dat klusje in huis wat je denkt in een uurtje te kunnen doen. Er komen altijd verrassingen uit waardoor het minstens twee keer, maar vaak nog langer duurt. Of erger: je moet terug naar de bouwmarkt omdat je materialen en/of een bepaald soort gereedschap mist. Het werk van ICT’ers is net zo. Dus net als bij klussen in je eigen huis zijn ICT’ers geneigd om hun eigen werk te optimistisch in te schatten.

Tot slot is er nog voortschrijdend inzicht. Dat we vergeten we nogal eens. Omdat met de oplevering van (delen van) het systeem dingen opeens enorm concreet worden, ontstaan vaak nieuwe inzichten. Daardoor groeit het wensenlijstje, neemt het werk toe en loopt de planning uit. En, paradoxaal: dat wil je! Voortschrijdend inzicht zorgt ervoor dat het systeem alleen maar beter wordt. Dus dat zou je moeten omarmen. Maar je wilt toch die planning halen.

In het slechtste geval laten we (1) alle gebruikers met acute problemen voor, vragen we (2) niet naar de planning en randvoorwaarden en laten we (3) de ICT’er het werk een factor 2,5 te optimistisch inschatten. En als er iets opgeleverd wordt, laten we (4) geen nieuwe wijzigingen toe. Vind je het gek dat sommige mensen erg ontevreden zijn over ICT?

Hoe dit nu op te lossen?

De oplossing laat zich vrij eenvoudig uittekenen.

Stap 1

De eerste en belangrijkste stap is zorgen dat medewerkers zonder gestoord te worden aan de gewenste oplevering kunnen werken. Dit bereik je door andere medewerkers aan alle overige verstoringen te laten werken: gebruikersproblemen, helpdesk, telefoon en mail. En langslopende gebruikers “Ik was toevallig toch in de buurt”. Zorg er ook voor dat je afspraken maakt of iets regelt als de rest van de afdeling is om ergens anders in het gebouw een probleem op te lossen. Dat is één.

Stap 2

De tweede stap is zorgen dat alle randvoorwaarden duidelijk zijn en ingevuld worden. ICT’ers weten vaak uitstekend waar ze allemaal van afhankelijk zijn. Want daardoor halen ze iedere keer hun planning niet! Dus vraag er gewoon naar: “Wat heb jij allemaal nodig van anderen om je planning te halen?” En: “Dus als dit-en-dat allemaal geregeld is, ben jij dan de enige die nog kan zorgen voor vertraging?”. Vervolgens is het zaak om voor elke randvoorwaarde specifieke afspraken te maken met de partij die de randvoorwaarde moet invullen. Inclusief duidelijke afspraak over de deadline waarop het geregeld moet zijn. Normaal projectmanagement dus. Kwestie van regelen.

Stap 3

De derde stap komt aan op goede aansturing. Ik ben van mening dat elke professional in staat moet zijn om een realistische planning af te geven. En veel ICT’ers kunnen dat ook. Probleem is vaak dat daarvoor bepaalde randvoorwaarden ingevuld moeten worden. En die afhankelijkheden worden vaak niet helder gecommuniceerd. Het is dus zaak om alle afhankelijkheden zo uitvoerig mogelijk in kaart te brengen en dat de rest uitgevoerd kan worden door de persoon of het team in kwestie. Dan kun je iemand ook verantwoordelijk houden voor die planning.

Het punt van voortschrijdend inzicht is in te vullen door een goede wijzigingsprocedure . Een Agile werkwijze voorziet daar van nature in. En natuurlijk moet die wijzigingsprocedure zo goed mogelijk gefaciliteerd worden. Voorschrijvend inzicht wil je! Bedenk van tevoren goed hoe de besluitvorming rondom wijzigingen moet verlopen. Wie moet je allemaal betrekken? Wie mag/moet er iets van vinden? Waar wordt besloten? Op basis waarvan? Wat zijn de consequenties voor de planning? Als je de route voor wijzigingen goed hebt ingevuld, kun je daar een redelijk geoliede procedure van maken. Mits de besluitvorming goed is, is het geen enkel probleem om wijzigingen te faciliteren. Van voortschrijdend inzicht kan het echt alleen maar beter worden. Zolang de slechte wijzigingen er maar uitgefilterd worden.

Conclusie

Met bovenstaande maatregelen moet het mogelijk zijn om meer dan 80% van alle planningen in ICT te halen . De toekomst is niet te voorspellen. Dus die overige 20% gaan we denk ik nooit halen. Maar als 80% van de planningen wel gehaald wordt, zal iedereen veel tevredener zijn over ICT. En daar worden alle ICT’ers én de rest van de organisatie een stuk blijer van. En daar wordt ik dan weer blij van!

Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.