LESSEN UIT FALENDE EN SUCCESVOLLE ICT-PROJECTEN

Transcriptie

1 Projectmanagement: LESSEN UIT FALENDE EN SUCCESVOLLE ICT-PROJECTEN CONTROLLERS MOETEN VANAF DE START EEN ROL SPELEN 40 Aaron Kohr: beeld

2 ICT-projecten hebben een negatief imago: ze zijn te duur, te laat gereed en ze missen de gewenste functionaliteit. Aangezien de investeringen in ICT-innovaties alleen nog maar zullen toenemen de komende jaren, is het goed te leren van de fouten bij het projectmanagement. Bisnez Management onderzocht daarom welke hobbels en valkuilen bedrijven in de praktijk tegenkomen bij dit soort projecten. Een van de conclusies is dat het essentieel is de controller nadrukkelijker te betrekken bij de investeringsbeslissing. Ing. Norman Martijnse en drs. Peter Noordam: Wat maakt een project succesvol? Hierover bestaan veel theorieën, maar in essentie kunnen we zeggen dat een succesvol project voldoet aan drie factoren: het voldoet aan de vooraf overeengekomen functionaliteit, het wordt op tijd geleverd en het wordt geleverd binnen het afgesproken budget. Wanneer deze drie factoren met elkaar in balans zijn, kunnen we spreken over een succesvol project. Uit diverse onderzoeken is de laatste jaren duidelijk geworden dat het op tijd en binnen budget opleveren van de beoogde functionaliteit een moeizame aangelegenheid is en dat falende projecten veel geld kosten. In 2003 werd het verlies als gevolg van falende projecten binnen de Europese gemeenschap geschat op 140 miljard dollar. 1 In een onderzoek van KPMG 2 onder 252 controllers gaven de respondenten als belangrijkste redenen voor het mislukken van projecten: 1. gebrekkig projectmanagement (32 procent); 2. gebrek aan communicatie in en rond het project (20 procent); 3. doelstellingen niet gedefinieerd (17 procent); 4. onbekendheid met scope en complexiteit (17 procent); 5. technische complexiteit en technische integratie-issues (7 procent); 6. overig (7 procent). Noten 1 C. Verhoef (2006). 290 miljard dollar kwijt aan falende IT, Automatisering Gids. 2 KPMG (2004). Programmamanagement leidt tot betere projectresultaten. Wij stelden ons de vraag hoe het anno 2007 is gesteld met de tevredenheid over projecten en of het mislukken van projecten nog steeds wordt geweten aan genoemde factoren. Daarbij vroegen wij ons af wat we kunnen leren van falende en geslaagde ICTprojecten. Wij besloten tot een projectmanagementonderzoek om handvatten te krijgen voor succesvolle projectuitvoering, gebaseerd op inzicht in de succes- en faalfactoren van ICT-projecten. Onderzoeksopzet Het onderzoek is door middel van een enquête in de periode oktober tot en met december 2006 uitgevoerd. De vragenlijst is uitgezet bij circa 3000 ITprofessionals (managers, projectmanagers en ITspecialisten) in Nederland en kende ruim 230 respondenten. Twee teams studenten van de Vrije Universiteit hebben de enquêteresultaten verwerkt en getoetst aan andere onderzoeksgegevens. De tussenresultaten zijn in een aantal brainstormsessies, waaraan ook een selectie van de geënquêteerden deelnam, geanalyseerd. De eindresultaten zijn samengevat in een rapport dat te downloaden is op Aangezien resultaat moeilijk te onderzoeken valt immers, resultaat heeft te maken met het realiseren van de vooraf vastgelegde doelstellingen (baten) van een project hebben we ons voor de beantwoording van de enquête vooral laten leiden door de mate van tevredenheid over projecten. Tevredenheid is meer kwalitatief en geeft een gevoel weer bij het project. In het onderzoek is de respondenten gevraagd hun tevredenheid over de projecten in hun organisatie weer te geven met een rapportcijfer op een schaal van 1 tot 10. Over de 41

