Het ministerie van Defensie is al jaren bezig met het invoeren van een ERP (Enterprise Resource Planning)-softwaresysteem. Dit project, genaamd SPEER, is bekend geworden als één van de grote, mislukte ICT-projecten van de overheid. Oorspronkelijk zou het programma vanaf 2009 draaien, maar dat is tot op heden niet het geval. Na vele vertragingen, reorganisaties en omvangrijke kostenoverschrijdingen, ontsloeg minister Hennis-Plasschaert onlangs de topmanagers die het project aanstuurden en er werd aangekondigd dat de voltooiing van het project nog langer op zich laat wachten. Extra mankracht zal worden ingehuurd om het alsnog op een afzienbare termijn af te ronden.
Van dat laatste moet echter niet te veel verbetering worden verwacht; althans als we Brooks’ Law moeten geloven. Software engineer Fred Brooks schreef in zijn boek The Mythical Man-Month dat het toevoegen van extra mankracht aan een softwareproject de oplevering eerder later maakt dan vroeger. Zijn ervaringen bij IBM deden hem inzien dat het uitdrukken van de scope van een complex project in manuren (of –maanden) niet werkt, omdat de totale inzet voor het werk niet overeenkomt met het aantal mensen dat eraan werkt maal de uren die zij theoretisch maken.
Hier zijn verschillende redenen voor. Hoe complexer een project, hoe meer mensen eraan werken en hoe specialistischer het werk is dat zij doen. Dat betekent ook: hoe meer zij daarover met elkaar moeten communiceren en hun werkzaamheden moeten coördineren. Als mankracht wordt toegevoegd, nemen die activiteiten dus ook toe. Bovendien moet nieuwe mankracht ingewerkt worden en dat kost tijd. Niet alleen hun eigen tijd, maar ook die van degenen die hen moeten inwerken. En dat zijn vaak de mensen die al aan het project werkten en nu van hun hoofdtaak worden afgeleid. Daarbij komt nog eens dat de extra mensen die worden ingezet vaak aan meerdere projecten werken of kunnen werken. Gedurende de tijd die zij aan het vertraagde project werken, kunnen zij niet ergens anders worden ingezet, wat ook weer andere projecten zou kunnen vertragen.
Het meest logische alternatief lijkt dan om de mensen die al aan het project werken overuren te laten maken. Maar ook die oplossing kent beperkingen. Jack Homer beschreef in een artikel in System Dynamics Review dat overwerk vaak inefficiënt is. Het kan leiden tot uitputting, frustratie en improductiviteit. Verbeteringen in tijdsbesteding worden dus niet bereikt door het gemaakte aantal manuren te maximaliseren, maar door de productiviteit van de individuele werknemer te optimaliseren, met bijbehorend aantal manuren.
Om te voorkomen dat de totale productiviteit daalt en andere activiteiten van een organisatie eronder lijden, is het bij vertraagde complexe projecten vaak beter om dynamiek te vermijden. Optimalisaties zijn vooral zinnig aan het begin van het project. Accepteer daarna dat het werk zijn tijd nodig heeft of snijd in de scope, zoals het ministerie van Defensie nu gedaan heeft. Zoals Fred Brooks zelf zei: ‘negen vrouwen kunnen een baby niet in één maand maken’.
Do’s:
- Verbeter een project aan de voorkant: het optimaliseren van scopedefinitie en planning heeft veel grotere effecten dan herstelwerk tijdens het project.
- Optimaliseer tijdsplanning op basis van (individuele) productiviteit, niet op basis van manuren.
Don’ts:
- Vertragingen van een complex project oplossen met meer mankracht.
- Vertragingen van een complex project oplossen met het maken van overuren.
