Channels

Dat IT-projecten vaak mislukken is bekend. Maar dat eindverantwoordelijke opdrachtgevers meestal zélf verantwoordelijk zijn voor de problemen, veel minder. Het mislukken van projecten gaat vaak gepaard met vage en steeds veranderende doelen, of met een stevige managementaanpak die roet in het eten gooit. Eindverantwoordelijke opdrachtgevers laten het afweten maar in de praktijk valt dit nauwelijks op. Sommige gerenommeerde IT-bedrijven maken hen het uitglijden ook wel erg gemakkelijk.

IT in organisaties is tegenwoordig méér en méér confectiewerk. IT-systemen worden steeds minder gebouwd: men koopt en implementeert standaardsoftware. Keuze is er te over. Een manager die een ERP-pakket moet selecteren en in de eigen organisatie laat implementeren, heeft daar meestal weinig ervaring mee. Een directeur van een zorginstelling die aan de slag gaat met een veelbelovend ZIS (Ziekenhuis Informatie Systeem) al evenmin. Gebrek aan ervaring leidt tot onzekerheid. Er heerst onder businessmanagers een hardnekkig misverstand dat je van IT verstand moet hebben om als projectopdrachtgever goed te kunnen functioneren. Bovendien zijn IT-projecten door hun bedenkelijke reputatie niet erg populair onder eindverantwoordelijken. Ze worden gezien als kostbaar, lastig te beheersen, risicovol en detaillistisch. ‘Van IT-projecten heb ik géén verstand en dat wil ik gráág zo houden’ is een veelgehoorde grap onder managers. Het opdrachtgeverschap wordt daarom maar al te graag overgelaten aan iemand met ‘verstand van zaken’: een IT-specialist of een gedelegeerd opdrachtgever. En daar gaat het mis. Op het moment dat je de doelstellingen te laag in de organisatie laat formuleren of laat uitwerken, moet je niet verbaasd zijn dat deze te technisch of te instrumenteel zijn en voor een goede projectbesturing niet geschikt. In de projectchaos die daarna ontstaat, valt het bijna niemand op dat inadequaat opdrachtgeverschap de kernoorzaak is.

Vijfenzestig miljoen en vijf jaar levert nagenoeg niets op

De afhoudende houding van het businessmanagement en het slecht georkestreerde opdrachtgeverschap is de belangrijkste faaloorzaak van pakketimplementaties. Het onderzoek bevestigt dat meer dan de helft (53%) van de IT-projecten met standaardsoftware deels of volledig faalt. Vier van de vijf falende projecten falen vóórdat de informatietechnologie in beeld komt. Het falen wordt niet veroorzaakt door technische problemen, maar vooral door onduidelijkheid in de communicatie en -zeer belangrijk- het dichttimmeren van alle onzekerheden in het selectie- en implementatieproces. Zelfs de doelen van een project zijn vaak niet eens duidelijk. In het onderzoek is er bijvoorbeeld sprake van een volledig falend IT-project dat oorspronkelijk op ruim vijftig miljoen Euro was geraamd. De doelstellingen van dit project bleven lang onduidelijk. Een betrokkene zei daarover: “Het eerste jaar was de doelstelling ‘het uitfaseren van bestaande ICT-systemen’. Daarna werd het doel ‘meer procesmatig werken’ en uiteindelijk werd het doel ‘klantwaarde’. Bij de laatste wijziging van het doel sloeg het weer helemaal door naar het nastreven van businessdoelen en werd de ICT weer vergeten. Daarom is het nooit echt goed van de grond gekomen. De eerste businesscase was een goede businesscase. Die was ook positief, alleen parallel gingen er reorganisaties lopen. Door deze reorganisaties werden de besparingen die in de businesscase stonden al gerealiseerd. Na drie jaar werd er weer een nieuwe businesscase gemaakt. Toen was de businesscase negatief omdat de creditkant deels al was gerealiseerd. Vervolgens werd er gezegd, het is toch wel noodzakelijk om het te doen, dus laten we het maar doen.”

Lees ook:

Een succesvol bedrijf kent geen ICT-projecten

Typerend is dat het doel van dit kolossale project eerst in ‘IT-termen’ beschreven is: ‘het uitfaseren van bestaande ICT-systemen’. Daarin loopt men vast. Vervolgens grijpt men terug naar het doel van de IT-systemen en wordt het projectdoel: ‘meer procesmatig werken’. Maar ook dat levert niet de gewenste voortgang op. IT-dienstverleners en programmamanagers lopen steeds opnieuw vast. Koppen rollen daar waar de chaos het grootste is: op uitvoerend niveau. Nog één ultieme poging. Het doel wordt (het nog abstractere) ‘klantwaarde’. Wederom loopt men vast. In dit project werd dus jarenlang letterlijk gependeld tussen IT- en businessdoelstellingen zonder dat men elk van de twee definitief op zijn plek kreeg. Het project werd na vijf jaar en het spenderen van een ‘vertrouwelijk’ bedrag (van rond de 65 miljoen) gestaakt. Honderden mensen werkten jarenlang aan iets dat uiteindelijk  nagenoeg niets opleverde. Het is een hilarisch en zeer kostbaar voorbeeld van volkomen falend IT-opdrachtgeverschap dat de kwalificatie mismanagement met glans verdient, maar onopgemerkt blijft.

IT-opdrachtgever laat het gebeuren

Uit het onderzoek blijkt dat in 40% van de faalgevallen de projecten al tijdens de offerte/contractfase en daarop volgende definitiefase misgaan. Nog eens 40% van de faalgevallen ontstaan tijdens het ontwerpen van de specifieke toepassing van het standaardpakket. Globaal blijkt dat zo’n vier van de vijf falende IT-projecten falen vóórdat er met de technische realisatie gestart wordt.

De ondervraagde opdrachtgevers ervaren het moment van falen geheel anders. Zij zijn vrijwel allemaal van mening dat falende projecten pas tegen het einde in de problemen komen: tijdens het testen en bij de ingebruikname van de standaardsoftware. Dit verschil in perceptie van het moment van falen is misschien wel begrijpelijk omdat voor een opdrachtgever het projectresultaat pas echt concreet wordt wanneer systeem getest wordt. Maar het betekent ook dat de opdrachtgever niet in control was. Je mag in elk geval de conclusie trekken dat het samenwerkingsproces gedurende de voorbereidende-, ontwerp- en ontwikkelfase(n), tijdens welke de opdrachtgever tussenresultaten accepteert, kennelijk voor een opdrachtgever onvoldoende voorspellende waarde heeft voor het projectresultaat. Het opdrachtgeverschap schiet dus tekort. Er blijkt veel te weinig aandacht te zijn voor de samenhang tussen de bedrijfsvoering en de IT. Dit komt in het onderzoek tot uiting bij het gebrekkig richten van het project. Vooral door geen businesscase te maken, of deze niet te gebruiken voor de projectbesturing. Daarnaast is het gebrekkig of helemaal niet hanteren van op de business gerichte acceptatiecriteria een typisch voorbeeld van inadequaat IT-opdrachtgeverschap. Ook het sluiten van een onevenwichtig contract voor het verlenen van de IT-diensten is een belangrijk faalsymptoom. Eindverantwoordelijke opdrachtgevers geven dikwijls opdracht het proces juridisch helemaal dicht te timmeren, hetgeen een goede samenwerking frustreert. Opdrachtgevers laten vaak na de juiste vragen te stellen. Ze zijn daardoor niet effectief in het bewaken van de voortgang van een project. Het gevolg is dat opdrachtgevers pas ‘merken’ dat het project gaat falen op het moment dat het IT-systeem is ingericht en wordt getest. Dan blijkt het systeem misschien technisch wel te functioneren (het is immers standaardsoftware), maar niet aan de behoefte van de organisatie te voldoen. Het IT-systeem staat dan scheef op de operatie: het is niet of onvoldoende bruikbaar in de werkprocessen. Voor bijsturen is het te laat omdat het geld al is gespendeerd. Het falen is een feit.