3 branches heen werd een gemiddelde van 5,5 gegeven. Dit is geen mooi gemiddelde en er valt dan ook nog veel te verbeteren. Gebruik business case Eén van de eerste vragen uit de enquête was de vraag naar de wijze waarop organisaties projecten voorbereiden en op welke manier besluitvorming rond voorgenomen ICT-investeringen tot stand komt. Om te weten of een project succesvol is en de hoge kosten rechtvaardigt, is het van belang vooraf vast te stellen wat de organisatie van het project verwacht en wanneer het succesvol is (Derksen en Noordam, 2006). Hiervoor kan men een business case gebruiken. De business case is de zakelijke verantwoording van het project, waarin naar voren moet komen welke businessdoelstellingen het project ondersteunt en hoe de organisatie controleert of die doelstellingen zijn gehaald. Een business case moet worden opgesteld onder verantwoordelijkheid van de opdrachtgever of businesscase-eigenaar (Van der Zalm en Noordam, 2003). Deze is immers beter dan de projectmanager in staat de businessdoelstellingen te bepalen. Wel is de expertise van een projectmanager of een projectenbureau nuttig om de business case vorm te geven. Uit de enquête kwam naar voren dat: ~ 30 procent van de geënquêteerden voor investeringsbeslissingen nog steeds niet of onvoldoende gebruikmaakt van een business case; ~ 35 procent van de geënquêteerden grotendeels gebruikmaakt van een business case, waarbij vooral de begrote projectkosten goed worden ingevuld. Echter, het investeringskader met andere woorden: wanneer besluiten we wel of niet om de investering te doen en de bijdrage aan de bedrijfsdoelstellingen met andere woorden: wat zijn de baten worden nog steeds onvoldoende ingevuld. Wel wordt in veel gevallen aandacht gegeven aan de bedrijfsrisico s. Deze worden echter sterk kwalitatief ingevuld, waardoor een onderlinge vergelijking lastig te maken is; ~ 32 procent van de geënquêteerden volledig gebruikmaakt van een business case; ~ 3 procent van de geënquêteerden niet weet of er gebruik wordt gemaakt van een business case. 100 Ontevreden ontevreden Tevreden Niet tevreden, niet ontevreden tevreden Onbekend of een business case wordt gebruikt Altijd gebruik van een business case Grotendeels gebruik van een business case Gedeeltelijk gebruik van een business case Nooit gebruik van een business case Figuur 1. De aanwezigheid van een business case uitgezet tegen de tevredenheid over het project Ontevreden ontevreden Onbekend Tevreden Niet tevreden, niet ontevreden Evaluatie wordt uitgevoerd Evaluatie wordt niet uitgevoerd tevreden Uit de enquêteresultaten bleek verder dat het gebruik van een business case leidt tot grotere tevredenheid over het project. Het niet gebruiken van een business Figuur 2. Uitvoering van evaluatie in relatie tot de tevredenheid over het project 42

