Management accounting & control:
AGILE SYSTEEMONTWIKKELING EEN STUDIE NAAR PROJECTSUCCES IN DE FINANCIËLE SECTOR De financiële functie verschuift en wordt steeds meer gezien als een volledige business partner. Nieuwe trends in rapportage zijn echter niet mogelijk zonder de juiste toepassing van IT. Voor ontwikkeling van IT-systemen bestaan verschillende methodieken: traditionele methoden zoals het watervalmodel, die sterk leunen op formele mijlpalen en een hiërarchische structuur, en Agile methoden die uitgaan van flexibiliteit, sociale leerprocessen, korte ontwikkelcycli en directe feedback. Traditionele methoden lijken beter te passen bij de eisen van de sterk gereguleerde financiële sector, maar ook daar is Agile aan een opmars bezig. In de praktijk blijken echter niet alle IT-projecten op te leveren wat ze beloven. Wat is de invloed van de ontwikkelmethodiek op het succesvol afronden van een project voor systeemontwikkeling?
30
MCA: februari 2014, nummer 1
Miriam Martens, Guido Veldhuijs en Joris Hulstijn: Binnen de ‘finance’ afdelingen
Finance nader beschreven
van financiële dienstverleners worden regelmatig projecten doorlopen voor de ontwikkeling of aanpassing van informatiesystemen. Vooral door veranderingen in de bestaande wet- en regelgeving is er veel behoefte aan een integrale aanpak van projecten. Veel IT-projecten falen echter en dit percentage is relatief groot bij financiële instellingen (Lee en Xia, 2010; Markus, 1983; Richmond, 2008; Tichy en Bascom, 2008; Zhen, 2005). Vaak zijn de oorzaken terug te leiden naar menselijk handelen, maar het falen lijkt mede te worden veroorzaakt door de gebruikte traditionele ontwikkelmethodieken. Deze zijn vrij ‘mechanisch’: ze leunen sterk op bestaande hiërarchische lijnen, op een vastgelegde planning en op harde afspraken over op te leveren resultaten (Geraldi, 2008). Een methodiek die hiervoor een goede oplossing lijkt te bieden is Agile systeemontwikkeling (Lee en Xia, 2010; Mahnic en Zabkar, 2008). Deze methodiek is gericht op het kunnen inspringen op veranderingen, strategisch denken en leren gedurende het project. Doordat de financiële sector wordt gedomineerd door strakke regelgeving waarbinnen geen ruimte lijkt te bestaan voor een flexibele inrichting van eisen en producten, is het de vraag of Agile ontwikkelmethodieken geschikt zijn voor systeemontwikkeling binnen het financiële domein. In dit artikel vergelijken we het succes van de twee ontwikkelmethoden. We laten zien welke factoren kunnen bijdragen aan een succesvol project voor systeemontwikkeling. Hiervoor hebben wij als cases een zestal systeemontwikkelingsprojecten bij twee financiële instellingen onderzocht. We gaan eerst in op de ontwikkeling van de financiële functie. Daarna beschrijven we wanneer een project als succesvol kan worden beschouwd. Op basis van deze definitie is bepaald welke van de zes cases ‘succesvol’ kunnen worden genoemd. We lichten de twee verschillende projectmethoden toe en we vergelijken de typische elementen van de traditionele systeemontwikkelingsmethodiek met de typische elementen van Agile methoden en brengen deze vergelijking onder in een raamwerk. Uit analyse van de onderzochte cases aan de hand van het raamwerk blijkt dan welke elementen gelden als ‘succesfactor’ en een positieve invloed hebben op het succesvol opleveren van een project en welke elementen juist een negatieve invloed hebben.
Financiële instellingen zoals banken en verzekeraars staan onder invloed van verschillende ontwikkelingen in de wereld onder grote belangstelling. Deze ontwikkelingen hebben rechtstreeks invloed op het functioneren en op de werkzaamheden van de financiële afdeling binnen deze organisaties. De financiële afdeling wordt geacht een toegevoegde waarde te leveren aan de organisatie door een proactievere houding aan te nemen bij het nastreven van de strategische doelstellingen van de organisatie (De Waal, 2003). Daarbij moet de van buitenaf opgelegde wet- en regelgeving worden omgezet in werkbare toepassingen binnen de onderneming. Daarnaast zijn er meer primair bedrijfseconomische redenen voor een proactievere houding. Te denken valt aan het aantal sterk toegenomen complexe financiële producten, het transparanter worden van de financiële markten en de extreem grote hoeveelheid toepassingen van ICT en internet binnen de financiële instellingen (Cohan, 2006). Deze ontwikkelingen maken dat marges versmallen, zodat het accuraat managen, meten en rapporteren van risico’s steeds noodzakelijker worden (Leenaars, 2003). De hierboven beschreven trends zouden niet mogelijk zijn zonder de invloed van de vele ontwikkelingen op het gebied van de informatietechnologie (IT). Er is dan ook een zichtbare toename in het aantal Finance gerelateerde IT-projecten (De Waal, 2003). Lang niet alle projecten worden echter succesvol afgerond.
Succesvol project Om succes te definiëren is gebruik gemaakt van de definitie van Bradley (2008, p. 175): ‘Project success is defined as organizational impact and on time and on/under budget project completion.’ Of een project als succesvol kan worden bestempeld, wordt vaak beoordeeld aan de hand van drie succesfactoren: of een project binnen budget is gebleven, of het project is opgeleverd binnen de gestelde tijd en of het resultaat voldoet aan de vooraf gestelde eisen. Er wordt in dit verband ook wel gesproken van de duivelsdriehoek (Brooks, 1987). Wanneer aan een van de succesfactoren niet wordt voldaan, kan met de andere twee worden geschoven. Vaak zijn het echter de succesfactoren budget en tijd die vaststaan en zodoende zal dan met de eisen worden geschoven. Ieder project worstelt met deze afwegingen en dit heeft zijn invloed op het gevoerde projectmanagement.
MCA: februari 2014, nummer 1
31
Ref. Factoren
Projectmanagementbenadering
1.1
Traditioneel
Voornamelijk gericht op projectplan en projectproces
Agile
Gericht op hoe mensen functioneren binnen project
Traditioneel
Prioriteit geven om alles binnen de scope van project te ontwikkelen
1.2
2
3
4
Focus bij project
Agile
Eerst doen wat meest belangrijk is, de rest wordt in back log gehouden
Wijzigingsbeheer
Traditioneel
Wijzigingsbeheer uitvoeren waarbij de procedures strikt gevolgd worden
Agile
Wijzigingsbeheer uitvoeren waarbij de procedures flexibel zijn en aangepast kunnen worden
Team
Traditioneel
Formeel team, bestaande uit voornamelijk IT-technische mensen, die functioneren middels strikte hiërarchie en officiële communicatie
Agile
Kleine multidisciplinaire teams, die zelfsturend opereren, open communiceren en zelforganiserend zijn
Traditioneel
Management volgt hiërarchische organisatie en formele richtlijnen, stuurt vooral op methode
Agile
Management acteert continu op basis van vrijwillige interactie, waarbij flexibel en met zo min mogelijk hiërarchie gewerkt wordt, stuurt vooral op uitkomst
Traditioneel
Werknemers zijn vervangbaar. Prioriteit is dat de expertise aanwezig is
Agile
Werknemers zijn essentieel en onmisbaar
Traditioneel
De klant is alleen betrokken bij het opstellen van de eisen en de oplevering
Agile
De klant is continu betrokken en is onderdeel van het team
Management
5
Mens
6
Klant
7
8
9
10
11
Omschrijving
Ontwikkelaars Traditioneel
Testen
Techniek en complexiteit software
Agile
Ontwikkelaars werken middels korte oplevermomenten met iteraties, waarbij het doel is continu te leren aangezien eisen door de tijd veranderen
Traditioneel
Testen vinden plaats aan het einde van ontwikkelcycli (eindtest), middels aparte testers
Agile
Testen gebeurt veelvuldig en vaak geautomatiseerd; (veelal) unittest en integratietest) waarbij de tester onderdeel is van het team
Traditioneel
Grote mate van complexiteit, doordat techniek en software ook aan toekomstige eisen/wensen moeten voldoen
Agile
Alleen minimaal benodigde software wordt gebouwd; per onderdeel minder complex, samenvoegen van de losse onderdelen is wel complex
Documentatie Traditioneel
Planning
Ontwikkelaars gaan uit van projectplan en op te leveren ‘milestones’ volgens planning
Continu gedurende het project wordt er documentatie bijgehouden
Agile
De geschreven softwarecode vormt zelf de documentatie
Traditioneel
Er wordt gewerkt volgens vaste planning en duidelijk gestelde producten
Agile
Er wordt gewerkt met continue planning, gericht op gestelde prioriteiten, hoogste prioriteit eerst
Figuur 1. Mogelijk succesbepalende factoren per methodiek
Mate van acceptatie Naast de succesfactoren uit de duivelsdriehoek is er nog een vierde factor die de mate van projectsucces kan weergeven en dat is de mate van acceptatie (Davis, 1989). Wanneer het eindproduct van een project niet wordt geaccepteerd door het management of door de eindgebruikers, en het wordt vervolgens niet gebruikt, is het project niet succesvol. De definitie van succes is daarom sterk afhankelijk van de betrokken personen. Personen die alleen betrokken zijn bij de technische implementatie, zullen al van succes spreken voordat een systeem geac-
32
cepteerd is, terwijl voor een klant juist de acceptatie van belang is.
Projectmethoden vergeleken Projectmanagementmethoden omvatten het geheel van afspraken, werkwijzen, procedures en hulpmiddelen bedoeld om de activiteiten zo te plannen dat de projectdoelstellingen kunnen worden gehaald (Project Management Institute inc., 2000, p. 6). In het bijzonder voor IT-ontwikkeling wordt er gesproken over systeemontwikkelingsmethodieken. Deze kunnen worden ingedeeld in de traditionele en de nieuwere Agile methoden. De traditionele metho-
MCA: februari 2014, nummer 1
den zijn vooral geschikt voor routinematige projecten waarvan de eisen vastliggen (Khalifa en Verner, 2000). Ze werken veelal volgens een vast stramien waarbij het volgende pad wordt doorlopen: analyseren, ontwerpen, implementeren, testen en ten slotte het in productie brengen. De traditionele methoden pakken de planning van het gehele product in één keer aan en kunnen daarom niet goed omgaan met tussentijdse aanpassingen. Ze lijken zekerheid te bieden door het voorspellen van een vaste opleverdatum, projectprijs en op te leveren functionaliteiten, maar in de praktijk blijkt dit niet altijd gerealiseerd te worden (Richmond, 2008). Daarnaast wordt er geen rekening gehouden met de managementvaardigheden van de betrokken medewerkers, met de gevolgen van sociale interactie en wordt de klant pas laat bij het project betrokken. Als tegenhanger hierop heeft Agile zich ontwikkeld. De Agile ontwikkelmethodieken zijn sterker gericht op de wensen van de klant, kunnen goed omgaan met veranderende eisen gedurende het project en werken volgens een snelle ontwikkel- en oplevertijd (Van Drunen et al., 2008). Als nadelen worden genoemd dat de eisen vooraf niet tot in detail duidelijk zijn, niet helder is hoeveel middelen en tijd er benodigd zijn en de formele communicatie buiten het team niet wordt gepromoot (Barlow et al., 2011). Er kan dus niet zonder meer worden gesteld dat de ene methodiek geschikter is dan de andere. De Agile ontwikkelmethodieken hebben veel gemeen met iteratieve ontwikkelmethodieken zoals Rapid Application Development en Rapid Prototyping. Deze methodieken zijn ook gericht op de wensen van de klant en het inspringen op veranderende eisen. Ze propageren het herhaald doorlopen van een ontwikkelcyclus. Het belangrijkste verschil tussen Agile en Rapid Prototyping is dat deze laatste methodiek gelijk begint met het ontwikkelen van een prototype en dit gedurende het traject voortdurend bijwerkt tot het gewenste product is bereikt. Agile daarentegen werkt meer vanuit het idee om één project in kleinere deelprojecten op te knippen en deze pas op te leveren wanneer ze gereed zijn. In ons onderzoek beperken we ons tussen een vergelijking van Agile en de traditionele projectmethoden. Door de jaren heen is verschillend onderzoek gedaan naar de factoren die hun invloed kunnen hebben op het succes van een project (Augustine en Woodcock, 2008; Barlow et al., 2011; Dagevos, 2011;
Van Drunen et al., 2008; Ghosh et al., 2012; Hoda et al., 2008; Khalifa en Verner, 2000; Lindstrom en Jefries, 2004; Lyndsay, 2007). Op basis van deze literatuur hebben we een elftal mogelijk succesbepalende factoren geïdentificeerd die de verschillende methodieken karakteriseren. In figuur 1 is aangegeven hoe deze karakteristieke factoren per systematiek zijn ingevuld.
Methode van onderzoek Om te kunnen onderzoeken of een bepaalde ontwikkelingsmethodiek nu meer of minder geschikt is voor systeemontwikkeling en welke factoren hier aan bijdragen, hebben we een zestal praktijkcases van ITprojecten bij financiële instellingen onderzocht. Daarbij zijn er drie cases die volgens de traditionele methodiek zijn uitgevoerd en drie cases die kunnen worden gezien als een toepassing van de Agile methodiek. Voor elk van de cases hebben we onderzocht in hoeverre deze projecten bestempeld konden worden als succesvol, op basis van de volgende kenmerken (Bradley, 2008; Brooks, 1987; Davis, 1989): ~ binnen budget; ~ binnen gestelde tijd; ~ conform gestelde eisen; ~ acceptatie door management en eindgebruikers.
Beschrijvingen en validatie cases De zes geselecteerde cases zijn financieel gerelateerd en hebben alle betrekking op systeemontwikkeling. Bij beide organisaties van de auteurs zijn zowel Agile als traditionele cases meegenomen in de selectie, bij iedere organisatie zijn drie cases geselecteerd. Hieronder volgt kort een beschrijving waarop de betreffende case betrekking heeft: ~ Case 1: het opleveren van een eenduidig klantbeeld in financiële rapportages. Rol
Projectmanager
Case 1
x
Case 2 Case 3
IT
Business
x x
Case 4
x
x
x
Case 5
x
Case 6
x
x
x
Figuur 2. Overzicht interviews per case met de verschillende rollen
MCA: februari 2014, nummer 1
33
VERDELING FACTOREN PER CASE Traditionele factoren
Agile factoren
12 # FACTOREN
10
2
4 6
8
10
6
9
11
4 2
2
0
3
1
CASE 1
10
8
6
CASE 2
CASE 3 CASE 4 CASES
CASE 5
naar de gebruikte ontwikkelmethodiek voor de betreffende case. Volgens de respondenten van de interviews zijn case 1, 2 en 3 Agile projecten geweest en case 4, 5 en 6 traditionele projecten. Middels interviews en vragenlijsten hebben we gevalideerd in hoeverre bij een gekozen methode daadwerkelijk invulling wordt gegeven aan de beschrijvingen, passend bij de betreffende factoren uit de tabel, door per factor steeds twee stellingen aan de respondenten voor te leggen, zonder kenbaar te maken welke stelling betrekking had op welke methode. De validatie van de gebruikte projectmethodiek op basis van de antwoorden op de stellingen is weergegeven in figuur 3.
CASE 6
Figuur 3. Validatie van de cases op basis van antwoorden op de stellingen TRADITIONELE CASES Agile beoordeeld
# WAARNEMINGEN
Traditioneel beoordeeld 1
1
1
1
1
1
2
2
3
3 4
4
4
4 4
4
4
4
3
3
2
2 1
1.1
1.2
2
3
1
4
5
6
7
8
9
10
11
FACTOR REF
Figuur 4. Waarnemingen op de stellingen met betrekking tot de factoren van projectsucces binnen de onderzochte traditionele cases
~ Case 2: Het opruimen van verschillende rapportages en een datawarehouse en dit naar een nieuw platform brengen. ~ Case 3: Maandelijkse releases op grootboeksystemen. Dit kan worden gezien als aparte kleine projecten binnen de bestaande beheersorganisatie. ~ Case 4: Standaardisatie van de managementrapportage om te zorgen voor één uniforme tool die voor zowel rapportage op centraal als decentraal niveau geschikt is. ~ Case 5: Het opzetten van een systeem voor tijdregistratie om meer inzicht te krijgen in de duur van processen en de capaciteitsplanning van medewerkers te optimaliseren. ~ Case 6: Het vervangen van een oud (maatwerk) systeem voor de verwerking en administratie van betalingen en implementatie van een nieuw standaardsysteem. Voor sommige cases zijn meerdere interviews gehouden, bijvoorbeeld met een projectmanager, met IT-technische mensen of met de gebruikers die onderdeel uitmaakten van het project. In totaal hebben we 10 interviews gehouden, 5 per methodiek. We hebben bewust alle informatie apart verwerkt, omdat de mensen in de verschillende rollen verschillende inzichten hebben in het project. In de interviews hebben we allereerst gevraagd
34
Resultaten In de figuren 4 en 5 geven we een overzicht van de resultaten van de stellingen voor alle cases en laten we het onderscheid zien tussen de resultaten voor de traditionele en de Agile cases. De definitie Traditioneel of Agile is vooraf gegeven door de respondenten tijdens de interviews en komt overeen met de positionering van de cases op de factoren uit het theoretisch kader zoals weergegeven in figuur 1. De details onder Traditioneel beoordeeld en Agile beoordeeld zijn bepaald door de keuze van de stellingen. Dus wanneer een respondent bij factor 6 kiest voor ‘de klant is alleen betrokken bij het opstellen van de eisen en de oplevering’, dan zeggen we dat de case op dat punt ‘traditioneel’ is beoordeeld. Uit deze figuren blijkt het volgende. De Agile cases maken voornamelijk gebruik van Agile factoren. Opvallend is dat de traditionele cases een mix vormen van traditionele en Agile factoren. In de praktijk blijkt dus dat ook in projecten die als traditioneel bestempeld zijn, duidelijk elementen van de Agile methodes worden toegepast. Dat geldt vooral voor factor 2 (wijzigingsbeheer), 3 (team), 6 (klant) en 10 (documentatie).
Individuele succesfactoren Naast het feit dat we onderzoeken of Agile systeemontwikkeling succesvoller is dan traditionele systeemontwikkeling, veronderstellen we dat de door ons genoemde factoren op zichzelf een positieve bijdrage kunnen leveren aan succesvolle systeemontwikkeling binnen de financiële afdelingen. Op basis van de door ons onderzochte cases en de diepte-interviews blijkt dat onderstaande factoren individueel het succes van een project beïn-
MCA: februari 2014, nummer 1
AGILE CASES Agile beoordeeld
# WAARNEMINGEN
Traditioneel beoordeeld
vloeden. Uit de interviews kwam naar voren dat de hieronder genoemde individuele factoren een dusdanige impact hebben op het wel of niet succesvol zijn van een project dat deze door ons als individuele succesfactor bestempeld zijn. Afhankelijk van de gekozen projectmethodiek kan er per factor dus volgens de Agile systeemontwikkeling of volgens de traditionele systeemontwikkeling invulling aan gegeven zijn. Functioneren van het team Deze set stellingen geeft de keuze tussen ‘IT-technische mensen, formele teams, middels hiërarchische aansturing, officiële communicatie’ (traditionele methode) en ‘kleine multidisciplinaire teams, zelfsturend, open communicatie, zelforganiserend’ (Agile methode). Een verrassende uitkomst is dat voor alle projecten de voorkeur wordt gegeven aan kleine multidisciplinaire teams die zelfsturend en zelforganiserend zijn. Er is slechts één uitzondering bij een traditioneel ingericht project. Daar wordt genoemd dat IT-mensen die IT-technisch goed zijn, niet altijd even goed zijn in het menselijke aspect en daardoor hiërarchisch moeten worden aangestuurd. Voor een project is het van belang dat er open communicatie is. De teams zijn vaak wel formeel en worden hiërarchisch aangestuurd, ook bij Agile projecten. Een goede samenstelling van het team draagt bij aan het succes van een project voor productontwikkeling. Er is bij voorkeur een mix nodig van ervaring in het vakgebied en ervaring binnen de organisatie. Feitelijk zouden de beste mensen op het project moeten worden gezet om de kans op succes te vergroten. Als bij een project wordt gekozen voor minder goede of minder ervaren mensen, is de kans op projectsucces kleiner. Een stabiel team verhoogt de kans op een succesvol project. Als er continu wijzigingen plaatsvinden in het team, wordt de kans op projectsucces kleiner. Het functioneren van het team wordt zowel binnen de Agile als de traditionele systeemontwikkeling gezien als succesbepalende factor om een project te laten slagen. Rol van de mens Deze set stellingen geeft de keuze tussen ‘werknemers zijn vervangbaar. Prioriteit is dat de expertise aanwezig is’ (traditionele methode) en ‘werknemers zijn essentieel en onmisbaar’ (Agile methode). In de traditionele projecten zijn werknemers vervangbaar,
2 3
3
3
3
4 5
5
5
5
5
5 3
2
2
2
2 1
0
1.1
1.2
0
2
3
4
5
0
0
0
6
7
8
0
9
10
11
FACTOR REF
Figuur 5. Waarnemingen op de stellingen met betrekking tot de factoren van projectsucces binnen de onderzochte Agile cases
zo lang er maar voor wordt gezorgd dat de expertise aanwezig is. Het project gaat door. Deze factor is direct gerelateerd aan de samenstelling van het team. In de Agile projecten is de voorkeur minder zichtbaar. Werknemers zijn hier essentieel en onmisbaar, omdat je in een klein hecht team werkt dat goed op elkaar ingespeeld is. Zou je het project met allemaal onervaren mensen uitvoeren, dan zou het project niet succesvol zijn. Daarnaast wordt het zeer van belang geacht dat de juiste expertise aanwezig is. Bij alle beschreven projecten is de factor mens essentieel. De meeste projecten zijn (in meer of mindere mate) succesvol afgerond, juist door de persoonlijke inzet van de mensen die het moesten doen. Rol van de klant Voor alle onderzochte cases konden we stellen dat de rol van de klant belangrijk was bij het succesvol uitvoeren van een project. Waar de klant vroeger vooral betrokken was bij het opstellen van de eisen en daarna pas weer bij de oplevering van het product, blijkt de klant in de praktijk nu onderdeel van het team te zijn. Deze factor wordt ook in de traditionele projecten gezien als een toegevoegde waarde. Op deze manier verbetert en versnelt de communicatie. Als er vragen zijn vanuit het team over de wensen van het product, kunnen deze direct worden beantwoord in het projectteam. Zowel de traditionele als de Agile projecten geven er de voorkeur aan de klant actief te laten deelnemen aan het projectteam. De klant actief betrekken bij het project wordt zodoende gezien als een factor die kan bijdragen aan succesvolle systeemontwikkeling. Testen Testen gebeurt in traditionele projecten vaak tijdens het project door de ontwikkelaars en pas na oplevering van het product vindt de eindtest plaats door aparte testers. In Agile projecten worden tests op tussenresultaten iteratief (in steeds herhalende stappen) uitgevoerd door het hele
MCA: februari 2014, nummer 1
35
team, dus inclusief de klant. Door het iteratief testen worden fouten sneller gevonden. Dan kan ervoor worden gekozen deze fouten in de huidige sprint (een korte vooraf bepaalde periode waarin een deel van een project wordt opgeleverd) nog te verwerken of mee te laten nemen in de volgende sprint. Dat fouten eerder worden gevonden en sneller opgelost levert een positieve bijdrage aan het projectsucces, hetgeen werd bevestigd in de verschillende interviews. Zodoende kunnen we stellen dat testen invloed heeft op succesvolle systeemontwikkeling.
Randvoorwaarden Op basis van de door ons onderzochte cases en interviews blijkt dat onderstaande factoren geen directe invloed hebben op het succes van een project voor systeemontwikkeling. Deze factoren moeten eerder worden beschouwd als randvoorwaarden. Voor het starten, uitvoeren en afronden van een project is het van belang dat er invulling is gegeven aan deze factoren. Zodoende worden ze door ons niet herkend als factoren die op zichzelf invloed hebben op succesvolle systeemontwikkeling. Wijzigingsbeheer Onder wijzigingsbeheer wordt verstaan de manier waarop wijzigingen worden doorgevoerd in het systeem. Samen met de controle op deze wijzigingen spreekt men van governance. Voor dit artikel zien we beide begrippen als één. Vooral binnen een sterk gereguleerd financiële organisatie is wijzigingsbeheer van levensbelang. De factor wijzigingsbeheer is dan ook van toepassing op alle onderzochte cases. Het maakt niet uit of een project traditioneel of Agile wordt ingestoken. Binnen de vooraf gestelde eisen wordt flexibiliteit op prijs gesteld, maar alles dient te worden uitgevoerd binnen deze eisen. Er kan zodoende geen keuze worden gemaakt over de manier waarop wijzigingsbeheer moet worden ingericht en daarom is deze factor niet van invloed op het projectsucces. Documentatie Documentatie vormt een randvoorwaarde voor het project. Het is een vereiste vanwege de sterk gereguleerde aard van het domein, maar het opleveren van documentatie op zichzelf heeft geen invloed op het
36
projectsucces. Met een goede documentatie kunnen toekomstige wijzigingen makkelijker worden gemaakt, maar voor het huidige project heeft dat geen impact. In de meeste onderzochte cases is de vereiste documentatie opgeleverd en zowel bij de traditionele methode als bij Agile is dat vaak achteraf gedaan. In sommige situaties is documentatie een onderdeel van wijzigingsbeheer.
Factoren die geen directe invloed hebben op het succes van het project De overige vijf factoren (focus, management, ontwikkelaars, techniek en complexiteit software en planning) werden tijdens de interviews niet bestempeld als succesbepalende factoren tijdens een project. Het feit dat ze niet als bepalende factor worden bestempeld wil echter nog niet zeggen dat ze geen invloed hebben op het succes, maar dat ze op zichzelf niet als essentieel werden gezien bij een traditioneel of Agile uitgevoerd project.
De rol van acceptatie Volgens de drie eerdergenoemde traditionele voorwaarden zijn alle cases op te vatten als een succes. Er is voldaan aan de gestelde voorwaarden betreffende budget, tijd en eisen. Daar waar niet aan de voorwaarden werd voldaan is dit vaak in overleg met de opdrachtgevers aangepast, waardoor uitstel of overschrijding van het budget alsnog goedgekeurd is. Wanneer we ook de eerdergenoemde dimensie acceptatie opvatten als een noodzakelijke voorwaarde van succes, ontstaat een ander plaatje (figuur 6). In dat geval zijn alleen de als Agile betitelde projecten 1, 2 en 3 succesvol. Op basis van de cases blijkt dus dat Agile gebruikersacceptatie bevordert. Een verklaring dat Agile tot meer acceptatie leidt ligt in het feit dat de Agile systeemontwikkeling een sterkere nadruk legt op de actieve rol van de klant in het project. Door de klant actief te betrekken bij het project wordt de kans vergroot dat een project na afloop ook daadwerkelijk wordt geaccepteerd door de eindgebruikers (klanten). Alleen op basis van de drie dimensies budget, tijd en eisen stellen we dat Agile systeemontwikkeling ten opzichte van de traditionele systeemontwikkeling op zichzelf geen sterkere invloed heeft op projectsucces. Wij zijn van mening dat, onafhankelijk van de gekozen methodiek, een
MCA: februari 2014, nummer 1
Projectsucces (binnen budget, tijd en eisen)
Succes
Geen succes
Ontwikkelmethodiek
Meest Agile
Case 1 Case 2 Case 3 Case 4
Meest traditioneel Projectsucces (binnen budget, tijd en eisen mét acceptatie)
Case 5 Case 6 Succes
Geen succes
Ontwikkelmethodiek
Meest Agile
Case 1 Case 2 Case 3 Case 4
Meest traditioneel
Case 5 Case 6
Figuur 6. Positionering van de cases op de variabele projectsucces (budget, tijd, eisen)
project sneller als succesvol kan worden bestempeld wanneer alleen wordt gekeken naar de drie traditionele dimensies, aangezien deze kunnen schuiven naar gelang de prioriteiten veranderen. De gekozen projectmethodiek vormt dan geen onderscheid meer. Een opvallende bevinding heeft betrekking op case 3 waarin Agile wordt toegepast bij de maandelijkse releases op het systeem. Het blijkt dat Agile zich goed leent voor deze vorm van beheer van een systeem. In dit verband wordt er dus niet meer gesproken van een volgens de Agile principes ingerichte en beheerde projectorganisatie, maar is er sprake van een volgens Agile principes ingerichte beheerorganisatie. Mogelijkerwijs zou dit kunnen leiden tot een compleet andere inrichting van organisaties. Hierbij wordt de organisatie niet meer volgens functionaliteit en strakke hiërarchie ingericht. In plaats daarvan kan de organisatie worden ingericht door middel van Agile teams, waarbinnen alle vereiste kennis aanwezig is en die zelfsturend opereren.
nele als met Agile geassocieerde factoren. De Agile projectbenadering gebruikt daarentegen vooral Agile factoren. Uit ons onderzoek blijkt dat de volgende factoren individueel het succes van een project beïnvloeden: functioneren van het team, rol van de mens, rol van de klant en testen. De factoren wijzigingsbeheer en documentatie zijn belangrijk, maar hebben geen invloed op het succes van een project voor systeemontwikkeling en moeten daarom worden beschouwd als randvoorwaarden. Het gebruik van Agile zorgt voor een positieve bijdrage aan het succes van een project, als acceptatie als een van de voorwaarden wordt gezien van projectsucces. Acceptatie bij eindgebruikers is via Agile groter, doordat de klant veel directer en intensiever bij het ontwikkeltraject betrokken is. Als we de variabele acceptatie meenemen, zijn de traditionele cases niet succesvol geweest. Opvallend is dat Agile niet alleen wordt gebruikt in projecten voor systeemontwikkeling, maar ook voor beheer en onderhoud van applicaties. Juist die processen lenen zich prima voor Agile, doordat wijzigingen als gevolg van beheer goed in overzichtelijke stappen zijn op te delen. Op basis van de door ons onderzochte cases kunnen we concluderen dat Agile niet alleen een projectmethodiek is, maar dat alle applicaties binnen de organisatie kunnen worden beheerd volgens Agile principes. Dit komt voornamelijk omdat Agile erg iteratief is en gericht op voortbouwen wat al bestaat. Agile helpt ook om de klant te laten nadenken over prioriteiten. Daarnaast stellen we dat men niet altijd alle factoren van de gekozen methodiek blind moet toepassen. Het is belangrijker te kijken naar de verschillende factoren en hoe deze kunnen worden ingezet binnen de financiële sector. Op deze manier zal voor de meeste projecten een combinatie van zowel traditionele als Agile factoren worden gekozen, zodat een optimaal resultaat voor de projecten kan worden gehaald.
Conclusie en discussie Op de vraag of de toegepaste ontwikkelmethodiek en de daarbij behorende factoren invloed hebben op het succesvol afronden van een project voor systeemontwikkeling kunnen we het volgende concluderen. De traditionele projectbenadering voor systeemontwikkeling bestaat in de door ons onderzochte cases uit een mix van zowel traditio-
Aanbevelingen voor de praktijk In deze casestudie hebben we projecten voor systeemontwikkeling binnen de financiële afdelingen van twee financiële instellingen onderzocht. We hebben in dit onderzoek gezien dat Agile ook goed lijkt te passen in beheerstaken en niet alleen maar in projecten. De reden hiervoor kan zijn dat be-
MCA: februari 2014, nummer 1
37
heerstaken aanleiding geven tot kleine projectjes en dat de interactie met de klant in de bestaande beheersorganisatie heel belangrijk is. Agile kan dus breder in financiële organisaties worden toegepast dan vooraf gedacht. Tijdens deze casestudie is de focus geweest op systeemontwikkeling binnen de financiële afdelingen van twee financiële instellingen. Dit is een beperking van dit onderzoek. Zodoende kunnen de volgende vervolgonderzoeken interessant zijn. We kunnen het onderzoek uitbreiden naar andere financiële instellingen om te valideren of de uitkomsten dan hetzelfde blijven. Het is ook interessant te onderzoeken of het succes van Agile nog steeds geldt als de onderzoekspopulatie groter is. Dit onderzoek zou kunnen worden gevalideerd door een uitgebreide vragenlijst uit te zetten bij meerdere financiële instellingen. We hebben in dit onderzoek gezien dat Agile systeemontwikkeling goed lijkt te passen in beheerstaken in plaats van alleen maar in projecten. Vervolgonderzoek naar de toepassing van de Agile methode binnen bestaande beheersorganisaties kan dan een interessante toevoeging zijn. Daarnaast zijn wij uitgegaan van vooraf gestelde dimensies (tijd, budget, eisen en acceptatie) die bepalend zijn voor het meten van het succes van projecten. Verder onderzoek zou mogelijk zijn om te bepalen of deze dimensies van succes nog steeds valide zijn.
~ Drunen, C. van, L. Gommers en W. van Schaik (2008), Prince2 en Scrum, Tijdschrift IT management, issue 6, p. 58-61. ~ Geraldi, J.G. (2008), The balance between order and chaos in multi-project firms: A conceptual model, International Journal of project management, vol. 26, issue 4, p. 348-356. ~ Ghosh, S., D. Forrest, T. DiNetta, B. Wolfe en D.C. Lambert (2012), Enhance PMBOK by Comparing it with P2M, ICB, PRINCE2, APM and Scrum Project Management Standards, PM World Today, vol. 14, issue 1, p. 1-77. ~ Hoda, R., J. Noble en S. Marshall (2008), Agile Project Management, New Zealand Computer Science Research Student Conference, april, p. 218-221. ~ Khalifa, M. en J.M. Verner (2000), Drivers for Software Development Method Usage, IEEE Transactions on Engineering Management, vol. 47, issue 3, p. 360369. ~ Lee, G. en W. Xia (2010), Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility, MIS Quarterly, vol. 34, issue 1, p. 87-114. ~ Leenaars, J.J.A. (2003), Risicomanagement van banken, Maandblad voor Accountancy en Bedrijfseconomie, vol. 77, issue 7/8, p. 340-347. ~ Lindstrom, L. en R. Jeffries (2004), Extreme programming and agile software development methodologies, Information Systems Management, vol. 21, issue 3, p. 41-52. ~ Lyndsay, J. (2007), Testing in an agile environment, Workroom Productions Ltd. ~ Mahnic, V. en N. Zabkar (2008), Using COBIT Indicators for Measuring Scrumbased Software Development, WSEAS Transactions on Computers, vol. 7, issue 10, p. 1605-1617. ~ Markus, M.L. (1983), Power, Politics, and MIS Implementation, Communications of the ACM, vol. 26, issue 6, p. 430-444. ~ Project Management Institute inc. (2000), A guide to the Project management body of knowledge, PMBOK® guide, Pennsylvania, Project Management Institute. ~ Richmond, I. (2008), On time, on target, Engineering & Technology, vol. 3, issue 16, p. 52-54.
Literatuur ~ Augustine, S. en S. Woodcock (2008), Agile project management, www.ccpace.
~ Tichy, L. en T. Bascom (2008), The Business End of IT Project Failure, Mortgage Banking, vol. 68, issue 6, p. 28-35.
com. ~ Barlow, J.B., J.S. Giboney, M.J. Keith, D.W. Wilson, R.M. Schuetzler, P.B. Lowry en A. Vance (2011), Overview and Guidance on Agile Development in Large Organizations, Communications of the Association for Information Systems, vol.
~ Waal, A. de (2003), Trends en ontwikkelingen in de financiële functie (II), Tijdschrift Controlling, vol. 2, issue 3, p. 19-22. ~ Zhen, J. (2005), Why IT Projects Fail, Computerworld, vol. 39, issue 6, p. 31-35.
29, issue 2, p. 25-44. ~ Bradley, J. (2008), Management based critical succes factors in the implementa-
Miriam Martens MSc EMFC RC is werkzaam als Head of Opera-
tion of enterprise resource planning systems, International Journal of Account-
tions bij AEGON N.V. en studeerde in 2013 af aan Nyenrode
ing Information Systems, issue 9, p. 175-200.
Business Universiteit.
~ Brooks, F.P. (1987), No Silver Bullet: Essence and Accidents of Software Engi-
ING NV en studeerde in februari 2013 af aan Nyenrode Business
neering, Computer, vol. 20, issue 4, p. 10-19. ~ Cohan, P.S. (2006), Finance & IT: The Transforming Power of Technology, Fi-
~ Dagevos, R. (2011), Agile tester zit kort op de bal, Tijdschrift IT management,
niek, Bestuur en Management van de Technische Universiteit Delft. Hij houdt zich bezig met onderzoek op het raakvlak van
issue 6, p. 86-88. ~ Davis, F.D. (1989), Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology, MIS Quarterly, vol. 13, issue 3, p. 319-340. ~ Drunen, C. van; L. Gommers en W. van Schaik (2008), Agile Prince2, utopie of
38
Universteit. Dr. J. Hulstijn is onderzoeker en docent aan de Faculteit Tech-
nancial Executive, vol. 23, issue 6, p. 18-23.
ideaal, Tijdschrift IT management, issue 5, p. 58-62.
Drs. Guido Veldhuijs EMFC RC is werkzaam als controller bij
recht en IT, in het bijzonder compliance management en modelbased auditing. Hij coördineert de master’s opleidingen ‘Compliance Design & Management’ en ‘Customs and Supply Chain Management’.
MCA: februari 2014, nummer 1