Eerste faaloorzaak: een vaag en steeds veranderend doel

Wanneer we wat dieper ingaan op de oorzaken, blijkt een vaag en steeds veranderend doel één van twéé monumentale faaloorzaken te zijn, die beide zijn terug te voeren op de gebrekkige invulling van het opdrachtgeverschap. Maar hoe kan een project nu vage en steeds veranderende doelen hebben? De oorzaak zit dikwijls in de manier van denken en werken, in combinatie met afwezig leiderschap. IT’ers zijn geneigd IT-projectvoorstellen te doen die bij aanvang een onduidelijk of globaal doel hebben, omdat ze erop vertouwen dat ze het doel van het project gaandeweg zelf kunnen verhelderen. Dit van ‘grof naar fijn’ werken ziet men als een gangbaar onderdeel van de projectmatige IT-aanpak. Projectdoelen kunnen volgens veel IT’ers vooraf slechts globaal worden vastgesteld en worden daarna in het project uitgewerkt. Dit klinkt logisch en overtuigend. Het probleem hierbij is dat betrokkenen niet zelden hun eigen vermogen overschatten om de ontwikkelingen in de door hen zelf bedachte (en zinnig geachte) richting te kunnen sturen. Dat lukt zonder de hulp van het top-businessmanagement vaker niet dan wel. Het opdrachtgeverschap wordt vaak naar een te laag niveau gedelegeerd, zodat er een gebrek aan overzicht en zeggenschap is. De praktische obstakels die de IT’ers op hun weg aantreffen komen meestal pas in de tweede helft van het project op tafel. Ze kunnen allerhande vormen aannemen: de noodzakelijke afstemming tussen business en IT lukt niet, de IT-architecten van het hoofdkantoor werken niet mee, de achterliggende strategie is niet duidelijk zodat men niet weet wat men wil, het softwarepakket deugt niet, de infrastructuur is ongeschikt of nog niet klaar, afdelingsmanagers willen alleen maar tegenwerken, of hebben steeds maar nieuwe wensen, et cetera. Eindeloos doormodderen is vaak het gevolg. Wat er in feite als kernoorzaak onder zit, blijkt een slechte project governance en onduidelijke doelen bij de aanvang. Alle respondenten in het onderzoek, dus de opdrachtgevers, de opdrachtnemers, de geïnterviewde specialisten én de geënquêteerde projectbetrokkenen geven dit als voornaamste reden voor het falen. In de online enquête bijvoorbeeld werd verzocht de volgende zin af te maken:

Projecten gaan fout omdat…

  • ‘de klant het project onvoldoende ondersteunt in de organisatie.’
  • ‘de organisatiestrategie en bedrijfsdoelstellingen onduidelijk zijn.’
  • ‘er fouten in de doelstellingsfase worden gemaakt.’
  • ‘men niet de juiste tool kiest voor ‘het probleem’.’
  • ‘men te veel in één keer wil neerzetten.’
  • ‘de opdrachtgeversorganisatie onvoldoende helder heeft wat men exact wil bereiken.’
  • ‘de focus op de doelstelling en de businesscase verloren gaat.’
  • ‘men niet duidelijk weet wat men wil.’
  • ‘de organisatie niet klaar is voor de nieuwe manier van werken.’
  • ‘beslissers denken dat een pakketimplementatie al hun problemen oplost.’

Uit deze willekeurige greep uit de antwoorden van de projectbetrokkenen (consultants, projectleiders, etc.) blijkt een zekere onmacht. Onduidelijke uitgangspunten en doelstellingen zijn ook in hun ogen de voornaamste oorzaken voor falen.

Tweede faaloorzaak: de stevige managementaanpak

De tweede grote faaloorzaak typeer ik als volgt: ‘Het is de stevige managementaanpak die roet in het eten gooit.’ Dit zal ik toelichten. Eindverantwoordelijke opdrachtgevers hebben doorgaans erg weinig ervaring met grootschalige pakketimplementaties. Gemiddeld heeft men maar één of twee organisatiebrede IT-projecten als opdrachtgever meegemaakt. Daardoor ontbreekt het ze vóór aanvang van een omvangrijk project met standaardsoftware mogelijk aan een visie op het omgaan met onzekerheid in het project. Een manier om met die onzekerheid om te gaan, kan worden getypeerd als ‘de stevige managementaanpak’. Er staat veel op het spel en er mag niets misgaan. Dus de scope, het budget en de planning moeten vooraf 100% duidelijk zijn. Aangemoedigd door juristen en inkopers zet de opdrachtgever pas zijn handtekening onder een contract met de IT-leverancier als alle specificaties van het te realiseren IT-systeem 100% bekend zijn. Opdrachtgevers hebben daarnaast niet zelden een voorkeur voor een zogenaamd ‘fixed price contract’. Dit lijkt immers maximale duidelijkheid te geven.

De belangrijkste les die over ‘falende IT-projecten’ te leren valt, is dat het simpelweg onmogelijk is een complex project op voorhand helemaal in scope, tijd en budget te fixeren, en het systeem in zijn geheel te specificeren alvorens men het gaat realiseren. De meeste stevig gemanagede fixed price contracten gaan mis. Dit komt omdat het fixeren van scope, budget en planning niet alleen gevolgen heeft voor de prijs en de andere condities van het project, maar óók voor de samenwerking met het externe IT-bedrijf die de implementatie begeleidt. Dat is onder opdrachtgevers veel minder bekend. Bij het fixeren van een projectbudget wordt de onzekerheid over het verloop van het project niet weggenomen, ze wordt alleen overgeheveld naar de IT-leverancier. Dit heeft allerhande nare bijwerkingen die een goede samenwerking in de weg staan. De IT-leverancier gaat achter een façade van schijnzekerheid aan de slag. De kwaliteit van de samenwerking is lager omdat de informatievoorziening vanuit IT-leverancier naar de opdrachtgever onvolledig is. Uit het onderzoek blijkt dat projecten die in zijn geheel gefixeerd zijn in tijd en geld, váker teleurstellen dan projecten waarbij die fixatie op voorhand niet plaatsvindt. In beide faalvoorbeelden lijkt de aanpak overzichtelijk en gestructureerd. De ene keer is het doel losjes geformuleerd en zal het gaandeweg verhelderd worden, de andere keer wordt alles tot achter de komma gespecificeerd. Begeleid door professionele partijen zoals inkoop- en adviesbureaus, gaat men aan de slag. In beide gevallen gaat het uiteindelijk in meer dan de helft van de gevallen geheel of voor een deel fout. Organisaties leiden tonnen of zelfs miljoenen schade.

