De sturing van ICT-projecten is vanuit het klassieke gedachtegoed zeer eenzijdig gericht op techniek, budget en tijd. Overschrijding van tijdlijn en/of budget wordt in de media opgevolgd met schreeuwende koppen zoals ‘Veel ICT-projecten mislukken’ zonder al teveel nuancering. Deze door de tijd ingehaalde klassieke benadering vraagt om een flinke bijstelling. Het tot stand komen van de doorlooptijd (planning) en beoordelen van het projectresultaat zijn namelijk erg discutabel.
Doorlooptijd
Vaak bepaalt het hogere management de doorlooptijd van een ICT-project door het vaststellen van een opleverdatum voor de te bouwen ICT-oplossing. De opleverdatum minus de actuele datum is dan de maximale doorlooptijdtijd van het project. De nieuwe ICT-oplossing zorgt echter vaak voor veranderingen in de werkinhoud en samenwerking tussen mensen in en buiten de eigen organisatie. Werkinhoud en samenwerking veranderen als gevolg van bijvoorbeeld het invoeren van een (nieuw) ERP-systeem. ERP staat voor Enterprise Resource Planning en zorgt voor integratie van processen over afdelingen heen. Het in laten slijten van deze veranderingen - ook wel 'inslijtpijn' genoemd - kost leertijd. Deze leertijd kan zelfs meer tijd kosten dan de tijd die nodig is voor het ontwikkelen en bouwen van de ICT-oplossing. Omdat de eenzijdige op techniek gebaseerde doorlooptijd hier geen rekening mee houdt, staat het ICT-project al meteen vanaf het begin onder grote druk. Een vergelijking met ons eigen leertraject in het onderwijs is hier te maken. Iemand in één jaar van bijvoorbeeld 2 naar 5 Atheneum laten doorstromen is erg ambitieus maar weinig realistisch. De slaagkans hiervan is bijzonder klein. Waarom negeert het hogere management (nog steeds) dat technologieveranderingen leiden tot veranderingen in de werkinhoud van en samenwerking tussen mensen? Waarom krijgen deze eenzijdige, op het bouwen van de techniek gebaseerde planningen, een soort ‘heilige’ status binnen een ICT-project?
Resultaat
Als het resultaat van een ICT-project zorgt voor flinke verbetering in de bedrijfsvoering of bijdraagt aan het vergroten van de omzet en/of marges, is het dan terecht om te spreken van een mislukt project bij het (beperkt) overschrijden van de planning en/of het budget? Deze klassieke benadering over het al dan niet slagen van projecten leidt tot teveel hokjesgeest en stemmingmakerij, waardoor projecten een doel op zich lijken in plaats van een middel om bij te dragen aan het organisatiedoel. De projectmanager wil van zijn project af, want tijd en budget zijn immers op. Gevolg is dat projecten vaak half afgemaakt worden opgeleverd of snel worden afgeraffeld. Gebruikers en beheerders hebben dan te maken met een haperende ICT-oplossing en een flinke nazorginspanning om dit weer gerepareerd te krijgen. In plaats van planning en budget vormen andere criteria een veel betere basis voor het beoordelen van het projectresultaat en het beoordelen van de prestatie van de projectmanager. Deze criteria zijn bijvoorbeeld:
- Is het projectresultaat een verbetering?
- Past het projectresultaat bij het organisatiedoel?
- Sluit het projectresultaat aan bij de verwachting?
- Is de nazorginspanning van het projectresultaat beperkt geweest?
Een andere beoordeling van het projectresultaat zorgt voor een betere borging en absorptie van het resultaat van een ICT-project. Nazorginspanningen zijn dan kleiner en de investering van het ICT-project kan dan sneller worden terugverdiend.
Gerelateerde artikelen
Falende IT-projecten een schande voor de (IT)adviesbranche?
Nico Beenker
Samen werken en leren in de verdrukking
Leon Dohmen
Opdrachtgever grootste risico bij IT-projecten
Nico Beenker
Kom met uw praktijkervaringen op het terrein van managen en organiseren
Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)
Word een pro!
SCHRIJF MEE >>
Ook ik kom inde praktijk de beschreven gevallen tegen. Naar mijn mening hebben we te maken met de noodzaak tot het doorontwikkelen van het vakgebied projectmanagement naar een hoger niveau.
De projectmanager van nu zal zich verder moeten bekwamen. Het binnen de afgesproken kaders opleveren van deliverbles zal steeds minder een mogelijkheid bieden om jezelf als projectmanager op te profileren. Harde vaardigheden zijn commodity (of zouden dat moeten zijn).
Het verschil gaat gemaakt worden op de vaardigheden van projectmanagers op het gebied van veranderkunde. Het pallet van de projectmanager kijgt meer kleuren.
Dat dit ook gevolgen heeft voor de opdrachtgevers mag duidelijk zijn. De eerste discussie tussen de opdrachtgever en de projectleider (ik praat in deze situatie liever over projectleiders) zou naast de gebruikelijke zaken, moeten gaan over de vraag wie welke actieve rol pakt als het gaat om de verandering die het project teweeg brengt? Hierbij ga ik bewust tegen de gevestigde orde in door te stellen dat dit feitelijk de projectleider zou moeten zijn. Simpel weg omdat ik er niet in geloof dat de opdrachtgever de kennis/kunde of tijd voor heeft deze actieve rol op zich te nemen. Het boegbeeld zijn prima, de uitvoering: ik geloof er niet in.
Dus projectmanagers die dit artikel en deze reactie gelezen hebben: ontwikkel je naar projectleider en de toekomst ligt aan je voeten!!
Rob Buijtendijk
Alg. Directeur
InnerVisie BV
Nr.1 In strategie implementatie
Ik ben het volledig eens met de stelling van Leo dat de doelen van een ICT project niet op het niveau van het 'opleveren van een systeem' maar op het niveau van de business moeten worden vastgespijkerd.
Ik koopt ook geen wasmachine om het ding aan te zetten, ik wil een wasmachine omdat ik schone was wil, maar dan moet ik ook aandacht besteden aan het op kleur sorteren van het wasgoed, het goede wasmiddel in de juiste dosering, de juiste temperatuur, etc. Een schone was is een kunst waar meer bij komt kijken dan het installeren van een machine.
De individuele competenties van projectmanagers zullen wellicht helpen om de chaos die jullie beschrijven te bedwingen, maar zal deze niet wegnemen. Projectmanagers zijn namelijk niet de spelbepalers, zij werken in opdracht van opdrachtgevers en dat zijn meestal programmamanagers of iets dergelijks. En het is hier waar de chaos begint. Ik verklaar me nader.
Zolang opdrachtgevers accepteren dat de doelen van een ICT project worden gesteld in termen van het opleveren van een 'systeem', is de business case van zo'n project op drijfzand gebaseerd. Die behoort immers gebaseerd te zijn op verbeterde prestaties in de leverketen, verbeterde dienstverlening EN baten voor klant & bedrijf.
Zolang de opdrachtgevers (en dus de programmamanagers) boterzachte businesscases voor zoete koek slikken, ziet men verbeterprojecten als ICT-projecten die alsmaar mislukken en zijn projectmanagers veredelde wasmachinemonteurs.
Het aardige is dat de ICT sector zelf ook een rol in dit geheel speelt, althans volgens de Rekenkamer in haar rapport over de grote ICT projecten bij de overheid. Aanbieders van oplossingen beloven gouden bergen, maar waken er wel voor dat die als p.m. kosten in de offerte worden meegenomen, dus uurtje factuurtje en de klant betaalt. Het 'mislukken' van die projecten is dus geen toeval, maar zorgvuldig gepland!
De bal ligt dus bij de programmamanager als opdrachtgever, en die moet drie dingen doen: ten eerste de projectdoelen op het niveau van de business vastspijkeren met alle betrokken partijen, ten tweede met de business een projectplan maken waarbij van het begin af aan alle kosten van veranderen en 'inslijten' zijn opgenomen en ten derde de business maar eens vragen of de investering ECHT de moeite waard is. En dat niet éen keer, maar iedere keer als er een project wordt opgestart, en volgens dezelfde methodiek. Managen van de projectcyclus noem ik dat, zodat succes geen toeval meer is.
Charles de Monchy
De Monchy & Partners
doelgericht samenwerken