Planning maken in ICT – Zo levert ICT wél op tijd

by | Jul 13, 2018 | Artikelen, Planning

Planning maken in ICT.
Zo levert ICT wél op tijd

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.

Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Lees ook deze artikelen

Het luikje bij de chinees

Het luikje bij de chinees

Je kent het vast wel. Je ziet het steeds minder. Maar ik vind het een mooie vergelijking. Het luikje bij de afhaalchinees. De grote vraag is natuurlijk: "Wat gebeurt daar achter dat luikje?" De  vergelijking met IT werd gebruikt door een architect. Toen hij een...

Assumption is the mother of all fuckups

Assumption is the mother of all fuckups

Assumption is the mother of all fuckups. Het is een veelgehoorde uitspraak in IT. En terecht, want een misverstand is snel geboren. Als je het verkeerde IP-adres intikt, gaat het gewoon niet werken. Zeker als systemen met elkaar moeten communiceren. Dat weten IT’ers...

Share This