IT project risicomanagement in het MKB
Geert-Jan Hoekstra S2351579
EBM870B20
Begeleider: Dhr. Swagerman
Co-assessor: Mevr. van der Meer-Kooistra Aantal woorden: 8347
1
1. Abstract
Dit ontwerpend onderzoek had tot doel het ontwikkelen van een risicomanagement model voor IT projecten in het midden- en kleinbedrijf. Het ontwikkelde model uit dit onderzoek is getest aan de hand van vooraf opgestelde functionele eisen. De resultaten laten zien dat het model in meerdere mate aan de functionele eisen voldoet. Met behulp van het ontwikkelde model is het makkelijker geworden voor het midden- en kleinbedrijf om risicomanagement toe te passen op IT projecten. De theorie op het gebied van risicomanagement van IT projecten in het midden- en kleinbedrijf was voorafgaand aan dit onderzoek zeer beperkt. Dit onderzoek is een handreiking aan andere
onderzoekers die zich willen richten op risicomanagement of projectmanagement in het midden- en kleinbedrijf.
2
2. Voorwoord
Risicomanagement komt steeds meer onder de aandacht bij verschillende organisaties. Met name door de snelle ontwikkeling in IT is er vraag naar risicomanagement op het gebied van IT projecten. Bedrijven in het MKB maken vaak de keuze om geen risicomanagement uit te voeren bij de IT projecten. Deze scriptie is een handreiking voor ondernemers om risicomanagement te gaan gebruiken om op die manier meer grip te houden op de IT projecten waarvan zij afhankelijk zijn. Deze scriptie is geschreven als eindproduct voor mijn Masteropleiding Accountancy & Controlling aan de Rijksuniversiteit te Groningen. Zonder de bijdrage van verschillende betrokkenen zou deze scriptie niet tot stand zijn gekomen. Hierbij wil ik in het bijzonder bedanken mijn begeleider Dhr. Dirk
3
3. Inhoudsopgave
1. Abstract ... 1 2. Voorwoord ... 2 3. Inhoudsopgave ... 3 4. Inleiding ... 4 5. Literatuur ... 8 5.1 Risicomanagement ... 9 5.2 Project management ... 10 6. Praktijkmodel ... 12 7. Methodologie ... 15 8. Resultaten... 17 9. Conclusie en discussie ... 19 10. Systeemdocumentatie... 20 11. Referentielijst ... 23
4
4. Inleiding
IT project risicomanagement in het MKB
In welke mate verschilt het IT project risicomanagement model van kleine IT projecten in het midden en klein bedrijf ten aanzien van grote IT projecten bij het grootbedrijf?
Doel van het onderzoek: Ontwikkel een model voor IT project risicomanagement in het MKB
In het begin van dit jaar werd het IT project SPEER van het Ministerie van Defensie beëindigd. Het project omvatte de ontwikkeling van een systeem voor Enterprise Resource Planning. De totale kosten van het grootste en langstlopende IT project van de rijksoverheid is vastgesteld op €433 miljoen. De Algemene Rekenkamer schat daarentegen dat het bedrag ongeveer twee keer zo hoog ligt (NRC, 2015). Het is maar de vraag of er een adequate risicoanalyse is gemaakt tijdens de start van project SPEER. De kosten zijn uiteindelijk veel hoger uitgevallen dan gebudgetteerd. Project SPEER is hierin echter geen uitzondering. Onderzoek door Harvard (2011) heeft aangetoond dat 1 op de 6 IT projecten 200% meer kost en 70% langer duurt dan begroot.
Het MKB is met een omvang van 57,8% van de totale economie, de grootste economische drijfveer binnen de Europese Unie (Europese Commissie, 2015). Daarnaast vormen MKB bedrijven ongeveer 99,8% van alle bedrijven in de Europese Unie en zijn ze verantwoordelijk voor 66,9% van de totale werkgelegenheid (Europese Commissie, 2015). Het grootste deel van de projecten en daarmee dus ook het management van deze projecten, wordt uitgevoerd binnen deze groep. Wanneer er in dit artikel over MKB bedrijven wordt gesproken, gebruiken we de accreditatie van de Europese Unie. De Europese Unie stelt de grens van een MKB bedrijf bij maximaal 250 werknemers in combinatie met een omzet van maximaal 50 miljoen of een balanstotaal van maximaal 43 miljoen (EUR Lex, 2003). Voor de specifieke categorisatie wordt verwezen naar tabel 1. Binnen de algemene en project management literatuur is echter nog weinig aandacht geweest voor MKB bedrijven.
Tabel 1: Categorieën MKB bedrijven.
Over het algemeen hebben MKB bedrijven toegang tot beperkte middelen in verhouding tot grote organisaties. Daarnaast kunnen veranderingen in wet- en regelgeving, modernisatie van het management of de organisatie of expansie naar andere markten tot gevolg hebben dat het noodzakelijk is dat er projecten worden ondernomen. Dit betekent dus dat er naast de standaard werkzaamheden, vaak projecten worden uitgevoerd om veranderingen door te voeren. Projecten binnen MKB bedrijven worden vaak uitgevoerd zonder gebruik van de algemene standaarden en door onervaren personeel (PMI, 2013). Het doel van dit ontwerpend onderzoek is een
risicomanagement model aan te dragen dat specifiek op deze situaties kan worden toegepast. Categorie Aantal werknemers Omzet of Balanstotaal
Midden < 250 ≤ € 50 m ≤ € 43 m Klein < 50 ≤ € 10 m ≤ € 10 m
Micro < 10 ≤ € 2 m ≤ € 2 m
5
Daarnaast worden ook kleinere organisaties net als grote organisaties in grotere mate afhankelijk van IT voor de bedrijfsvoering. De IT wordt gebruikt voor opslag van data van de organisatie en het efficiënt maken van processen. De meeste ondernemers in het MKB willen de IT zelf ontwikkelen om op die manier de controle ten aanzien van beslissingen te behouden. Deze ontwikkeling brengt voor de MKB ondernemers onbewust risico’s met zich mee ten aanzien van deze IT (itformule.nl, 2014). Door echter bij IT projecten de IT risico’s adequaat te beheersen, kunnen operationele doelstellingen ten aanzien van IT worden gewaarborgd (Tesch et al., 2007). Dit is de aanleiding om onderzoek te doen naar de mate waarin IT project risicomanagement model van kleine IT projecten in het MKB ten aanzien van grote IT projecten bij het grootbedrijf verschilt.
De vraagstelling van dit ontwerpend onderzoek kan als volgt worden geformuleerd;
In welke mate verschilt het IT project risicomanagement model van kleine IT projecten in het midden en klein bedrijf van grote IT projecten bij het grootbedrijf?
Doel van het onderzoek: Ontwikkel een model voor IT project risicomanagement in het MKB
Het meest bekende en gebruikte model binnen risicomanagement is het COSO model. Dit model is organisatie-breed georiënteerd en is volgens het COSO ERM rapport (2006): “ontworpen om potentiële gebeurtenissen die invloed kunnen hebben op de onderneming te identificeren en om risico’s te beheren zodat deze binnen de risicoacceptatiegraad vallen, om een redelijke zekerheid te bieden ten aanzien van het behalen van de ondernemingsdoelstellingen”. Het COSO model is zeer geschikt voor toepassing van risicomanagement binnen de organisatie maar is irrelevant voor de toepassing op projecten. Hieronder zal PMBOK worden behandeld, welke zich focust op algemene management praktijken voor risico’s binnen projecten.
De vijfde editie van de PMBOK, een algemene standaard voor projectmanagement, beschrijft project risico’s als gebeurtenissen of condities die een positief of negatief effect hebben op de doelstellingen van het project zoals kosten, doorlooptijd of kwaliteit (PMI, 2013). Olsson (2007) concludeert dat de toepassing van risicomanagement (door managers) positief wordt geassocieerd met het succes van projecten. Tot nu toe heeft empirisch onderzoek echter nog geen duidelijke relatie kunnen aantonen tussen risicomanagement en succes van projecten. De oorzaak hiervan is de veronderstellingen waarop dit empirisch onderzoek is gebaseerd, namelijk hoe risicomanagement zou moeten functioneren, over het algemeen niet toepasbaar zijn op de meeste IT projecten in de praktijk (de Bakker, Boonstra en Wortmann, 2010). In dit onderzoek zal een beter begrip worden gecreëerd van de praktijk van risicomanagement ten aanzien van IT projecten in het MKB.
Binnen de management literatuur focust het overgrote deel op grote IT projecten, terwijl er voor de kleinere IT projecten in het MKB nog te weinig management literatuur is geschreven. (Diab, 2010 & PMI, 2013). De definitie van IT projecten is in dit geval, software ontwikkelingsprojecten, die na implementatie, informatie voor de dagelijkse bedrijfsvoering, besluitvorming en management informatie verschaffen. (Dey et al., 2007).Onderzoek van Garg et al. (2010) stelt dat er nog geen standaarden voor de ontwikkeling van informatiesystemen in het MKB zijn ontwikkeld. Ook het PMI heeft aangegeven dat er onderzoek nodig is om PMBOK af te stemmen op het MKB (PMI 2013). Effectief project management is een vereiste voor het succes voor een IT project (Tesch et al., 2007). De technische aspecten zijn doorgaans van minder belang voor het succes van een IT project dan de management aspecten (Anderson, 1995). Volgens Vemor en Evanco (2005) heeft het
bedrijfsmanagement vaak weinig begrip voor de stappen die nodig zijn om een project succesvol te maken. Project managers worden uitgesloten van de eerste besprekingen en onderhandelen over de project eisen wordt niet toegestaan. Leung (2002) heeft onderzoek uitgevoerd naar factoren van goed management ten aanzien van IT projecten. In de eerste plaats staat in deze lijst van factoren
6
een individuele software project manager per project. In dezelfde lijst wordt ook de formele beoordeling van risico’s, voordelen en levensvatbaarheid genoemd. In de praktijk maakt slechts driekwart van alle organisaties gebruik van een dergelijke risicobeoordeling. Onderzoek (Standish Group, 2015) onder 50.000 IT projecten laat zien dat het succes-ratio van IT projecten met 29% nog onder het niveau ligt van het aantal organisaties dat gebruik maakt van een risicobeoordeling. Succesvol betekent in dit geval dat het project op tijd afgerond is, binnen budget en het gewenste resultaat heeft opgeleverd. Ditzelfde onderzoek laat zien dat de omvang van het project grote invloed heeft op het succes-ratio van het project. Managers moeten dus vooraf aan en gedurende de levensduur van het project risico’s inschatten om het aantal succesvolle projecten te laten
toenemen. Hierbij is het noodzakelijk dat managers begrijpen welke bijdrage risicomanagement kan leveren in het begrijpen en inschatten van risico’s. Dit ontwerpend onderzoek zal daarmee een bijdrage zijn in de al bestaande literatuur over effectief risicomanagement bij IT projecten. Onderzoek van Vemer en Evanco (2005) binnen financiële en verzekeringsinstellingen stelt dat risicomanagement de belangrijkste voorspellende factor is voor het succes van IT projecten. In de praktijk wordt dit echter door de meeste programmeurs en project managers als ook
bedrijfsmanagement gezien als het creëren van extra werk en kosten. Daarmee is risicomanagement ook de minst gebruikte discipline van project management. Als het bewustzijn bij zowel gebruikers als programmeurs en projectmanagers van IT ontstaat over de noodzaak van risicomanagement voor het succes van een project, zal dit leiden tot een bredere toepassing van risicomanagement bij de start en gedurende de levensduur van een project.
Onderzoek van Tesch et el. (2007) stelt dat de markt van de IT zich nog steeds ontwikkelt Het is dus noodzakelijk dat er onderzoek wordt gedaan naar de veranderende risico’s ten aanzien van IT projecten om een nieuwe strategie ten aanzien voor deze nieuwe risico’s te ontwikkelen. Dit onderzoek zal bijdragen aan de managementliteratuur over deze veranderende IT omgeving en risico’s.
Dit ontwerpende onderzoek is exploratief van aard en focust op een de combinatie van een project risicomanagement voor het MKB en de beschikbare literatuur op het gebied van IT risico’s. Yin (2003) geeft als definitie voor exploratief onderzoek: “het onderzoeken van een situatie waarbij een te evalueren interventie geen enkele of duidelijke uitkomsten heeft”. Een situatie die Yin (2003) noemt is de situatie waarbij er een bepaalde situatie onderzocht wordt waarbij de geëvalueerde interventie geen duidelijke uitkomsten heeft. De interventie is in dit geval een IT project risicomanagement model.
Om tot een goed model te kunnen komen zijn er een aantal functionele eisen opgesteld waaraan het model moet voldoen. Deze functionele eisen vormen de basis voor ontwerpend onderzoek.
Functionele eisen zijn een beschrijving van de prestatie die het product of de dienst moet leveren. Pas als éénduidig vaststaat aan welke functionele eisen voldaan moet worden, kan worden
overgegaan tot de ontwerpfase. Na het ontwerpen van het praktijkmodel, zal worden getest of het model aan deze functionele eisen voldoet. Dit zal getest worden na gebruik van het model door de opdrachtgever en eventuele toegewezen gebruikers. Er zal met de gebruiker worden gekeken naar de functionele eisen voor het model en met behulp daarvan eventuele positieve en verbeterpunten van het model worden vastgesteld. Door middel van de functionele eisen kan door de opdrachtgever worden getest of het model aan de gestelde eisen wordt voldaan. Deze positieven en
verbeterpunten zullen uiteindelijk ook de resultatensectie van dit onderzoek vormen. De eisen van het model zijn opgesomd in tabel 2.
7
Dit ontwerpende onderzoek bestaat uit verschillende onderdelen. Allereerst wordt ingegaan op de huidige literatuur door middel van een literatuuronderzoek. Het literatuuronderzoek bestaat in dit geval weer uit twee onderdelen. Allereerst wordt een overzicht gegeven van de huidige literatuur op het gebied van projectmanagement en ten tweede een overzicht van de huidige literatuur op het gebied van risicomanagement en IT risico’s. Hierna volgt het ontwikkelde praktijkmodel voor IT project risicomanagement in het MKB. Daarna zal de methodologie voor dit onderzoek worden behandeld. Hierna zullen de resultaten van het testen van het model worden gepresenteerd. Waarna uiteindelijk zal worden afgesloten met een conclusie en discussie.
Tabel 2
Functionele eisen voor het nieuwe IT project risicomanagement model voor het MKB
Het ondersteunt de DGA om een goed beeld te krijgen van de risico’s van een IT project. Het is duidelijk en makkelijk in gebruik, om obstakels als ervaring en training op te heffen. Het bestaat uit verschillende stappen waardoor het proces overzichtelijk wordt.
De stappen zijn efficiënt en effectief door de resultaat verwachtingen per stap duidelijk te definiëren.
Het levert een makkelijke en snelle documentatie van het risicomanagement op. Het houdt rekening met de karakteristieken van IT projecten.
Het houdt rekening met de karakteristieken van MKB projecten
Het is flexibel en kan voor verschillende IT projecten binnen het MKB worden ingezet. Het draagt bij aan de verspreiding van kennis, informatie en ervaring tussen de betrokkenen. Het zorgt voor een betere communicatie tussen betrokkenen over gebeurtenissen die de
ontwikkelingen van het project kunnen beïnvloeden.
Het gebruik van lessons-learned draagt bij aan het verbeteren van risicomanagement en het succesvol afsluiten van een project.
8
5. Literatuur
Over het algemeen wordt de groei van bedrijven geassocieerd met het behalen van doelstellingen en vooruitgang. In de meeste bedrijven wordt groei behaald met behulp van projecten (Retrato de las Pyme, 2011). MKB bedrijven ervaren obstakels bij de implementatie van projecten en dit is met name het geval voor situaties waarin kapitaal nodig is of toegang tot nieuwe technologieën moet worden verkregen (Galindo Lucas, 2004). Onderzoek van Rogers (2004) en Farinas (1994) heeft aangetoond dat de omvang van een organisatie een belangrijke factor vormt voor de ontwikkeling van het bedrijf. De verschillen worden met name zichtbaar als het gaat om investeringen, innovatie, internationalisatie en aantrekken van verschillende soorten kapitaal. Dit heeft een significant effect op de overlevingskans van een bedrijf.
Onderzoek naar de relatie tussen omvang van een bedrijf en innovatie heeft verschillende uitkomsten laten zien (Klomp en Van Leeuwen, 2001 & Loof en Heshmati, 2002). Verschillende empirische studies hebben aangetoond dat de relatie positief, negatief of insignificant kan zijn. In onderzoek van Hashi en Stojcic (2013) worden de industrie karakteristieken aangedragen als mogelijk verklarende factor voor deze verschillen in resultaten.
Het is nog niet aangetoond met behulp van onderzoek dat MKB bedrijven minder goed zijn in innoveren dan grootbedrijven. MKB bedrijven hebben vaak een sterke drang om te innoveren, maar zijn beperkt in kennis en middelen om deze projecten daadwerkelijk uit te voeren. Dat de innovatie bij MKB bedrijven over het algemeen efficiënter is dan bij grootbedrijven, neemt niet weg dat er nog steeds veel discussie is over de innovativiteit van MKB bedrijven (Lee et al., 2010). Er is in de
literatuur ook aandacht geweest voor de noodzaak van MKB bedrijven om toegang te krijgen tot bedrijfsnetwerken om de obstakels van beperkte middelen en technologie te overwinnen. Op die manier kunnen technologische kansen beter worden gebruikt (Chesbrough, 2003 & Tomlinson en Fai, 2013).
Er is een grote hoeveelheid literatuur beschikbaar op het gebied van project- en risicomanagement. Maar slechts een paar onderzoeken leggen de focus op MKB bedrijven. Onderzoek van Ghobadian and Gallear (1997) heeft een aantal verschillen gevonden tussen MKB bedrijven en grootbedrijven waardoor algemene project management methodologieën niet op elke organisatie toepasbaar zijn. De verschillen zijn door Turner et al. (2010) opgedeeld in vier punten:
Proces: In het MKB wordt gebruik gemaakt van eenvoudige planning en control systemen in combinatie met een informele wijze van rapporteren.
Procedures: In het MKB heerst een beperkte mate van standaardisatie en beslissingen worden op informele wijze genomen.
Structuur: Het niveau van specialisatie is beperkt maar het niveau van innovativiteit hoog. Mensen: De impact van de consequenties is groot, dus men heeft de voorkeur voor bekende
methodes.
Uit de punten ‘proces’ en ‘procedures’ kunnen we concluderen dat minder behoefte is aan
bureaucratie en meer ruimte voor flexibiliteit. De punten ‘structuur’ en ‘mensen’ impliceren dat er een sterke focus is op mensen en sterke mate van diversiteit in de taken in verschillende omgevingen wat leidt tot een beperkte mate van specialisatie (Turner et al, 2009). Bij IT project management wordt daarom door bedrijven de voorkeur gegeven voor “agile” project management, welke zeer interactief en flexibel is (Schwaber et al, 2004). Dit gegeven wordt door onderzoek van Standish group, (2015) bevestigd.
9
5.1 Risicomanagement
Risicomanagement is binnen projectmanagement het proces dat op systematische wijze de risico’s identificeert en beheerst. Met behulp van systemen en procedures kunnen risico’s worden
geïdentificeerd, geanalyseerd, geëvalueerd en gereageerd (Conroy & Soltan, 1998). Volgens Zhi (1994) kan er op vier manier worden gereageerd op risico’s die ontstaan bij een project. Namelijk ontlopen, reduceren, overhevelen, accepteren. De strategie die het meest gebruikt wordt is het reduceren van risico’s (Pritchard, 1997). De toepassing van risicomanagement moet bijdragen aan het vaststellen van projectdoelstellingen, beheersing van het project, succes verhogen,
communicatie tussen deelnemers verbeteren en besluitproces optimaliseren. (AFNOR, 2003 & Courtot, 1998).
Project systemen zijn van nature riskant en brengen verschillende soorten risico’s met zich mee. Dit maakt het lastig de risico’s te identificeren. Omdat het onmogelijk is alle risico’s vast te stellen, is het noodzakelijk de risico’s te groeperen (Marle, 2002). De impact van een mislukt project op het
resultaat kan bij MKB bedrijven erg groot zijn. De oorzaak ligt in veel gevallen in het feit dat een bepaald project niet aansluit bij de lange termijn strategie (Yen en Sheu, 2004). Er moeten methodes en hulpmiddelen worden ontwikkeld om de negatieve gevolgen te beperken (Marcelino-Sádaba en Pérez-Ezcurdia, 2010). Turner et al. (2009) stellen in hun onderzoek daarnaast nog dat de technieken die nodig zijn om project te managen verschillen van de management technieken die worden
gebruikt voor de dagelijkse gang van zaken.
Er is volgens Artiful et al. (2006) al veel literatuur beschikbaar over risico’s en risicomanagement. Ditzelfde onderzoek stelt dat in de meeste onderzoeken naar risico’s en risicomanagement de focus wordt gelegd op een speciale context waarin de gevolgen zeer schadelijk zijn voor mens of omgeving. Er zijn echter minder onderzoeken op het gebied van MKB bedrijven aangezien de gevolgen over het algemeen een minder omvangrijke impact hebben. De meeste onderzoeken bestaan uit een analyse die gelimiteerd blijft tot de identificatie, inschatting en priorisering van risico’s om daarmee
incidenten te voorkomen (Marhavilas et al., 2011 & Tixier et al., 2002) .
Het aantal studies op het gebied van project risicomanagement in het MKB zijn zeer beperkt en meestal alleen ontwikkeld voor organisaties die veel projecten uitvoeren (Aloini et al., 2007). Verschillende standaarden zijn ontwikkeld om de management van projecten te ondersteunen (Mostafa et al., 2011). Mostafa et al. (2011) heeft de verschillende standaarden vergeleken en is tot de conclusie gekomen dat er grote overeenkomsten zitten tussen de standaarden (zie figuur 1). De standaarden bestaan uit regels en voorschriften die helpen het maximale succes te behalen in het geval deze regelmatig worden toegepast (Sanchez et al., 2009). De mogelijkheid tot toepassing in het MKB is beperkt aangezien de standaarden grotendeels zijn gefocust op grote projecten.
Figuur 1; risicostandaarden / bron: Mostafa, 2011
Er zijn geen artikelen beschikbaar die kijken naar de risico
management modellen voor interne IT projecten. Wel één artikel, die specifiek in gaat op de ERP implementatie (Malhotra en Temponi, 2010). Daarom zal dit met behulp artikel getracht worden de literatuur op dit gebied aan te vullen.
10
5.2 Project management
Thomas en Mullaly (2008) hebben onder andere onderzoek gedaan naar het nut van project management. In dit onderzoek concluderen zij dat waarde gecreëerd wordt wanneer de gebruikte management praktijken, de aard van de moederorganisatie en de aard van een project op één lijn liggen (denk hierbij aan onzekerheid, complexiteit en snelheid). De traditionele manier van IT project risicomanagement gebruikt in het onderzoek van Thomas en Mullaly (2008) is echter niet geschikt voor het MKB. Ten eerste om het feit dat de projecten bij het MKB kleiner zijn dan bij grootbedrijven. Ten tweede omdat de cultuur bij kleine organisaties over algemeen verschilt van de cultuur bij grote organisaties. (PMI, 2013 & International Project Management Association, 2006 & Office of
Government Commerce, 2009 & Turner, 2009).
In 1996 is PMBOK (PMI, 2013) ontworpen om op het niveau van projecten risicomanagement te kunnen toepassen. PMBOK heeft tot doel de kans en impact van potentiële risico’s te minimaliseren en de kans en impact van potentiële kansen te maximaliseren. Het procesmatige model van PMBOK bestaat uit zeven stappen. In dit artikel wordt de methode van PMBOK voor het risicomanagement gebruikt. De zeven stappen waaruit dit proces bestaat, zijn als volgt (PMI, 2013):
1. Planning: Het besluitproces en uitlijnen van het risicomanagement inclusief de procedure. 2. Risico-identificatie: Het proces van het identificeren van mogelijke effectieve risicofactoren in
relatie tot de project doelstellingen, de kenmerken vaststellen en de uiteindelijke documentatie van de bevindingen.
3. Kwalitatieve analyse: De risico’s categoriseren naar prioriteit, van totaal niet belangrijk tot zeer belangrijk.
4. Kwantitatieve analyse: Het proces van de inschatting van impact en kans van de risicofactoren op de project doelstellingen.
5. Reactie op risico: Het proces van selecteren en vaststellen van reactie om de mogelijkheden te vergroten en de gevaren voor het project te verminderen.
6. Monitoren en controleren: Continue monitoren van geïdentificeerde, bestaande en mogelijk nieuwe risico’s.
7. Beheersen risico’s: Het risicomanagement plan biedt verschillende strategieën voor alle mogelijke risico’s en noodzaak in de perceptie van de stakeholders. Een dynamisch beheersingssysteem moet opgezet worden om de snelle keuzes te maken ten aanzien van risico evenementen.
De meeste MKB bedrijven hebben begeleiding nodig in het kiezen van een bepaalde project management methode (Turner et al., 2009). En de lijst met keuzemogelijkheden moet niet te lang zijn. Het model dat gebruikt wordt in dit onderzoek is van Marcelino-Sádaba et al. (2014). Dit model zal worden aangepast met behulp van de literatuur die over risico’s ten aanzien van IT beschikbaar is. Het model van Marcelino-Sádaba et al. (2014) is gebaseerd op AFNOR X50-117 (2009).
Het eerst onderdeel van het model bestaat uit een inschatting van de risico’s. Dit zijn de eerste vier stappen van het PMBOK model. De nadruk zou bij MKB bedrijven meer moeten liggen bij de kwalitatieve analyse omdat de priorisering van risico’s belangrijker is voor het model dan de inschatting van de impact op de doelstellingen. De verzamelde informatie moet makkelijk en snel gedocumenteerd kunnen worden om ook weer makkelijk en snel beschikbaar te zijn. De continue stroom van informatie of veranderingen binnen de organisatie kan inzicht geven in nieuwe risico’s. Het is belangrijk dat er een maandelijkse vergadering wordt gehouden waarin het management van het project de risico’s ten aanzien van het project bespreekt met als doel deze te beheersen.
11
Het tweede onderdeel van het model bestaat uit een risico-checklist en strategieën om met deze risico’s te dealen (zie bijlage Excel risicomap). De lijst is samengesteld uit de specifieke IT risico’s die Baccarini et al. (2004) hebben gevonden in de literatuur. Baccarini et al. (2004) hebben daarnaast ook onderzoek gedaan naar de meest gebruikte strategische reacties ten aanzien van deze risico’s. Het artikel van Baccarini et al. (2004) geeft daarnaast een opsomming van de tien belangrijkste en meest relevante individuele risico’s binnen IT projecten. De risico’s zijn opgesomd in tabel 3: risico ranking en strategische reacties.
Tabel 3: risico ranking en strategische reacties
De meest voorkomende problemen bij IT risicomanagement zijn slechte of het niet uitvoeren van risicoanalyses binnen organisaties (Remenyi, 1999). McFarlan (1981) stelt dat te weinig aandacht wordt geschonken aan individuele risico’s van projecten en de verschillende strategische methodes om de risico’s te beheersen. Managers focussen daarnaast over het algemeen alleen op een beperkt aantal oplossingen (Ocasio, 1997). Een risicolijst kan een relevante bijdrage leveren aan het beperken van deze problemen. Het is daarbij belangrijk te realiseren dat de aangedragen oplossingen slechts vanuit een bedrijfskundig perspectief worden aangedragen. Juridische oplossingen voor het vraagstuk worden daarbij dus niet in deze risicomap opgenomen. Het is echter wel belangrijk deze oplossingen niet uit te sluiten.
Rank Risico Strategische reactie
1 Persoonlijke tekortkomingen Middelen plannen / externen inschakelen 2 Onhaalbare project planning en budget Afwegen tussen kosten, tijd, kwaliteit en scope 3 Onhaalbare verwachtingen Voorstellen scannen / duidelijke eisen definiëren
4 Incomplete eisen Duidelijke scope en afkadering
5 Vergeven kansen door verlate levering van software
Strakke planning en planning management
6 Herhaalde veranderingen van eisen door klant
Formele verander management processen
7 Slechte kwaliteit van opgeleverde systemen Testen / bewijs van test bewaren 8 Slecht leiderschap Ervaren project manager aanstellen
9 Inadequate gebruikershandleiding Duidelijke eisen / gedurende project opstellen 10 Lage acceptatiegraad gebruikers Gebruikers trainen en ondersteunen
12
6. Praktijkmodel
Het IT project management voor het MKB is opgebouwd uit een aantal stappen. Deze stappen zijn op basis van de literatuur van PMBOK (2007) opgebouwd. In deze scriptie worden de stappen uit het onderzoek Marcelino-Sádaba, S. et al. (2014) als basis gebruikt voor het model aangezien dit een getest model is.
Project definiëren
De eerste stap binnen IT project management model is het selecteren en definiëren van een project. Er zijn veel verschillende criteria waarop een project geselecteerd kan worden maar het komt in bijna alle gevallen op de onderstaande drie punten neer:
- Het verwachte resultaat
- Voldoende middelen om het project te starten - Bijdragen aan de algemene bedrijfsstrategie
Het proces van project definitie bestaat uit een omgevingsanalyse, vaststellen van doelstellingen en het vaststellen van de strategische risico’s ten aanzien van deze doelstellingen (risicomap - project definitie).
Project plannen
Project planning bestaat uit de volgende stappen:
Definiëren van een risico management plan. Bij het definiëren van het risicomanagement plan gaat het om het vaststellen van vaste momenten om de risico-indicatoren te meten en het verdelen van deze taken.
Identificatie van operationele risico’s. Bij de operationele risico’s gaat het om risico’s die tijdens het uitvoeren van aan het project gerelateerde activiteiten direct kunnen ontstaan. Een goede risico-identificatie omvat de aspecten oorzaak, impactperiode, gevolgen,
evaluatie, reactieplan en verantwoordelijke persoon (Marcelino-Sádaba et al. 2014). Om het aantal fouten bij de identificatie te minimaliseren, wordt net als Marcelino-Sádaba et al. (2014) een lijst met veel voorkomende potentiële risico’s gebruikt.
Risico analyse en evaluatie. Met behulp van de lijst van risico’s kunnen specifieke IT risico’s als belangrijk worden aangemerkt. De lijst kan worden aangevuld met project-specifieke risico’s maar de algemene risico’s ten aanzien van IT projecten zijn al in het model opgenomen. Uiteraard moet er ook aandacht worden geschonken aan project-specifieke risico’s. Hiervoor is ruimte binnen de lijst met standaard IT project risico’s.
De inschatting van de mate van risico voor een project wordt gedaan met behulp van de heat map van ISO 31000 (2009). ISO 31000 (2009) heeft als voordeel dat duidelijke schalen
gedefinieerd zijn ten aanzien van de categorisering van risico’s. Deze schalen moeten uiteraard gezien worden in relatie tot de grootte van het project en kunnen naar inzicht worden aangepast. De categorisering is voor zowel de consequenties als kans vijfdelig, waardoor de keuze binnen de grenzen valt die in het onderzoek van Marcelino-Sádaba et al. (2014) worden aandragen. De risico’s worden met behulp van figuur 2 uiteindelijk opgedeeld in lage, middelmatig, hoog en kritische risico’s. De opdeling zal worden gebruikt tijdens de priorisering van de risico’s.
13
Figuur 2 Bron: ISO 31000:2009 Risk Matrix Project uitvoering
Met behulp van de risico inschatting en analyse zal de project manager een plan opstellen dat is gebaseerd op de vastgestelde risico’s. Daarbij is het belangrijk een verschil te maken in welke mate de te nemen acties belangrijk zijn. Zo wordt het succes van het project gegarandeerd.
Het is voor projectmanagers van belang zich te realiseren dat het risicorapport dat tijdens de analyse is gemaakt, een doorlopend document is waarin alle handelingen ten aanzien van de risico’s moeten worden bijgehouden. Alleen op die manier kan worden gerealiseerd dat in de fase van het leerproces duidelijk is welke fouten in de toekomst voorkomen moeten worden.
Monitoren en beheersen van risicostatus
Bij het monitoren en beheersen van risico status gaat het om de operationele risico indicatoren en strategische risico’s. Voor de manager is het van belang te aandacht te schenken aan vertragingen, budgetoverschrijdingen, niet afgeronde taken en taken die niet aan de eisen voldoen. Deze kunnen er op duiden dat er actie moet worden genomen en een inspectie is uiteraard noodzakelijk. Het moet duidelijk zijn wat de risico-indicatoren zijn, welke foutmarges acceptabel zijn en hoe vaak de indicateren gemeten moeten worden. Er wordt aangeraden drie tot zes indicatoren vast te stellen per risico. Foutmarges kunnen worden gesteld op gebied van budget, tijd en scope. De benodigde informatie voor deze indicatoren moeten gemakkelijk uit het huidige management systeem
14
onttrokken kunnen worden. Het aantal metingen is afhankelijk van de levensduur en zwaartekracht van het risico. Na het herzien van de risico’s kan er geen actie worden genomen, een nieuw actieplan worden opgesteld om de risico’s te beheersen of eventueel nader onderzoek worden gedaan.
Project risico communicatie
De communicatie omvat in dit geval de onderlinge uitwisseling van de informatie ten aanzien van monitoring van indicatoren en het updaten van de risico’s. Alle interne en externe partijen dienen hierbij betrokken te worden. Tijdens het definiëren van het project is de interne en externe communicatie gedefinieerd en hier kan tijdens het proces van communiceren op worden teruggevallen. Het is hierbij van belang dat de informatie tijdig naar de externe partijen wordt gecommuniceerd.
Afsluiting en evaluatie van project
De afsluiting van een project is een belangrijke fase die vaak wordt overgeslagen. Het eind van een project moet duidelijk worden afgebakend zodat het geen project zonder eind wordt. Een laatste vergadering zou moeten plaatsvinden om de officiële afsluiting van het project bekend te maken en het team te bedanken.
Project resultaat management. Resultaat management omvat identificatie en opslag van opgedane kennis. De kennis zou beschermd moeten worden om in de toekomst de kennis te kunnen hergebruiken. Wanneer derden betrokken zijn, moeten duidelijke afspraken worden gemaakt over gebruik van de kennis. Documentatie zal garanderen dat de resultaten op een gewenste manier worden gebruikt en verspreid aan degenen die daar recht toe hebben. In tabel 4 zijn alle fases van het model nogmaals opgenomen. Hierbij wordt aangegeven
welke activiteit bij deze fase hoort. De activiteiten zullen worden uitgevoerd met een vastgestelde techniek en dit zal resulteren in bepaalde documentatie.
Tabel 4: Fases in project management
Fase Activiteit Techniek Document
Definiëren Strategische risicoanalyse en evaluatie
Strategische risicolijst (risicomap -projectdefinitie)
Initial risk evaluation
Plannen Risico management planning
Planning template Risico planning Operationele risico analyse
en evaluatie
Operationele risicolijst (IT risico’s – risicomap)
Operationele risicolijst Definiëren indicatoren Indicatoren bepalen Indicatorenlijst
Uitvoeren & beheersen
Indicatoren herzien Indicatorenlijst Aangepaste indicatorenlijst Strategische acties Risicoplanning Aangepaste risicoplanning Strategische risico review Strategische risicolijst
(risicomap -projectdefinitie)
Geüpdate risicolijst
Afsluiting Besluit tot afsluiten project Vergadering
checklist risico’s t.a.v. resultaatmanagement
Project resultaat rapport
Toestemming Lessons learned template vergadering
Lessons learned
Bron: Tabel 2 Phases, activities, techniques and documents resulting from project management methodology in SMEs. P 335, Marcelino-Sádaba et al. (2014)
15
7. Methodologie
De dataverzameling van dit ontwerpende onderzoek heeft plaatsgevonden door middel van een kwalitatieve studie. Hierbij zullen kwalitatieve data worden verzameld ten aanzien van een drietal IT projecten binnen Nederlandse organisaties in verschillende stadia van ontwikkeling en waarbij de beslissingsbevoegdheid bij de directeur-grootaandeelhouder ligt. Er is gekozen voor drie
praktijkgevallen omdat er vanuit gegaan wordt dat meer praktijkgevallen geen extra toegevoegde waarde bieden voor de eindconclusie.
Dit onderzoek is een ontwerpend onderzoek. Voor ontwerpend onderzoek worden vooraf
functionele eisen opgesteld door de opdrachtopgever. Functionele eisen zijn een beschrijving van de prestatie die het product of de dienst moet leveren. Pas als éénduidig vaststaat aan
welke functionele eisen voldaan moet worden, kan worden overgegaan tot de ontwerpfase. Deze functionele eisen vormen de basis voor het ontwikkelen van de functionaliteit van het model. Het nut van het opstellen van functionele eisen is dat het model achteraf kan worden beoordeeld door de opdrachtgever in welke mate de verwachte functionaliteit in het model is opgenomen. Deze beoordeling van de functionele eisen vormt daarmee ook de basis voor de resultatensectie waar de test van de functionele eisen zijn opgenomen.
Voor de methodologie zijn de verschillen tussen ontwerpend onderzoek en empirisch onderzoek erg belangrijk. Schwarz (2009) beschrijft ontwerpend onderzoek als “het toevoegen van elementen uit de praktijk (construeren, gebruik, evaluatie en aanpassing van modellen) en de metakennis die de praktijk stuurt en motiveert”. Ons leerproces voor wetenschappelijk ontwerpen omvat twee
dimensies die de metakennis en elementen uit de praktijk combineren – wetenschappelijke modellen als instrumenten voor het voorspellen en uitleggen en modellen veranderen als inzicht toeneemt.“ (Schwarz, 2009). Het grootste verschil dus tussen empirisch en ontwerpend onderzoek is dus de praktijkelementen die zijn toegevoegd aan het onderzoek. Met de praktijkelementen kan theoretische kennis op die manier gebruikt worden om een in de praktijk opererend model te construeren. Empirisch onderzoek echter is alleen gefocust op de theorieontwikkeling om daarmee wetmatigheden te kunnen beschrijven vanuit een waarneming. De praktijkelementen worden daar niet in beschouwing genomen. Het is belangrijk hier te benoemen dat verschillende
onderzoeksgebieden ook verschillende ideeën hebben over ontwerpend onderzoek. Een ontwerpend onderzoek uit de natuur- of scheikunde zal een andere vorm aannemen dan de economische vorm. Echter één punt blijft gelijk aan beide vormen, namelijk dat er vooraf functionele eisen worden gesteld om achteraf te kunnen testen of het model aan de eisen van de opdrachtgever voldoet. Dit garandeert de (wetenschappelijke) contoleerbaarheid van het model.
De resultaten van een ontwerpend onderzoek is een model, in dit geval een praktijkmodel. De methodologie en resultatensectie zullen in dit geval bestaan uit het testen van het ontwikkelde praktijkmodel. Het doel van het testen van het praktijkmodel is het beoordelen in welke mate het ontwikkelde praktijkmodel aan de vooraf gestelde functionele eisen voldoet. Het testen bestaat uit het toepassen van het model op drie praktijkgevallen van verschillende omvang en met verschillende doelstellingen. De eerste stap van het testen is het toepassen van het model op het project door een gebruiker. De tweede stap is de gebruiker te laten beoordelen of het model aan de vooraf opgestelde functionele eisen voldoet door middel van een checklist (checklist.xlsx). De laatste stap is het
documenteren van goede en verbeterpunten van de gebruiker op het model.
In een ideale situatie zal er een test worden gedaan over de gehele looptijd van een project waarbij risicomanagement wordt uitgevoerd op de individuele risico’s. De tijdspan waarin dit onderzoek
16
geschreven moet worden, laat het echter niet toe dat er een test wordt gedaan over de hele ontwerpcyclus van een project. Een ontwerpcyclus bestaat meestal uit vier stappen, namelijk initiatie, plannen, uitvoeren en afsluiting en heeft vaak een doorlooptijd van enkele maanden. Het is voor dit onderzoek alleen mogelijk het risicomanagement model op één moment te testen in drie verschillende casussen. Dit vormt daarmee een beperking voor dit onderzoek. Tijdens het testen van het model wordt deze levenscyclus wel in acht genomen en indien nodig de toepassing van het model in historisch of toekomstig perspectief bekeken.
Het doel van valideren is bepalen of het model in de realiteit toepasbaar is voor het doel waarvoor het ontwikkeld is. Dit proces bestaat uit het vergelijken van de functionele eisen met de resultaten onder vooraf vastgestelde omstandigheden. Dit betekent echter niet dat het model op alle mogelijke casussen toepasbaar is. Een significant verschil tussen de functionele eisen en de resultaten heeft tot gevolg dat het model beter afgestemd moet worden. Dit kan leiden tot verschillende aanpassingen van het model (Yin, 2003).
Door middel van interne validatie wordt in dit onderzoek bepaald in welke mate er wordt gemeten wat we willen meten (Smith, 2015). Lillis (2006) concludeert dat voor case studies geen
controlegroep aanwezig is waardoor het lastig is om dergelijk onderzoek te valideren. De validiteit in dit onderzoek voor het model wordt allereerst gewaarborgd met behulp van triangulatie, oftewel het gebruik van verschillende bronnen uit de theorie bij het opstellen van het model. De tweede
methode is de beoordeling door participanten van dit onderzoek over de mate waarin het model aan de vooraf gestelde functionele eisen voldoet, waarbij de onderzoeker de rol van niet participerende observant inneemt. Met beide methodes wordt ook de onafhankelijkheid van de onderzoeker gewaarborgd (Smith, 2015).
In de volgende sectie zullen de resultaten van de test worden beschreven. De resultaten van het testen van het model zullen allereerst bestaan uit de checklist met een beoordeling van de
functionele eisen van het model volgens de gebruiker. We zullen daarmee een beoordeling van de gebruiker over het model kunnen geven in combinatie met een beschrijving van eventuele varianties in waardering van het model tussen de drie casussen. Daarnaast is er een beperkte hoeveelheid kwalitatieve data ten aanzien van het model verzameld. Deze kwalitatieve data zijn opgenomen in de vorm van goede en verbeterpunten van het model.
17
8. Resultaten
Beschrijving praktijkgevallenHet eerste praktijkgeval X is een groothandel in groente en fruit. Zij hebben opdracht gegeven aan een externe partij tot het bouwen van een nieuwe business information omgeving. Het project is klein van omvang met een kostenpost van €10.000 en een projectgroep bestaande uit vier leden. Het project is niet vooraf beoordeeld door middel van een risicoanalyse.
Het tweede praktijkgeval Y is een specialist op het gebied van water en lucht. Het huidige project omvat de her-implementatie van AFAS en is van middelgrote omvang. De projectgroep bestaat uit tien personen met een bestuur bestaande uit vier personen. De projectkosten zijn begroot op ongeveer €50.000 exclusief licenties. Het project is niet vooraf beoordeeld door middel van een risicoanalyse.
Het derde praktijkgeval Z is een landelijke organisatie op het gebied van rechtsbijstand. Het huidige project omvat de implementatie van een standaard systeem van Canon voor ondersteuning van primaire en secundaire processen. Dit omvat document management, urenregistratie, casus- en financiële registratie en de boekhouding ten aanzien van inkoop, verkoop en financieel overig. Het gaat hier om een project van grote omvang en heeft een doorlooptijd van anderhalf jaar. De projectgroep bestaat uit twintig personen. De kostprijs van het project is begroot op een totaal van €2,7 miljoen. Het project is vooraf beoordeeld door middel van een risicoanalyse.
Uit de resultaten in tabel 5 blijkt dat het praktijkgeval X oftewel het kleine project de hoogste score genereert voor het risicomanagement model met tien van de elf eisen. Zowel het middelgrote als het grote model geven een score van acht van de elf eisen aan het risicomanagement model. Daarnaast blijkt uit deze resultaten ook dat het stimuleren van de communicatie binnen het project nog een verbeterpunt is voor het model.
Tabel 5; resultaten
Gebruiker X Y Z
Functionele eisen voor het nieuwe IT project risicomanagement model voor het MKB 1 / 0
Het ondersteunt de DGA om een goed beeld te krijgen van de risico’s van een IT project. 1 1 0
Het is duidelijk en makkelijk in gebruik, om obstakels als ervaring en training op te heffen. 1 1 1
Het bestaat uit verschillende stappen waardoor het proces overzichtelijk wordt. 1 1 1
De stappen zijn efficiënt en effectief door de resultaat verwachtingen per stap duidelijk te
definiëren. 1 0 1
Het levert een makkelijke en snelle documentatie van het risicomanagement op. 1 0 1
Het houdt rekening met de karakteristieken van IT projecten. 1 1 1
Het houdt rekening met de karakteristieken van MKB projecten 1 0 1
Het is flexibel en kan voor verschillende IT projecten binnen het MKB worden ingezet. 1 1 0
Het draagt bij aan de verspreiding van kennis, informatie en ervaring tussen de betrokkenen. 1 1 1
Het zorgt voor een betere communicatie tussen betrokkenen over gebeurtenissen die de
ontwikkelingen van het project kunnen beïnvloeden. 0 1 0
Het gebruik van lessons-learned draagt bij aan het verbeteren van risicomanagement en het
succesvol afsluiten van een project. 1 1 1
18 Goede punten (X)
De opzet dwingt je om volgens een soort van vast schema langs alle belangrijke punten te lopen. Hierdoor raak je met de klant in gesprek over mogelijke risico's die anders niet direct aan de orde zouden komen.
Verbeterpunten (X)
Als wij bij een IT project met een risicoanalyse aankomen dan zal men dat in eerste instantie direct schrappen om kosten te besparen.
Bij kleine bedrijven is het slim om risicomanagement commercieel anders in te kleden.
Ik vind dat wij als organisatie dit standaard wel uit moeten voeren maar misschien niet als dus danig moeten benoemen in de offerte.
Goede punten (Y) Eenvoudig in gebruik
Biedt uiteindelijk best practice voor ons Communicatiemiddel is het erg geschikt voor Snel/efficiënt uit te voeren
Verbeterpunten (Y)
Meer inspelen op communicatie
Projectstructuur betrekken in je model: overlegstructuren / taken en verantwoordelijkheden / juiste bemensing
Projectdefinitie toevoegen: hoe zorg ik dat alle externe partijen betrokken worden?
Goede punten (Z) Overzichtelijk
Makkelijk te gebruiken Geeft inzicht
Verbeterpunten (Z)
Digitaal keuzes aanvinken waardoor heat map wordt ingevuld Goed meenemen door model (voorbeeld digitaal invullen) Betere gebruiksaanwijzing
Bovenstaande kwalitatieve data omvat de goede en verbeterpunten ten aanzien van het model aangedragen door de gebruikers van het model. De verbeterpunten bij Y en Z aangaande communicatie, projectstructuur, projectdefinitie externe partijen en gebruiksaanwijzing zijn inmiddels in het model van dit onderzoek verwerkt. Hiervoor wordt terugverwezen naar het onderdeel praktijkmodel in dit artikel.
De constatering bij de verbeterpunten van X is dat MKB ondernemers vaak het nut van
risicomanagement niet inzien. Als verbeterpunt wordt aangedragen om risicomanagement mogelijk commercieel anders aan te kleden. Dit probleem vormt ook één van de aanleidingen voor dit onderzoek. Een verband ligt hier met de verbeterpunten van gebruiker Z. Deze gebruiker stelt een gedigitaliseerde en interactieve vorm voor van het huidige papieren risicomanagement model voor om het gebruiksvriendelijker, toegankelijk en laagdrempelig te maken.
19
9. Conclusie en discussie
De resultaten laten zien dat met behulp van dit onderzoek en het ontwikkelde model, het
makkelijker en beter bereikbaar is geworden voor het midden- en kleinbedrijf om risicomanagement toe te passen op IT projecten. Het is belangrijk voor de directeur grootaandeelhouder zich te
realiseren dat risicomanagement onderdeel is van effectief projectmanagement. De resultaten van dit onderzoek bevestigen dat een vergrote toepassing van risicomanagement binnen projecten in het midden- en kleinbedrijf noodzakelijk is. Daarnaast illustreert dit onderzoek hoe, met behulp van het model uit dit onderzoek, risicomanagement kan worden toegepast op IT projecten. De theorie op het gebied van risicomanagement van IT projecten in het midden- en kleinbedrijf was voorafgaand aan dit onderzoek zeer beperkt. Dit onderzoek is een handreiking aan andere onderzoekers die zich willen richten op risicomanagement of projectmanagement in het midden- en kleinbedrijf. Dit ontwerpend onderzoek had tot doel het ontwikkelen van een risicomanagement model voor IT projecten in het midden- en kleinbedrijf. Het ontwikkelde model uit dit onderzoek is getest aan de hand van vooraf opgestelde functionele eisen. Het resultaat van deze testen laat zien dat het model met een minimumscore van acht van de elf eisen volgens de gebruikers in meerdere mate aan de functionele eisen voldoet. De verbeterpunten die de gebruikers aandragen ten aanzien van het model zijn verwerkt in het huidige model in dit onderzoek. Het laatste verbeterpunt ten aanzien van de digitalisering van het model is niet in dit model verwerkt. Het is voor de opdrachtgever van het model makkelijk een digitale interactieve vorm van het huidige model te ontwikkelen. Dit
verbeterpunt zullen wij daarom ook overdragen aan de opdrachtgever voor eventuele toepassing in de toekomst.
De eerste beperking van dit onderzoek is de toepassing van het model in de praktijk op een beperkt aantal praktijkgevallen. De generaliseerbaarheid van het model is daarmee beperkt. Ten tweede is het model tijdens drie lopende projecten toegepast en niet gedurende de hele levenscyclus van een project. Dit vormt een beperking voor dit onderzoek aangezien het model is ontwikkeld om
gedurende de levenscyclus van een project te worden toegepast. Projecten hebben vaak een levenscyclus van enkele maanden en deze tijdspan was voor dit onderzoek niet haalbaar. Als suggestie voor nieuw onderzoek dragen wij dan ook aan om het model uit dit onderzoek toe te passen op de volledige levenscyclus van een project om daarmee het model uitvoeriger te testen. De derde beperking is dat het hier gaat om ontwerpend onderzoek. De uitkomst van ontwerpend onderzoek is een model. De beperking bij het ontwerpen van een dergelijk model, is dat
verschillende onderzoekers met verschillende modellen zullen komen. Het model in dit onderzoek is slechts één model. Er is niet één juist model op basis van de functionele eisen op te stellen. Een aanbeveling op basis van dit onderzoek voor nieuw onderzoek zou zijn om ook deze functionele eisen voor het model op basis van de literatuur op te stellen.
Met het afsluiten van dit ontwerpend onderzoek wordt dit onderzoek overhandigt aan de opdrachtgever. Bij het overhandigen van het model en de systeemdocumentatie accepteert de opdrachtgever de uitwerking van de opdracht. Het model bevat documentatie (zie de
systeemdocumentatie) om de bruikbaarheid in de toekomst te kunnen blijven garanderen. In de documentatie is kort uitgelegd hoe het model dient te worden toegepast. Om de anonimiteit van de deelnemers te kunnen garanderen, zijn er geen namen opgenomen in dit onderzoek. De namen liggen ter inzage bij de onderzoeker en kunnen ten allen tijde worden ingezien. In verband met de vertrouwelijkheid van dit onderzoek is dit onderzoek niet beschikbaar voor publicatie. Daarnaast ligt het intellectueel eigendom van dit model bij Baker Tilly Berk N.V. te Gouda.
20
10. Systeemdocumentatie
Bijlage ter informatie voor de toepassing van het risicomanagement model.Het model bestaat uit een tweetal bestanden. Allereerst de pagina’s praktijkmodel uit dit Word bestand en ten tweede de Excel sheet met de tabbladen projectdefinitie en risicomap. Het Word bestand is de basis van het model en verwijst tijdens de verschillende stappen naar het Excelbestand en het desbetreffende tabblad.
De toepassing van het model begint met het doorlopen van de stappen van het model zoals weergegeven in dit Word bestand. De verschillende stappen zijn ook te vinden in tabel 4. Tabel 4 geeft een duidelijk overzicht van de stappen, methodes en documenten die benodigd zijn of
voortkomen uit het doorlopen van de stappen van het model. Elke stap bevat een toelichting waarin kort omschreven staat wat er van de gebruiker verwacht wordt. Soms is de stap opgedeeld in enkele sub stappen om het proces handbaar te houden. Het uitwerken van het risicomanagement vindt plaats door het doorlopen van de verschillende stappen en het vastleggen van uitkomsten van de verschillende stappen. Hieronder wordt kort beschreven wat precies hoe elke stap van het model precies werkt.
Project definitie:
Bij de face project definitie wordt van de gebruiker verwacht dat deze in het Excel bestand het tabblad project definitie doorloopt (zie afbeelding). Het is hierbij van belang dat de punten in chronologische volgorde worden afgewerkt om te komen tot een volledige project definitie. Met behulp van een groen of rood vakje kan worden aangegeven wel of niet aan de voorwaarde voldaan wordt bij het definiëren van het project. De voorwaarden met rode vakjes moeten worden
verhelderd voor men overgaat tot de volgende set met voorwaarden. Het vakje resultaat mag pas groen worden gemaakt wanneer aan alle bovenstaande voorwaarden wordt voldaan.
21 Project planning:
De eerst stap is hier vaststellen door de gebruiker op welke vaste momenten de indicatoren gaan worden gemeten om daarmee een planning te vormen. Van de gebruikers van het model wordt verwacht dat zij zelf een planning opstellen, dit model bevat dus geen vaste planningstemplate. De tweede stap is het vaststellen van de operationele risico’s voor het project met behulp van de risicomap in het Excel bestand (zie afbeelding). Deze risicomap kan dus naar eigen inzicht worden aangevuld met specifieke operationele risico’s voor het desbetreffende project. Om de gebruiker te helpen zijn al een aantal standaard IT risico’s in de risicomap opgenomen (kolom C). De IT risico’s worden allereerst opgedeeld per risicogroep (kolom B). In de risicomap zijn een zevental
standaardgroepen opgenomen. Uiteraard kan naar eigen inzicht een groep worden verwijderd of toegevoegd. De operationele risico’s worden daarna beoordeeld en geprioriteerd met behulp van de heat map (kolom D). De heat map van ISO geeft een duidelijk categorisering van de impact en kans van risico’s. Uiteraard dient elke organisatie deze categorisering voor zichzelf in te vullen. De volgende stap is het vaststellen van de strategische reacties ten aanzien van de risico’s (kolom E/F/G). Op die manier is het voor alle betrokkenen in het project duidelijk op welke manier het risico gemitigeerd gaat worden. Om ook de voortgang van deze mitigatie van risico’s te monitoren wordt van de gebruikers verwacht dat zij aangeven voor welke risico’s nog actie vereist is (kolom H). Als laatste worden de indicatoren van de risico’s vastgesteld. De indicatoren vormen een onderdeel van de planning en worden op vaste vooraf vastgestelde momenten gemeten. De indicatoren kunnen eventueel worden vastgelegd in de risicomap om de relatie tussen het risico en de indicator te documenteren. Het uiteindelijke resultaat na deze fase, is een volledige risicoanalyse en -planning.
Project uitvoering en beheersing:
De uitvoering van het risicomanagement door de gebruiker loopt parallel aan het project. Het is hier van belang dat de gebruiker de risico’s uit de risicomap monitort en beheerst door de planning te volgen en indien nodig de strategische reacties uit te voeren. Eventueel kan de risicomap worden herzien door de gebruiker om de risico’s up-to-date te houden. Daarnaast dient de interne en externe communicatie te worden uitgevoerd zoals deze is vastgesteld in de fase projectdefinitie. Op die manier blijven alle partijen betrokken bij het project en blijven de noodzakelijke
22 Project Afsluiting
Dit onderdeel bestaat uit de evaluatie van het risicomanagement van het project. De lesson’s learned worden verzameld en aan het eind van het traject bij de evaluatie besproken. Daarnaast kan hierbij achteraf worden gekeken naar de werking van de risicoanalyse en -planning. Eventuele
verbeterpunten kunnen in het volgende project worden meegenomen. Ook kan er tijdens de afsluitende vergadering worden bepaald wat met eventuele resultaten van het project zal worden gedaan. In sommige gevallen heeft het eindproduct van een project nog waarde.
23
11. Referentielijst
AFNOR, (2003). Norma FD X 50-117 Management des Risques d'un Project, Avril, ISSN:0335-3931. Aloini, D., Dulmin, R., Mininno, V., (2007). Risk management in ERP project introduction: review of the literature. Information Management, 44, p. 547–567.
Anderson S.W. (1995). A Framework for Assessing Cost Management System Changes: The Case of Activity Based Costing Implementation at General Motors, 1986-1993. Journal of Management Accounting Research, 7, p. 1-51.
Artiful, I., Tedford, J.D., Haemmerle, E., (2006). Strategic risk management approach for small and medium-sized manufacturing enterprises (SMEs). A Theoritical Framework: IEEE International Conference on Management of Innovation and Technology, 2 (21–23 June).
Baccarini D., Salm G., Love P.E.D. (2004). Management of risks in information technology projects. Industrial Management & Data Systems, 104(4), p. 286-295.
de Bakker, K., Boonstra, A., en Wortmann, H. (2010). Does risk management contribute to IT project success? A meta-analysis of empirical evidence. International Journal of Project Management, 28, p. 493-503.
Chesbrough, H.W., (2003). The logic of open innovation: managing intellectual property. California Management Review 45(3), p. 33.
Conroy, G., Soltan, H., (1998). ConSERV, a project specific risk management concept. International Journal of Project Management 16(6), p. 353–366.
COSO (2004). Enterprise Risk Management — Integrated Framework Executive Summary. Retrieved from: http://www.coso.org/documents/coso_erm_executivesummary.pdf.
Courtot, H., (1998). La gestion des risques dans les projects. Edition Economica. 2-7178-3692-6, p. 294.
Dey P. K., Kinch J., Ogunlana S., O., (2007). Managing risk in software development projects: a case study. Industrial Management & Data Systems, 107 (2), p. 284-303
Diab, P.R. (2010), “Project management for small to medium-sized organizations”. Retrieved from: www.linkedin.com/groups?featured¼&gid¼3618297&goback¼%2Egmp_3618297.
Europese Commissie, (2015). SME Performance Review. Retrieved from:
http://ec.europa.eu/growth/smes/business-friendly-environment/performance-review/index_en.htm#t_0_0.
EUR lex. (2003). - Commission Recommendation of 6 May 2003 concerning the definition of micro, small and medium-sized enterprises. Retrieved from::
http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32003H0361.
Fariñas, J.C. (1994). Importancia y dinámica de las Pyme industriales. Estrategias diversas,
diagnósticos específicos. Revista TELOS: Cuadernos de Comunicación, Tecnología y Sociedad 40 (Dec 1994 – Feb 1995).
Galindo Lucas, A. (2004). El tamaño empresarial como factor de diversidad. Electronic edition. Retrieved from: http://www.eumed.net/libros/2005/agl3.
24
Garg, A., Goyal, G.P. & Lather, A.S. (2010). The influence of the best practices of information systems development on software SMEs: a research scope. International Journal of
Business Information Systems, 5(3), p. 268-90.
Ghobadian, A. & Gallear, D. (1997) TQM and organisation size. International Journal of Operations and Production Management, 17, p. 121-63.
Harvard business review, (2011). Why your IT project may be riskier than you think. Retrieved from: https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1.
Hashi, I., Stojcic, N., (2013). The impact of innovation activities on firm performance using a multi-stage model: evidence from the community innovation survey 4. Research Policy, 42, p. 353–366. International Organization for Standardisation, 2009. ISO 31000:2009.
International Project Management Association (IPMA), 2006. The IPMA Competence Baseline, ICB 3.0. IPMA, The Netherlands.
ITformule.nl (2014) Retrieved from: https://www.itformule.nl/mkb-ondernemers-nemen-onbewust-risico-met-eigen-automatisering/.
Klomp, L., Van Leeuwen, G., (2001). Linking innovation and firm performance: a new approach. International Journal of the Economics of Business, 3, p. 343-364.
Lee, S., Park, G., Yoon, B., Park, J., (2010). Open innovation in SMEs - an intermediated network model. Research Policy, 39, p. 290–300.
Leung, H. (2002). Organizational factors for successful management of software development. Journal of Computer Information Systems, 42(2), p. 26-37.
Lillis, A.M., 2006. Reliability and validity in field study research. In Z. Hoque (ed.), Methodological issues in accounting research: theories and methods. Spiramus Press, London: p. 461-475. Loof, H., Heshmati, A., (2002). Knowledge capital and performance heterogeneity: a firm-level innovation study. International Journal of Production Economics, 76, p. 61–85.
Malhotra, R., Temponi, C., (2010). Critical decisions for ERP integration: small business issues. International Journal of Information Management, 30, p. 28–37.
Marcelino-Sádaba, S., Pérez-Ezcurdia, A., (2010). Gestión del riesgo en proyectos abordados por Pymes. Dyna, 85(6), p. 504-512.
Marcelino-Sádaba, S., Pérez-Ezcurdia, A., Echeverría Lazcano A.M., Villanueva P. (2014). Project risk management methodology for small firms. International Journal of Project Management, 32, p. 327– 340.
Marhavilas, P.K., Koulouriotis, D., Gemeni, V., (2011). Risk analysis and assessment methodologies in the work sites: on a review, classification and comparative study of the scientific literature of the period 2000–2009. Journal of Loss Prevention in the Process Industries, 24, p. 477–523.
Marle, F., (2002). Modele d'informations et methodes pour aider a la prise de decision en anagement de projets. (Ph.D. Thesis) Ecole Centrale Paris, Paris.
25
McFarlan, F.W. (1981). Portfolio approach to information systems. Harvard Business Review, 142, p. 142-150.
Mostafa J., Rezaeenour J., Mahdavi M. M., Hooshmandi, A., (2011). Development and evaluation of a knowledge risk management model for project-based organizations. Management Decision, 49(3) p. 309-329.
NRC (2015). Defensie stopt met ontwikkeling duurste automatiseringssysteem ooit. Retrieved from: http://www.nrcq.nl/2015/05/02/defensie-stopt-met-ontwikkeling-duurste-automatiseringssysteem-ooit.
Ocasio, W. (1997). Towards an attention based view of the firm. Strategic Management Journal, 18, p. 187–206.
Office of Government Commerce OCG UK, 2009. PRINCE2R — Projects in Controlled Environments. OCG, UK.
Olsson, R. (2007). In search of opportunity management: Is the risk management enough? International Journal of Project Management, 25, p. 745–752.s
PMI, (2013). A Guide to the Project Management Body of Knowledge a.k.a. PMBOK Guide. 5th edition.
Pritchard, C.L. (1997). Risk Management – Concepts and Guidance, ESI International, Arlington. Remenyi, D. (1999). Stop IT Project Failures through Risk Management, Computer Weekly Series, Butterworth Heinemann, Oxford.
Retrato de las Pyme (2011). Dirección general de Política de la Pequeña yMediana Empresa, Ministerio de Industria, Turismo y Comercio Subdirección general de fomento empresarial. Rogers, M. (2004). Networks, firm size and innovation. Small Business Economics, 22, p. 141-153. Sanchez, H., Robert, B., Bourgault, M., Pellerin, R., (2009). Risk management applied to projects, programs, and portfolios. International Journal of Managing Projects in Business, 2(1), p. 14–35. Schwaber, K., (2004). Agile Project Management with Scrum. Microsoft Press, Redmond.
Schwarz, C.V., Reiser, B.J. Davis, E.A., Kenyon, L., Acher, A., Fortus, D., Shwartz, Y., Hug, B., Krajcik J., 2009. Developing a Learning Progression for Scientific Modeling: Making Scientific Modeling
Accessible and Meaningful for Learners. Journal of research in science teaching, 46(6) p. 632-654. Smith M., 2015. Research methods in accounting 3rd edition. Sage, Los Angeles, p. 33-34.
Standish group, (2015). Chaos report. Retrieved from: http://www.infoq.com/articles/standish-chaos-2015
Tesch D., Kloppenborg T.J., Frolick, M.N. (2007). IT projects risk factors: The project management professionals perspective. Journal of Computer Information Systems, 47(4) p. 61-69.
Thomas, J.L. & Mullaly, M. (2008). Researching the Value of Project Management. Project Management Institute, Newtown Square.
Tixier, J., Dusserre, G., Salvi, O., Gaston, D., (2002). Review of 62 risk analysis methodologies of industrial plants. Journal of Loss Prevention in the Process Industries, 15, p. 291–303.
26
Tomlinson, P.R., Fai, F.M., (2013). The nature of SME co-operation and innovation: a multi-scalar and multi-dimensional analysis. International Journal of Production Economics, 141(1), p. 316–326. Turner R., Ledwith A., Kelly J., (2009). Project management in small to medium-sized enterprises: Matching processes to the nature of the firm. International Journal of Project Management, 28, p. 744-755.
Turner, J.R., Ledwith, A., Kelly, J., (2010). Project management in small to medium-sized enterprises: matching processes to the nature of the firm. International Journal of Project Management, 28 (8), p. 744–755.
Vemor, J.M. & Evanco, W.M. (2005). In-House Software Development: What Project Management Practices Lead to Success? IEEE Software, 22(1), p. 86-92.
Yen, H.R., Sheu, C., (2004). Aligning ERP implementation with competitive priorities of manufacturing firms: an exploratory study. International Journal of Production Economics, 92, p. 207–220.
Yin, R. K. (2003). Case study research: Design and methods (3rd ed.), Sage Publishing, Thousand Oaks. Zhi (1994). Risk management for overseas construction projects. International Journal of Project Management, 13(3), p. 231-237.
