Rolling Planning

by marc 17. januari 2010 07:22

Voortgangsrapportages tonen vaak hoeveel procent een bepaalde taak al is afgerond.

  • Maar heb je wel echt alle activiteiten die nodig zijn voor dat requirement doordacht? Met andere woorden weet je echt wel wat 100% is?
  • En is het niet zo dat de laatste 20% altijd 80% van de tijd kost?

Kortom wat heb je aan voortgangspercentages die zeggen dat een bepaalde taak voor 70% gereed is? Helemaal niets.

Hoe komen we wel tot een een rapportage die een beeld geeft en die aanknopingspunten voor bijsturing biedt?

  • per taak een verwachte einddatum invullen door degene die de taak uitvoert
  • als meer informatie is over een taak, dan deze direct uitsplitsten naar subtaken en per subtaak een verwachte einddatum laten invullen.
  • degene die moet bijsturen, gaat niet verwachte einddata ter discussie stellen. Hij heeft immers minder expertise en het getuigt van weinig respect ten opzichte van de professional die de inschatting maakt als hij zegt het beter te weten
  • degene die moet bijsturen, gaat wel de volgorde van gelijkwaardige, niet onderling afhankelijke taken ter discussie stellen. Sommige verder naar achter schuiven, waardoor meer tijd vrijkomt om risicovolle taken toch op tijd gereed te hebben.

En dat is mijn mening.

Tags:

Mogelijk Interessant

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