Projectmanagement is risicomanagement
Het slagen danwel falen van een softwareproject heeft alles te maken met management. En ondanks de technische lading van de term ‘softwareontwikkelmethode’, is een methode een van de sterkste krachten achter het management van een project. Hoewel deze stelling ongetwijfeld op weerstand stuit, is dit eenvoudig te motiveren: met de keuze voor een bepaalde methode als startpositie van een project maken we veel impliciete managementkeuzes. Ter illustratie: we kunnen niet voor een ‘agile’ methode kiezen en vervolgens ook nog eens ‘kiezen’ voor een autoritaire managementstijl. Een van agile’s fundamenten is namelijk een coachende leiderschapsstijl die uitgaat van gelijkheid. Zonder dit fundament kan een project niet ‘agile’ worden genoemd. De selectie van een methode is derhalve van groot belang, omdat het mogelijk is dat we bij een keuze voor een methode onbewust ook keuzes maken die een risico voor het project zijn.
Een softwareontwikkelmethode – zoals RUP (Rational Unified Process) en XP (Extreme Programming) – beschrijft elementen zoals de levenscyclus van het project, de principes, de belangrijke rollen en producten, en de technieken die gebruikt kunnen worden om een softwareproject aan te pakken. Kijkend naar alle beschikbare methoden, dan is er een heel aantal dimensies waarop ze kunnen verschillen. Zo ontwikkelt de ene methode bijvoorbeeld alles in één keer terwijl de andere de software opdeelt in kleinere, gemakkelijker beheersbare projecten (iteraties). De ene methode beschrijft gedetailleerd ‘wat’ de projectleden moeten doen en ‘hoe’ dat te doen, terwijl de andere methode het projectteam vrij laat in zijn keuzes.
Het is duidelijk dat deze verschillen niet per definitie ‘goed’ of ‘slecht’ danwel ‘sterk’ of ’zwak’ zijn. Wel is expliciet te stellen dat het ene sterker is in een bepaalde situatie dan het andere. Dit lijkt een open deur, maar denkend aan ongenuanceerde claims die veel boeken en websites bezitten, wordt duidelijk dat deze deur in de praktijk vaak hermetisch is gesloten. XP’s keuze om primair te werken op basis van ‘tacit knowledge’ (kennis in de hoofden van mensen) in tegenstelling tot gedocumenteerde kennis, werkt bijvoorbeeld uitstekend in het geval van ‘bewegende’ functionele eisen. Wijzigingen zijn dan immers sneller en gemakkelijker door te voeren. Echter, de kracht van XP is beduidend zwakker wanneer het een project van langere duur betreft, vanwege het kennisverlies dat wordt geriskeerd door onvermijdelijk personeelsverloop. Of in het geval dat projectmedewerkers niet gemakkelijk bij elkaar langs kunnen lopen, zoals het geval is bij offshore outsourcing.
Door de grote verscheidenheid aan projectsituaties en het missen van een raamwerk om de projectsituatie te ‘matchen’ met een methode, staat de softwareprojectmanager met de handen in het haar. Wat is ‘de juiste’ keuze? Hoe maak je die keuze? De projectmanager kiest er vervolgens veelal intuïtief voor om een klein aantal vuistregels (‘gebruik <methodenaam> wel/niet als <omschrijving van situatie>’) toe te passen. De beschikbare literatuur, maar ook gezond verstand, biedt hiervoor prima handvatten. Kortom: we beseffen dat ieder project anders is en daarom een andere methode c.q. aanpak vereist. Daar handelen we dan ook naar met behulp van een aantal algemene vuistregels. Wat is dan nog het probleem?
De genoemde vuistregels vormen inderdaad een nuttige uitgangspositie voor een projectmanager. Een aantal clichévoorbeelden: wanneer de eisen duidelijk en stabiel zijn, dan kiezen we een watervalaanpak. Wanneer er sprake is van grote dynamiek en software met hoge interactiviteit, dan kiezen we voor een ‘agile’ methode zoals XP of Scrum. Zonder in dit artikel uitspraken te willen doen over de validiteit van deze voorbeelden, is het achterliggende ‘waarom’ gemakkelijk te begrijpen. Er zijn namelijk projectrisico’s die we willen voorkomen, en daarom maken we bepaalde keuzes. Softwareprojectmanagement is dan ook in essentie risicomanagement.
Het management moet alle risico’s zoveel mogelijk beperken. In het geval we bijvoorbeeld levenskritische software ontwikkelen, moeten we ervoor zorgen dat de aanwezigheid van defecten minimaal is. Wanneer de software een lange geplande levensduur heeft, moeten we er zeker van zijn dat toekomstig onderhoud geen probleem wordt. De crux is dat de ene methode beter is in het voorkomen/beperken van het risico dan de andere.
Dit sluit aan op de filosofie achter de vuistregels. Het grote probleem van de selectie en toepassing van een methode zit dan ook niet in deze vuistregels op zich, maar meer in de beperkte dekking ervan. De meest eminente risico’s zijn wellicht gedekt, maar het is een misvatting om te denken dat de methode er dan niet zo veel meer toe doet. De ervaring leert namelijk dat het project vervolgens toch telkens tegen problemen (het optreden van risico’s) aanloopt en dat de initiële aanpak tot het einde toe evolueert tot ‘de juiste’ aanpak. Een van deze problemen kan bijvoorbeeld zijn dat ondanks de gebrekkige klantdomeinkennis van het team, de betrokkenheid van de klant laag is, wat vervolgens misverstanden (en daarmee vertragingen) in de hand werkt. Als dit wordt geconstateerd – er is dan al pijn geleden – kan de aanpak zodanig worden aangepast dat de kennis van de klant (die het domein zonder meer het beste kent) beter wordt benut.
De initiële keuzes zijn, kortom, vaak minder compleet en doordacht dan wordt aangenomen. Dit heeft alles te maken met onze gelimiteerde rationaliteit (‘bounded rationality’). Het is bekend dat we niet in staat zijn om alle relevante factoren (in dit geval risico’s) te definiëren en te wegen. Een ander psychologisch feit betreft onze neiging om besluitvormingsprocessen af te breken op het moment dat we iets gevonden hebben dat acceptabel lijkt. We hebben wat vuistregels om een methode te selecteren en te gebruiken, zien vervolgens een methode die daar op aan lijkt te sluiten (bij voorkeur natuurlijk een methode die we al kennen) en beginnen enthousiast aan het project.
Softwareprojectmanagement is complex. Veel softwareprojecten zijn op dit moment te reactief: op het moment dat er iets misgaat, wordt dit gesignaleerd en actie ondernomen. Het probleem is echter dat er dan al extra kosten zijn gemaakt, tijd is verloren en frustraties zijn gecreëerd.
Juist door aan het begin van een nieuw project inzicht te creëren in de risico’s, kunnen we objectiever en proactief nadenken over de ‘juiste’ methode/aanpak.