IT-bedrijven maken opdrachtgevers het uitglijden erg gemakkelijk

Organisatiebrede IT-projecten vragen een besturing die zich uitstrekt over alle disciplines, dus boven functionele domeinen als ‘de business’, stafafdelingen, en (externe) IT-specialisten. Daarom is IT-opdrachtgeverschap per definitie het werkveld van het algemeen management. Verstand hebben van IT is geen vereiste, wel goed opdrachtgeverschap! De grootste faaloorzaak is de ‘delegerende baas’ die de noodzaak voor deze besturing niet ziet, maar ook de Nederlandse IT-dienstverleners hebben een aandeel in het falen. Uit onderzoek blijkt dat de ene Nederlandse IT-dienstverlener de andere niet is. Vraag aan IT-dienstverleners: Hoeveel % van de eigen IT-projecten gaat over tijd én over budget of wordt afgebroken?

Dienstverlener A: 92%
Dienstverlener B: 12,5%
Dienstverlener C: 33%
Dienstverlener D: 30%
Dienstverlener E: 0%
Dienstverlener F: 10%
Dienstverlener G: 20%

Bron: Interviews met IT-dienstverleners: Accenture, Capgemini, CRMWaypoint, Deloitte, IBM, Innoveer en Ordina.

Bij één ‘gerenommeerde’ Nederlandse IT-dienstverlener faalt maar liefst 92% van de projecten, bij de anderen gebeurt dat minder, of bijna nooit. Dat is iets om óók even bij stil te staan. Uit het onderzoek volgt dat er een duidelijk verband bestaat tussen het gebruik van IT-richtinstrumenten door IT-bedrijven en het percentage eigen faalgevallen. IT-richtinstrumenten zijn hulpmiddelen die men kan gebruiken voor het richten (op bedrijfsdoelen) en gericht houden van een IT-project. Denk daarbij aan het maken en (tijdens het project) gebruiken een business case; het besturen van het project aan de hand van businessacceptatiecriteria, het gebruik van een op de bedrijfsstrategie gebaseerde projectfase-overgangstoets, et cetera. Hoe minder een IT-dienstverlener van deze instrumenten gebruik maakt en dus onvoldoende op het functioneren van een opdrachtgever let en hem of haar niet in de rol van actief betrokken eindverantwoordelijk opdrachtgever manoeuvreert, hoe groter de kans op falen. Dit simpele gegeven verschaft een eenvoudige lakmoesproef. Als het proces in de aanloop naar een IT-project goed is verlopen, is er een groot beroep op de businessmanager gedaan. Als het proces niet goed is verlopen, en de businessmanager is in zijn tijdelijke rol als IT-opdrachtgever nauwelijks betrokken, dan is te voorspellen dat het niet goed zal gaan.

Raad voor de Rechtspraak: weer IT-problemen in de maak

De Raad voor de Rechtspraak heeft in april 2010, na een mislukte aanbesteding in 2009, de draad maar weer  eens  opgepakt. Ze onderneemt nu een tweede poging voor het realiseren van een nieuw IT-systeem op basis van standaardsoftware. Budget: 10 miljoen. De aanbestedingsdocumenten (Viro 2010) zijn dit voorjaar gepubliceerd. Uit deze documenten blijkt dat de Raad helaas wederom een zeer ongelukkige benadering kiest, die zeer waarschijnlijk tot grote problemen gaat leiden. Het uitgangspunt voor de voorgenomen IT-investering zijn de organisatorische doelen die de Raad voor de Rechtspraak doormaakt. Dit stelt nieuwe eisen aan de invulling van de bedrijfsprocessen van de Raad. De noodzakelijke organisatorische verandering moet mede mogelijk gemaakt worden door een nieuw IT-systeem, dat bijvoorbeeld het digitaal procederen in de toekomst ook mogelijk maakt. In de uitwerking van de aanbesteding van het Viro-project vindt men dat niet terug. Niet de organisatorische uitgangspunten en de organisatorische doelstellingen van de Raad staan centraal, maar de toepassing van standaardsoftware (ICT): het vervangen van een verouderd IT-systeem. De vraagstelling is nadrukkelijk opgesteld vanuit vier IT-invalshoeken, hierin ontbreekt de organisatorische invalshoek (veranderissues, spanningvelden, mensen, politiek, cultuur, kennis, organisatiestructuur) zo goed als geheel. Het perspectief van de businessmanager ontbreekt dus in de paparassen. De kans dat de Raad voor de Rechtspraak haar IT-doelen en haar organisatiedoelen tijdens het project alsnog bij elkaar houdt (of krijgt) is, door het ontbreken van waarborgen en selectie-eisen in de selectieleidraad (het belangrijkste en meest onderschatte aanbestedingsdocument), laag. De Raad stelt geen gerichte eisen aan de bekwaamheid van gegadigden op het gebied van organisatieontwikkeling en implementatiemanagement, terwijl deze nu juist het belangrijkste struikelblok zijn bij de implementatie van standaardsoftware. De gevolgen laten zich goed voorspellen.

Verbazing

Bij het inleveren van dit artikel stelde hoofdredacteur Willem Mastenbroek de volgende vraag: ‘Nico, hoe kan het dat IT-bedrijven er dan niet voor zorgen dat het verantwoordelijke management bij de les blijft ??? Dat is toch eigenlijk een grote schande!‘ Hierin kan ik Willem alleen maar gelijk geven. Deze hele gang van zaken heeft mij ook verbaasd. Ik zal hier in een volgend artikel voor ManagementSite nader op ingaan. Hieronder alvast een voorschot:

  • Zes van de zeven ondervraagde IT-dienstverleners geven onomwonden toe dat de projecten die zij doen MEESTAL NIET goed gealined zijn met de businesskant van hun opdrachtgever;
  • IT-bedrijven laten na de doelen van een investering te checken. Ze brengen ook wanneer het businessdoel bij een klant NIET duidelijk is doodleuk een offerte uit;
  • Door de klant opgestelde business cases worden door IT-bedrijven niet of nauwelijks gecontroleerd;
  • IT-bedrijven krijgen (en nemen) veel te weinig tijd voor offertes;
  • De projecten worden door IT-bedrijven niet goed op voortgang gecontroleerd en vaak slecht en door sommigen zelfs geheel niet geëvalueerd, één gerenommeerd Nederlands IT-bedrijf legt anno 2009 stelselmatig alleen de ‘projectsuccessen’ vast, zodat gevreesd moet worden dat daar al jaren dezelfde fouten gemaakt worden;
  • Maatregelen die IT-bedrijven nemen om projecten op de rails te houden beslaan meestal uitsluitend IT-technische of projectmanagementaspecten, terwijl daar de uitdaging niet in zit. Projecten met standaard software mislukken immers niet door technische problemen, maar door miscommunicatie en het dichttimmeren van het samenwerkingsproces;

