AGILE SYSTEEM ONTWIKKELING EEN STUDIE NAAR PROJECT- SUCCES IN DE FINANCIËLE SECTOR

Transcriptie

1 Management accounting & control: AGILE SYSTEEM ONTWIKKELING EEN STUDIE NAAR PROJECT- SUCCES 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 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 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? 0 MCA: februari 0, nummer

2 Miriam Martens, Guido Veldhuijs en Joris Hulstijn: Binnen de finance afdelingen 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, 00; Markus, 98; Richmond, 008; Tichy en Bascom, 008; Zhen, 005). 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, 008). Een methodiek die hiervoor een goede oplossing lijkt te bieden is systeemontwikkeling (Lee en Xia, 00; Mahnic en Zabkar, 008). 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 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 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. Finance nader beschreven 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, 00). 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, 006). Deze ontwikkelingen maken dat marges versmallen, zodat het accuraat managen, meten en rapporteren van risico s steeds noodzakelijker worden (Leenaars, 00). 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, 00). Lang niet alle projecten worden echter succesvol afgerond. Succesvol project Om succes te definiëren is gebruik gemaakt van de definitie van Bradley (008, p. 75): 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, 987). 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 0, nummer

3 Ref. Factoren Projectmanagementbenadering Omschrijving. Focus bij Traditioneel Voornamelijk gericht op projectplan en projectproces. project Gericht op hoe mensen functioneren binnen project Traditioneel Prioriteit geven om alles binnen de scope van project te ontwikkelen Eerst doen wat meest belangrijk is, de rest wordt in back log gehouden Wijzigingsbeheer Traditioneel Wijzigingsbeheer uitvoeren waarbij de procedures strikt gevolgd worden 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 Kleine multidisciplinaire teams, die zelfsturend opereren, open communiceren en zelforganiserend zijn Management Traditioneel Management volgt hiërarchische organisatie en formele richtlijnen, stuurt vooral op methode Management acteert continu op basis van vrijwillige interactie, waarbij flexibel en met zo min mogelijk hiërarchie gewerkt wordt, stuurt vooral op uitkomst 5 Mens Traditioneel Werknemers zijn vervangbaar. Prioriteit is dat de expertise aanwezig is Werknemers zijn essentieel en onmisbaar 6 Klant Traditioneel De klant is alleen betrokken bij het opstellen van de eisen en de oplevering De klant is continu betrokken en is onderdeel van het team 7 Ontwikkelaars Traditioneel Ontwikkelaars gaan uit van projectplan en op te leveren milestones volgens planning Ontwikkelaars werken middels korte oplevermomenten met iteraties, waarbij het doel is continu te leren aangezien eisen door de tijd veranderen 8 Testen Traditioneel Testen vinden plaats aan het einde van ontwikkelcycli (eindtest), middels aparte testers Testen gebeurt veelvuldig en vaak geautomatiseerd; (veelal) unittest en integratietest) waarbij de tester onderdeel is van het team 9 Techniek en complexiteit software Traditioneel Grote mate van complexiteit, doordat techniek en software ook aan toekomstige eisen/wensen moeten voldoen Alleen minimaal benodigde software wordt gebouwd; per onderdeel minder complex, samenvoegen van de losse onderdelen is wel complex 0 Documentatie Traditioneel Continu gedurende het project wordt er documentatie bijgehouden De geschreven softwarecode vormt zelf de documentatie Planning Traditioneel Er wordt gewerkt volgens vaste planning en duidelijk gestelde producten Er wordt gewerkt met continue planning, gericht op gestelde prioriteiten, hoogste prioriteit eerst Figuur. 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, 989). 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 geaccepteerd 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., 000, p. 6). In het bijzonder voor IT-ontwikkeling wordt er gesproken over systeemontwikkelingsmethodieken. Deze kunnen worden ingedeeld in de traditionele en de nieuwere methoden. De traditionele metho- MCA: februari 0, nummer

