Universiteit Utrecht
Kritieke Succesfactoren van webapplicaties in de zorg
Rutger Bouwes 3351408 8 Juli 2013
Inhoud 1. Inleiding ............................................................................................................................. 3 2. Theoretisch kader ................................................................................................................ 4 2.1 Succes........................................................................................................................... 4 2.1.1 Problematische projecten .......................................................................................... 4 2.1.2 Vormen van succes................................................................................................... 5 2.2 Succesfactoren ............................................................................................................... 6 2.2.1 Strategische en tactische factoren .............................................................................. 6 2.2.2 Selectie ................................................................................................................... 6 2.2.3 Big Hitters ............................................................................................................... 8 2.3 Gebruikersacceptatie..................................................................................................... 10 2.3.1 Technology Acceptance Model (TAM) ....................................................................... 10 2.4 Functionaliteit .............................................................................................................. 12 2.5 Onderzoeksmodel ......................................................................................................... 12 2.6 Hypothesen ................................................................................................................. 14 3. Operationalisering.............................................................................................................. 16 4. Resultaten Onderzoek ........................................................................................................ 24 4.1 Kwantitatief onderzoek .................................................................................................. 24 KSF01 – Het aanwezig zijn van volledig en proactief risicomanagement ............................... 24 KSF02 – Het vooraf aanwezig zijn van een volledige en realistische Business Case ................ 25 KSF03 – Goede Communicatie ......................................................................................... 26 KSF04 – Realistische inschatting van tijd en kosten en genoeg momentum om binnen deze beperkingen te blijven ..................................................................................................... 27 KSF05 – Teamleider die de teamdynamiek bevordert ......................................................... 28 KSF06 – Juiste keuze van platform en ontwikkelmethode.................................................... 28 KSF07 – Voldoende steun van Senior Management ............................................................ 30 KSF08 – Het opbreken van het project in kleine stappen..................................................... 30 BH04 – Incomplete/Zwakke requirementsdefinitie .............................................................. 31 BH07 – Onvoldoende professionele instelling ..................................................................... 32 USA – Usability ............................................................................................................... 32 JREL – Job Relevance...................................................................................................... 33 OUQ – Output Quality ..................................................................................................... 33 ACC – Accessibility .......................................................................................................... 34 1
Tijd ............................................................................................................................... 34 Budget .......................................................................................................................... 35 Gebruikersacceptatie ....................................................................................................... 36 Functionaliteit................................................................................................................. 37 Algemeen ...................................................................................................................... 38 4.2 Statistische Analyse ...................................................................................................... 38 4.2.1 Wanneer is een project succesvol? ........................................................................... 39 4.2.2 Tijd ....................................................................................................................... 39 4.2.3 Gebruikersacceptatie .............................................................................................. 39 4.2.4 Budget .................................................................................................................. 40 4.2.5 Functionaliteit ........................................................................................................ 40 4.2.6 Algemeen .............................................................................................................. 40 4.3 Kwalitatieve Interviews ................................................................................................. 41 4.3.1 IT-Maturity ............................................................................................................ 41 4.3.2 Gebruikersacceptatie en incrementele development ................................................... 41 4.3.3 Zorgapplicaties als promotietool ............................................................................... 42 4.3.4 Privacy .................................................................................................................. 42 4.3.5 Vergelijking met enquête ........................................................................................ 42 5. Verder onderzoek .............................................................................................................. 43 6. Conclusie .......................................................................................................................... 44 Literatuur ............................................................................................................................. 45 Bijlagen ................................................................................................................................ 47 Bijlage 1 – SUFFI-chart ....................................................................................................... 47 Bijlage 2 – Kwalitatieve Interviews ....................................................................................... 53 Bijlage 3 – Resultaten Statistische Analyse............................................................................ 56 Bijlage 4 – Wanneer is een project succesvol ........................................................................ 58 Bijlage 5 – Referentie vragen .............................................................................................. 59 Bijlage 6 – Kwantitatieve enquête ........................................................................................ 61
2
1. Inleiding Zorg en ICT is een veelbesproken onderwerp. De controversie rond het Elektronisch PatiëntenDossier is veelvuldig besproken in de media. Experts wijzen op de vooruitgang die geboekt kan worden met verdere implementatie van E-Health en de patiënt wil via moderne communicatiemiddelen het contact met de zorgverleners vergemakkelijken (Adams & Boot, 2007). In dit onderzoek bestuderen wij het succes van (web)applicaties in de zorg. Dit zijn webapplicaties of mobiele apps die zijn ontwikkeld om de patiënt te informeren over, en te betrekken in het zorgproces. Het gaat hierbij om in opdracht ontwikkelde applicaties. Wij identificeren en analyseren de factoren die invloed hebben op het succes van deze applicaties, met speciale aandacht voor het projectverloop. In de literatuur is veel onderzoek gedaan naar de kritieke succesfactoren van ICT applicaties, maar vrijwel geen onderzoek naar webapplicaties en/of applicaties specifiek voor de zorg. In dit onderzoek zullen we literatuur analyseren en de kritieke succesfactoren die relevant zijn voor (web)applicaties identificeren. We zullen deze kritieke succesfactoren identificeren door middel van literatuuronderzoek. Met een onderzoek onder een aantal Nederlandse (web)applicaties in de zorg worden deze succesfactoren geanalyseerd. Dit onderzoek voltrekt zich via kwantitatieve enquêtes en kwalitatieve interviews. Op deze manier hopen we een beeld te schetsen van relevantie van de succesfactoren voor applicaties in de zorg. In Hoofdstuk 2 wordt het theoretisch kader besproken. We analyseren de literatuur over het onderwerp, identificeren kritieke succesfactoren, presenteren we het onderzoeksmodel en de hypothesen. In Hoofdstuk 3 wordt verder ingegaan op de geïdentificeerde kritieke succesfactoren en het onderzoeksmodel. De reden waarom kritieke succesfactoren zijn gekoppeld aan de in het model gepresenteerde vormen van succes wordt verder toegelicht. In Hoofdstuk 4 verkennen we de resultaten van de kwantitatieve enquête, voltrekken we een statistische analyse op deze resultaten en verkennen we de kwalitatieve interviews. In Hoofdstuk 5 bespreken we mogelijk verder onderzoek. De resultaten van het onderzoek worden samengevat in Hoofdstuk 6, de conclusie.
3
2. Theoretisch kader Het succesvol implementeren van ICT-applicaties is een knelpunt voor veel organisaties. 53% van de Nederlandse managers geeft aan dat ICT-projecten niet aan de verwachtingen voldoen (Harmsen & Verschuur, 2010). Het succes van een project wordt beïnvloed door een verscheidenheid aan factoren. Voordat we deze factoren identificeren definiëren we het succes van een project. Vervolgens zullen we aan de hand van eerder onderzoek naar de kritieke succesfactoren binnen de ICT een eigen set van kritieke succesfactoren identificeren en categoriseren. Nadat wij de kritieke succesfactoren die relevant zijn voor het onderzoek hebben geïdentificeerd, wordt een verdere selectie gemaakt. Dit onderzoek richt zich op de succesfactoren die specifiek zijn voor WebApplicaties en webSites in de Zorg (WASZ). Het gaat hierbij om Nederlandse WASZ, ontwikkeld in opdracht, die als doel hebben het informeren van gebruikers, of het ondersteunen van de gebruiker in hun zorgvraag. De uiteindelijke selectie van relevante succesfactoren zal alleen succesfactoren bevatten die relevant zijn voor WASZ.
2.1 Succes 2.1.1 Problematische projecten
Er is een inherent verschil tussen succesvolle, problematische en mislukte projecten in de ICT. Een succesvol project is voltooid binnen de afgesproken tijd, zonder overschrijding van het budget en het voldoet aan de functionaliteitseisen (Norman et al., 2007). Een mislukt project is eenvoudigweg een project dat nooit succesvol is geïmplementeerd (Smith, 2001). Hierbij moet gedacht worden aan projecten die voortijdig zijn afgeblazen vanwege tijdsoverschrijding, budgetoverschrijding of andere zaken die ervoor zorgen dat het project nooit succesvol is afgerond. De definitie van een problematisch project loopt binnen de bestaande literatuur enorm uiteen. In zijn boek “Troubled IT Projects: Prevention and Turnaround” bespreekt Smith (2001) enkele bestaande definities van problematische projecten. Deze definities lopen uiteen van projecten die uitdagend zijn qua tijd en vereiste vaardigheid (Boddie, 1986) tot zogenaamde 'runaway projects', projecten die meer dan 100% over het geprojecteerde budget heen gaan (Glass, 1997). In dit onderzoek houden wij de door Van Dijk (2009) gebruikte definitie aan, welke als eerste is geponeerd door Smith. Deze definitie is te zien in Figuur 2.1 (Smith, 2001).
4
Figuur 2.1: De definitie van een problematisch project. Overgenomen van "Troubled IT projects: prevention and turnaround door Smith, J. 2001. Copyright 2001 door IEEE, Herts, UK. 2.1.2 Vormen van succes
Projecten kunnen op verschillende vlakken succesvol zijn. Een project dat over zijn budget heengaat maar wel alle beloofde functionaliteit levert binnen de afgesproken tijd, kan in sommige gevallen toch als succesvol worden beschouwd. Voor dit onderzoek is het van belang dat we de verschillende vlakken waarop een WASZ succesvol kan zijn identificeren. Hierbij kijken we naar indicatoren van succes die relevant zijn voor WASZ. Deze indicatoren zijn:
Tijd: Het project wordt als succesvol beschouwd op het gebied van tijd als het project binnen de vooraf uitgetrokken tijd is voltooid. Budget: Het project wordt als succesvol beschouwd op het gebied van budget als de uiteindelijke kosten van het project niet het vooraf bepaalde budget overschrijden. Functionaliteit: Het succes op het gebied van functionaliteit wordt bepaald door de mate waarin de uiteindelijke functionaliteit van de applicatie in lijn licht met de vooraf gespecificeerde functionaliteit. Gebruikersacceptatie: Het succes op het gebied van de gebruikersacceptatie wordt bepaald door de mate waarin de frequentie van gebruik en het aantal gebruikers in lijn ligt met de vooraf ingeschatte frequentie van gebruik en het vooraf ingeschatte aantal gebruikers.
Wij zullen het succes van deze indicatoren analyseren en proberen te verklaren aan de hand van kritieke succesfactoren.
5
2.2 Succesfactoren 2.2.1 Strategische en tactische factoren
Een Kritieke SuccesFactor (KSF) is een factor die goed moet gaan om het succes van een project op verschillende vlakken te verzekeren (Boynton & Zmud, 1984). Er is uitgebreid onderzoek geweest naar deze succesfactoren, wat tot gevolg heeft dat er een bijna onuitputtelijke hoeveelheid KSF's bekend is. Deze factoren verschillen per auteur en vakgebied. In dit artikel zullen wij de KSF's van verschillende auteurs vergelijken en de toepasbaarheid op webapplicaties analyseren. Eén manier om KSF's te categoriseren is door ze op te delen in strategische en tactische factoren. Strategische factoren zijn gerelateerd aan het doel wat bereikt moet worden met het project en de manieren waarop de organisatie het doel wil bereiken. Een goed voorbeeld van een strategische KSF is het maken van een volledige business case, waarin de verwachte winst en risico's, eisen van het project en de haalbaarheid van het project zijn gedocumenteerd. Deze factoren zijn relevant in de voorbereidende fase van een project. Tactische factoren zijn gerelateerd aan de allocatie van de middelen die vereist zijn voor het bereiken van het strategische doel. Onder deze middelen vallen onder andere mankracht en beschikbaar budget. Deze factoren zijn relevant voor de implementatie van het project (Slevin & Pinto, 1987). Deze factoren staan niet los van elkaar, maar er is sprake van een dynamische wisselwerking tussen de twee categorieën. Factoren uit beide categorieën kunnen elkaar aanvullen. Bij het hebben van genoeg momentum bij het ontwikkelen van een applicatie (tactische factor) is het belangrijk om de deadlines (strategische factor) te halen. Ook verandert het gewicht van de categorieën naarmate het project vordert. In het begin van het project (de planningsfase) zijn de strategische factoren van groter belang, terwijl tactische factoren meer gewicht hebben naarmate het project vordert (Slevin & Pinto, 1987). In dit onderzoek zal deze categorisering gehandhaafd worden, om zo het belang van de factoren in de verschillende categorieën te kunnen vergelijken. 2.2.2 Selectie
Met de grote hoeveelheid literatuur die beschikbaar is over KSF’s is het van belang om een selectie te maken van relevante succesfactoren. Voor deze selectie is gebruik gemaakt van de Success and Failure Factors in ICT projects chart (SUFFI chart) van Van Dijk (2009 – Bijlage 1). Deze SUFFI chart heeft 139 succesfactoren herkend in 11 artikelen. Aan de hand van de SUFFI chart zijn 8 KSF’s geïdentificeerd die voldoen aan de volgende criteria:
Genoemd door ten minste drie verschillende auteurs Indien er sprake is van succesfactoren voor specifieke applicaties moeten deze applicaties in lijn zijn met de scope van het onderzoek. KSF’s die specifiek zijn voor bijvoorbeeld ERP-systemen worden niet behandeld. Indien er sprake is van succesfactoren voor projecten met een bepaalde omvang, dan moet deze omvang in lijn zijn met de scope van het onderzoek. Nederlandse WASZ’s zijn over het algemeen projecten met niet meer dan 100 medewerkers.
6
KSF’s die alleen van toepassing zijn op projecten met een grotere omvang worden niet behandeld. De succesfactoren moeten onderzoekbaar zijn in kwantitatief onderzoek
Aan de hand van deze criteria zijn de volgende relevante kritieke succesfactoren geïdentificeerd. De codes verwijzen naar de individuele vermeldingen van de kritieke succesfactoren in de SUFFI chart. KSF01. Het aanwezig zijn van volledig en proactief risicomanagement ◦
JS PUBRC05 – Poor risk management and contingency planning
◦
JS RC14 – Failure to actively manage risks and maintain robust contingency plans
◦
EV 07 – Lack of proactive risk management
◦
KY 03 – Inadequate project risk analysis
KSF02. Het vooraf aanwezig zijn van een volledige en realistische Business Case ◦
JS RC01 – Project based on unsound premise or unrealistic business case
◦
KY 02 – Weak definitions of requirements and scope
◦
PN 06 – The use of a business case results in a higher degree of satisfaction with the project, whilst the satisfaction with the project is very low when no business case is used
KSF03. Goede communicatie ◦
LM 08 – Communication breakdowns
◦
KY 08 – Poor internal communication
◦
NB06 – In cases of failure there is too little appreciation and attention to the quality of the (written) communication
KSF04. Realistische inschatting van tijd en kosten en genoeg momentum om binnen deze beperkingen te blijven ◦
JO 13 – The development process takes too long and the costs are too high
◦
JS RC07 – Vendor setting unrealistic expectations on cost, time-scale or vendor capability
◦
JR 02 – Maintain momentum (attrition, quality and management)
KSF05. Teamleider die teamdynamiek bevordert ◦
KY 09 – Absence of an influential champion and change agent 7
◦
TAH 16 – A major challenge to managers is to motivate employees. A mechanism for motivation, which is attracting interest in the software engineering field, is “goal setting”
◦
AvD01 – A project leader who works with small teams and who is able to act as working foreman
◦
AvD03 – A project leader who rarely has problems with his project officers and manages to motivate them well
KSF06. Juiste keuze van platform en ontwikkelmethode ◦
JS RC03 – Project based on state-of-the-art and immature technology
◦
KY 13 – Inappropriate choice of software
◦
JRR02 – The method does not work
KSF07. Voldoende steun van Senior Management ◦
AvD07 – Involve ICT Management in the project at an early stage
◦
JS RC04 – Lack of buyer-level ownership/commitment or competence
◦
JS PUBRC01 – Lack of senior management involvement and commitment
KSF08. Het opbreken van het project in kleine stappen ◦
JS PUBRC03 – Failure to break complex projects into manageable, separately contracted ‘chunks’
◦
JS RC06 – Buyer failure to break a complex project into phases or smaller projects
◦
EV01 – Failure to apply essential project management practices
2.2.3 Big Hitters
Van Dijk (2009) identificeert aan de hand van de bestudeerde literatuur 7 zogenaamde Big Hitters (Zie Bijlage 1). Deze Big Hitters zijn volgens de door Van Dijk bestudeerde auteurs de belangrijkste en meestvoorkomende KSF’s. Er bestaat overlap tussen de door Van Dijk geïdentificeerde Big Hitters en de in 2.2.2 genoemde succesfactoren. Om deze redenen zullen we waar mogelijk de door Van Dijk genoemde Big Hitters samenvoegen met de in 2.2.2 genoemde succesfactoren.
BH01 – Ondermaats project management Gerelateerd aan KSF01, proactief risicomanagement en KSF02 de aanwezigheid van een volledige business case. 8
BH02 – Onrealistische deadlines Deels gerelateerd aan KSF04, maar niet volledig. BH02 blijft individueel bestaan. BH03 – Slechte communicatie Reeds genoemd in KSF03. BH04 – Incomplete/Zwakke requirements-definitie Nieuw. BH04 blijft individueel bestaan. BH05 – Onvoldoende involvement van eindgebruikers Nieuw. BH05 blijft individueel bestaan. BH06 – Onvoldoende steun en toewijding van management Reeds genoemd in KSF07. BH07 – Onvoldoende professionele instelling Nieuw. BH07 blijft individueel bestaan. Hieruit volgt dat in dit onderzoek zal worden gekeken naar de volgende KSF's, ingedeeld in de door Slevin & Pinto (1987) geïdentificeerde categorieën.
Strategische factoren
Tactische factoren
KSF01
KSF03
KSF02
KSF04
KSF06
KSF05
KSF07
KSF08
BH02
BH04 BH07
Waar wel op gelet moet worden is dat de Big Hitters in tegenstelling tot de in 2.2.2 genoemde KSF's negatief geformuleerd zijn, waardoor je deze Big Hitters moet zien als factoren die het mislukken van een WASZ beïnvloeden. Om deze reden zullen we de Big Hitters behandelen als Kritieke FaalFactoren (KFF's). De KSF’s worden verder toegelicht in Hoofdstuk 3.
9
2.3 Gebruikersacceptatie Het doel van WASZ is het informeren en ondersteunen van de beoogde doelgroep. Een belangrijke succesindicator is de gebruikersacceptatie van de WASZ. Gebruikersacceptatie is de mate waarin de webapplicatie wordt gebruikt. Om een WASZ als succesvol te beschouwen moet de webapplicatie of website bezocht en gebruikt worden door de doelgroep. Hierbij wordt gekeken naar het aantal gebruikers en in welke mate dit aantal in lijn ligt met het verwachte aantal. Ook de frequentie van gebruik is een belangrijke indicatie van het succes op het gebied van gebruikersacceptatie. 2.3.1 Technology Acceptance Model (TAM)
Het TAM is een model dat in staat is om de adoptiegraad van applicaties te verklaren en voorspellen (Davis et al., 1989). De adoptiegraad is in het model terug te vinden onder Usage Behavior. De rest van de in het model genoemde factoren beïnvloeden deze Usage Behavior. Dit model is later uitgebreid met de invloed van sociale processen en cognitief instrumentele processen. Dit vernieuwde model is te zien in Figuur 2.2 en heeft de naam TAM2 gekregen (Venkatesh & Davis, 2000).
Figuur 2.2: Het TAM2 model. Overgenomen van "A Theoretical Extension of the Technology Acceptance Model: Four Longitudinal Field Studies door Venkatesch, V. en Davis, F. Management Science, 2000, 46, 2, p. 188. Dit verbeterde model vult het TAM aan met de sociale processen Subjective Norm, Voluntariness en Image. Ook geeft het de cognitief informatieve processen Job Relevance, Output Quality, Result Demonstrability en Perceived Ease of Use weer.
10
De Subjective Norm is een indicatie voor de acceptatie van het gebruik van de nieuwe technologie, gebaseerd op de referentie van personen die voor het individu belangrijk zijn. De Voluntariness is de mate waarin gebruik van het systeem vrijwillig is. Of de gebruiker vrijwillig gebruik maakt van de technologie, of dat de gebruiker verplicht is deze technologie te gebruiken, heeft een effect op de Intention to Use. De Intention to Use is de frequentie van en manier waarop de gebruiker het systeem wil gaan gebruiken. Voluntariness heeft een relatie met de Subjective Norm. De Subjective Norm heeft een significant effect op de intentie om de nieuwe technologie te gebruiken, mits het gebruik van de nieuwe technologie verplicht is (Hartwick & Barki, 1994). Image heeft te maken met de verandering van het aanzien van de gebruiker binnen zijn of haar sociale groepen. Het gebruik van het systeem zorgt voor meer aanzien binnen de sociale groep, als de andere individuen in de groep het gebruik aanmoedigen. De sociale processen Subjective Norm en Voluntariness zijn niet relevant voor dit onderzoek, omdat de scope van het onderzoek beperkt is tot WASZ waaraan de deelname vrijwillig is. Als het gebruik van de applicatie niet verplicht is hebben deze factoren geen signifcant effect. Image is gerelateerd aan het statusverhogende effect wat gebruik van een nieuwe applicatie tot gevolg kan. Image past niet in de scope van het onderzoek, omdat er in dit onderzoek wordt gekeken naar de manier waarop projectmanagement het succes van WASZ kan beïnvloeden. Om de invloed van Image te bestuderen moet de eindgebruiker van applicatie worden onderzocht. Dit valt niet binnen de scope van het project. Job Relevance is de perceptie van de gebruiker naar de bruikbaarheid van het nieuwe systeem voor de werkzaamheden van de gebruiker. Dit hoeven niet per sé professionele werkzaamheden zijn, maar is gerelateerd zijn aan het doel van het systeem, en de mate waarin het systeem de gebruiker ondersteunt met het bereiken van dit doel. De systemen die worden bestudeerd in dit onderzoek zijn voornamelijk informatie ontsluitende systemen. Job Relevance kan hier worden gezien als relevantie van de ontsloten informatie. Output Quality is de kwaliteit van de door de applicatie gepresenteerde informatie en is gerelateerd aan de Job Relevance. Output Quality is een indicatie van de bruikbaarheid van het systeem, in welke mate de gepresenteerde output kan bijdragen aan de Job Relevance. Result Demonstrability is de door de gebruiker waargenomen toegevoegde waarde van het systeem voor zijn dagelijkse professionele werkzaamheden. Result Demonstrability is een subjectieve factor voor de gebruiker. Dit valt niet binnen de scope van het onderzoek. Omdat bij WASZ, in tegenstelling tot informatiesystemen in het bedrijfsleven, het gebruik vrijwillig is, is het van belang om tijdens zowel de voorbereidende als de implementatiefase rekening te houden met de factoren die de adoptiegraad beïnvloeden. In dit onderzoek zullen wij aandacht besteden aan twee onderdelen van het TAM2-model. De Job Relevance en Output Quality. Deze zijn eerder al besproken. Vervolgens voegen we nog twee factoren toe, de Accessibility en Usability. Voor applicaties die gericht zijn op het delen van informatie met patiënten is het van het grootste belang dat de sites gebruikt kunnen worden door elke potentiële gebruiker. In 2007 waren er ongeveer anderhalf miljoen mensen in Nederland die aangaven dat zij een lichamelijke beperking ervaarden (Gool et al, 2009). Accessiblity wordt definiëerd als toegankelijkheid van websites en webapplicaties voor mensen met een fysieke beperking (W3C, 2008) Accessibility heeft een indirect significant effect op de gebruikersacceptatie van WASZ (Chau & Lai, 2003). Met andere woorden, 11
het richten op de verbetering van de toegankelijkheid is erg belangrijk voor de gebruikersacceptatie van WASZ. Usability wordt gedefiniëerd als de effectiviteit, efficiëntie en de tevredenheid waarmee gebruikers het doel van een applicatie kunnen bereiken (ISO 9241-110, 2006). Als de usability van een applicatie niet voldoende is, kan dit er toe leiden dat de applicatie niet gebruikt wordt (Goodwin, 1987). Om de gebruikersacceptatie te verhogen is het van belang dat er aandacht wordt besteed aan de usability.
2.4 Functionaliteit In dit onderzoek wordt ook gekeken naar de functionaliteit die het nieuwe systeem biedt. Van belang is of de functionaliteit van het uiteindelijke systeem aansluit bij de gespecificeerde requirements, of de klant tevreden is met de functionaliteit die het nieuwe systeem biedt, en of er requirements zijn geschrapt tijdens de ontwikkeling van de WASZ. Als we spreken over requirements zijn er twee vormen: requirements die zijn gespecificeerd voordat begonnen is met de ontwikkeling van de applicatie, en requirements die zijn gespecificeerd tijdens de ontwikkeling van de applicatie. Deze requirements bepalen de uiteindelijke functionaliteit die het systeem moet vertonenen. Het succes op het gebied van functionaliteit kan worden bepaald door de requirements te vergelijken met de functionaliteit die het systeem uiteindelijk vertoont.
2.5 Onderzoeksmodel Het onderzoeksmodel kijkt naar de in 2.1.2 genoemde vormen van succes. De KSF's en BH's zijn genummerd en gekoppeld aan de vormen van succes. De in 2.3 genoemde factoren zijn afgekort, Job Relevance (JREL), Output Quality (OUQ), Accessibility(ACC) en Usability (USA). De door de onderzoeker verwachte relaties tussen de KSF en succesindicatoren zijn gerepresenteerd door pijlen. De verwachte relaties worden verder toegelicht in Hoofdstuk 3. KSF03, KSF05 en BH07 zijn uniek omdat ze invloed hebben op alle vormen van succes. Uit deze informatie volgt het onderzoeksmodel zoals te zien in Figuur 2.3.
12
Figuur 2.3: Het onderzoeksmodel KSF01 – Het aanwezig zijn van volledig en proactief risicomanagement KSF02 – Het vooraf aanwezig zijn van een volledige en realistische business case KSF03 – Goede communicatie KSF04 – Realistische inschatting van tijd en kosten en genoeg momentum om binnen deze beperkingen te blijven KSF05 – Teamleider die teamdynamiek bevordert KSF06 – Juiste keuze van platform en ontwikkelmethode KSF07 – Voldoende steun van Senior Management KSF08 – Het opbreken van het project in kleine stappen BH02 – Onrealistische deadlines BH04 – Incomplete/zwakke requirements-definitie BH07 – Onvoldoende professionele instelling ACC – Accessiblity USA – Usablity JREL – Job Relevance OUQ – Output Quality
13
2.6 Hypothesen Uit het onderzoeksmodel volgen de volgende hypothesen Budgetsucces Als het succes op het gebied van budgetmanagement gerelateerd is aan de succesfactoren KSF01, KSF02 en KSF06 dan zullen projecten waar aandacht is besteed aan deze KSF's meer succes hebben met het beheren van het budget. H0 = Er is geen relatie tussen KSF01, KSF02 en KSF06 en het succes van het budgetmanagement. H1 = Er is een relatie tussen KSF01, KSF02 en KSF06 en het succes van het budgetmanagementgebied Tijdsucces Als het succes op het gebied van tijdsmanagement gerelateerd is aan de succesfactoren KSF01, KSF04, KSF06, KSF07, KSF08 en BH02 dan zullen projecten waar aandacht is besteed aan deze KSF's meer succes hebben met met betrekking tot het op tijd afronden van het project. H0 = Er is geen relatie tussen KSF01, KSF04, KSF06, KSF07, KSF08 en BH02 en het succes van het tijdsmanagement. H1 = Er is een relatie tussen KSF01, KSF04, KSF06, KSF07, KSF08 en BH02 en het succes van het tijdsmanagement. Gebruikersacceptatie Als het succes op het gebied van gebruikersacceptatie gerelateerd is aan de succesfactoren ACC, USA, JREL, OUQ en BH04 dan zullen projecten waar aandacht is besteed aan deze KSF’s meer succes hebben met betrekking tot de gebruikersacceptatie. H0 = Er is geen relatie tussen ACC, JREL, OUQ en BH04 en het succes van de gebruikersacceptatie. H1 = Er is een relatie tussen ACC, JREL, OUQ en BH04 en het succes van de gebruikersacceptatie. Functionaliteitsucces Als het succes op het gebied van functionaliteit gerelateerd is aan de succesfactoren JREL, OUQ, BH04 en KSF02 dan zullen projecten waar aandacht is besteed aan deze KSF's meer succes hebben met betrekking tot de fuctionaliteit. H0 = Er is geen relatie tussen JREL, OUQ, BH04 en KSF02 en het succes op het gebied van functionaliteit. H1 = Er is een relatie tussen JREL, OUQ, BH04 en KSF02 en het succes op het gebied van functionaliteit. 14
Algemeen succes Als het succes van WASZ gerelateerd is aan de succesfactoren KSF03, KSF05 en BH07 dan zullen projecten waar aandacht is besteed aan deze KSF's succesvoller zijn. H0 = Er is geen relatie tussen KSF03, KSF05 en BH07 en het succes van een WASZ. H1 = Er is een relatie tussen KSF03, KSF05 en BH07 en het succes van een WASZ.
15
3. Operationalisering In dit hoofdstuk zullen we de kritieke succesfactoren verder toelichten. Ook beargumenteren we hier de keuzes die gemaakt zijn om de kritieke succesfactoren te koppelen aan de succesvormen zoals te zien is in het onderzoeksmodel (Figuur 2.3). Daarnaast zullen we de kritieke succesfactoren toelichten door middel van de factoren geïdentificeerd in de SUFFI-chart (Bijlage 1). Ook introduceren we hier de vragen zoals ze te vinden zijn in de kwalitatieve enquête aan de hand van de kritieke succesfactoren KSF01. Het aanwezig zijn van volledig en proactief risicomanagement Risico is het effect van onzekerheid op de doelen van een project (ISO, 2006). Risico's kunnen zowel positief als negatief zijn. Het gaat bij risico's om de kans dat een positief of negatief effect voor het project optreedt. Deze kans wordt afgewogen tegen de mogelijke winst of verlies dat het optreden van dit risico tot gevolg heeft. Risicomanagement is het identificeren van risico's, gevolgd door het gecoördineerd monitoren en controleren van de geïdentificeerde risico's (Hubbard, 2009). De verwachting is dat het proactief monitoren en beheersen van de risico's ervoor zorgt dat een project minder snel over het budget of planning gaat. Het risicomanagement heeft minder invloed op de gebruikersacceptatie en de functionaliteit omdat het voornamelijk relevant is voor het projectmanagement. Volledig en proactief risicomanagement zal de gebruikersacceptatie en en functionaliteit niet beïnvloeden, terwijl het wel een grote invloed kan hebben op het succes op het gebied van tijd en budget. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: JS PUBRC05 – Poor risk management and contingency planning JS RC14 – Failure to actively manage risks and maintain robust contingency plans EV 07 – Lack of proactive risk management KY 03 – Inadequate project risk analysis Met de volgende vragen zullen we de aandacht voor het risicomanagement meten in de kwantitatieve enquête: KSF01-1 KSF01-2 goed) KSF01-3 KSF01-4
– Was er sprake van risicomanagement bij dit project? (Ja/Nee) – Hoe beoordeelt u het identificeren van de risico’s? (Likert 1-5 van zeer slecht tot zeer - Hoe beoordeelt u het monitoren van de risico’s? (Likert 1-5 van zeer slecht tot zeer goed) – Hoe beoordeelt u het beheersen van de risico’s? (Likert 1-5 van zeer slecht tot zeer goed)
KSF02. Het vooraf aanwezig zijn van een volledige en realistische Business Case Een business case is een document of een set documenten waarin een volledige kosten-baten analyse van het project wordt gemaakt. Op basis van de informatie in dit document wordt besloten of het gerechtvaardigd is om te beginnen met het project. Een volledige business case bevat het doel van het project, de tijds- en geldinvestering, de voordelen van implementatie, identificatie van de stakeholders, de scope en de verwachtingen van het project (Robertson, 2004). De aanwezigheid van een business case kan het succes van het project in het algemeen beïnvloeden. 16
Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: JS RC01 – Project based on unsound premise or unrealistic business case KY 02 – Weak definitions of requirements and scope PN 06 – The use of a business case results in a higher degree of satisfaction with the project, whilst the satisfaction with the project is very low when no business case is used Met de volgende vragen zullen we de aandacht voor de business case meten in de kwantitatieve enquête: KSF02-1 – Was er vooraf een business case gemaakt? (Ja, een volledige/Ja, een beperkte/Nee) KSF02-2 – Hoe beoordeelt u op het moment van schrijven de volledigheid van de gemaakte Business Case? (Likert 1-5 van zeer slecht tot zeer goed) KSF02-3 – Hoe beoordeelt u op het moment van schrijven de haalbaarheid van de gemaakte Business Case? (Likert 1-5 van zeer slecht tot zeer goed) KSF03. Goede communicatie In dit onderzoek wordt onder communicatie verstaan de frequentie en de kwaliteit van het contact tussen de klant en de ontwikkelaar, en tussen de klant en de eindgebruiker. Deze KSF heeft een mogelijke relatie met het succes op het gebied van functionaliteit en gegbruikersacceptatie. Er is niet direct een connectie te verwachten tussen deze KSF en de succesindicatoren tijd en budget. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: LM 08 – Communication breakdowns KY 08 – Poor internal communication NB06 – In cases of failure there is too little appreciation and attention to the quality of the (written) communication Met de volgende vragen zullen we de kwaliteit van de communicatie meten in de kwantitatieve enquête: KSF03 -1 - Hoe beoordeelt u de communicatie met de developer? (Likert 1-5 van zeer slecht tot zeer goed) KSF03-2 – Hoe beoordeelt u de betrokkenheid van de developer? (Likert 1-5 van zeer slecht tot zeer goed) KSF03-3 – Hoe beoordeelt u de communicatie met de eindgebruikers? (Likert 1-5 van zeer slecht tot zeer goed) KSF03-4 – In welke mate zijn de eindgebruikers betrokken bij de ontwikkeling van de applicatie? (Likert 1-5 van zeer weinig tot zeer veel)
17
KSF04. Realistische inschatting van tijd en kosten en genoeg momentum om binnen deze beperkingen te blijven Onder een realistische inschatting van de tijd en kosten wordt verstaan in welke mate de inschatting van de tijd en kosten in lijn ligt met de werkelijke tijd en kosten. Indien het nodig is om de deadline aan te passen, of het budget te verhogen is deze inschatting niet realistisch. Maar ook als er functionaliteit wordt geschrapt om binnen deze beperkingen te blijven is er geen sprake van een realistische inschatting. Het momentum is de mate waarin het project vloeiend verliep. Als het project vastloopt op een bepaalde functionaliteit, of na een belangrijke fase is dit een kenmerk van onvoldoende momentum. Verwacht wordt dat deze KSF een relatie heeft met de succesfactoren tijd en budget. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: JO 13 – The development process takes too long and the costs are too high JS RC07 – Vendor setting unrealistic expectations on cost, time-scale or vendor capability JR 02 – Maintain momentum (attrition, quality and management) Met de volgende vragen zullen we de aandacht voor deze KSF meten in de kwantitatieve enquête: KSF04-1 – Hoe realistisch was de inschatting van de benodigde tijd? (Likert 1-5 van zeer onrealistisch tot zeer realistisch) KSF04-2 – Hoe beoordeelt u het momentum van het project? (Likert 1-5 van zeer slecht tot zeer goed) KSF04-3 – Hoe realistisch was de inschatting van de benodigde kosten? (Likert 1-5 van zeer onrealistisch tot zeer realistisch) KSF05. Teamleider die teamdynamiek bevordert Dynamiek kan zich op verschillende manieren uiten. Bijvoorbeeld door de rollen in het ontwikkelteam af te wisselen, of door het ontwikkelteam de vrijheid te geven om zelf te kiezen welke functionaliteit ze zal implementeren. Dynamische teams hebben duidelijkheid over het doel van het project, en de rol die zij vervullen in het behalen van dit doel (Agnew, 2005). Een dynamisch team en een teamleider die deze dynamiek bevordert hebben een mogelijk positief effect op het succes van het project in het algemeen. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: KY 09 – Absence of an influential champion and change agent TAH 16 – A major challenge to managers is to motivate employees. A mechanism for motivation, which is attracting interest in the software engineering field, is “goal setting” AvD01 – A project leader who works with small teams and who is able to act as working foreman AvD03 – A project leader who rarely has problems with his project officers and manages to motivate them well Met de volgende vragen zullen we deze KSF meten: 18
KSF05-1 – Hoe beoordeelt u de betrokkenheid van de teamleider van het developmentteam? (Likert 1-5 van zeer slecht tot zeer goed) KSF05-2 – Hoe beoordeelt u de dynamiek van het developmentteam? (Likert 1-5 van zeer slecht tot zeer goed) KSF06. Juiste keuze van platform en ontwikkelmethode Het platform is een bundel van functies die de basis opmaken van applicaties (Taudes et al., 2000). Op het platform worden de applicaties gemaakt die waarde toevoegen. De platformkeuze is belangrijk omdat het platform de juiste functionaliteiten moet bieden en de kosten in lijn moeten liggen met de baten. Verwacht wordt dat onvoldoende aandacht aan de platformkeuze het succes van een applicatie negatief beïnvloedt. Ontwikkelmethodes zijn de systematische aanpak die gebruikt worden om de ontwikkeling van de applicatie te structureren (Murugesan & Ginige, 2005). De ontwikkelmethode bepaalt hoe de ontwikkeling van de applicatie wordt aangepakt. De keuze van de ontwikkelmethode moet worden afgestemd op de middelen (mankracht, tijd, kwaliteit, etc.) van het ontwikkelteam en het doel van de applicatie. Deze KSF heeft een mogelijke relatie met tijd en budget. Ook het succes op het gebied van functionaliteit kan worden beïnvloed door deze KSF. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: JS RC03 – Project based on state-of-the-art and immature technology KY 13 – Inappropriate choice of software JRR02 – The method does not work Via de volgende vragen zullen we kijken naar de aandacht is besteed aan de keuze van het platform en ontwikkelmethode: KSF06-1 – Van welke ontwikkelmethode is gebruik gemaakt? (Meerdere antwoordmogelijkheden) KSF06-2 – Hoeveel aandacht is besteed aan de keuze voor de ontwikkelmethode? (Geen/Beperkt/Anders namelijk) KSF06-3 – Hoeveel aandacht is besteed aan de keuze voor het platform? (Geen, keuze van developer/Geen, standaard platform/Beperkt (2 tot 4)/Veel (Meer dan 4) KSF07. Voldoende steun van Senior Management De steun van het Senior Management kan zowel op directe als indirecte wijze invloed uitoefenen op het succes van een project (Gornes et al., 2001). Sturingsgroepen, beslissingsmakende teams met Senior Managers, het afstemmen van de strategie op het project of allocatie van middelen zijn een paar van de manieren waarop de steun van het Senior Management het succes van een project kan beïnvloeden. Mogelijk is dat de mate waarin een project steun krijgt van het Senior Management gerelateerd aan het succes van een project op het gebied van tijd en budget. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: 19
AvD07 – Involve ICT Management in the project at an early stage JS RC04 – Lack of buyer-level ownership/commitment or competence JS PUBRC01 – Lack of senior management involvement and commitment Met de volgende vraag kijken we naar de kwaliteit van de steun van het Senior Management: KSF07-1 – Hoe beoordeelt u de betrokkenheid van het senior management? (Likert 1-5 van zeer slecht tot zeer goed) KSF08. Het opbreken van het project in kleine stappen Elk project bestaat uit verschillende stappen. De grootte van deze stappen varieert per project en ontwikkelmethode. Wij onderzoeken een relatie tussen de grootte van de stappen en het succes van het project. Daarnaast zullen we kijken naar de indeling van de stappen. Is deze sequentieel (Waterfall) of parallel (Agile). Er wordt gekeken of er een relatie is tussen deze twee vormen van fasering en het succes van het project. We verwachten dat de fasering van het project voornamelijk een effect zal hebben op de succesindicator tijd. Deze kritieke succesfactor is opgebouwd uit de volgende succesfactoren uit de SUFFI-chart zoals te zien in Bijlage 1: JS PUBRC03 – Failure to break complex projects into manageable, separately contracted ‘chunks’ JS RC06 – Buyer failure to break a complex project into phases or smaller projects EV01 – Failure to apply essential project management practices Met de volgende vragen zullen we deze KSF meten: KSF08-1 – Is het project gefaseerd verlopen? (Ja/Nee) KSF08-2 – Wat was de gemiddelde grootte van deze stappen? (In weken) BIG HITTERS Deze KSF's zijn negatief geformuleerd. Dit heeft tot gevolg dat de aanwezigheid van deze factoren geïnterpreteerd moet worden als een Kritieke Faal Factor. BH02 – Onrealistische deadlines Elke fase van het project heeft een deadline die moet worden gehaald. Indien door een onrealistische inschatting van de benodigde tijd deze deadlines niet haalbaar zijn, zal dit een negatief effect hebben op het succes van het project op het gebied van tijd. Met de volgende vragen zullen we het succes van deze big hitter analyseren: KSF04-1 – Hoe realistisch was de inschatting van de benodigde tijd? (Likert 1-5 van zeer slecht tot zeer goed) BH04 – Incomplete/Zwakke requirements-definitie Het specificeren van requirements is het proces van de eisen van het systeem verkrijgen, documenteren en organiseren. Het specificeren van de requirements is een proces dat een overeenkomst over het verwachte gedrag van het systeem vaststelt tussen de klant en de ontwikkelaar (Wahono, 2003). Indien deze requirements niet aansluiten bij het gewenste gedrag 20
van de applicatie zal dit een negatief effect hebben op het succes van het project op het gebied van functionaliteit en gebruikersacceptatie. Omdat de requirements voornamelijk relevant zijn voor de functionaliteit van de applicatie, en de functionaliteit gerelateerd is aan de gebruikersacceptatie ligt het voor de hand dat er een relatie tussen deze KSF en de genoemde succesindicatoren is. Het lijkt onwaarschijnlijk dat de requirements invloed hebben op de succesindicatoren tijd en budget. De vragen gerelateerd aan deze big hitter zijn: BH04-1 – Hoe beoordeelt u de kwaliteit van de requirements die gespecificeerd zijn bij aanvang van het project? (Likert 1-5 van zeer slecht tot zeer goed) BH04-2 - Hoe beoordeelt u de volledigheid van de requirements die gespecificeerd zijn bij aanvang van het project? (Likert 1-5 van zeer onvolledig tot zeer volledig) BH07 – Onvoldoende professionele instelling Onder professionaliteit verstaan wij in dit onderzoek de door Brint (1994) geponeerde definitie van de 'nieuwe' professional. De 'nieuwe' professional is een expert op zijn vakgebied. Een onvoldoende professionele instelling manifesteert zich in gedrag wat experts in het relevante vakgebied niet zouden moeten vertonen. Fouten op het gebied van projectmanagement (bijvoorbeeld slechte allocatie van de beschikbare middelen), op het gebied van programmeren (fouten die experts niet zouden maken) of andere relevante gebieden (financieel management, infrastructuur, etc.) zijn tekenen dat er sprake is van een onvoldoende professionele instelling. Daarnaast wordt gekeken naar de professionaliteit van teams. De professionaliteit van teams is voornamelijk terug te zien in het onderlinge vertrouwen, de communicatie, het respect van teamleden voor elkaar en steun in het doen van de werkzaamheden. Verwacht wordt dat indien het schort aan de individuele- of groepsprofessionaliteit dit een negatief effect heeft op het succes van het project in het algemeen. Dit onderzoeken wij met de volgende vragen: BH07-1 – Hoe beoordeelt u de professionaliteit van het developmentteam? (Likert 1-5 van zeer onprofessioneel tot zeer professioneel) SUCCESINDICATOREN In het onderzoeksmodel (Figuur 2.3) zijn vier vormen van succes geïdentificeerd. Deze vormen van succes zullen we hier nog verder toelichten. Tijd Het succes op het gebied van tijd is gerelateerd aan de planning van het project. Een project wordt als succesvol beschouwd op het gebied van tijd als het project is afgerond binnen de vooraf vastgestelde tijd. Deze succesindicator wordt vastgesteld via de volgende vragen: Tijd-1 - Is het project afgerond binnen de vooraf afgesproken tijd? (Ja, eerder/Ja, op tijd/Nee) Tijd-2 – In hoeverre week het project af van de verwachtte opleverdatum? (Uitgedrukt in procenten) 21
Tijd-3 – Is de opleverdatum van het project aangepast tijdens het project? (Ja/Nee) Tijd-4 – Indien de opleverdatum is aangepast tijdens het project, hoe vaak is dit gebeurd? (Open vraag) Budget Om een project als succesvol te beschouwen op het gebied van budget mag het vooraf afgesproken budget niet worden overschreden. Ook is het mogelijk dat het budget tijdens de ontwikkeling van het webproject is aangepast. Om te weten of een project succesvol is geweest op het gebied van budget moet er gekeken worden naar de tijdsoverschrijding en het aantal keer dat het budget is aangepast. Deze succesindicator wordt vastgesteld via de volgende vragen: Budget-1 - Is het project binnen het budget gebleven? (Ja/Nee) Budget-2 - Indien het project niet binnen het budget is gebleven, hoeveel was de overschrijding van het budget? (Open vraag, uitgedrukt in procenten) Budget-3 - Is het budget van het project aangepast tijdens de ontwikkeling? (Nee/Ja, verhoogd/Nee, verlaagd) Budget-4 - Indien het budget van het project is aangepast, hoe vaak is het budget aangepast? (Open vraag) Gebruikersacceptatie Een project is succesvol op het gebied van gebruikersacceptatie als het aantal gebruikers en de frequentie van gebruik in lijn ligt met de verwachtingen. Deze succesindicator is opgedeeld in twee indicatoren (Aantal en Frequentie) omdat het een vollediger beeld geeft van de gebruikersacceptatie. Deze succesindicator wordt vastgesteld via de volgende vragen: Gebruikersacceptatie-1 – Is het aantal gebruikers in lijn met het verwachte aantal gebruikers? (Ja/Nee, minder/Nee, meer) Gebruikersacceptatie-2 – Indien het aantal gebruikers afwijkt van het aantal verwachte gebruikers, in welke mate wijkt het aantal gebruikers af? (Uitgedrukt in procenten) Gebruikersacceptatie-3 – Is de frequentie van het gebruik door eindgebruikers in lijn met de verwachte frequentie van gebruik? (Nee, het gebruik is minder frequent/Ja/Nee, het gebruik is frequenter) Functionaliteit Een project is succesvol op het gebied van functionaliteit als de functionaliteit van het systeem na het afronden van het project in lijn ligt met de vooraf vastgestelde functionaliteit die het project moet vertonen. Als er functionaliteit ontbreekt die wel gewenst was kan een project niet als succesvol worden beschouwd op het gebied van functionaliteit. Deze succesindicator wordt vastgesteld via de volgende vragen: Functionaliteit-1: In hoeverre is de functionaliteit van het systeem in lijn met de vooraf gespecificeerde functionaliteit? (Likert 1-5 van Helemaal niet in lijn tot Volledig in lijn) 22
Functionaliteit-2: Is er tijdens de ontwikkeling van de applicatie functionaliteit geschrapt? (Ja/Nee) Functionaliteit-3: Indien er functionaliteit is geschrapt, hoeveel procent van de functionaliteit is geschrapt? (Open vraag, uitgedrukt in procenten) Algemeen Tenslotte kijken we naar het succes van het project in het algemeen. Dit geeft ons de mogelijkheid om te identificeren wat de respondenten de belangrijkste succesindicatoren vinden voor het succes van het project. Deze succesindicator wordt vastgesteld via de volgende vragen: Algemeen-1 – Hoe beoordeelt u het succes van het project in het algemeen? (Likert 1-5 van Helemaal niet succesvol tot Zeer succesvol)
23
4. Resultaten Onderzoek Het onderzoek bestaat naast de theoretische achtergrond uit een tweeledig praktisch onderzoek. -
Een kwantitatief onderzoek, afgenomen via een online enquête. Dit onderzoek had 25 respondenten, allen projectmanagers van (web)applicties in de zorg. Een kwalitatief onderzoek, bestaande uit 5 semi-gestructureerde interviews afgenomen bij 5 projectmanagers van (web)projecten in de zorg.
4.1 Kwantitatief onderzoek De online enquête bestaat uit 52 hoofdvragen en meerdere antwoordmogelijkheden waarin de respondenten de mogelijkheid hadden om het antwoord extra toe te lichten. Er zijn 57 mogelijke respondenten aangeschreven. Het gaat hierbij om afgeronde WASZ ontwikkeld in opdracht. De respondenten zijn gevonden door WASZ via nieuwsartikelen, gespecialiseerde websites en achtergronden te identificeren. Vervolgens is hier een selectie van gemaakt op basis van de scope van het onderzoek (Applicaties ontwikkeld in opdracht, met als doel het informeren van de patiënt). In totaal hebben 25 personen de enquête volledig ingevuld. De participatiegraad is 43,8%. Het kwantitatief onderzoek is opgezet op basis van het in 2.5 getoonde onderzoeksmodel. De vragen zijn opgezet om een indicatie te geven van de aandacht die besteed is aan de kritieke succesfactoren. Ook is gevraagd naar indicatie van het succes van het project gerelateerd aan de vier in het onderzoekmodel geïdentificeerde vormen van succes. In dit hoofdstuk zullen we de resultaten van het onderzoek eerst verkennen aan de hand van de gegeven antwoorden op de hoofdvragen. Vervolgens zullen we de statistische analyse van deze resultaten uitvoeren aan de hand van de relaties tussen de antwoorden op deze vragen en de antwoorden op de vragen over het succes van het project. KSF01 – Het aanwezig zijn van volledig en proactief risicomanagement
In 56% (n=14) van alle gevallen is er geen sprake geweest van risicomanagement bij het project. 24%(n=6) is er beperkt aandacht besteed aan het risicomanagement. Vijf respondenten (20%) geven aan dat er er veel aandacht is besteed aan het risicomanagement (Figuur 4.1).
Risicomanagement Aanwezig Nee 20%
24%
56%
Ja, beperkte aandacht Ja, veel aandacht
Figuur 4.1 – Was er sprake van risicomanagement bij dit project? De volgende vragen werden alleen gesteld aan de respondenten die hadden aangegeven dat er bij het project sprake was van enige vorm van risicomanagement. De vragen gaan over het 24
identificeren, monitoren en beheersen van de risico’s. De resultaten van deze vragen zijn weergegeven in Figuur 4.2.
Identificeren Risico's
Monitoren Risico's
Beheersen Risico's
10
10
10
5
5
5
0 Zeer slecht
Zeer goed
0 Zeer slecht
Zeer goed
0 Zeer slecht
Zeer goed
Figuur 4.2 – V.l.n.r. : Hoe beoordeelt u het identificeren (blauw), monitoren (rood), beheersen (groen), van de risico’s De laatste vraag over het risicomanagement vroeg om een indicatie van het succes van het risicomanagement in het algemeen (Figuur 4.3). Beoordeling Risicomanagement 10 5 0 Zeer slecht
Zeer goed
Figuur 4.3 – Hoe beoordeelt u het risicomanagement van het project in het algemeen? Er was ruimte voor de respondenten om een toelichting te geven op de gegeven antwoorden. Uit deze toelichtingen kwamen de volgende belangrijke zaken: -
Volgens één respondent was het risicomanagement eenvoudig te beheersen omdat het project opgedeeld was in kleine sprints. Hierdoor kon voortdurend worden bijgestuurd. Meerdere respondenten gaven aan dat als er verantwoording moet worden afgelegd aan verschillende bestuurders er automatisch meer aandacht besteed wordt aan het risicomanagement.
Uit de data blijkt dat een minderheid van alle (web)projecten in de zorg gebruik maakt van risicomanagement. De respondenten die aan hebben gegeven wel gebruik te maken van risicomanagement beoordelen het risicomanagement als neutraal of goed. KSF02 – Het vooraf aanwezig zijn van een volledige en realistische Business Case
In slechts 36% (n=9) van de onderzochte gevallen is er geen enkele Busines Case gemaakt. 56% (n=14) van de respondenten geeft aan dat er een beperkte Business Case is gemaakt. De overige 8% (n=2) heeft een volledig uitgewerkte Business Case gemaakt. Deze data is terug te vinden in figuur 4.4.
25
Business Case 8%
Nee 36%
Ja, een beperkte
56%
Ja, een volledige
Figuur 4.4 – Was er vooraf een Business Case gemaakt? De respondenten die vooraf een Business Case hebben gemaakt, zijn over het algemeen erg tevreden over de volledigheid en haalbaarheid van deze Business Cases, zoals te zien is in figuur 4.5 Volledigheid Business Case
Haalbaarheid Business Case
10
12 10 8 6 4 2 0
8 6 4 2 0 Zeer slecht
Zeer goed
Zeer slecht
Zeer goed
Figuur 4.5 – V.l.n.r. : Hoe beoordeelt u op het moment van schrijven de volledigheid (rood) en de haalbaarheid (groen) van de gemaakte Business Case Uit de extra toelichting blijkt dat veel organisaties beginnen met een subsidieaanvraag en deze vervolgens verder uit te werken tot een volledigere Business Case. Ook hebben meerdere respondenten aangegeven dat de Business Case in het begin zeer minimaal was, maar werd uitgebreid naarmate het project vorderde. KSF03 – Goede Communicatie
Bij deze vragen is geprobeerd de kwaliteit van het contact met de developer en de eindgebruikers in kaart te brengen. De respons op deze vragen is te zien in Figuur 4.6.
26
Communicatie Developer
Betrokkenheid Developer
20
20
10
10
0 Zeer slecht
0 Zeer slecht
Zeer goed
Communicatie Eindgebruikers
Betrokkenheid Eindgebruikers
20
20
10
10
0 Zeer slecht
Zeer goed
0 Zeer weinig
Zeer goed
Zeer veel
Figuur 4.6 – V.l.n.r. : Hoe beoordeelt u de communicatie met de developer (groen), de betrokkenheid van developer (rood), de communicatie met de eindgebruikers (blauw)en in welke mate zijn de eindgebruikers betrokken bij de ontwikkeling van de applicatie (geel). Uit de antwoorden blijkt dat men overwegend positief is over alle gevraagde vormen van communicatie. Vooral de communicatie met de eindgebruikers en de betrokkenheid van de eindgebruikers wordt als zeer positief beoordeelt. Ook een groot deel van de respondenten de betrokkenheid van de developer als goed (40%, n=10) of zeer goed (28%, n=7). Uit deze cijfers kan men de conclusie trekken dat de respondenten over het algemeen dat het idee hebben dat de communicatie goed verloopt.
KSF04 – Realistische inschatting van tijd en kosten en genoeg momentum om binnen deze beperkingen te blijven
Realisme Tijdinschatting
Momentum
15
15
10
10
5
5
0 Zeer onrealistisch
Zeer realistisch
0 Zeer slecht
Zeer goed
Figuur 4.7 – V.l.n.r. : Hoe realistisch was de inschatting van de benodigde tijd (rood), hoe beoordeelt u het momentum van het project (geel). De resultaten van de aan KSF04 gekoppelde vragen lopen, zoals te zien is in Figuur 4.7, sterk uiteen. Het realisme van de inschatting van de benodigde tijd wordt voornamelijk neutraal beoordeelt, met enkele uitschieters beide kanten op. Bij de antwoorden op de vraag waarin gevraagd werd naar het momentum van het project is dezelfde lijn terug te zien. Al moet hierbij wel 27
worden vermeld dat het momentum iets positiever wordt beoordeelt dan de inschatting van de benodigde tijd.
KSF05 – Teamleider die de teamdynamiek bevordert
Uit de respons blijkt dat men over het algemeen zeer tevreden is over de betrokkenheid van de teamleider van het developmentteam (Figuur 4.8). 44% (n=11) van respondenten geeft aan dat de betrokkenheid zeer goed is. Slechts 4% (n=1) geeft aan de betrokkenheid van de teamleider slecht is. Betrokkenheid Teamleider 15 10 5 0 Zeer slecht
Zeer goed
Figuur 4.8 – Hoe beoordeelt u de betrokkenheid van de teamleider van het developmentteam? Ook de dynamiek van het developmentteam wordt overwegend positief beoordeeld. 56% (n=14) van de respondenten vindt de dynamiek van het developmentteam goed of zeer goed (Figuur 4.9). In de toelichting waren er twee respondenten die aangaven dat de samenwerking binnen het development zeer goed verliep door de dynamiek. Indien de rolverdeling niet direct duidelijk was werd dit eenvoudig opgelost met behulp van de interne communicatie. Een andere respondent spreekt over een zeer gemotiveerd developmentteam. Dynamiek Developmentteam 15 10 5 0 Zeer slecht
Zeer goed
Figuur 4.9 – Hoe beoordeelt u de dynamiek van het developmentteam? KSF06 – Juiste keuze van platform en ontwikkelmethode
Een groot deel van de respondenten (56%, n=12) wist niet van welke ontwikkelmethode gebruik is gemaakt (Figuur 4.10). De reden hiervoor blijkt uit de volgende vraag, waar 16 respondenten (64%) aangeeft dat de developer de keuze heeft gemaakt voor de ontwikkelmethode. Slechts 20% (n=5) heeft zelf verschillende ontwikkelmethodes vergeleken (Figuur 4.11).
28
Ontwikkelmethode Anders Weet niet Agile,… Incremental Prototyping Waterfall 0
5
10
15
Figuur 4.10 – Van welke ontwikkelmethode is gebruik gemaakt?
Aandacht voor keuze Ontwikkelmethode
Geen, keuze van developer
16%
Beperkt (2-4)
20% 64%
Anders
Figuur 4.11 – Hoeveel aandacht is er besteed aan de keuze voor deze ontwikkelmethode? Bij de keuze voor het platform was de betrokkenheid van de respondenten, zoals te zien in Figuur 4.12, groter. Hoewel 40% (n=10) nog steeds aangeeft dat de developer de keuze hiervoor heeft gemaakt blijkt uit de antwoorden dat er door de respondenten meer is meegedacht over de platformkeuze. Aandacht Platform-keuze Geen, keuze van developer
16%
Geen, standaard platform
40%
8%
Beperkt (2-4)
20%
Veel (Meer dan 4)
16%
Figuur 4.12 – Hoeveel aandacht is er besteed aan de platform-keuze?
29
KSF07 – Voldoende steun van Senior Management
De respondenten beoordelen de betrokkenheid van het management positief (Figuur 4.13). Slechts 8% (n=2) van de respondenten vindt de betrokkenheid van het Senior Management slecht. Nog 8% (n=2) beoordeelt de betrokkenheid van het Senior Management neutraal. De rest van de respondenten beoordeelt de steun als goed (44%, n=11) of zeer goed (40%, n=10). Betrokkenheid Senior Management 15 10 5 0 Zeer slecht
Zeer goed
Figuur 4.13 – Hoe beoordeelt u de betrokkenheid van het Senior Management? KSF08 – Het opbreken van het project in kleine stappen
Zoals te zien is in Figuur 4.14 is 76% (n=19) van de onderzochte projecten gefaseerd verlopen. De gemiddele grootte van de stap varieerde van 2 weken tot 5 maanden. Het aantal stappen varieerde van 2 tot 10 stappen. De verdeling tussen de grootte van de stap en het aantal stappen is aangegeven in Figuur 4.15. Project gefaseerd
JA
24% 76%
NEE
Figuur 4.14 – Is de ontwikkeling van het project gefaseerd verlopen?
30
Figuur 4.15 –Scatterplot van de gemiddelde grootte van de stappen, en het aantal stappen. In Figuur 4.15 is door middel van een scatterplot de gemiddelde grootte van de stappen afgezet tegen aantal stappen. Uit de figuur blijkt dat er geen direct aanwijsbare relatie valt te vinden tussen de grootte van de stappen en het aantal stappen. BH04 – Incomplete/Zwakke requirementsdefinitie
Te zien is in figuur 4.16 dat bij vrijwel alle onderzochte projecten er vooraf requirements zijn gespecificeerd (92%, n=23). De kwaliteit van de requirements wordt over het algemeen positief beoordeelt; 60% (n=15) geeft aan dat de kwaliteit goed was. De volledigheid van de requirements wordt overwegend neutraal (48%, n=12) of positief (44%, n=11) beoordeelt (Figuur 4.17). Aanwezigheid Requirements 8% JA 92%
NEE
Figuur 4.16 – Waren er bij aanvang van het project requirements gespecificeerd?
31
Kwaliteit Requirements
Volledigheid Requirements
20 20 10
10
0 Zeer slecht
Zeer goed
0 Zeer slecht
Zeer goed
Figuur 4.17 – V.l.n.r. : Hoe beoordeelt u de kwaliteit (groen), volledigheid (rood) van de requirements die gespecificeerd zijn bij aanvang van het project?
BH07 – Onvoldoende professionele instelling
De respondenten zijn overwegend positief over de professionaliteit van het developmentteam (Figuur 4.18). 60% (n=15) geeft aan dat het developmentteam zich professioneel heeft opgesteld. 16% (n=4) vindt de opstelling van het developmentteam zeer professioneel. Professionaliteit Developmentteam 20 15 10 5 0 Zeer onprofessioneel
Zeer professioneel
Figuur 4.18 – Hoe beoordeelt u de professionaliteit van het developmentteam? USA – Usability
In vrijwel alle onderzochte gevallen (92%, n=23) is er aandacht besteed aan de usability van de applicatie. Uit de toelichting op de antwoorden blijkt dat in veel gevallen aandacht wordt besteed aan de usability door de eindgebruikers te betrekken in de ontwikkeling. Er worden concepten, prototypes en wireframes gepresenteerd aan de gebruiker. De ervaring van de gebruiker weegt zwaar mee in de rest van de ontwikkeling. Opmerkingen worden meegenomen en functies worden aangepast als blijkt dat de gebruiker hier behoefte aan heeft. De kwaliteit van de usability wordt ook als overwegend goed ervaren (Figuur 4.19).
32
Usability
Kwaliteit Usability 15
8%
10 JA 5
NEE
92%
0 Zeer slecht
Zeer goed
Figuur 4.19 – V.l.n.r. : Is er aandacht besteed aan de usablity van de applicatie?, Hoe beoordeelt u de kwaliteit van de usability? JREL – Job Relevance
In de onderzochte projecten is veel aandacht besteed aan de relevantie van de gepresenteerde informatie (Figuur 4.20. Ook hier wordt in de toelichting veel gesproken over het betrekken van de eindgebruiker. De eindgebruiker werd regelmatig gevraagd zijn mening te geven over de relevantie van de informatie. Ook worden de teksten regelmatig geanalyseerd en geredigeerd door experts op verschillende vakgebieden, zoals wetenschappers, ervaringsdeskundigen en PR deskundigen. Aandacht Informatierelevantie 15 10 5 0 Zeer weinig
Zeer veel
Figuur 4.20 – Hoe veel aandacht is besteed aan de relevantie van de gepresenteerde informatie? OUQ – Output Quality
Ook aan de kwaliteit van de gepresenteerde informatie is veel aandacht besteed (Figuur 4.21). Om de kwaliteit van de informatie te waarborgen wordt de eindgebruiker veel betrokken. Ook hebben vier respondenten expliciet gemeld wetenschappers betrokken te hebben in de ontwikkeling om zo de kwaliteit van de informatie te waarborgen.
33
15
Aandacht Informatiekwaliteit
10 5 0 Zeer weinig
Zeer veel
Figuur 4.21 – Hoeveel aandacht is besteed aan de kwaliteit van de gepresenteerde informatie? ACC – Accessibility
In iets meer dan de helft (52%, n=13) van de onderzochte projecten is er aandacht besteed aan de toegankelijkheid van de applicatie. Het succes van de accessiblity wordt overwegend positief beoordeelt (Figuur 4.22). Accessibility
Succes Accessiblity 8 6
48% 52%
JA
4
NEE
2 0 Zeer goed
Zeer slecht
Figuur 4.22 – V.l.n.r. : Is er aandacht besteed aan de accessiblity van de applicatie? Hoe beoordeelt u het succes van de accessiblity? Tijd
Een minderheid van de projecten (44%, n=11) is op tijd afgerond. Het percentage waarin de uiteindelijke opleverdatum afweek van de geplande opleverdatum is hieronder weergegeven in Figuur 4.23. Op Tijd Afgerond
44% 56%
Tijdsafwijking
JA NEE
6 4 2 0 10 15 20 25 30 40 100 %
Figuur 4.23 – V.l.n.r. : Is het project afgerond binnen de vooraf afgesproken tijd? In hoeverre week het project af van de verwachte opleverdatum?
34
In 68% (n=17) van de gevallen was de opleverdatum tenminste éénmaal aangepast gedurende het project (Figuur 4.24). Het aantal keer dat deze datum is aangepast varieert van 1 tot 3 keer. Opleverdatum aangepast
32%
JA NEE
68%
Figuur 4.24– Is de opleverdatum aangepast tijdens het project?
Budget
72% (n=18) van de projecten is binnen het budget gebleven. In slechts 24% (n=6) van de gevallen is het budget verhoogd tijdens de ontwikkeling van de applicatie (Figuur 4.25). Het aantal keer dat in ieder geval het budget is verhoogd tijdens de ontwikkeling variëert van 1 tot 3 keer. Opvallend is dat als het project niet binnen het budget is gebleven het budget verhoogd is. Hieruit kan men concluderen dat het voltooien van het project belangrijker is dan het binnen budget blijven. Binnen Budget
28%
Budget Aangepast
24%
JA 72%
NEE
76%
Ja, verhoogd Nee
Figuur 4.25 – V.l.n.r. : Is het project binnen het budget gebleven? Is het budget van het project aangepast tijdens de ontwikkeling?
35
Is het project binnen het budget gebleven? * Is het budget van het project aangepast tijdens de ontwikkeling? Crosstabulation Count Is het budget van het project
Total
aangepast tijdens de ontwikkeling? Ja, het budget
Nee
is verhoogd Is het project binnen het
Ja
1
17
18
budget gebleven?
Nee
5
2
7
6
19
25
Total
Tabel 4.1 – “Is het project binnen het budget gebleven?” tegenover “Is de opleverdatum aangepast tijdens het project?”
Gebruikersacceptatie
Uit het onderzoek blijkt dat de gebruikersacceptatie over het algemeen goed kan worden ingeschat. In slechts 28% (n=7) van gevallen is het aantal gebruikers minder dan verwacht en in 16% (n=4) overtreft het aantal gebruikers het aantal verwachte gebruikers zelfs (Figuur 4.26). Aantal Gebruikers tegenover Verwachting Ja 16% 28%
Nee, minder gebruikers
56%
Nee, meer gebruikers
Figuur 4.26 – Is het aantal gebruikers in lijn met het verwachte aantal gebruikers? Ook de frequentie van gebruik kan goed worden ingeschat. In 20% (n=5) van de gevallen is het gebruik frequenter. In 68% (n=17) van de gevallen is de frequentie in lijn met de verwachte frequentie (Figuur 4.27).
36
Frequentie Gebruik tegenover Verwachting 12%
Ja Nee, frequenter
20% 68%
Nee, minder frequent
Figuur 4.27 – Is de frequentie van het gebruik door eindgebruikers in lijn met de verwachte frequentie van gebruik? Functionaliteit
De uiteindelijke functionaliteit van de applicatie is relatief goed in lijn met de vooraf gespecificeerde functionaliteit. In slechts 1 geval is de functionaliteit niet in lijn. Het grootste deel van de respondenten beoordeelt de functionaliteit als ‘in lijn’ of ‘volledig in lijn’ (Figuur 4.28). Functionaliteit In Lijn 15 10 5 0 Helemaal niet in lijn
Volledig in lijn
Figuur 4.28 – In hoeverre is de functionaliteit van het systeem in lijn met de vooraf gespecificeerde functionaliteit? Wel is in de meerderheid (56%, n=14) van de onderzochte projecten tijdens de ontwikkeling functionaliteit geschrapt. De percentages van de functionaliteiten die geschrapt zijn, zijn hieronder aangegeven in Figuur 4.29. Gemiddeld wordt ongeveer 18% van de functionaliteit geschrapt indien er functionaliteit wordt geschrapt.
37
Functionaliteit Geschrapt
% Functionaliteit Geschrapt 5 4 3
44% 56%
Ja
2
Nee
1 0 5
10
15
25
30
45
Figuur 4.29 – V.l.n.r. : Zijn er tijdens de ontwikkeling van de applicatie functionaliteit geschrapt? Indien er functionaliteit is geschrapt, hoeveel procent van de functionaliteit is geschrapt? Algemeen
De respons op de vraag hoe men het succes van het project in het algemeen beoordeelt is overwegend positief (Figuur 4.30). Slechts 1 respondent geeft aan dat het project niet succesvol was. 6 respondenten (24%) beoordelen het succes van het project neutraal, terwijl de overige 18 respondenten het project als succesvol of zeer succesvol beoordelen. Wat opvallend is, is dat de respondenten van de enquête het succes van het project positief beoordelen. Dit druist in tegen de waarneming van Harmsen & Verschuur (2010) die stellen dat slechts 47% van de Nederlandse ICT-projecten als succesvol worden beschouwd. Algemeen Projectsucces 16 14 12 10 8 6 4 2 0 Helemaal niet succesvol
Zeer succesvol
Figuur 4.30 – Hoe beoordeelt u het succes van het project in het algemeen?
4.2 Statistische Analyse Op basis van het onderzoeksmodel is op de data statistisch onderzoek uitgevoerd. Hierbij is gezocht naar correlaties via Kendalls tau(т), Pearson product-moment correlation(ρ) en de Chikwadraat (χ2) toets. De resultaten van dit onderzoek zijn te vinden in Bijlage 3. Hieronder zullen we de belangrijkste bevindingen bespreken. Het is van belang om in het achterhoofd te houden dat het aantal responsen van 25 mogelijk niet genoeg is om conclusies te trekken voor alle webapplicaties en websites in de zorg. Het geeft slechts 38
een beeld van de relaties tussen kritieke succesfactoren en het succes van de onderzochte projecten. 4.2.1 Wanneer is een project succesvol?
Het is interessant om te weten wat voor de respondenten de belangrijkste factor was om het project als succesvol te beschouwen. Dit hebben we onderzocht door een correlatie te vinden tussen de in het onderzoeksmodel (Figuur 2.3) genoemde succesindicatoren en beoordeling van het succes van het project in het algemeen. Hieruit volgen twee significante correlaties voor p <0.10. De correlatie tussen het algemene projectsucces en het succes op het gebied van budget (Is het project binnen het budget gebleven?) is ρ=.395 (p=0.056). De correlatie tussen het algemene projectsucces en het aantal gebruikers is т=.333 (p=0.091)(Bijlage 4). Hieruit kunnen we de conclusie trekken dat onder de respondenten de twee belangrijkste factoren die het succes van het project bepalen gerelateerd zijn aan het aantal gebruikers en of het project zijn budget heeft overschreden. 4.2.2 Tijd
Het succes van een project op het gebied van tijd is af te meten via één simpele vraag: Is het project op tijd afgerond? Uit de resultaten van de statistische analyse blijkt dat één KSF een significante correlatie heeft met het succes van het project op het gebied van tijd. KSF04, de realistische inschatting van tijd en kosten heeft een sterke relatie met het op tijd afronden van het project. De vraagstelling van KSF04-1, “Hoe realistisch was de inschatting van de benodigde tijd?” kan echter als zeer leidend worden beschouwd. Het is mogelijk dat de respondenten het antwoord deze vraag beoordelen aan de hand van de vraag of het project op tijd is afgerond. De vraag heeft een correlatie van ρ=.422 met het succes op het gebied van tijd (p=0.035). Er blijkt echter ook een relatie tussen te zijn tussen vraag KSF04-2 en het succes op het gebied van tijd. De vraag “Hoe beoordeelt u het momentum van het project” heeft een correlatie van ρ=.542 (p=0.005) met het succes. Omdat beide vragen een significante correlatie hebben met het succes op het gebied van tijd kunnen we de voorlopige conclusie trekken dat de realistische inschatting van benodigde tijd een significant effect heeft op het succes van een project op het gebied van tijd. Een ander interessant resultaat is de relatie tussen de aanwezigheid van risicomanagement en het succes op het gebied van tijd. Dit blijkt uit de vraag KSF01-1 (“Was er sprake van risicomanagement bij dit project?”). Hoewel dit effect niet significant is voor p<0.05 (p=0.086) toont het desondanks aan dat er een correlatie van т=.351 is tussen het succes van een project op het gebied van tijd en de aanwezigheid van risicomanagement als de significantiewaarde minder streng wordt gehanteerd. 4.2.3 Gebruikersacceptatie
Voor dit onderzoek hebben we besloten om het succes van de gebruikersacceptatie te meten via twee criteria: Het aantal gebruikers, en de frequentie van gebruik. Uit de analyse blijkt dat voor 39
geen van de vragen een correlatie heeft met het succes op het gebied van gebruikersacceptatie die significant is voor p<0.05. Toch zijn er twee opvallende correlaties. Beide van deze correlaties zijn van toepassing op de vraag “Is het aantal gebruikers in lijn met het verwachte aantal gebruikers”. Vraag BH04-2 (Hoe beoordeelt u de volledigheid van de requirements die gespecificeerd zijn bij aanvang van het project) en vraag ACC-2 (Hoe beoordeelt u het succes van de accessiblity) hebben een sterke relatie met het aantal gebruikers van de applicatie. Respectievelijk т=.371 (p=0.082) voor BH04-2 en т=.485 (p=0.078) voor ACC-2. 4.2.4 Budget
Als we kijken naar het succes op het gebied van budgetmanagement via de vraag “is het project binnen het budget gebleven?” zijn er twee opvallende resultaten. Als eerste wordt er een significante correlatie aangetoond tussen vraag KSF01-4 (“Hoe beoordeelt u het beheersen van de risico’s, т=.611, p=0.046). Andere vragen over het risicomanagement hebben echter geen relatie met het succes van budgetmanagement. Tot slot zien we dat de vragen KSF02-1 (Was er vooraf een Business Case gemaakt?, т=.327, p=0.109) en KSF03-1 (Hoe beoordeelt u de communicatie met de developer?, т=.296, p=0.118) een correlatie hebben met het succes op het gebied van budget. Deze relatie is echter niet statistisch significant, maar kan interessant zijn voor verder onderzoek. 4.2.5 Functionaliteit
Op het gebied van functionaliteit (In hoeverre is de functionaliteit van het systeem in lijn met de vooraf specificeerde functionaliteit?) zien we duidelijke correlatie met BH04, de kwaliteit en volledigheid van de requirementsdefinitie. Zowel BH04-1 (Hoe beoordeelt u de kwaliteit van de requirements die gespecificeerd zijn bij aanvang van het project?, ρ=.462, p=0.027) als BH04-2 (Hoe beoordeelt u de volledigheid van de requirements die gespecificeerd zijn bij aanvang van het project?, т=.569 p=0.004) hebben een duidelijk aantoonbare correlatie met het succes van de applicatie op het gebied van functionaliteit. Een ander opvallend, maar niet significant resultaat is de relatie met JREL-1 (In welke mate is er aandacht besteed aan de relevantie van de gepresenteerde informatie?, т=.353, p=0.056). Een direct aantoonbare correlatie kan op dit moment niet aangetoond worden, maar kan zeer interessant zijn voor verder onderzoek. 4.2.6 Algemeen
Tenslotte hebben we gekeken naar de in het onderzoeksmodel genoemde factoren die relevant zijn voor het succes van het project in het algemeen. Hieruit blijkt dat KSF03-1 (Hoe beoordeelt u de communicatie met de developer?) een statistisch significante correlatie (т=.453) heeft met het succes van het project in het algemeen (p=.017). KSF03-2 (Hoe beoordeelt u de betrokkenheid van de developer) heeft een relatie die erg dicht aanligt tegen statistisch significant (p=.402, p=0.052).
40
Er is ook een aantoonbare correlatie tussen de vraag KSF05-2 (Hoe beoordeelt u de dynamiek van het developmentteam?, т=.406) en het succes van het project in het algemeen (p=.028). Opvallend is dat al deze factoren vallen onder de tactische KSF’s. Het is mogelijk om de conclusie te trekken dat het algemene projectsucces voornamlijk wordt beïnvloedt door tactische factoren.
4.3 Kwalitatieve Interviews Voor het kwalitatieve onderzoek zijn er vijf projectmanagers geïnterviewd. Deze projectmanagers zijn gevonden via hetzelfde bestand als de respondenten van de enquête. Personen die aangaven liever geïnterviewd te worden dan een online enquête in te vullen zijn benaderd om een afspraak voor een interview te maken. De interviews zijn zowel telefonisch als persoonlijk afgenomen. De interviews hadden een semi-gestructureerd karakter, en behandelden zowel de geïdentificeerde KSF’s als succesfactoren die de geinterviewde als belangrijk zag. De belangrijkste bevindingen die niet eerder zijn geïdentificeerd zullen hier kort worden besproken. 4.3.1 IT-Maturity
In een interview met de ICT-manager van één van de onderzochte projecten werd een nog niet onderzochte verklaring gegeven voor tegenvallende resultaten op het gebied van gebruikersacceptatie: IT Maturity. IT Maturity is een begrip gerelateerd aan de volwassenheid van een organisatie op het gebied van het definiëren, controleren, meten en de efficiëntie van softwareprocessen (Paulk et al., 1993). De IT Maturity van een organisatie kan worden ingedeeld in één van vijf ‘maturity levels’. Deze levels geven een indicatie van de volwassenheid van de organisatie op ICT-gebied. In het interview werd aangegeven dat een verschil in de IT-maturity tussen de ontwikkelaar en de eindgebruiker of tussen de ontwikkelaar en de opdrachtgever het succes van de gebruikersacceptatie kan remmen. In de literatuur is al onderzocht dat het succes van de implementatie van IT processen negatief wordt beïnvloedt door verschillen in IT-Maturity levels tussen twee bedrijven (Paulk et al., 1993). Maar of dit ook het geval is als het gaat om applicaties die gebruikt worden door particuliere gebruikers, met name afnemers van applicaties in de zorg, is nog niet onderzocht. 4.3.2 Gebruikersacceptatie en incrementele development
In één van de afgenomen interviews is gesproken met de projectleider van een webapplicatie die op het gebied van gebruikersacceptatie zeer succesvol was. Uit dit interview bleek dat er gewerkt werd met een werkwijze waarbij de eindgebruiker constant betrokken werd. Elke twee weken werd een nieuw prototype opgeleverd en dit werd samen met de gebruikers geëvalueerd. De opmerkingen van de eindgebruikers werd direct verwerkt in nieuwe prototypes. Deze vorm van ontwikkelen, waarbij de eindgebruiker in iedere stap van het proces is betrokken, heeft er volgens de projectleider voor gezorgd dat het project een dergelijk succes is geworden. Wat opvalt is dat met de statistische analyse van de enqête is aangetoond dat er een positieve correlatie bestaat tussen de volledigheid van de requirements en het succes op het gebied van
41
gebruikersacceptatie. Het project wat besproken is in dit interview is echter boven verwachting succesvol, terwijl er geen expliciete requirements zijn gespecificeerd. 4.3.3 Zorgapplicaties als promotietool
Een applicatie die onderzocht is, was ontwikkeld in opdracht van een zorgverzekeringsmaatschappij. De applicatie heeft functionaliteit die in staat is om de gebruiker te helpen met het vinden van artsen, en de gesprekken en de informatie die in deze gesprekken is gedeeld op te slaan. Hoewel de applicatie de gebruiker bijstaat in het zorgproces is de applicatie niet alleen als dienst ontwikkeld. De applicatie wordt gebruikt als promotionele tool. Door de naam van de zorgverzekeraar te verbinden aan de applicatie hoopt men meer klanten te trekken. Het kan interessant zijn voor verder onderzoek om te onderzoeken of de kritieke succesfactoren van applicaties die zijn ontwikkeld als promotionele tool afwijken van WASZ die voornamelijk als dienst zijn ontwikkeld. 4.3.4 Privacy
Een onderwerp wat niet aan bod is gekomen in de enquête maar wel in de interviews is de privacykwestie. Het kan zijn dat webapplicaties in de zorg gevoelige informatie vragen aan de gebruiker, informatie die de gebruiker niet graag op het internet wil zetten. Het is voor ontwikkelaars en projectleiders van het grootste belang om deze privacygevoelige informatie goed te beveiligen. De geïnterviewde gaf aan dat het delen van privacygevoelige informatie mogelijk de gebruikersacceptatie kan verminderen. De manier waarop moet worden omgegaan met privacygevoelige informatie is wettelijk vastgelegd in de Wet Bescherming Persoonsgegevens. De geïnterviewde gaf echter aan dat het delen van privacygevoelige informatie ondanks de wetgeving de gebruikersacceptatie in de weg kan staan. De geïnterviewde gaf aan dat dit probleem kan mogelijk worden opgelost door een onafhankelijk keurmerk in het leven te roepen. Dit keurmerk zou specifiek zijn voor webapplicaties in de zorg. Dit keurmerk zal waarborgen dat de privacygevoelige informatie zorgvuldig wordt behandeld. 4.3.5 Vergelijking met enquête
Wat direct opvalt is dat de respondenten van de enquête positiever zijn over het succes met betrekking tot de gebruikersacceptatie. 72% van de respondenten gaf aan dat het aantal gebruikers in lijn was met de verwachting, terwijl men bij de interviews wat terughoudender was over het succes van de gebruikersacceptatie. Hier kunnen twee verklaring voor zijn: men kan bij het invullen van een online enquête wat makkelijker een positieve wending aan de werkelijkheid geven. Een andere verklaring is dat de interpretatie van de interviewer het project als minder succesvol beschouwt dan dat de geïnterviewde zelf vindt. Ook beoordelen de geïnterviewden het algemene projectsucces minder succesvol. Deze discrepantie kan op dezelfde manier verklaard worden. Verder is in vrijwel elk interview aangegeven dat er veel aandacht is besteed aan de kwaliteit van de gepresenteerde informatie. Dit is in lijn met de respons op de enquête, maar in de interviews leek men meer waarde te hechten aan het belang van de kwaliteit van de gepresenteerde informatie.
42
5. Verder onderzoek Er is een groot en continu groeiend aantal websites en webapplicaties in de zorg. Het aantal respondenten op het kwantitatieve onderzoek was slechts 25. Dit heeft tot gevolg dat de foutenmarge van het onderzoek groot is. Om de volledigheid en de juistheid van de bevindingen van dit onderzoek te waarborgen is het van belang dat hetzelfde onderzoek op een grotere steekproef wordt uitgevoerd. Ook is een groot deel van de resultaten niet significant voor p < 0.05, maar ligt dermate dicht bij deze p-waarde dat een significante correlatie alsnog kan ontstaan bij een grotere onderzoekspopulatie. Daarnaast is in het onderzoek geen aandacht besteed aan de relatie tussen IT-maturity en het succes van de projecten. Één kwalitatief interview gaf aan dat er mogelijk een relatie tussen deze twee factoren bestaat en ook de literatuur toont aan dat het effect van IT-maturity niet onderschat moet worden. In verder onderzoek kan deze relatie verder worden onderzocht.
43
6. Conclusie Websites en webapplicaties in Nederland in de zorg worden over het algemeen als succesvol beoordeeld. De belangrijkste factoren die bepalen of een project als succesvol wordt beschouwd zijn het aantal gebruikers en of het project zijn budget niet heeft overschreden. Er is een correlatie aangetoond tussen de volledigheid van de vooraf gespecificeerde requirements en het aantal gebruikers. Ook de aandacht die besteed wordt aan de accessibility van de applicatie heeft een effect op het aantal gebruikers. Drie factoren hebben een correlatie met het succes op het gebied van budgetmanagement: De kwaliteit van het beheersen van de risico’s, de aanwezigheid van een business case en de kwaliteit van de communicatie met de developer. De overschrijding van de ingeplande tijd voor een project wordt beïnvloed door één vooraf geïdentificeerde kritieke succesfactor: een realistische inschatting van tijd en kosten en genoeg momentum om binnen deze beperkingen te blijven. Extra aandacht voor de KSF kan het succes op het gebied van tijd van een project beïnvloeden. Ook de aanwezigheid van risicomanagement beïnvloed deze succesindicator. Er is een significante correlatie aangetoond tussen de kwaliteit en de volledigheid van de requirementspecificering en de mate waarin de functionaliteit van het systeem in lijn ligt met de vooraf gespecificeerde functionaliteit. Ook de mate waarin aandacht wordt besteed aan de relevantie van de gepresenteerde informatie beïnvloedt deze succesindicator. Het presenteren van relevante informatie wordt gezien als een belangrijke functionaliteit van het systeem. Het succes van het project in het algemeen wordt sterk beïnvloed door de kwaliteit van de communicatie met de developer en de betrokkenheid van de developer. Ook de dynamiek van het developmentteam beïnvloed het succes van het project in het algemeen.
44
Literatuur Adams, S. A. & Boot, C. R. L. (2007). ICT en de gezondheidzorg. SCP jaarboek ICT en Samenleving 2007. Amsterdam: Uitgeverij Boom Boddie, J. (1986). Crunch mode: Building effective systems on a tight schedule. Upper Saddle River, NJ, USA: Prentice-Hall, Inc. Boynlon, A. C., & Zmud, R. W. (1984). An assessment of critical success factors. Sloan Management Review, 25(4), 17-27. Chau, P. Y. K., & Lai, V. S. K. (2003). An empirical investigation of the determinants of user acceptance of internet banking. Journal of Organizational Computing and Electronic Commerce, 13(2), 123-145. doi: 10.1207/S15327744JOCE1302_3 Davis, F. D., Bagozzi, R. P., & Warshaw, P. R. (1989). User acceptance of computer technology: A comparison of two theoretical models. Management Science, 35(8), 982-1003. doi: 10.1287/mnsc.35.8.982 Glass, R.,L. (1997). Software runaways-lessons learned from massive software project failures. Upper Saddle River, NJ, USA: Prentice-Hall, Inc. Goodwin, N. C. (1987). FUNCTIONALITY AND USABILITY. Communications Of The ACM, 30(3), 229-233. Gool CH van (RIVM), Hoeymans N (RIVM), Picavet HSJ (RIVM). Lichamelijk functioneren: Hoeveel mensen hebben beperkingen? In: Volksgezondheid Toekomst Verkenning, Nationaal Kompas Volksgezondheid. Bilthoven: RIVM,
Nationaal Kompas Volksgezondheid\Gezondheid en ziekte\Functioneren en kwaliteit van leven\Lichamelijk functioneren, 7 december 2009. Harmsen, F., & Verschuur, J. (2010). Onderzoeksresultaten ICT barometer over ICT-projecten. (). Rotterdam: Ernst & Young. ISO, (2006). ISO 9241-110:2006, Ergonomics of human-system interaction -- Part 110: Dialogue
principles. Geneva, Switzerland: ISO/IEC.
Paulk, M. C., B. Curtis, M. B. Chrissis, and C. V. Weber. (1993). Capability Maturity Model for
Software, version 1.1. Pittsburgh: Carnegie Mellon University, Software Engineering Institute.
45
Slevin, D. P., & Pinto, J. K. (1987). Balancing strategy and tactics in project implementation. Sloan Management Review, 29(1), 33-41. Smith, J. (2001). Troubled IT projects: Prevention and turnaround. Herts, UK: IEEE. Van Dijk, A. J. (2009). Success and failure factors in ICT projects: A dutch perspective. (Unpublished Engineering Doctorate). Middlesex University, Ridderkerk. Venkatesh, V., & Davis, F. D. (2000). A theoretical extension of the technology acceptance model: Four longitudinal field studies. Management Science, 46(2), 186-204. doi: 10.1287/mnsc.46.2.186.11926 W3C. (2008). Web Content Accessiblity Guidelines (WCAG) 2.0.Geraadpleegd via http://www.w3.org/TR/2008/REC-WCAG20-20081211/
46
Bijlagen Bijlage 1 – SUFFI-chart Van Dijk, A. J. (2009). Success and failure factors in ICT projects: A dutch perspective. (Unpublished Engineering Doctorate). Middlesex University, Ridderkerk.
47
48
49
50
51
52
Bijlage 2 – Kwalitatieve Interviews Woensdag 17 April – 11:00 Geïnterviewd: ICT Manager van een Nederlands kennisinstituut over adviserende webapplicatie met betrekking tot depressie. Het interview heeft ongeveer een uur geduurd en is afgenomen op locatie bij de ICT Manager. In deze tijd hebben wij het doel van het project besproken, het succes van het project en mogelijke verklaringen voor het succes van het project. De applicatie bestaat uit een korte vragenlijst die de gebruiker invult. De gebruiker krijgt vervolgens een indicatie van zijn psychische gesteldheid, en wordt doorverwezen naar verschillende behandelmethodes, zowel online als offline. De applicatie is ontwikkeld om gebruikers een beeld van hun psychische gesteldheid te geven via een korte vragenlijst, en te informeren over mogelijke behandelmethodes. Het project wordt niet als zeer succesvol beschouwd. Het aantal gebruikers is veel minder dan het verwachte aantal gebruikers. Een verklaring die werd gegeven is IT-maturity, en met name een verschil in de IT-maturity van het instituut en de IT-maturity van de eindgebruiker. Een groot verschil tussen deze twee maturity-levels kan het acceptatie van het project inde weg staan. De vragenlijst is ontwikkeld in samenwerking met in-house wetenschappers. De kwaliteit van de vragenlijst was zeer belangrijk voor het project, omdat het instituut veel waarde hecht aan kwalitatief goede zorg. Het is van groot belang om de gebruiker goed advies te geven over mogelijke vervolgstappen in het zorgproces.
Woensdag 17 April – 13:00 Geïnterviewd: Projectleider van applicatie om hulpzoekenden en hulpbiedenden met elkaar in contact te brengen. Het interview heeft ongeveer 30 minuten geduurd, en is vooral gegaan over het succes van het project en de informatierelevantie. Geen ICT-gerelateerde onderwerpen zijn aan bod gekomen omdat de projectleider zich niet heeft bezig gehouden met de ICT-kant van het project. Het succes van het project is redelijk in lijn met het verwachte succes. Het aantal gebruikers is iets meer dan vooraf verwacht, maar de frequentie van gebruik is minder dan verwacht. Minder mensen gebruiken de applicatie meerdere keren. De geïnterviewde wist hier geen verklaring voor te geven. De relevantie van de informatie van de applicatie was zeer belangrijk tijdens de ontwikkeling van het project. Omdat het project zich vooral richt op hulpzoekende ouderen was het belangrijk om de informatie helder weer te geven, en moest de informatie eenvoudig te vinden zijn. De projectleider was zeer tevreden over de informatierelevantie. De geïnterviewde wist niet of er aandacht was besteed aan de accessiblity en usablity van de applicatie.
53
Donderdag 9 Mei – 16:00 Geïnterviewd: Projecthoofd van een applicatie om het contact tussen jonge patiënten en artsen te vergemakkelijken. Het telefonische interview heeft ongeveer 25 minuten geduurd. In dit interview is vooral de filosofie achter de applicatie en de ontwikkeling van de applicatie besproken. De applicatie is ontwikkeld om de communicatie tussen arts en patiënt te vergemakkelijken via moderne communicatiemiddelen. Men zag dat deze communicatie verbeterd kon worden door een applicatie, en men is direct begonnen aan de ontwikkeling van de applicatie. Er is direct een prototype ontworpen, gebaseerd op bestaande applicaties. Na sprints die variëerde tussen twee weken en twee maanden, werd de applicatie ge-evalueerd door een groep eindgebruikers. De opmerkingen van de patiënten werden vervolgens direct verwerkt in de nieuwe versie van het project. Het project is uitermate succesvol. Het projecthoofd vertelde dat meerdere ziekenhuizen interesse hadden in de applicatie, en dat ze deze vraag bijna niet aankunnen. Het projecthoofd denkt dat het project zo succesvol is door de betrokkenheid van de eindgebruiker. Door bij de ontwikkeling voornamelijk te luisteren naar de wens van de gebruiker is de applicatie zeer populair bij de eindgebruiker. Er zijn geen requirements of business cases opgesteld voordat begonnen werd aan de ontwikkeling van het project. Men is direct begonnen met de ontwikkeling van het prototype, en voegde vervolgens functionaliteit toe aan de hand van de wensen van de eindgebruiker.
Donderdag 23 Mei – 11:00 Geïnterviewd: Hoofdontwikkelaar van een webapplicatie om de communicatie tussen ouders met hulpbehoevende kinderen en verschillende instanties te verbeteren. Het interview heeft ongeveer 45 minuten geduurd. In dit interview hebben we de ontwikkeling van de applicatie besproken en het proces voordat begonnen is aan de ontwikkeling van de applicatie. De applicatie is ontwikkeld om de communicatie over de ontwikkeling van het kind te vergemakkelijken. De applicatie is een soort dagboek, waarin de voortgang en opmerkelijke zaken van het kind worden opgeslagen. De ouder kan vervolgens zelf beslissen met wie deze informatie gedeeld wordt. Privacy was erg belangrijk bij de ontwikkeling van het project. De gebruiker moet zelf eenvoudig kunnen inzien en aanpassen wie de informatie kan lezen. Bij het opstellen van de requirements is veel aandacht besteed aan de privacy. Ook tijdens de ontwikkeling is regelmatig de hulp van externe adviseurs ingeroepen om de privacy van de applicatie te waarborgen. De applicatie is ontwikkeld met de SCRUM-methode. Het aantal gebruikers van de applicatie is minder dan verwacht. De geïnterviewde dacht dat dit voornamelijk 54
kwam omdat gebruikers niet graag privé-informatie over hun kind op het internet zetten. Hoewel er veel aandacht is besteed aan de privacy, is het lastig om deze informatie te communiceren met de eindgebruiker. Maandag 17 Juni – 14:00 Geïnterviewd: Projectmanager van mobiele applicatie van verzekeraar om het contact met de arts te vergemakkelijken. Dit telefonisch interview heeft ongeveer 20 minuten geduurd. In dit interview hebben wij vooral het doel van de applicatie en de informatiekwaliteit besproken. De applicatie is ontwikkeld om de gebruiker te ondersteunen in zijn communicatie met de arts. De applicatie kan gebruikt worden om artsen op te zoeken en te beoordelen, en om de details van het gesprek eenvoudig op te slaan. De applicatie is ontwikkeld als promotie van de zorgverzekeraar. Hoewel iedereen de applicatie gratis kan downloaden is zowel de naam van de applicatie als het logo van de applicatie reclame voor de zorgverzekeraar. De geïnterviewde beoordeelde de kwaliteit van de informatie als zeer goed, omdat alle informatie over de artsen uit het bestand van de zorgverzekeraar komen. Omdat de naam van de zorgverzekeraar verbonden is aan de applicatie wordt alle informatie nauwkeurig gecontroleerd voordat deze in de applicatie wordt gepresenteerd. De applicatie is vaker dan verwacht gedownload, maar de geïnterviewde wist niet of de frequentie van gebruik in lijn was met de verwachting. De geïnterviewde vond het lastig om de applicatie als succesvol te beschouwen, omdat het voornamelijk een promotietool is, en het effect van deze promotie niet direct te meten is.
55
Bijlage 3 – Resultaten Statistische Analyse In deze bijlage zijn de resultaten van de statistische analyse te vinden. Van alle resultaten waarbij p<0.1 is de correlatie uitgerekend. De succesindicator die wordt onderzocht staat bovenin de tabel. De vragen zijn genummerd aan de hand van Bijlage 5, welke gebruikt kan worden als referentie. De toets die gebruikt is, is terug te vinden in de eerste kolom van de tabel. De legenda voor de tests staat onder de tabel. Tijd – Is het project op tijd afgerond? Vraag P KSF08-1** .130 KSF08-2** .928 KSF06-1* .334 KSF07-1** .722 KSF04-1*** .035 KSF04-2*** .005 KSF01-1** .086 KSF01-2** .601 KSF01-3** .673 KSF01-4** .375
Correlatie .422 .542 .351 -
Gebruikersacceptatie – Is het aantal gebruikers in lijn met het verwachte aantal gebruikers? Vraag P Correlatie BH04-1** .867 BH04-2** .082 .371 USA-1*** .368 JREL-1** .202 OUQ-1** .225 ACC-1** .753 ACC-2** .078 .485 Gebruikersacceptatie – Is de frequentie van het gebruik door eindgebruikers in lijn met de verwachte frequentie van gebruik? Vraag P Correlatie BH04-1** .295 BH04-2** .131 USA-1** .594 JREL-1** .711 OUQ-1** .441 ACC-1** .595 ACC-2** .592 Budget – Is het project binnen het budget gebleven? Vraag P KSF02-1** .109 KSF02-2** .296 56
Correlatie .327 -
KSF02-3** KSF03-1** KSF03-2** KSF03-3** KSF03-4** KSF01-1** KSF01-2** KSF01-3** KSF01-4** KSF06-1* KSF04-1 KSF07-1
.529 .118 .620 .789 .190 .491 .144 .673 .046 .428 .214 .768
.296 .611 -
Functionaliteit – In hoeverre is de gespecificeerde functionaliteit? BH04-1*** BH04-2** JREL-1** OUQ-1** KSF02-1** KSF02-2*** KSF02-3**
functionaliteit van het systeem in lijn met de vooraf .027 .004 .056 .226 .324 .882 .537
.462 .569 .353 -
Algemeen – Hoe beoordeelt u het succes van het project in het algemeen? BH07-1** .556 KSF03-1** .017 .453 KSF03-2*** .052 .402 KSF03-3*** .208 KSF03-4*** .127 KSF05-1*** .148 KSF05-2** .028 .406 KSF02-1** .553 KSF02-2** .599 KSF02-3** .738 * Chikwadraat ** Kendall’s tau_b *** Pearson
57
Bijlage 4 – Wanneer is een project succesvol Algemeen – Hoe beoordeelt u het succes van het project in het algemeen? Vraag P Correlatie Tijd** .195 Budget *** .056 .395 Gebruikersacceptatie – .091 .333 Aantal** Gebruikersacceptatie – .378 Frequentie** Functionaliteit** .416 * Chikwadraat ** Kendall’s tau_b *** Pearson
58
Bijlage 5 – Referentie vragen KSF01 – Risicomanagement KSF01-1 – Was er sprake van risicomanagement bij dit project? KSF01-2 – Hoe beoordeelt u het identificeren van de risico’s? KSF01-3 - Hoe beoordeelt u het monitoren van de risico’s? KSF01-4 – Hoe beoordeelt u het beheersen van de risico’s? KSF02 – Business Case KSF02-1 – Was er vooraf een business case gemaakt? KSF02-2 – Hoe beoordeelt u op het moment van schrijven de volledigheid van de gemaakte Business Case? KSF02-3 – Hoe beoordeelt u op het moment van schrijven de haalbaarheid van de gemaakte Business Case? KSF03 – Communicatie KSF03 -1 - Hoe beoordeelt u de communicatie met de developer? KSF03-2 – Hoe beoordeelt u de betrokkenheid van de developer? KSF03-3 – Hoe beoordeelt u de communicatie met de eindgebruikers? KSF03-4 – In welke mate zijn de eindgebruikers betrokken bij de ontwikkeling van de applicatie? KSF04 – Realistische inschatting van tijd en kosten KSF04-1 – Hoe realistisch was de inschatting van de benodigde tijd? KSF04-2 – Hoe beoordeelt u het momentum van het project? KSF04-3 – Hoe realistisch was de inschatting van de benodigde kosten? KSF05 – Dynamiek KSF05-1 – Hoe beoordeelt u de betrokkenheid van de teamleider van het developmentteam? KSF05-2 – Hoe beoordeelt u de dynamiek van het developmentteam? KSF06 – Platformkeuze en ontwikkelmethode KSF06-1 – Van welke ontwikkelmethode is gebruik gemaakt? KSF06-2 – Hoeveel aandacht is besteed aan de keuze voor de ontwikkelmethode? KSF06-3 – Hoeveel aandacht is b esteed aan de keuze voor het platform? KSF07 – Steun Senior Management KSF07-1 – Hoe beoordeelt u de betrokkenheid van het senior management? KSF08 – Fasering KSF08-1 – Is het project gefaseerd verlopen? KSF08-2 – Wat was de gemiddelde grootte van deze stappen? BH04 – Requirementsdefinitie BH04-1 – Hoe beoordeelt u de kwaliteit van de requirements die gespecificeerd zijn bij aanvang van het project? BH04-2 - Hoe beoordeelt u de volledigheid van de requirements die gespecificeerd zijn bij aanvang van het project? 59
BH07 – Professionaliteit BH07-1 – Hoe beoordeelt u de professionaliteit van het developmentteam? USA – Usability USA-1 – Is er aandacht besteed aan de usability van de applicatie? JREL – Job relevance JREL-1 – In welke mate is er aandacht besteed aan de relevantie van de gepresenteerde informatie? OUQ – Output Quality OUQ-1 – In welke mate is er aandacht besteed aan de kwaliteit van de gepresenteerde informatie? ACC – Accesibility ACC-1 – Is er aandacht besteed aan de accessibility van de applicatie? ACC-2 – Hoe beoordeelt u het succes van de accessibility?
60
Bijlage 6 – Kwantitatieve enquête
61
62
63
64
65
66
67
68
69
70
71
