Wat werkt er allemaal niet op de gemiddelde IT afdeling waar we projecten voor de 'business' uitvoeren?

by marc 2. november 2009 07:26

Wat werkt er allemaal niet op de gemiddelde IT afdeling waar we projecten voor de 'business' uitvoeren?

- De organisatie blijf dusdanig veranderen qua koers en bemensing dat iedere keer het wiel weer opnieuw wordt uitgevonden. De lessons learned worden wel opgesteld, maar zijn bij begin van het volgende project al onvindbaar.

- De invoering van nieuwe ontwikkelmethoden (RUP) stokt door de omvang en interdepentie van projecten en door het outsourcingscontracten. Alles blijft waterval.

- Het niet opleveren (van voldoende kwaliteit) lijkt acceptabel, het niet hebben van een planning of zeggen dat je je aan een planning lijkt NIET acceptabel. Dat is raar, want iedereen vindt het dan blijkbaar prima dat er iets (een requirementsdocument, een ontwerp, een systeem) wordt opgeleverd waar iedereen van weet dat er nog een slag overheen moet. Maar de planning blijft heel lang heilig. Op een afgesproken datum krijgen we dus iets wat we onvolledig vinden, of eigenlijk niet willen, terwijl we dan nog steeds niet weten wanneer we wel krijgen wat we willen.


Dat moet worden aangepakt...

Naar mijn overtuiging werkt het (een beetje beter) als we
1. Agile planning toepassen
2. Vertrouwen creeeren tussen klant (business) en leverancier (it)
3. Fouten mogen maken.

 

Agile planning toepassen

Agile planning zegt dat plannen waarschijnlijk snel kunnen veranderen. Het is daarom nuttig om een 'feature'planning te maken. Los inschatten wat de omvang van een stukje functionaliteit is. Oftewel hoeveel tijd zou het kosten om een bepaald requirement te gaan realiseren. Nog even los van andere requirements. Pas nadat we alle inschattingen gemaakt hebben, proberen we de doorlooptijd in te schatten. Voordeel: je denkt elk requirement afzonderlijk door. Ook dat is nuttig bij het zien van de afzonderlijke risico's. Pas daarna voeg je gedeelde functies samen. Doe je het niet in deze volgorde dan zul je zien dat je per requirement minder goed weet wat er mee gemoeid is en tegelijkertijd reken je je rijk in de planning omdat je vermoed dat er gedeelde componenten in zitten.
Wees ook helder over onzekerheid òf in functionaliteit òf in de opleverdatum. Maar niet in allebei!

Vertrouwen creeren

Politiek gezien is de focus van verschillende afdelingen vaak erg uiteenlopend. Gevolg hiervan is dat beide partijen vaak enigszins wantrouwend zijn ten aanzien van de doelen die men met een bepaald programma of project denkt te bereiken.
Vertrouwen ontstaat pas als op meerdere niveau's bij zowel klant als leverancier helder en open gecommuniceerd wordt over korte en lange termijn doelen. Met daarbij uiteraard de kanttekening dat korte en lange termijn consistent moeten zijn en in elkaars verlengde liggen.

Fouten mogen maken

Het vermijden van fouten leidt tot gedrag waarbij risico's en onzekerheid onder de oppervlakte blijven. Dat op zijn beurt is niet goed voor het onderling vertrouwen. Des te eerder wordt overgegaan van planvorming naar uitvoering (van een eerste deelgebied) des te eerder loop je tegen je eigen onwetenheid aan. Dit moet niet afgestraft worden door de omgeving, maar herkend worden als aandachtsgebied.

 

Tags: , ,

Mogelijk Interessant