Projectsucces is geen toeval

De laatste weken ben ik intensief betrokken geweest bij de review van een aantal grote (ICT) projecten. Het viel me op dat, ondanks dat we al 50 jaar ICT projecten uitvoeren, we niet snel leren. Het is wel aardig om in dit verband het meerjarige onderzoek van de ‘Standish Group’ aan te halen. Al in 1994 onderzochten zij het succesvol verloop van ICT projecten, in dat jaar waren 16% van de projecten succesvol afgerond. In 1998 was dit gestegen naar 26% en 2004 stond de teller op 34%, waarna in 2009 het ‘succes’ weer terugzakte naar 32%. Een ding is zeker: in Nederland doen we het niet beter.

Vanuit mijn eigen ervaring en de veelheid aan onderzoeken die ingaan op de vraag ‘waarom mislukken ICT projecten’, heb ik een top vijf gemaakt van de belangrijkste voorwaarden voor een succesvol project. Ik verneem graag of u het hier mee eens bent.

1. De allerbelangrijkste voorwaarde is rol van de opdrachtgever.
Een succesvol project heeft een opdrachtgever die zich écht verantwoordelijk voelt; voor het succes van zijn project, die ’s nachts wakker ligt als het project tegenslag heeft; die van de start tot het einde betrokken is; die voldoende mandaat en gezag heeft om veranderingen door te voeren in zijn organisatie. Daarnaast is het belangrijk dat een opdrachtgever (vaak de voorzitter van een stuurgroep) een intensieve, respectvolle en vertrouwelijke relatie heeft met zijn projectmanager. In de praktijk is dit natuurlijk lastig. Eindverantwoordelijke opdrachtgevers zitten vaak te ver van de operatie af, hebben een drukke agenda en delegeren hun verantwoordelijkheid naar beneden. Programma’s gaan vaak over afdelings- organisatiegrenzen heen, met als gevolg meerdere eigenaren. Mijn advies als er geen duidelijke opdrachtgever gevonden kan worden, gewoon niet starten met het project.

2. De tweede hele voor de hand liggende voorwaarde is een goede business case.
De afgelopen maand heb ik weer een aantal business cases mogen evalueren. Goed dat ze er zijn, want er starten nog steeds ICT projecten zonder voorafgaand een duidelijke kosten, baten en risico analyse. De business cases die ik gezien heb, voldeden geen van allen aan de minimum eisen; waren geschreven door de beoogd projectleider; de benefits waren vaag en alleen kwalitatief beschreven; de kosten beperkt tot de projectkosten; het ‘nulscenario’: wat gebeurt er als we niets doen? ontbrak. Ook antwoord op de vragen: ‘wie is verantwoordelijk voor het binnenhalen van de benefits, kortom wie moet zorgen dat na oplevering van het project de organisatie ook echt efficiënter gaat werken, was slecht uitgewerkt.
Mijn advies: de opdrachtgever is verantwoordelijk voor een goede business case. Als verwachte benefits te vaag of te complex zijn, doe dan je huiswerk over tot je wel kan aangeven wat het voorgesteld project voor je moet betekenen. Betrek alle partijen bij het opstellen en laat je ondersteunen door mensen met ervaring.

3. Reviewen is bijsturen, auditen is de achteruitkijkspiegel.
Zorg dat je in en rondom het project voldoende kritische mensen hebt rondlopen. Maak afspraken met je projectleider over regelmatige reviews. Organiseer dus je eigen kritiek. Beperk de reviews niet tot het project, maar betrek hierbij nadrukkelijk de omgeving van het project (boards, stuurgroepen, klankbordgroepen, etc.). Audits zijn formeel, kosten vaak meer tijd en auditors willen zaken zeker weten voor ze tot een uitspraak komen. Auditors komen met bevindingen, reviewers komen met aanbevelingen. Ook hier: meten is weten, maar ongeveer zegt vaak meer en bij projecten is snelheid essentieel om nog bij te kunnen sturen.

4. Hang je niet op aan een methode.
Prince2 en MSP zijn prima projectmanagement methoden. Ze zorgen voor een kader en een gemeenschappelijke taal. Prince2 is vooral voor opleidingsdoeleinden bijzonder geschikt. Maar ik ken geen enkele organisatie die deze projectmanagement methodes integraal toepast. Het overbekende PINO (Prince in Name Only) kom ik het meeste tegen. Een ervaren projectmanager zal dankbaar gebruik maken van dit soort methoden, maar begrijpt ook dat projecten maatwerk zijn en dat hij te maken heeft met mensen en een omgeving. Ik hoorde pas de uitspraak: “een beginnend projectleider besteedt 90% van zijn tijd aan de sturing van zijn project en 10% aan zijn omgeving. Bij een ervaren projectleider is dit precies andersom.

5. Halveer het aantal projecten.
Veel projecten worden gestart om de incompetentie of de starheid van de ‘lijn’ te camoufleren. Kleine aanpassingen die eigenlijk in de staande organisatie zouden moeten worden opgelost, worden opgetild tot projecten. Veel andere projecten worden gestart om de manager van een probleem te verlossen of een probleem naar achteren te schuiven. Daarnaast weten we inmiddels allemaal dat teveel projecten de ‘going concern’ verstikken. ‘Key users’ die full time bij verschillende projecten rondhollen, gefrustreerde afdelingen en ruime gelegenheid voor medewerkers en management om zich te verschuilen in projecten. Kortom stop hiermee.

Ik wens alle opdrachtgevers en betrokkenen bij een project veel wijsheid toe.

Drs. P.G. Noordam
Directeur Bisnez Management