Projectmanagement:
LESSEN UIT FALENDE EN SUCCESVOLLE ICT-PROJECTEN CONTROLLERS MOETEN VANAF DE START EEN ROL SPELEN
40
MCA: april 2007, nummer 3
Aaron Kohr: beeld
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?
Wij stelden ons de vraag hoe het anno 2007 is gesteld met de tevredenheid over projecten en of het
Hierover bestaan veel theorieën, maar in essentie
mislukken van projecten nog steeds wordt geweten aan genoemde factoren. Daarbij vroegen wij ons af wat we kunnen leren van falende en geslaagde ICT-
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 KPMG2 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.
projecten. 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 www.bisnez.com. 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
MCA: april 2007, nummer 3
41
Zeer
tevreden
Tevreden
Niet tevreden,
niet ontevreden
Gebruik business case
Ontevreden
ven. Dit is geen mooi gemiddelde en er valt dan ook nog veel te verbeteren.
Zeer
ontevreden
branches heen werd een gemiddelde van 5,5 gege-
100
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
80
rond voorgenomen ICT-investeringen tot stand
60
komt. Om te weten of een project succesvol is en de hoge kosten rechtvaardigt, is het van belang vooraf
40
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 pro-
20 0 Onbekend of een business case wordt gebruikt
ject ondersteunt en hoe de organisatie controleert of die doelstellingen zijn gehaald. Een business case moet worden opgesteld onder verantwoordelijkheid
Altijd gebruik van een business case
van de opdrachtgever of ‘businesscase-eigenaar’ (Van der Zalm en Noordam, 2003). Deze is immers
Nooit gebruik van een business case
beter dan de projectmanager in staat de businessdoelstellingen te bepalen. Wel is de expertise van een projectmanager of een projectenbureau nuttig
Grotendeels gebruik van een business case Gedeeltelijk gebruik van een business case
Figuur 1. De aanwezigheid van een business case uitgezet tegen de tevredenheid over het project
Zeer
tevreden
Tevreden
Niet tevreden,
MCA: april 2007, nummer 3
niet ontevreden
42
Ontevreden
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
Zeer
ringsbeslissingen 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.
ontevreden
om de business case vorm te geven. Uit de enquête kwam naar voren dat: ~ 30 procent van de geënquêteerden voor investe-
100 80 60 40 20 0 Onbekend Evaluatie wordt uitgevoerd Evaluatie wordt niet uitgevoerd
Figuur 2. Uitvoering van evaluatie in relatie tot de tevredenheid over het project
‘Wie controleert of het project de verwachte baten realiseert?’
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
Zeer
tevreden
Tevreden
Niet tevreden,
Ontevreden
Zeer
ontevreden
niet ontevreden
business case op te stellen en de tevredenheid over het project. Deze relatie blijkt minder sterk aanwezig. Een algemeen gebruikte ondergrens om ver-
100 80 60 40 20 0 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
Figuur 3. Verplichting om een business case op te stellen bij de start van een project in relatie tot de tevredenheid over het project
banden 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, 0.43. 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.
MCA: april 2007, nummer 3
43
Projectmanagementmethodieken
cesvolheid van een project. Kijkend naar de project-
Ruim 65 procent van de respondenten gaf aan dat ze
grootte in ons onderzoek zien we significante verschillen tussen de banken en verzekeraars enerzijds
een standaard projectmanagementmethodiek gebruiken. We hebben daarom gekeken naar de tevre-
en de centrale overheid anderzijds (zie figuur 4).
denheid over een project in relatie tot het gebruik
Zeer grote projecten van > € 10 miljoen vinden al-
van standaard projectmanagementmethodieken. Uit ons onderzoek bleek dat in het algemeen de te-
leen 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
vredenheid hierdoor toeneemt. Eveneens blijkt dat de zeer ontevreden respondenten geen gebruikma-
overheid circa 43 procent is. Uitgaande van de on-
ken van een standaard methodiek. Bij de ontevre-
derzoeksgegevens van de Standish Group zou dit
den respondenten is dit nog steeds ruim 45 procent.
een verklaring kunnen zijn voor de lagere tevreden-
Van de tevreden respondenten maakt ruim 75 procent gebruik van een standaard projectmanage-
heid bij de centrale overheid ten opzichte van de banken/verzekeraars. Enige terughoudendheid bij het trekken van deze conclusie is gerechtvaardigd,
mentmethodiek. Tevens onderzochten wij de relatie tussen het gebruik van een standaard projectmanagementme-
daar er geen verder onderzoek is verricht naar even-
thodiek en de omvang van het project. Wat hierbij opviel, was dat 55 procent van de respondenten ook
tuele andere ter zake doende factoren, zoals cultuur. Op basis van het onderzoek van de Standish
gebruikmaakt van een methodiek als het betreffende project kleiner is dan 75000 euro. Een signaal van een groeiende volwassenheid in het project-
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 ge-
management. Van de gebruikte standaard methodieken blijkt Prince2 met 73 procent veruit de meest gebruikte
bruik te maken van actief portfolio- en programmamanagement kunnen projecten kleiner en in samenhang worden beheerst, waardoor de
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
doelstellingen wel kunnen worden gehaald. Slechts 12 procent van de respondenten geeft echter aan
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) $ 75 000 / 55 procent $ 1,5 - 3 miljoen / 25 procent $ 10 miljoen of meer / 0 procent
44
MCA: april 2007, nummer 3
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-
‘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% < 75 000
75 000 – 1,5 milj.
20% 1,5 – 3 milj.
40% 3 – 7 milj.
60% 7 – 10 milj.
80%
100%
> 10 milj.
Figuur 4. Verdeling van de projectgrootte over de verschillende branches
Tatiana Sayig: beeld
MCA: april 2007, nummer 3
45
bij de technologie een ondergeschikte rol speelt en
tijdens het project en bijna 43 procent past cyclisch
de verandering van de organisatie het primaire projectdoel is, bijvoorbeeld reorganisaties.
risicomanagement toe zowel voorafgaand aan als
Bij technologieprojecten gaf 29 procent van de respondenten aan dat ‘ervaring met soortgelijke pro-
neer we dit afzetten tegen de tevredenheid, blijkt dat het cyclisch uitvoeren van risicomanagement
jecten’ een belangrijke eigenschap is. Deze eigenschap zien we niet meer terug bij de twee andere
tot de grootste tevredenheid leidt.
typen projecten. Verder kwam naar voren dat bij alle drie typen projecten zowel ‘technische kennis’
dere vorm van risicomanagement uit te voeren, was de vervolgvraag: ‘Wat zijn binnen uw organisatie de
als het ‘managen van het proces’ ieder door een derde van de respondenten als top drie eigenschap
drie belangrijkste risicogebieden c.q. aandachtspunten die bij de projectevaluaties naar voren
wordt gezien. Gesteld kan worden dat er in de ogen van de res-
komen?’ Ze konden kiezen uit de volgende aan-
pondenten 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
46
MCA: april 2007, nummer 3
tijdens de uitvoering van het project. 18 procent maakt geen gebruik van risicomanagement. Wan-
Voor de geënquêteerden die aangaven één of an-
dachtsgebieden. 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
‘Projecten moeten niet omvangrijker zijn dan 1,5 miljoen euro’
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 gemid-
RISICOANALYSEPRINCIPES
deld of zelfs een laag risico.
~ 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).
Mission impossible
van complexiteit
Risico als gevolg van de mate
Hoog
Voorbeeld
Hoog risico
Laag risico
Gemiddeld risico
Laag
Hoog Risico als gevolg van de mate van beheersing
Figuur 5. Grafische weergave acht aandachtsgebieden risicomanagement volgens de risicostaalkaart van Van Strijen en Kleyn
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;
MCA: april 2007, nummer 3
47
‘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.
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 wor-
Dat blijkt ook uit de vraag in hoeverre de baten in de
den geëvalueerd. De evaluatieresultaten kunnen in
business case zijn opgenomen en in hoeverre het rea-
belangrijke mate bijdragen aan het succesvol uitvoeren van nieuwe projecten. Door te leren van
liseren 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,
48
MCA: april 2007, nummer 3
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 2006-2007. 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.