4 den zijn vooral geschikt voor routinematige projecten waarvan de eisen vastliggen (Khalifa en Verner, 000). 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, 008). 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 zich ontwikkeld. De 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., 008). 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., 0). Er kan dus niet zonder meer worden gesteld dat de ene methodiek geschikter is dan de andere. De 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 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. 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 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, 008; Barlow et al., 0; Dagevos, 0; Van Drunen et al., 008; Ghosh et al., 0; Hoda et al., 008; Khalifa en Verner, 000; Lindstrom en Jefries, 00; Lyndsay, 007). Op basis van deze literatuur hebben we een elftal mogelijk succesbepalende factoren geïdentificeerd die de verschillende methodieken karakteriseren. In figuur 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 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, 008; Brooks, 987; Davis, 989): ~ 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 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 : het opleveren van een eenduidig klantbeeld in financiële rapportages. Rol Projectmanager IT Case x Case x Case x x x Case x Case 5 x x x Case 6 x Business Figuur. Overzicht interviews per case met de verschillende rollen MCA: februari 0, nummer

5 VERDELING FACTOREN PER CASE # FACTOREN Traditionele factoren factoren CASE CASE CASE CASE CASE 5 CASE 6 CASES Figuur. Validatie van de cases op basis van antwoorden op de stellingen # WAARNEMINGEN TRADITIONELE CASES Traditioneel beoordeeld FACTOR REF beoordeeld Figuur. Waarnemingen op de stellingen met betrekking tot de factoren van projectsucces binnen de onderzochte traditionele cases ~ Case : Het opruimen van verschillende rapportages en een datawarehouse en dit naar een nieuw platform brengen. ~ Case : Maandelijkse releases op grootboeksystemen. Dit kan worden gezien als aparte kleine projecten binnen de bestaande beheersorganisatie. ~ Case : 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 0 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 naar de gebruikte ontwikkelmethodiek voor de betreffende case. Volgens de respondenten van de interviews zijn case, en projecten geweest en case, 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. Resultaten In de figuren 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 cases. De definitie Traditioneel of 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. De details onder Traditioneel beoordeeld en 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 cases maken voornamelijk gebruik van factoren. Opvallend is dat de traditionele cases een mix vormen van traditionele en factoren. In de praktijk blijkt dus dat ook in projecten die als traditioneel bestempeld zijn, duidelijk elementen van de methodes worden toegepast. Dat geldt vooral voor factor (wijzigingsbeheer), (team), 6 (klant) en 0 (documentatie). Individuele succesfactoren Naast het feit dat we onderzoeken of 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 0, nummer