Het is dus een combinatie van onkunde en plat commercieel opportunisme. Klanten van IT-bedrijven hebben een significant lagere klanttevredenheid dan die van andere zakelijke dienstverleners. Deze situatie bestaat waarschijnlijk al vele jaren. Ze zal in mijn ogen blijven bestaan totdat eindverantwoordelijke opdrachtgevers eisen dat het beter moet. En hun verantwoordelijkheid daarin nemen.

De in dit artikel vermelde gegevens zijn afkomstig uit een onafhankelijk en representatief onderzoek van de auteur.

Het onderzoek bestond uit vijfentwintig gestructureerde interviews en een online enquête onder een zevental gerenommeerde IT-bedrijven waaronder Accenture, Capgemini, Deloitte, IBM en Ordina én hun klanten.

De onderzoeksbevindingen zijn samen met dertien praktische IT-hulpmiddelen voor businessmanagers gebundeld in een nieuw Nederlandstalig boek, getiteld ‘Lead IT or Lose IT’, dat onlangs is verschenen.

Kennisbank onderwerpen:

Kennisbank onderwerpen:

 

Reageer

Na het plaatsen kunt u uw reactie nog 30 minuten aanpassen.

Reacties

Opvallend artikel. Blijkbaar is er in 25 jaar nog geen steek veranderd. Ik heb 25 jaar geleden onderzoek gedaan naar verschillende automatiseringsprocessen in opdracht van de medezeggenschap en deze conclusies hebben wij toen ook al min of meer getrokken.

“Simonse, A., Tijdens, K. en Reijnen, M.H., Meer energie voor sociale verbe­tering: de sociale gevol­gen van een logistiek informatie­systeem bij een energiebedrijf, Weten­schaps­winkel van de Universi­teit van Amsterdam, januari 1988.”

Marcel Reijnen
senior trainer/adviseur medezeggenschap

http://www.depijl-mz.nl

Weinig nieuws in dit artikel, tenzij de lezer van een IT leverancier afkomstig is.

De ellende begint al met het label wat je op een project plakt. Semantiek is belangrijk en mensen gedragen zich naar hun perceptie die door semantiek wordt beïnvloed. Houd daarom op met gebruik van het label “ICT project”. Praat voortaan over verbeterprojecten (waar misschien ook wel een stukje ICT aan te pas komt). Het label ICT project zorgt automatisch voor een technische, instrumentele perceptie.

Dan de opmerking dat projecten bij de leverancier niet falen. Dat herken ik. Ik heb ooit een PRINCE2 cursus gegeven war het volgende zich afspeelde. Een van de aanwezigen, een redelijk ervaren project manager van een ICT leverancier, vertelde heel trots dat projecten van zijn organisatie vrijwel nooit faalden. Vervolgens vroeg ik hem of zijn klanten er ook zo over dachten. Het antwoord? Nee, zijn klanten hadden altijd wel wat te zeuren…

Nu we toch bij PRINCE2 zijn. Alle ICT leveranciers passen deze aanpak toe. Zeggen ze…
Wat vrijwel iedereen negeert, zeker ICT leveranciers, is dat PRINCE2 een klantenaanpak is, geen leveranciersaanpak. De aanpak stelt expliciet dat een projectmanager het beste van een klant kan komen. Waarom? Vanwege de twee conflicterende business cases. Het wordt in dit artikel “een combinatie van onkunde en plat commercieel opportunisme” genoemd dat een leverancier niet goed met de Business Case van een klant omgaat. Dat is helaas erg naïef. Een leverancier moet nooit verantwoordelijk worden gesteld voor de business case van een klant, kan dat ook niet, moet dat ook niet willen. De kostenkant van de klant is de omzet van de leverancier. Ook hier is PRINCE2 weer heel duidelijk, dit is de reden dat een projectmanager van de klant zou moeten komen of, wanneer niet mogelijk, onafhankelijk zou moeten zijn. De realiteit is dat de PM vrijwel altijd van de leverancier komt en daarmee introduceer je een gigantisch risico. De opdrachtgever weet dit niet en de leverancier wil dit niet weten.

Dan komt het bij veel klanten, zeker bij de overheid, steeds vaker voor om een sterke CIO aan te stellen. Deze CIO neemt dan het opdrachtgeverschap voor de rekening van ICT projecten. En daar gaan we weer. Dit middel is vrijwel altijd erger dan de kwaal.
1. Het label ICT projecten komt in alle hevigheid terug
2. De CIO is natuurlijk niets anders dan een leverancier. Weliswaar een interne, maar nog steeds een leverancier. Zou je een externe leverancier ook zo veel macht geven? Een interne leverancier heeft ook een tegenstrijdige Business Case, alleen zal deze vaak politiek zijn.
3. Een CIO, net als andere C-level functies, is een uiting van de functionele organisatie. Iedereen die goed op de hoogte is van deze materie, zal stellen dat de functionele organisatie verandering in de weg staat en projecten bedreigt.

Nico Viergever
Management consultant, trainer
PRINCE2/MSP trainer

Bij de titel van dit artikel kreeg ik een enorme jeuk: De opdrachtgever bepaalt of een project succesvol is, dus hoe kan hij daar dan een risico voor zijn? Toen ik las dat de ondervraagde opdrachtgevers het falen heel anders ervaren, ontspande ik weer. Natuurlijk, want daar zit hem de crux. Wanneer gaan projectmanagers, projectleiders, of (in de context van dit artikel) IT-bedrijven nu eens beseffen dat zij ondersteunend zijn aan (en niet leidend in) de wensen van de opdrachtgever? Wanneer gaan we nu eens begrijpen dat een project pas een project is ALS je een doel helder kunt stellen. En zolang je dat nog niet kunt heb je geen project maar (bijvoorbeeld zoals in lijn met Viergever) een traject, of een proces, of een ding of een idee dat je graag wilt uitwerken.

Dus Nico, toen je schreef dat ‘de opdrachtgever niet de juiste vragen stelt en daardoor niet effectief is in het bewaken van de voortgang van het project’, bedoelde je toch de projectleider?

Ik ben het volledig met Willem Mastenbroek eens en kijk uit naar je vervolgartikel!

Groeten,
Nicoline Mulder

p.s. Baccarini (1999) heeft onderzocht dat projectsucces een formule is van projectmanagementsucces (binnen tijd en geld opleveren) en productsucces (doet het ding wat ie moet doen, m.a.w. is de opdrachtgever tevreden?), waarbij de laatste vele malen belangrijker is dan de eerste.

Helaas, Nicoline. Ik ben het eens met jouw betoog maar de realiteit is helaas anders.
Ik herkende wat in het artikel was geschreven: een opdrachtgever die zich afzijdig houdt omdat het toch over ICT, iets technisch gaat. En dat moet je vooral aan de ICT overlaten.