4 Wie controleert of het project de verwachte baten realiseert? ontevreden Ontevreden Figuur 3. Verplichting om een business case op te stellen bij de start van een project in relatie tot de tevredenheid over het project niet ontevreden Niet tevreden, Tevreden tevreden Onbekend of een business case verplicht moet worden opgesteld Een business case moet verplicht worden opgesteld Een business case moet grotendeels verplicht worden opgesteld Een business case moet deels verplicht worden opgesteld Er wordt geen business case opgesteld case bleek te leiden tot een zeer lage tevredenheid. In figuur 1 is de mate van gebruik van een business case afgezet tegen de mate van tevredenheid. Wanneer we het percentage respondenten dat een business case opstelt, confronteren met de verzamelde gegevens over projectevaluatie, leert ons dat het volgende: 32 procent van de respondenten gebruikt (grotendeels) een business case. Daarvan evalueert 58 procent het project op basis van deze business case. Slechts 18 op de 100 projecten wordt dus grondig geëvalueerd: 82 beperkt of niet. Wanneer de mate van tevredenheid over het project in relatie wordt gebracht tot het al dan niet uitvoeren van een evaluatie, blijkt dat het uitvoeren van een evaluatie leidt tot meer tevredenheid. Vervolgens kijken we naar de relatie tussen de verplichting om aan het begin van het project een business case op te stellen en de tevredenheid over het project. Deze relatie blijkt minder sterk aanwezig. Een algemeen gebruikte ondergrens om verbanden aan te tonen is een correlatie van 0.5. Deze ondergrens is voor geen enkele factor gehaald. Hierdoor is het niet mogelijk harde verbanden aan te tonen. In relatie tot de tevredenheid over projecten kan echter wel worden gekeken naar mogelijke verbanden. De controle van de business case door een controller haalde een correlatie van 0.1. Ook de bijdrage aan de bedrijfsdoelstellingen, 0.24 en de standaardisatie van de investeringsbegroting, 0.14, vertonen een lage relatie. De hoogste correlaties zijn te onderkennen in de toetsing van de baten na afronding van het project, 0.42 en de controle tijdens en na het project van de investeringsbegroting, Ondanks de lage correlaties ziet het ernaar uit dat de respondenten de rol van de controller aan het begin van het project lager inschatten dan tijdens en na het project. Dit is tegen de verwachting in. Een controller kan een te optimistische business case afkeuren, wat zou moeten leiden tot betere projectdefinities. Traditionele investeringsmethodes richten zich echter vooral op de kosten en minder op de baten. De benefits case is een methode waarin de baten een belangrijke rol spelen en is daarom geschikt voor dure ICT-projecten (Van der Zalm en Noordam, 2004). Het opstellen van de business case in relatie met de benefits case wordt hierdoor een samenspel tussen de controller en de business manager, waarmee zowel de investeringsbegroting als de projectbaten vooraf helder worden geformuleerd. 43

