ProjectManagement is risicomanagement

Het kiezen van een bepaalde softwareontikkelmethode heeft grote gevolgen voor het management van een project. Het implicitiert risicos’s. De softwareprojectmanager zit vaak met de handen in het haar: Hoe de projectsituatie te “matchen”met een methode? We zijn niet in staat, constateert KlaasJan Molendijk en Stef Oud, om alle relevante factoren te definieren en te wegen.

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 manage­mentstijl. Een van agile's fundamenten is namelijk een coachende leiderschaps­stijl 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 handvat¬ten. Kortom: we beseffen dat ieder project anders is en daarom een andere methode c.q. aanpak vereist. Daar hande¬len 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. Softwareprojectma¬nagement 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.

Er bestaat weinig tot geen regelgeving voor softwareontwikkeling

Dit sluit aan op de filosofie achter de vuistregels. Het groteprobleem 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 klantdomein­kennis van het team, de betrokkenheid van de klant laag is, wat vervolgens misverstanden (en daarmee vertraginingen) 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 ma¬ken 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. Softwareprojectrnanagement 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.

Klaas-Jan Molendijk (kmolendijk@deloitte.nl) is als consultant en
Stel Oud is als partner werkzaam bij
Deloitte Consulting - Business Technology Advisory

LESSONS LEARNED

• De projectsituatie is geen statisch element en bestaat derhalve voor een groot deel uit beïnvloedbare elementen. Het contracttype, wel of geen off­shoring, de mate van klantbetrokken­heid: het zijn allemaal keuzes.
  
  Een voorbeeld: waarom een project starten als de software-eisen onduidelijk zijn, maar de klant toch niet intensief betrokken kan/wil zijn? Een methode kan nooit de risico's compenseren die wij op een dergelijke manier zelf creëren.
  
  
• Een projectsituatie is vrijwel altijd niet upiform; één deel van de software is misschien wel bedrijfskritisch, maar een ander deel niet. Niet alleen ieder project behoeft een specifieke aanpak, ook de verschillende deelsituaties. Het is in deze gevallen zelfs aan te raden om een eigen methode/aanpak te kiezen voor deze subprojecten en de aandacht te concentreren op het managen van interfaces.
  
  
• De IT-wereld staat bekend om al zijn methoden. Het projectteam zou het echter los moeten laten om in metho­den te denken.
  
  Veel belangrijker zijn de elementen uit een methode die succesfactoren zijn voor het specifieke project. Het gaat er niet om of een project MSF wordt genoemd of XP, maar om het voorko­men danwel beperken van projectrisi­co's.
  
  De oplossing is dan ook niet altijd de selectie van een andere methode, maar juist om het op een andere manier toepassen van een methode.
  
  
• Ondanks alle beschikbare methoden en technieken bestaat er weinig tot geen regelgeving op het gebied van software­ontwikkeling. Iedereen mag zich bijvoorbeeld ontwikkelaar noemen en vrij gebruikmaken van methoden. Kortom: er is geen controle op methoden en daarmee op de kwaliteit van softwareontwikkeling.

BEKENDE METHODEN

• RUP (Rational Unified process)
  Een via een tooI aangeboden raamwerk voor het creëren van een projectspeci­fieke aanpak, gebaseerd op onder meer iteratief en architectuurgeoriënteerd ontwikkelen. Wordt gekenmerkt door de compleetheid en de sterke relatie met UML (use cases).
  
  
• SDM (Software Development Methodo­logy)
  Een concrete invulling van de waterva­laanpak die met name bekend is in Nederland. In een watervalaanpak volgen ontwikkelingsfasen - van definitiestudie tot de implementatie - elkaar sequentieel op. De aanpak wordt veelal bekritiseert vanwege het formele karakter en het gebrek aan flexibiliteit.
  
  
• XP (Extreme Programming)
  Zonder meer de bekendste 'agile' methode. Bekend door de korte iteraties, focus op eenvoud, face-to-face communi­catie, een volledig participerende klant en door 'practices' zoals 'refactoring' en 'pair programming'.
  
  
• MSF (Microsoft Solution Framework)
  Een relatief nieuwe, door Microsoft geïntroduceerde aanpak voor software­projecten. Is ook gebaseerd op 'agile' principes (zie bijvoorbeeld XP).
  Het 'framework' biedt twee smaken:
• MSF4Agile en
• MSF4CMMI.

Het grootste verschil is dat MSF4CMMI formeler is en daarmee geschikter voor grotere en langer durende projec­ten.

• DSDM (Dynamic Systems Development Method)
  Een aanpak die is gebaseerd op sterke gebruikersparticipatie, iteratief ontwik­kelen, zelforganiserende teams en een informele aanpak. Wordt vaak geassoci­eerd met technieken als prototyping, timeboxing en het prioriteren met behulp van MoSCoW.
  
  
• Scrum
  Een op rugby gebaseerde iteratieve aanpak, die grote vrijheid geeft aan de (kleine) teams wat betreft de te gebrui­ken technieken. Hierdoor wordt Scrum soms alleen een managementaanpak genoemd. De methode is bekend door de 'daily stand­up meetings'.

23 NOVEMBER 2007 Automatisering Gids

Technorati Tags XP, project, Automatisering, Gids, Projectmanagement, risicomanagement, RUP, SDM, MSF, DSDM, Scrum