Misschien even terugdenken aan het commentaar van een SAP directrice, een paar jaar geleden. Zij klaagde erover dat de gebruikers niet voldoende betrokken waren en dat daarom zoveel SAP implementaties faalden. Natuurlijk snapte deze dame het niet echt. Gebruikers zijn per definitie niet betrokken als een project een technisch lading krijgen (dus in jouw en mijn visie geen goed opdrachtgeverschap hebben) en wanneer, zoals bij ERP, je als gebruiker overal een mening over mag hebben maar het pakket dicteert de structuur.

Denk even aan de UWV casus van een paar jaar geleden. Het project was oorspronkelijk gepland voor, ik dacht, 6 miljoen. De stekker werd eruit getrokken bij een besteding van bijna 90 miljoen terwijl de laatste onzekere raming uitging van 125 miljoen.
Het project werd beschreven als integratie van IT systemen en het falen werd toegelicht door de hoogste ICT baas. Voor mij geen verdere toelichting nodig: doel en middel zijn weer eens verward.

PS: n.a.v. jouw op tijd en binnen budget opmerking. Randstadrail en Heathrow T5 leverden op tijd en binnen budget op. Vervolgens brak de hel los. In zijn standaardwerk over Project Based Work schreef J.Rodney Turner over een onderzoek in Australië, begin jaren 1990. De conclusie was dat ALLE bekeken projecten die op tijd en binnen budget eindigden na vijf jaar werden gezien als mislukt! De kosten/tijd discussie is goed voor routine werk, dat is betrouwbaar te plannen. In een project moet je ook andere factoren in ogenschouw nemen.
Zoals Randstadrail, Heathrow T5, Betuwelijn en vele andere voorbeelden aantonen: een project sturen op ALLEEN tijd en geld is dodelijk.

Het tocht hier. Dat komt door alle open deuren.

Natuurlijk weet de opdrachtgever meestens niet precies hoe zijn wensenboekje zodanig in te vullen dat zowel zijn businesscase als het IT project er ondubbelzinnig in zijn gevangen. Van zijn businesscase mag je veronderstellen dat ie alles af weet, alhoewel dat ook niet altijd zo is.

De eerste eis die je aan een GOEDE leverancier van een GOED IT-product mag stellen is dat ie de opdrachtgever helpt bij het goed formuleren van zijn wensen. Hij let daarbij op cause & effect, plausibiliteit en consequenties in tijd, geld, capaciteit en proces-performantie. De performantie van de businessprocessen van de opdrachtgever die IT ondersteund moeten gaan worden bedoel ik dan. Indien noodzakelijk laat hij zich bijstaan door terzake deskundige proces engineers, marketeers etc.

Als de IT leverancier dat niet kan moet ie zijn huiswerk doen. Als ie het wel kan maar denkt in uren x tarief (werkgelegenheid & kassa) of “na ons de zondvloed”, dan verdient ie solide strafpunten. Het kan betekenen dat ie een van zijn concurrenten moet adviseren.

De IT leverancier heeft dan gewoon goed verdiend (uren x tarief) en de klant moet snappen dat het voorwerk noodzakelijk en critisch en 100% resultaatbepalend is en dat daarvoor gewoon betaald moet worden. Als ie dat snapt betaalt ie ook gewoon. Als ie het niet snapt kun je wel leveren, maar da’s nie mooi en keert zich op den duur tegen de IT leverancier. Als je het niet doet, ben je gewoon een boormachine verkoper: “Hier heb je je boor, de gaten moet je zelf maken”.

Dames & heren IT-ers: doe dat nou gewoon, want je hebt als groep al een slechte naam.

Groet,
Jos Steynebrugh
Marketing & Innovatie Consultant

Jos,
Al die open deuren, maar de gemiddelde ICT-er blijft maar met zijn neus tegen die dichte deur aanlopen…

Trouwens, ook die inkoper van een overheidsinstelling die volgens (zijn versie van) de Europese aanbestedingsregels werkt. Een vage beschrijving van de verwachtingen maar toch een fixed time/price eisen. En natuurlijk heel, heel veel nadruk op onbelangrijke eisen (grootte leverancier, omzet van de afgelopen jaren, etc).
En uiteindelijk afrekenen op prijs alleen: de goedkoopste!

En er dan van staan te kijken dat projecten niet veel opleveren, na afloop veel onderhoudskosten eisen en (!) ongewenst gedrag van leveranciers wordt afgedwongen (bouwfraude affaire), dit alles door (de toepassing van) aanbestedingsregels.

Dus nog een gezellige open deur. Het blijft tochten. En er blijven mensen tegen gesloten deuren aanlopen…

En wat dat precies weten van de Business Case betreft: dat is de boekhouders perceptie. Die willen altijd een sluitende business case, zoals de minister van Financien bij de Betuwelijn. Maar met gezond verstand weet je dat een business case flexibel is en zich tijdens een project zal ontwikkelen. En zolang zaken binnen de tolerantie blijven, is dat acceptabel.

Triest, zoveel missers.

In het artikel wordt gemeld dat het falen aan opdrachtgever of aan IT-leverancier ligt. Er mist gewoon een laag.

Tussen opdrachtgever en IT-leverancier zit een projectmanager. De projectmanager is vanuit de business kant verantwoordelijk voor het project en het slagen ervan. Business cases worden door de (business) projectmanager gecheckt, niet door de IT-leverancier. De projectleider moet de bedrijfssituatie kennen en met de projectmanager aan de IT-kant kunnen sparren.
En het is geen CIO, want dan schuift de verantwoordelijkheid weer naar de IT-hoek.

Frappant is dat vaak de projectmanager aan leveranciers kant gezien wordt als DE projectleider. Zoals Viergever al duidelijk aangeeft, heeft een leverancier andere belangen dan een klant. Het enige gemeenschappelijke is het succes van het project en hoe dit succes ervaren wordt is voor de klant anders dan voor de leverancier.

Als een klant geen krachtige en ervaren projectmanager aan de business kant heeft, dan huur een goede in die onafhankelijk van de IT-leverancier is. Een projectleider die ook bij de opdrachtgever de focus op het project houdt, want achteroverleunen als de IT-leverancier na veel moeite gekozen is, is er tijdens het project niet bij.

Verder vind ik dat het niet alleen aan de opdrachtgever is om duidelijker te zijn, maar ook aan de leverancier om duidelijkheid te eisen. Beter langer doorgaan op helder krijgen wat het resultaat moet zijn dan maar beginnen en wel zien. En als een opdrachtgever echt niet weet wat hij/zij wil, stel een prototype voor als start. Dat geeft vaak op snelle wijze een goed idee van wat er gewenst is.

Jeanine Hendrikx
Business consultant

Nico,
wat ik bedoel met “Businesscase” is de het strategisch marketingplan van de opdrachtgever. Hij moet weten wat zijn klanten EN potentiële klanten in 2000-nu willen en een goed vermoeden over wat die over 3 jaar waarschijnlijk zullen willen. En of ie daar in wil voorzien. Dat zijn strategische keuzes die zich 1:1 vertalen in ondersteunende bedrijfsprocessen. Pas daarna komt IT als ondersteunende functie aan de orde. Volgend dus en niet leidend.