5 Projectmanagementmethodieken Ruim 65 procent van de respondenten gaf aan dat ze een standaard projectmanagementmethodiek gebruiken. We hebben daarom gekeken naar de tevredenheid over een project in relatie tot het gebruik van standaard projectmanagementmethodieken. Uit ons onderzoek bleek dat in het algemeen de tevredenheid hierdoor toeneemt. Eveneens blijkt dat de zeer ontevreden respondenten geen gebruikmaken van een standaard methodiek. Bij de ontevreden respondenten is dit nog steeds ruim 45 procent. Van de tevreden respondenten maakt ruim 75 procent gebruik van een standaard projectmanagementmethodiek. Tevens onderzochten wij de relatie tussen het gebruik van een standaard projectmanagementmethodiek en de omvang van het project. Wat hierbij opviel, was dat 55 procent van de respondenten ook gebruikmaakt van een methodiek als het betreffende project kleiner is dan euro. Een signaal van een groeiende volwassenheid in het projectmanagement. Van de gebruikte standaard methodieken blijkt Prince2 met 73 procent veruit de meest gebruikte methodiek. In het KPMG onderzoek van 2004 was dit nog 61 procent. Hierbij viel op dat de grootste gebruikers te vinden zijn bij banken en verzekeraars en bij de centrale overheid. Kijkend naar de tevredenheid zien we dat bij banken en verzekeraars ongeveer 85 procent van de respondenten tevreden tot zeer tevreden is over de uitgevoerde ICT-projecten. Hier is de conclusie gerechtvaardigd dat het gebruik van Prince2 tot grotere tevredenheid leidt. Bij de centrale overheid echter blijkt juist een aanzienlijke ontevredenheid te bestaan over de projecten; meer dan de helft van de respondenten is ontevreden. Hoe kan dit verschil worden verklaard? Hiervoor hebben we gekeken naar een andere belangrijke succesfactor, de projectgrootte. Uit onderzoek van de Standish Group international Inc. (1998) 3 blijkt dat er een sterke relatie bestaat tussen projectomvang (budget) en de mate van suc- Noot 3 Belangrijkste resultaten Standish Group 1998 Project budget (in $), slaagkans (in procent) $ / 55 procent $ 1,5-3 miljoen / 25 procent $ 10 miljoen of meer / 0 procent cesvolheid van een project. Kijkend naar de projectgrootte in ons onderzoek zien we significante verschillen tussen de banken en verzekeraars enerzijds en de centrale overheid anderzijds (zie figuur 4). grote projecten van > 10 miljoen vinden alleen plaats binnen de centrale overheid. 64 procent van de projecten bij banken en verzekeraars is kleiner dan 1,5 miljoen, terwijl dit bij de centrale overheid circa 43 procent is. Uitgaande van de onderzoeksgegevens van de Standish Group zou dit een verklaring kunnen zijn voor de lagere tevredenheid bij de centrale overheid ten opzichte van de banken/verzekeraars. Enige terughoudendheid bij het trekken van deze conclusie is gerechtvaardigd, daar er geen verder onderzoek is verricht naar eventuele andere ter zake doende factoren, zoals cultuur. Op basis van het onderzoek van de Standish Group is het niet onverstandig om projecten zodanig in te richten dat deze de 1,5 miljoen niet overschrijden om de slaagkans te vergroten. Door gebruik te maken van actief portfolio- en programmamanagement kunnen projecten kleiner en in samenhang worden beheerst, waardoor de doelstellingen wel kunnen worden gehaald. Slechts 12 procent van de respondenten geeft echter aan portfoliomanagement toe te passen binnen de organisatie. 24 procent geeft aan een gedeelte van de projecten hierin onder te brengen. 25 procent past nooit portfoliomanagement toe en 38 procent slechts heel af en toe. 1 procent geeft aan niet te weten of portfoliomanagement wordt toegepast. Hier is winst te behalen. Gewenste eigenschappen projectmanager Naast methodiek en projectgrootte hebben we ook gekeken naar de projectmanager als succesfactor. Hierbij is gekeken naar drie typen projecten, met in afnemende mate technische inbreng: ~ technologieprojecten: dit zijn projecten waarbij de technologie de belangrijkste factor is, bijvoorbeeld een nieuw besturingssysteem, of vervanging van hardware; ~ geïntegreerde projecten: dit zijn projecten waarbij de technologie een even belangrijk aandeel vormt als procesaspecten, bijvoorbeeld de implementatie van een nieuw informatiesysteem waarbij de impact op de (medewerkers binnen de) organisatie fors is; ~ bedrijfstransformatieprojecten: dit zijn projecten waar- 44

6 Bedrijven die een business case gebruiken, blijken tevredener met het resultaat Overig Telecommunicatie Lokale overheid Centrale overheid Onderwijsinstelling Gezondheidszorg Gegevensverwerkende organisaties Zakelijke dienstverlening: service Zakelijke dienstverlening: advies Transport en vervoer Handelsorganisaties Industrie (productie) Banken/verzekeraars 0% 20% 40% 60% 80% 100% < ,5 milj. 1,5 3 milj. 3 7 milj milj. > 10 milj. Figuur 4. Verdeling van de projectgrootte over de verschillende branches Tatiana Sayig: beeld 45