6 AGILE CASES Traditioneel beoordeeld 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 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 ( 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 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 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 ( methode). In de traditionele projecten zijn werknemers vervangbaar, # WAARNEMINGEN FACTOR REF Figuur 5. Waarnemingen op de stellingen met betrekking tot de factoren van projectsucces binnen de onderzochte 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 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 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 projecten worden tests op tussenresultaten iteratief (in steeds herhalende stappen) uitgevoerd door het hele 5 MCA: februari 0, nummer 5

7 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 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 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 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 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 betitelde projecten, en succesvol. Op basis van de cases blijkt dus dat gebruikersacceptatie bevordert. Een verklaring dat tot meer acceptatie leidt ligt in het feit dat de 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 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 6 MCA: februari 0, nummer

8 Projectsucces (binnen budget, tijd en eisen) Succes Geen succes Ontwikkelmethodiek Meest Meest traditioneel Projectsucces (binnen budget, tijd en eisen mét acceptatie) Ontwikkelmethodiek Meest Meest traditioneel Case Case Case Case Case 5 Case 6 Succes Case Case Case Geen succes Case 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 waarin wordt toegepast bij de maandelijkse releases op het systeem. Het blijkt dat zich goed leent voor deze vorm van beheer van een systeem. In dit verband wordt er dus niet meer gesproken van een volgens de principes ingerichte en beheerde projectorganisatie, maar is er sprake van een volgens 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 teams, waarbinnen alle vereiste kennis aanwezig is en die zelfsturend opereren. 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- nele als met geassocieerde factoren. De projectbenadering gebruikt daarentegen vooral 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 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 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 niet alleen wordt gebruikt in projecten voor systeemontwikkeling, maar ook voor beheer en onderhoud van applicaties. Juist die processen lenen zich prima voor, 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 niet alleen een projectmethodiek is, maar dat alle applicaties binnen de organisatie kunnen worden beheerd volgens principes. Dit komt voornamelijk omdat erg iteratief is en gericht op voortbouwen wat al bestaat. 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 factoren worden gekozen, zodat een optimaal resultaat voor de projecten kan worden gehaald. 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 ook goed lijkt te passen in beheerstaken en niet alleen maar in projecten. De reden hiervoor kan zijn dat be- MCA: februari 0, nummer 7

9 heerstaken aanleiding geven tot kleine projectjes en dat de interactie met de klant in de bestaande beheersorganisatie heel belangrijk is. 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 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 systeemontwikkeling goed lijkt te passen in beheerstaken in plaats van alleen maar in projecten. Vervolgonderzoek naar de toepassing van de 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. Literatuur ~ Augustine, S. en S. Woodcock (008), project management, com. ~ Barlow, J.B., J.S. Giboney, M.J. Keith, D.W. Wilson, R.M. Schuetzler, P.B. Lowry en A. Vance (0), Overview and Guidance on Development in Large Organizations, Communications of the Association for Information Systems, vol. 9, issue, p. 5-. ~ Bradley, J. (008), Management based critical succes factors in the implementation of enterprise resource planning systems, International Journal of Accounting Information Systems, issue 9, p ~ Brooks, F.P. (987), No Silver Bullet: Essence and Accidents of Software Engineering, Computer, vol. 0, issue, p ~ Cohan, P.S. (006), Finance & IT: The Transforming Power of Technology, Financial Executive, vol., issue 6, p. 8-. ~ Dagevos, R. (0), tester zit kort op de bal, Tijdschrift IT management, issue 6, p ~ Davis, F.D. (989), Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology, MIS Quarterly, vol., issue, p ~ Drunen, C. van; L. Gommers en W. van Schaik (008), Prince, utopie of ideaal, Tijdschrift IT management, issue 5, p ~ Drunen, C. van, L. Gommers en W. van Schaik (008), Prince en Scrum, Tijdschrift IT management, issue 6, p ~ Geraldi, J.G. (008), The balance between order and chaos in multi-project firms: A conceptual model, International Journal of project management, vol. 6, issue, p ~ Ghosh, S., D. Forrest, T. DiNetta, B. Wolfe en D.C. Lambert (0), Enhance PMBOK by Comparing it with PM, ICB, PRINCE, APM and Scrum Project Management Standards, PM World Today, vol., issue, p ~ Hoda, R., J. Noble en S. Marshall (008), Project Management, New Zealand Computer Science Research Student Conference, april, p. 8-. ~ Khalifa, M. en J.M. Verner (000), Drivers for Software Development Method Usage, IEEE Transactions on Engineering Management, vol. 7, issue, p ~ Lee, G. en W. Xia (00), Toward : An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility, MIS Quarterly, vol., issue, p ~ Leenaars, J.J.A. (00), Risicomanagement van banken, Maandblad voor Accountancy en Bedrijfseconomie, vol. 77, issue 7/8, p ~ Lindstrom, L. en R. Jeffries (00), Extreme programming and agile software development methodologies, Information Systems Management, vol., issue, p. -5. ~ Lyndsay, J. (007), Testing in an agile environment, Workroom Productions Ltd. ~ Mahnic, V. en N. Zabkar (008), Using COBIT Indicators for Measuring Scrumbased Software Development, WSEAS Transactions on Computers, vol. 7, issue 0, p ~ Markus, M.L. (98), Power, Politics, and MIS Implementation, Communications of the ACM, vol. 6, issue 6, p. 0-. ~ Project Management Institute inc. (000), A guide to the Project management body of knowledge, PMBOK guide, Pennsylvania, Project Management Institute. ~ Richmond, I. (008), On time, on target, Engineering & Technology, vol., issue 6, p ~ Tichy, L. en T. Bascom (008), The Business End of IT Project Failure, Mortgage Banking, vol. 68, issue 6, p ~ Waal, A. de (00), Trends en ontwikkelingen in de financiële functie (II), Tijdschrift Controlling, vol., issue, p. 9-. ~ Zhen, J. (005), Why IT Projects Fail, Computerworld, vol. 9, issue 6, p. -5. Miriam Martens MSc EMFC RC is werkzaam als Head of Operations bij AEGON N.V. en studeerde in 0 af aan Nyenrode Business Universiteit. Drs. Guido Veldhuijs EMFC RC is werkzaam als controller bij ING NV en studeerde in februari 0 af aan Nyenrode Business Universteit. Dr. J. Hulstijn is onderzoeker en docent aan de Faculteit Techniek, Bestuur en Management van de Technische Universiteit Delft. Hij houdt zich bezig met onderzoek op het raakvlak van 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. 8 MCA: februari 0, nummer