Ik heb gezien dat veel IT leveranciers de cruciale topics uit een branche niet kennen en TOCH hun software plus diensten willen slijten. Maar ik heb ook gezien dat een bedrijf vindt dat zijn processen zo bijzonder zijn dat ze niet naar de software toe wil reorganiseren. Dat, terwijl de softwareleverancier soms (bijvoorbeeld SAP) het probleem al vele (of vele duizenden malen) heeft getackled en daaruit een brancheoplossing heeft geboetseerd. Als de opdrachtgever hardnekkig niet willen “volgen” dan is dat vaak eigen schuld, dikke bult.

Paradoxaal hierbij is dat hoe slechter het afgeleverde product, hoe meer de kassa tikt door ondersteuning (uren x tarief). En dat laatste is een héééle kwalijke zaak.

Groet,
Jos Steynebrugh

Mijn eerste reactie bij dit artikel is: Veel woorden voor weinig nieuws.

Het is toch vreemd dat we zo veel geld spenderen aan het ontwikkelen of aanschaffen van een projectmanagementmethode, aan het certificeren van al onze projectmanagers en last but not least aan het aanschaffen van de meest geavanceerde projectmanagement software. En toch gaat er na al die jaren nog zoveel mis. Ligt dat inderdaad grotendeels aan de opdrachtgever?

Wel hier komt mijn nieuws: Het falen van projecten ligt aan de factor mens in het project! Ofwel de mate waarin de soft skills in balans zijn met de hard skills van projectmanagement.

En we kennen veel mensen in een projectorganisatie: inderdaad de opdrachtgever maar ook een scala aan andere stakeholders. We kennen programma managers, project managers, projectleden en project sponsoren. En vervolgens groeperen we al deze mensen, die vaak nog nooit met elkaar hebben samengewerkt, in een tijdelijke (project)organisatie en verwachten we de grootste wonderen.

Waarom kennen we in elke reguliere organisatie een scala aan (HRM) instrumenten die er op gericht zijn om een organisatie effectief te laten functioneren en verwachten we dat een tijdelijke (project)organisatie dat vanaf dag 1 vanzelf doet?

Terug naar de strekking van het artikel. Als het falen van projecten inderdaad grotendeels ligt aan de opdrachtgever, dan heb ik de volgende mens-georienteerde projectvragen:

– hoe heeft de projectorganisatie de opdracht van de opdrachtgever vertaald naar een goed doorleefde projectmissie inclusief de vertaling naar projectresultaat en resultaat voor de opdrachtgever?
– hoe hebben we de besluitvormingscriteria waarmee het project door de opdrachtgever is goedgekeurd vertaald naar projectvoortgangscriteria, zodanig dat deze criteria centraal blijven staan in de projectbesturing?
– hoe hebben we de opdrachtgever betrokken in projectbesturing en besluitvorming?
– hoe hebben we de belangen van de opdrachtgever en die van de andere stakeholders vertaald naar een gemeenschappelijk belang?
– hoe hebben we dit gemeenschappelijke belang centraal gesteld tijdens alle projectfasen en bij alle projectbetrokkenen?
– hoe hard hebben we de opdrachtgever durven sturen op ‘scope creep’?
– welke afspraken hebben we met de opdrachtgever gemaakt en welke verwachtingen hebben we naar elkaar uitgesproken? Hoe hebben we dit gedurende het gehele project bewaakt?
– in hoeverre hebben we op basis van vooraf gedefinieerde criteria de projectafsluiting met de opdrachtgever doorlopen?
– in hoeverre hebben we de projectorganisatie begeleid om uberhaupt met de opdrachtgever te durven en kunnen communiceren?

Moraal van dit verhaal: vindt een balans tussen de project hard- en soft skills om de projectslagingskans substantieel te vergroten.

Stef de Bont
http://www.effectif.nl

Het artikel, en ook de meeste reacties, gaan voorbij aan de mogelijkheid dat een opdrachtnemer “nee” kan zeggen tegen een “inadequaat functionerende opdrachtgever”. Dit raakt aan de beroepsethiek van de professionele projectmanager. Want “ja” zeggen terwijl je weet dat het eigenlijk niet kan is nogal onethisch. Zullen we het daar eens over hebben. Want de paradox van Jos (slecht afleveren is omzet) heeft daar alles mee te maken.

Teun,
Natuurlijk is dit een punt. Zeker bij de overheid mislukken projecten door slecht opdrachtgeverschap waardoor al niet zo best opererende leveranciers gedwongen worden nog slechter te presteren. O.a. aanbestedingsregels lokken dit uit, dwingen dit zelfs af.

En inderdaad, Jos, ik heb het zelf meegemaakt bij een grote ICT consultancy dat ik een verliesgevende offerte moest opstellen. Dat maakte niet uit, de eisen waren zo vaag en zacht dat de leverancier met rommel zou wegkomen. De winst zou later bij het onderhoud wel gemaakt worden.

Echt gebeurd en ik vond / vind het schandalig. Maar dat werd destijds door de aanbestedingsprocedure en de inkoopafdeling afgedwongen.

Zowel opdrachtgever a;s leverancier gedragen zich slecht. Probeer het maar eens te doorbreken. Ik zou niet weten hoe. Maar het initiatief moet, denk ik, bij de opdrachtgever liggen.

Als onafhankelijke heb ik het jaren vergeefs geprobeerd; geen doorkomen aan.

Sinds wanneer is het de schuld van de klant dat hij niet krijgt wat hij nodig heeft? Wat een onzin!

De verantwoordelijkheid ligt toch echt bij de leverancier om ervoor te zorgen dat de klantvraag in eerste instantie duidelijk wordt geformuleerd en vervolgens passend wordt ingevuld. Wanneer je aan de slag gaat zonder zeker te weten wat een klant nodig heeft en vervolgens ook niet in staat bent dat snel te achterhalen, geef je gewoon een brevet van onvermogen af. Wat dat betreft ben ik het volledig met Jos eens en spreekt vooral de formulering van Stef zijn “projectvragen” aan, want hij heeft het over “we” en slaat daarmee terecht de spijker op de kop van de opdrachtnemer.

En laten we nou niet gaan klagen over inkopers die de duimschroeven aandraaien. Dat is gewoon hun vak en het is de verantwoordelijkheid van een leverancier om duidelijk aan te geven wanneer de eisen conflicteren met de gevraagde oplossing.

Groet,

Mike Moolenbel

Heerlijke reactie, Teun!
Als de projectmanager zijn professionele beroepsethiek in acht neemt, zijn we inderdaad van vele niet-ter-zaken-doende discussies zoals hierboven verlost. Dan gaat het niet over geld, maar over mooie resultaten. Niet over schuld, maar over collectieve ambities. En niet over managen, maar over inhoud en trots. Dan is de vraag niet ‘hoe doorbreek ik dat?’, maar ‘hoe zorg ik dat ik alleen die dingen doe waar ik achter sta?’.
Als we als projectleiders maar vaak genoeg ‘nee’ zeggen tegen opdrachten waarbij we op voorhand weten dat ze gaan mislukken, sterven die falende opdrachtgevers en slechte werkgevers vanzelf uit…