7 bij de technologie een ondergeschikte rol speelt en de verandering van de organisatie het primaire projectdoel is, bijvoorbeeld reorganisaties. Bij technologieprojecten gaf 29 procent van de respondenten aan dat ervaring met soortgelijke projecten een belangrijke eigenschap is. Deze eigenschap zien we niet meer terug bij de twee andere typen projecten. Verder kwam naar voren dat bij alle drie typen projecten zowel technische kennis als het managen van het proces ieder door een derde van de respondenten als top drie eigenschap wordt gezien. Gesteld kan worden dat er in de ogen van de respondenten geen universele projectmanager bestaat die bij alle drie typen projecten even goed kan acteren. Waar bij geïntegreerde en bedrijfstransformatieprojecten communicatieve vaardigheden belangrijk zijn, zal bij technische projecten vooral de ervaring met gelijksoortige projecten een belangrijke eigenschap zijn. Tevens kan worden geconcludeerd dat technische kennis wel degelijk een belangrijke vaardigheid is van projectmanagers. Waar in de hedendaagse theorie veel gewicht wordt gegeven aan emotionele intelligentie en functionele kennis, blijkt in de praktijk toch vooral de technische kennis van belang. Cyclisch risicomanagement Risicomanagement is onlosmakelijk verbonden met de uitvoering van projecten. Ook binnen Prince2 is toepassing van risicomanagement belangrijk. Er zijn vele definities denkbaar om een risico te omschrijven. Voor dit onderzoek gebruikten wij de volgende definitie: Een risico in de projectcontext kan worden gezien als een factor die de succesvolle afronding van een project in gevaar kan brengen of kan leiden tot kostenoverschrijdingen, tijdsoverschrijdingen en/of kwalitatieve tekortkomingen. Eén van de vragen in dit verband was: Wanneer wordt bij de uitvoering van de projecten binnen uw organisatie risicomanagement toegepast? ~ Voor de start van het project. ~ Tijdens de uitvoering van het project. ~ Cyclisch voor en tijdens de uitvoering van het project. ~ Bij ons wordt geen risicomanagement toegepast. Hieruit kwam naar voren dat ongeveer 26 procent van de respondenten voor aanvang van het project risicomanagement toepast. Circa 13 procent doet dit tijdens het project en bijna 43 procent past cyclisch risicomanagement toe zowel voorafgaand aan als tijdens de uitvoering van het project. 18 procent maakt geen gebruik van risicomanagement. Wanneer we dit afzetten tegen de tevredenheid, blijkt dat het cyclisch uitvoeren van risicomanagement tot de grootste tevredenheid leidt. Voor de geënquêteerden die aangaven één of andere vorm van risicomanagement uit te voeren, was de vervolgvraag: Wat zijn binnen uw organisatie de drie belangrijkste risicogebieden c.q. aandachtspunten die bij de projectevaluaties naar voren komen? Ze konden kiezen uit de volgende aandachtsgebieden. A. Projectuitgangssituatie: opdrachtformulering, specificaties, stabiliteit interne en externe projectomgeving enzovoort. B. Projectdoelstellingen en afstemming op de bedrijfsdoelstellingen: informatiesystemen, technische infrastructuur, organisatiestructuur, sturing vanuit het management, verandermanagement enzovoort. C. Sociale/organisatorische complexiteit: de organisatorische reikwijdte van het systeem, veranderingsbereidheid en sociale acceptatie enzovoort. D. Technische/functionele complexiteit: complexiteit van de infrastructuur, interfaces, bediening, migratie enzovoort. E. Projectmedewerkers: beschikbare capaciteit, verloop, deskundigheid enzovoort. F. Projectorganisatie: structuur, afstemming met de lijnorganisatie, management committent, taken, verantwoordelijkheden en bevoegdheden, communicatie, besluitvorming enzovoort. G. Projectbeheer en beheersing: fasering, planning, bijsturing, begroting, kwaliteitssysteem enzovoort. H. Projecthulpmiddelen en -technieken: hulpmiddelen, faciliteiten, procedures en richtlijnen, relaties met leveranciers enzovoort. Deze indeling in acht risicocategorieën is overgenomen uit de risicostaalkaart uit het boek IT-projectrisicomanagement van Van Strijen en Kleyn (1994). De eerste vier aandachtsgebieden hebben betrekking op de (complexiteit van de) omgeving van het project, de laatste vier op de interne projectbeheersing. De gedachte hierachter is dat minstens de helft van het projectresultaat wordt bepaald door de omgeving van het project en de andere helft 46

8 Projecten moeten niet omvangrijker zijn dan 1,5 miljoen euro RISICOANALYSEPRINCIPES ~ Het risicoprofiel van een project bestaat uit de complexiteit in combinatie met de risico s die voortkomen uit de mate van beheersing: ~ ~ een eenvoudig project met weinig beheersing heeft een hoog risico; ~ ~ een complex project met een strakke control heeft een beperkt risico. ~ Complexiteit heeft te maken met de uitgangspunten, de doelstellingen en de resultaten van een project (mate van verandering van de organisatie, de sociale en technische implicaties). ~ Beheersing komt voort uit het project (staffing, organisatie, management & control en beschikbare resources en methodieken). Risico als gevolg van de mate van complexiteit Hoog Laag Laag risico Voorbeeld Mission impossible Hoog risico Gemiddeld risico Risico als gevolg van de mate van beheersing Figuur 5. Grafische weergave acht aandachtsgebieden risicomanagement volgens de risicostaalkaart van Van Strijen en Kleyn Hoog door de manier waarop het project wordt aangestuurd, ondersteund en ingericht. In figuur 5 zijn de acht aandachtsgebieden tegenover elkaar gezet. Op de verticale as zijn de eerste vier aandachtsgebieden gescoord, op de horizontale as de laatste vier. Het is de uitdaging van ieder project om zowel de omgeving als de beheersing zo in te richten dat er sprake is van een gemiddeld of zelfs een laag risico. De reacties van de geënquêteerden komen goed overeen met de theorie van IT-projectrisicomanagement. Wat in zijn algemeenheid naar voren kwam: ~ technische complexiteit wordt nog steeds onderschat bij IT-projecten. Dit sluit goed aan bij de recente hernieuwde aandacht voor architectuur en bouwen onder architectuur. Vrijwel iedere organisatie worstelt met een scala aan (deels verouderde) informatiesystemen en ingewikkelde interfaces en zoekt als haarlemmerolie haar heil bij ontwikkelingen als enterprise application integration, middle ware en Service Oriented Architectures (SOA) (Noordam en Derksen, 2006). Echter degelijk huiswerk vooraf, een goed (gedocumenteerd) beeld van het bestaande ICT-landschap en veel aandacht voor integratie tijdens de projectuitvoering blijven nog steeds noodzakelijk; ~ zeker bij grotere geïntegreerde projecten blijkt de sociale complexiteit nog steeds het grootste risicogebied. Bij geïntegreerde projecten waar ICT maar een onderdeel is van de totale transitie, geven vrijwel alle geënquêteerden aan dat de inpassing van de nieuwe werkwijze in de bestaande situatie het belangrijkst is; ~ dit sluit aan bij de conclusie dat bij integrale projecten en bedrijfstransformatieprojecten de projectorganisatie een belangrijk risicogebied is. Immers, hoe zorg je dat je met je project niet alleen het projectresultaat bereikt, maar ook voldoende draagvlak en commitment voor het projectresultaat? Projectevaluatie Ten slotte is gevraagd of projecten achteraf worden geëvalueerd, met als doel ervan te leren voor een volgend project. Wat opvalt is dat simpelweg het evalueren van projecten een sterke relatie heeft met de tevredenheid over de succesvolle uitvoering van projecten: ~ bij een project waar evaluatie plaatsvindt, is 80 procent van de respondenten neutraal tot tevreden; 47