Mike,
Wel eens met een openbare aanbestedingsprocedure te maken gehad? Duidelijk niet. Bij mijn eerste keer had ik dezelfde reactie tot iedereen om mij heen begin te lachen om mijn naïviteit.
Ik kreeg een pakket van eisen wat enorm abstract en boterzacht was, dus ik wilde een afspraak maken om duidelijkheid te verkrijgen. Maar als onderdeel van de procedure is overleg verboden! Alle potentiële leveranciers mochten hun vragen inzenden waarna in een open zitting antwoord werd gegeven. Geheel voorspelbaar leek deze sessie op een pokertoernooi; alle potentiële leveranciers lieten niet het achterste van hun tong zien om hun concurrenten niet wijzer te maken. Deze sessie was dus zinloos en de eisen bleven vaag.
Het resultaat: weer een falend project.

Wat een mooie reacties. Er zijn mensen zoals Nicole en Jeanine die vinden dat de PM in de analyse ontbreekt en dat de PM de missende sleutel is, waarop de hoop beslist gevestigd moet zijn. En er zijn mensen zoals Stef die vinden dat het ligt aan de mate waarin de soft skills in balans zijn met de hard skills van projectmanagement. Er zijn ook mensen zoals Jos en Nico V. (mag ik dat concluderen ?) en ikzelf die de opdrachtgever wat meer verantwoordelijk houden. Een schuldige aanwijzen is niet te doen en is ook niet zinvol. Mijn bottom line is wel dat projecten, projectmanagers en IT het gereedschap zijn van een opdrachtgever. Met goed gereedschap, meer ethiek en betere adviezen (zoals Teun en Mike bepleiten) zou het een stuk beter gaan. Een opdrachtgever heeft daar recht op. Feit is dat de praktijk (en mijn onderzoek) uitwijst dat dit vaak ontbreekt. De IT-business – de enkele goede daargelaten- is nog erg onvolwassen en erg opportunistisch. PM’s en IT’ers overschatten hun eigen invloed vaak: veranderen vanuit een enkele blauwdruk heeft zo z’n nadelen. Het uitglijden wordt dus vergemakkelijkt. Maar als een opdrachtgever ook nog eens geen plan heeft en geen leiderschap vertoont/heeft … heb je UWV, AMC, SVB, ANWB, en al die andere IT-zeperds. Deze organisaties zijn als gevolg daarvan stuk voor stuk trieste, naargeestige informatiedoolhoven. Geleid door leiders die zeggen ‘gelukkig geen verstand van IT te hebben’ of zelfs helemaal wegduiken. Ze maken de IT-adviesmarkt voor pappen en nathouden, al dan niet in projectvorm, erg lucratief, maar met serieus management heeft het niks te maken. Mijn conclusie is (met Marcel) dat het probleem er nog wel even zal zijn. Ik heb mijn hoop gevestigd op, en mijn boekje geschreven voor, de businessmanager/opdrachtgever die wel z’n schouders eronder wil (kan en hopelijk mag) zetten.

@Nico
. . . . De winst zou later bij het onderhoud wel gemaakt worden . . . schrijf je

Dat is BLOEDLINK!!!
Case (echt gebeurd)
Keurige offerte voor 600 hele dikke moddervette PC’s bij een account dat we al hadden, maar waar we de deur naar de concurrentie hermetisch wilden afsluiten.

Gesprek tussen inkoper en verkoper. Jullie zitten te hoog. Intern overleg. Verkoper nogmaals naar inkoper, nu met de instructie WAAR zitten we te hoog?

Passen, meten en nogmaals. Lang verhaal met als slotsom: hardware met negatieve marge, software met een forse korting en diensten idem. Offerte wordt bijgewerkt. Totale prijs ONDER de kostprijs. Geeft niet, halen we wel terug met helpdesk en opleidingen.

Sure kregen we de opdracht, maar dan zonder de opleidingen. Die gingen ze zelf doen (train the trainer programma). Dikke vette niet-coole pech. Resultaat: wèl de omzet, maar met zwaar negatief resultaat. De verkoper bleef er stoïcijns onder: “Diebinnebennebennebinne”.
Dat beaamde de verkoopleider, maar NIET de financiado.

De flessen bubbeltjes gingen open, maar géén echte champagne deze keer.

Groet,
Jos Steynebrugh
Marketing & Innovatie Consultant

@Jos: natuurlijk is dat bloedlink. Maar niet alleen voor de leverancier. Je kan het zelfs als bedrog zien. Maar het is ook doodnormaal! Dat is het griezelige.

Ik houd mij al enige jaren bezig met het thema ‘Goed Opdrachtgeverschap’ en het valt mij op dat in alle reacties geen onderscheid wordt gemaakt tussen de verschillende projecten waarvoor opdrachtgevers zich geplaatst zien.
Outsourcing, maatwerksoftware ontwikkeling, standaardsoftware implementatie zijn drie typen projecten die alle een eigen dynamiek en dus ook een eigen besturing vragen.

Maar wat altijd geldt is dit:

Natuurlijk is de opdrachtgever verantwoordelijk, net als een CEO of voorzitter van de RvB verantwoordelijk is voor alles wat er in zijn /haar bedrijf door medewerkers wordt gedaan (of nagelaten).
Natuurlijk dient de gebruikersorganisatie een samenhangend pakket van eisen op te stellen waaraan de gewenste oplossing moet voldoen.
Natuurlijk vereist de ethiek dat een project- of programmamanager zijn/haar opdrachtgever helpt en ook beschermt tegen ‘missons impossible’
Natuurlijk is een zichzelf respecterende IT-leverancier verplicht om zich te verdiepen in het probleem van de klant en met een passende oplossing te komen.

De praktijk echter laat zien dat deze ‘natuurlijkheden’ eerder uitzondering dan regel zijn en dus is het pleidooi voor een opdrachtgever die niet alleen verantwoordelijk is, maar ook verantwoordelijkheid neemt, volledig op zijn plaats.

Een dergelijke opdrachtgever zal zich dan ook omringen met deskundigen op het terrein van de gewenste IT oplossing, op het terrein van de organisatie waarbinnen het project zich afspeelt en op het terrein van het uitvoeren van het project zelf.

In Prince2 termen noemen we dit een stuurgroep of project board waarin behalve de opdrachtgever (Business Executive) ook de Senior User (vertegenwoordiger met mandaat van de gebruikersorganisatie) en de Senior Supplier(s) (vertegenwoordiger(s) met mandaat van interne en externe leveranciers) zitting hebben.
Deze personen dienen zodanig gemandateerd te zijn dat zij zelfstandig alle beslissingen die in de loop van het project aan de orde kunnen komen kunnen nemen zonder te worden teruggefloten.
De projectmanager/leider treedt in dit gremium op als procesbegeleider en zorgt dat alles wat ter tafel moet komen voor een succesvol verloop van het project, ook daadwerkelijk wordt besproken en besluitvorming plaatsvindt.