9 Technische complexiteit vormt onderschatte risicofactor ~ bij een project zonder evaluatie is minder dan de helft (44 procent) van de respondenten neutraal tot tevreden. Een evaluatie gericht op het gerealiseerd hebben van de projectdoelstellingen wordt als belangrijkste type evaluatie genoemd. Dit krijgt echter volgens de geënquêteerden nog steeds niet genoeg aandacht. Dat blijkt ook uit de vraag in hoeverre de baten in de business case zijn opgenomen en in hoeverre het realiseren van deze baten daadwerkelijk wordt geëvalueerd. Deze uitkomst pleit ervoor een project niet alleen af te rekenen op het realiseren van de gewenste functionaliteit op tijd en binnen budget, maar om een project ook verantwoordelijkheid te geven voor het daadwerkelijk realiseren van de baten. Een voorbeeld kan dit verduidelijken. Stel: in de business case van een project is een kostenreductie van 20 procent afgesproken. Echter, het daadwerkelijk realiseren van deze bate kan pas een jaar na afloop van het project worden gerealiseerd. De projectmanagementmethode MSP (Managing Successful Projects) stelt daarom voor een batenmanager aan te stellen die verantwoordelijk is voor het realiseren van de genoemde kostenreductie van 20 procent. Conclusies ICT-projecten hebben een negatief imago. Te duur, te laat en niet de gewenste functionaliteit is voor veel projecten nog steeds schering en inslag. Veel, vooral grotere organisaties, realiseren zich dit inmiddels en borgen hun ervaringen om ze in te brengen in volgende projecten. We zien een aantal hoopgevende ontwikkelingen, waarbij het aandachtsgebied projectmanagement volwassen lijkt te worden en verder professionaliseert. De aandacht voor business cases en besluitvorming rond ICT-projecten in het algemeen is duidelijk toegenomen. De respondenten dichten de controller een belangrijker rol toe tijdens en na het project dan eraan voorafgaand. Er kan nog veel worden gewonnen door de controller nadrukkelijker te betrekken bij de besluitvorming over projecten. Hierbij kan de controller optreden als adviseur van de directie in een rol die verder gaat dan het financieel doorrekenen van verschillende investeringsscenario s. Hij zal dan wel kennis moeten hebben van relevante overwegingen die spelen bij de investeringen (Van der Zalm en Noordam, 2003). Wanneer risico s prominente aandacht krijgen tijdens de start, maar vooral ook tijdens de uitvoering van projecten, vergroot dit de succeskans van het project. Het toepassen van deze vorm van cyclisch risicomanagement is nog onvolwassen en hier valt nog veel te winnen. Het kernwoord hierbij is overigens risicobeheersing en niet risicomijding. Een project dient niet alleen goed gestart en uitgevoerd te worden, maar bovenal ook goed te worden geëvalueerd. De evaluatieresultaten kunnen in belangrijke mate bijdragen aan het succesvol uitvoeren van nieuwe projecten. Door te leren van zowel de gemaakte fouten als de geboekte successen kun je als organisatie de volwassenheid van de projectuitvoering positief beïnvloeden en hiermee het aantal succesvol afgesloten projecten vergroten. Ook dit ICT-gebied kan zich niet geheel losmaken van de hypes. Dit komt onder andere naar voren uit de 13 procent groei van Prince2-gebruik in twee jaar. Het is goed dat er gaandeweg standaarden en formats ontstaan, die nuttig kunnen zijn bij het uitvoeren van projecten. Dit hoort ook bij de professionalisering van het vak. Het slaafs en blind navolgen van dit soort methoden als een garantie voor succes leidt echter vaak tot een papieren tijger die de projectvoortgang in negatieve zin beïnvloedt. Het op maat toepassen van Prince2 is in onze ogen dan ook de goede wijze van toepassing en deze mening lijkt te worden gedragen onder de respondenten. Literatuur ~ Bisnez Management (2007). Projectmanagement enquête Handvatten voor succesvolle projecten. ~ Bonham, S.S. (2005). Management and Project Portfolio Management, Artech House. ~ Derksen, B. en P. Noordam (2006). Modellen die werken, kwaliteit in bedrijf en informatievoorziening, Boekdrukkunst Uitgeverij. ~ Gras, C. Competentie als maatstaf voor gekwalificeerde projectmanager, Project Management Instituut Nederland. ~ Haughey, D. (2001). Eight key factors to ensuring project success. ~ KPMG (2004), Programmamanagement leidt tot betere projectresultaten. ~ Standish Group Report, 1994/2000. CHAOS. ~ Strijen, B. van en G. Kleyn (1994). Risicomanagement in IT-projecten, Kluwer. ~ Zalm, M. van der en P. Noordam (2004). Kosten, baten en risico s van ICT-investeringen, Kluwer, Deventer. Norman Martijnse is werkzaam bij Bisnez Management als projectmanager/adviseur. Peter Noordam is eveneens werkzaam bij Bisnez Management als Directeur Advies. 48