Ethiek wordt ‘natuurlijk’ als je in een project board keihard met de gevolgen van eventueel on-ethisch gedrag wordt geconfronteerd en je ten overstaan van je ‘peers’ met de billen bloot moet.
Verantwoordelijkheid wordt ‘natuurlijk’ als de gevolgen van onverantwoordelijkheid elke vergadering expliciet worden gemaakt.
Weten wat je wil/nodig hebt wordt ‘natuurlijk’ als de gebruikers scope-creep of ‘zwabberen’ elke keer weer moeten uitleggen en onderbouwen.

Afwijken van de oorspronkelijke doelstellingen en eisen wordt natuurlijk als het voor iedereen in deze groep aannemelijk en aanvaardbaar wordt gemaakt waarbij de gevolgen (zowel financieel als organisatorisch als in de tijd) door een ieder worden onderschreven.

Zo leiden we toch ook onze bedrijven??!

Goed artikel. Ben het met de auteur eens dat een opdrachtgever geen verstand hoeft te hebben van ICT. Deze kennis kun je inhuren. Echter, als opdrachtgever moet je wel weten welke kennis je op welk moment moet mobiliseren. En dat op verschillende momenten van een investeringstraject.
Ben het met de stelling eens dat slecht lopende projecten (en niet alleen in de ICT) voor een belangrijk deel zijn terug te voeren op een gebrek een Goed Opdrachtgeverschap. Maar zolang een Business Manager niet wordt afgerekend op het invullen van de rol van opdrachtgever, zullen deze misstanden blijven bestaan. Bestuurders hebben dan ook zelf de sleutel in handen om hier verandering in aan te brengen. De “Sense of Urgency” ontbreekt echter. Blijkbaar hebben organisaties de financiele ruimte om deze misstanden te laten bestaan. In ieder geval wordt het belang van een goede invulling van de rol van opdrachtgever zwaar onderschat. Bij de Business Managers en bij hun bestuurders!

Hoewel de Business Managers, die de rol van opdrachtgever vervullen, geen verstand van ICT hoeven te hebben, moeten zij wel in staat zijn verandering én continuïteit te managen. Een opdrachtgever bevindt zich op het snijvlak van een staande- en een projectorganisatie. En hiervoor is wat meer kennis en ervaring nodig dan het managen van een afdeling. Te veel geld en energie wordt gestopt in het verbeteren van de kwaliteit aan uitvoerende (lees projectmanagement) kant. Beter is het om een deel hiervan te besteden aan het verbeteren van de kwaliteit aan opdrachtgevende kant. Dit levert aanzienlijk meer rendement op. Helaas nog teveel een taboe.

Derk Kremer – Specialist in Goed Opdrachtgeverschap

[…] of event hier?   In mei publiceerde ik op managementsite het artikel Opdrachtgever grootste risico bij IT-projecten over een Nederlands onderzoek naar falende IT-projecten waaruit bleek dat eindverantwoordelijke […]

Ik ben het met de stelling eens, maar dan vanuit het perspectief dat de klant vaak niet weet wat hij nodig heeft. Vaak ontbreekt er een duidelijk doel. En dat doel mag inderdaad niet zijn het puur vervangen van IT Systemen. Het kan wel een noodzakelijke conditie zijn voor benodigde veranderingen binnen de organisatie, maar nooit het doel.
Ik ben van mening dat het doel van een onderneming het genereren van geld is nu en vooral in de toekomst. Dus, elk project moet erop gericht zijn om geld te genereren. Echter, de mogelijkheid om geld te genereren wordt beperkt door bestaande belemmeringen in de bedrijfsvoering. Dus, de meerwaarde van projecten moeten komen uit het feit dat het beperkingen opheft. Echter, om meerwaarde te realiseren, een bottom-line resultaat, is technologie noodzakelijk, maar niet voldoende. Immers, de grootste belemmeringen om de prestatie van de onderneming te verhogen en dus geld te genereren, zijn regels en procedures. Deze komen vaak voort uit huidige paradigma’s. Eén van de grootste paradigma’s is die van de kosten orientatie en de daarmee gemoeide locale efficienty syndroom. Alle onderdelen moeten efficient verlopen volgens dit paradigma. Maar, is dat wel noodzakelijk. Een bedrijfsketen is als een ketting en de sterkte van die ketting wordt bepaald door de sterkte van de zwakste schakel. Dus, alle andere schakels hebben een grotere sterkte, oftwel overcapaciteit. Dit is het eerste type belemmering waarmee bedrijven te maken hebben; fysieke belemmeringen. De belangrijkste les hiervoor is wat Deming ons trachtte duidelijk te maken en wel dat ‘optimaliseren tot op ruisniveau niet alleen zinloos is, maar zelfs schadelijk. Zolang het systeem oscilleert binnen de grenzen van de ruis, zal elke vorm van ingrijpen de fluctuaties aleen maar groter maken’.
Een project moet er dus op gericht zijn oo de zwakke schakels en niet op alle schakels. Dit kostenparadigma heeft ertoe geleid dat projecten niet goed gescreened en geprioritiseerd worden en veelal gericht zijn op teveel schakels in de gehele keten. Het gevolg is een te brede scope, complexiteit en teveel “configuratie” en “features”.
Met betrekking tot ERP Systemen, is het helaas ook nog eens zo, dat bedrijven één op één hun oude manier van werken overzetten op het nieuwe systeem. Mijn ervaring is dat dit dus niet leidt tot optimale bedrijfsprocessen. Men moet hierbij inderdaad best practice bedrijfsprocessen overnemen indien dit geen impact heeft op de competitive advantage en daar aanpassen waar nodig. Een van de belangrijkste reden voor het één op één overnemen van bestaande methodes en werkwijzen is het feit dat er in het verleden hiermee work-arounds zijn gevonden voor toen bestaande belemmeringen. Deze belemmeringen worden vaak veroorzaakt door bestaande regels en procedures. Dit is het tweede type belemmering. Dus, indien een project succesvol wilt zijn en de onderneming er profijt van kan hebben, moet er ook gekeken worden naar alle regels en procedures en indien nodig aangepast en/of zelfs verwijderd worden. En dit gebeurt dus vaak niet, met alle nare gevolgen van dien.
Indien dan ook nog niet de goede medewerkers op een project worden gezet en/of dat de meest capabele medewerkers slechts part-time worden ingezet, dan kan men er gif op innemen dat projecten ook nog eens niet op tijd en boven budget worden opgeleverd. Dit heeft te maken met het feit dat mensen die op projecten werken niet aan multi-tasking moeten doen, omdat het gevolg hiervan is dat men alle taken uitsmeert en dus de totale doorlooptijd toeneemt.
Een project kan dan ook alleen maar succesvol uitgevoerd worden, indien de juiste mensen op de juiste manier gepland en ingezet worden. Anders, krijgt men altijd te maken met overschrijdingen in tijd en geld.

[…] Lees verder op Managementsite en discussieer mee! AKPC_IDS += "2663,"; […]

[…] Opdrachtgever grootste risico bij IT-projecten Met delegeren red je het niet Dat IT-projecten vaak mislukken is bekend. De opdrachtgevers zijn vaak zélf verantwoordelijk voor de problemen. Sommige gerenommeerde IT-bedrijven maken hen het uitglijden wel erg gemakkelijk. […]

Toon alle 23 reacties
x
x