Volgens Computable-experts komt het regelmatig voor dat een businesscase te rooskleurig wordt ingeschat. Dat gebeurt lang niet altijd bewust, maar heeft ook te maken met de grootte en het innovatieve karakter van het project. Bovendien heb je bij een businesscase sowieso te maken met aannames. Het kan daarom zijn dat het project tussendoor moet worden gewijzigd.
Het komt regelmatig voor dat een businesscase voor een ict-project te rooskleurig wordt ingeschat. Dat zeggen Computable-experts. Het Servicecentrum Drechtsteden rekende in de businesscase te vroeg op voordeel uit het nieuwe ict-platform. Nu blijkt dat er nog twee miljoen euro nodig is om de oude applicaties te beheren. "Het komt vaak voor dat de ict-perceptie in het project op essentiële elementen afwijkt van de praktische situatie van de gebruiker", zegt Herman Heller, managing partner van Helderinzicht.
"Zeker bij complexere projecten is het voor een beoordelaar nauwelijks te overzien hoe realistisch de aannames zijn", zegt Marco Plas, evangelist van het Jericho Forum. André van Dalen, delivery director bij Amis, denkt dat het te maken heeft met de roze bril die initiatiefnemers ophebben. "Zij zijn vaak zeer enthousiast over vernieuwing en kiezen een rooskleurig scenario." Vooral bij nieuwe zaken is het lastig een goede businesscase op te stellen, zegt Mat Maas, directeur van DTP Work. "Men heeft dan geen referenties waarmee een en ander kan worden vergeleken."
Voorspellend
Doordat een businesscase een voorspellend karakter heeft, is de kans groot dat het rooskleurig wordt ingeschat, zeggen veel experts. "Er wordt met aannames gewerkt wat betreft de mogelijke opbrengsten van het eindresultaat", zegt Jaap Kalsbeek, partner bij TopSquare. Daardoor wijzigt de scope van het project. "Gemiddeld wijzigen requirements tijdens projecten zo'n twintig tot 25 procent", zegt Sander Hoogendoorn, principal technology officer bij Capgemini. "Bij het project bij de Drechtsteden kan ik me goed voorstellen dat initieel niet alle van de honderden applicaties zijn ‘ontdekt'."
Beste business case 2009
De redactie van Computable zoekt naar de beste business case van het jaar 2009. Een vakkundige jury buigt zich over voorgedragen cases en kiest de uiteindelijke winnaar.
Via een invulformulier kunnen bedrijven hun business case bij Computable aandragen. Uiteraard zijn business cases van afgeronde projecten welkom, maar ook de business cases van nog lopende of nog te starten projecten zijn welkom. Zolang de business case of het project maar linkt aan het jaar 2009.
Het aanmelden van business cases kan tot en met 20 januari 2010. In april 2010 worden de beste business cases van 2009 bekendgemaakt, mede in de jaargids Computable Business Cases 2010.
“Bij het project bij de Drechtsteden kan ik me goed voorstellen dat initieel niet alle van de honderden applicaties zijn ‘ontdekt’.”
Dit zijn typerende opmerkingen van bedrijven als CAPGEMINI. DIt hebben ze ook graag zodat er extra omzet gescoord kan worden en met de aanbesteding de deal geclosed kan worden. Dit is het andere graaien waar in de Media te weinig aandacht aan wordt
besteed.
Bedrijven die wel realistische offertes en Business Cases schrijven scoren gewoon weg de deals niet of niet altijd en zeker niet bij een overheid waarbij prijs vele punten oplevert bij een aanbesteding..
Het ligt natuurlijk ook aan de ICT managers dit de rose wolk BC beter kan verkopen intern dat die van het Bedrijf die de degelijke BC aanlevert.
Maatschappelijk Ondernemen is nog ver weg.
Maatschappelijk ondernemen is toch echt iets anders in mijn mening.
Wikipedia beschrijft het als: “Maatschappelijk verantwoord ondernemen (MVO) of duurzaam ondernemen is een vorm van ondernemen gericht op economische prestaties, met respect voor de sociale kant,binnen de ecologische randvoorwaarden.”
Wat jij waarschijnlijk bedoeld is de morele verantwoordelijkheid van een leverancier om de klant tegen zijn eigen enthousiasme te beschermen.
Terug on-topic: CAP Gemini is gewoon een leverancier, net als ATOS, KPN, Logica, noem maar op. Zij acteren op basis van een vraag van een klant. Helemaal omdat het hier een overheidsinstantie betreft en dus middels aanbestedingen wordt gewerkt moet CAP zelfs uitgaan van die informatie die is geleverd. Dat de klant vervolgens niet kloppende informatie aanlevert is niet de schuld van de potentiele leverancier. Dat een leverancier dat al meecalculeert is niet slim, hoe nobel de intentie ook is.
Ik ben wel met je eens dat, op basis van de expertise van de leverancier, de klant wel bewust gemaakt zou moeten worden van het feit dat bijvoorbeeld initiele inventarisaties heel vaak fout gaan omdat het meestal groffe schattingen zijn en geen daadwerkelijke metingen.
Organisaties zouden, zoals het artikel ook al stelt, kritischer en realistischer moeten zijn in hun BC’s. Vaak wordt een besluit genomen op basis van beperkte en optimistische informatie geleverd door een enthousiasteling die door zijn eigen enthousiasme een blinde vlek heeft voor de risico’s.
Organisaties zouden er goed aan doen om met grotere projecten onafhankelijke advies aan te vragen die juist op dit soort veel voorkomende fouten kunnen wijzen. Dat kan ook vanuit de eigen organisatie maar bijvoorbeeld vanuit een andere discipline. Dus meer tijd en geld stoppen in een vooronderzoek en op basis van feitelijke informatie een aanbesteding doen, niet op basis van een inschatting.
Vaak wordt de schuld gegeven aan slecht projectmanagement. Maar als je uitgangspunten al niet kloppen kan projectmanagement daar echt niets aan veranderen. Regelmatig wordt een leverancier hierop aangekeken en wordt vaak vergeten dat de klant net zo verantwooordelijk is voor het eindresultaat.
In mijn mening kunnen (overheids-) organisaties nog heel veel leren over goed opdrachtgeverschap.
Hieruit blijkt dat je grote projecten vanuit een team moet initieren, in de ICT en elders.
Initiatiefnemers bij de klant zijn vaak van het type matcher. Zij zien allerlei mogelijkheden. Hun valkuil is vaak het niet op waarde kunnen / willen schatten van problemen. Zij kunnen het beste met mismatchers gaan samenwerken (vaak beheerders bij de klant, vertegenwoordigers van de gebruikers) die de beren op de weg zien, neutrale rekenmeesters (zoals accountants, administrateurs) en creatievelingen (zoals ontwerpers) die een andere weg kunnen bedenken. De korte weg van de initiatiefnemer is niet altijd de weg die het snelst af te leggen is.
De opdrachtgever ? als hoofdverantwoordelijke ? moet natuurlijk kritisch zijn en doorvragen om te voorkomen om dat een voorstel geaccepteerd wordt dat inderdaad te mooi was om waar te zijn. Vooral accountmanagers zullen dat doen omdat ze bang zijn om omzet te verliezen. De opdrachtgever moet een maximum stellen aan doorlooptijd en pm kosten, bijvoorbeeld via een bonus malus regeling.
Zo voorkom je niet alle, maar wel veel problemen.
De oneindige niet te overbruggen kloof tussen business/ management/ functioneel ambitieuze hocus pocus figuren enerzijds en anderzijds realistische IT-ers vormt het hart van het probleem. Het ontbreekt de meeste opdrachtgevers gewoon aan benul, aangezond verstand, aan realiteitszin. Onbewoonbare luchtkastelen worden voor stenen bouwsel aangezien. De mensen die beslissen zijn geen technische IT-ers en hebben er ook geen verstand van; op technische ICT wordt vaak neergekeken en liever nog schopt men dat naar india.
Dit pleit ervoor pas een BC te (laten) maken als alle analyses zijn gedaan en de requirements zijn beschreven en goedgekeurd. Met andere woorden: Pas aanbesteden als duidelijk is waar het over gaat en wat men er mee wil. Dat levert ook een meer realistisch beeld op van wat er uiteindelijk mogelijk is en kleinere partijen hebben dan echt een goede kans (en ik voorspel dat ze het dan vaak winnen van de grote jongens).
@Hans Kroon.
Helaas, helaas. Een goed project is opgezet volgens een methode waarbij niet alleen een BC vooraf wordt opgezet (om ueberhaupt te kunnen vaststellen of het nuttig is om verder te gaan) maar ook nog eens regelmatig tegen het licht wordt gehouden (om te kunnen vaststellen of het nuttig is om verder te gaan). Je stelt dus eerst een BC op om te kijken of het nuttig is om analyses uit te voeren en requirements op te stellen. Die eerste BC kan op de achterkant van een bierviltje worden gemaakt, maar het opstellen dwingt je na te denken over de richting en het nut van het project. Het geeft daarnaast richting aan de analyses die je wilt gaan uitvoeren. In het wilde weg wat gaan analyseren en requirements opstellen kost ook geld. Een BC is een richtinggevend middel en het is de lat waarlangs je de kosten afweegt tegen de daarin gestelde baten (in de toekomst). Na elke fase de BC opnieuw opstellen en daarna de verwachte baten (en reeds gemaakte kosten) weer tegen die lat aanhouden zodat je elke keer weer de afweging kunt maken of je wel door moet gaan. Je moet als opsteller(s) natuurlijk wel eerlijk te werk gaan, niet de kosten lager inschatten en de baten hoger omdat je zo graag het project wilt uitvoeren. Het kan ook zijn dat van tevoren vaststaat dat het project moet doorgaan, bijvoorbeeld in die gevallen waarbij het niet uitvoeren gaat leiden tot overtreden van de wet, maar dan nog dien je een BC op te stellen om het project richting te geven.
Waar jij schrijft “pas aanbesteden als duidelijk is waar het over gaat en wat men ermee wilt” is nu precies wat in een BC zou moeten staan, uitgewerkt tot aan de kosten. Ik ben wel nieuwsgierig waar je de bewering over de kleine en grote partijen op baseert.
De vraag die gesteld moet worden is wat de doelstelling is van de BC. Niet wat het zou moeten zijn! (Klant binnenhalen of voorzien in een behoefte op een effici?nte wijze) Vandaar dat ik geen fan ben van het opstellen van een BC zonder enig inzicht en/of controle vanuit de klant. De investering die je hier doet betaalt zich terug in de beslissing en de rest van het traject.
Waar het mij vooral om gaat is het moment van aanbesteding. Volgens mij zijn we het op een aantal fronten wel eens. Eerst moet je (de klant) onderzoeken of het zinvol is iets te veranderen. Dat onderzoek moet in mijn optiek onder regie van de klant zelf gebeuren (al dan niet ondersteund door een specifiek voor dit deel van het traject ingeschakelde externe partij – zie ook reactie Edwin) en mag geen deel van de aanbesteding zijn. Dat kan ook niet omdat je voordat je iets onderzoekt nog geen idee hebt of er wel sprake is van een zinvol project. Mijn mening is dat je dat pas kunt doen als dat voortraject is afgerond. Dan pas ga je aanbesteden en in dat geval krijgen alle partijen precies dezelfde, maar wel juiste en volledige informatie uit het voortraject. Zo?n aanbesteding vraagt dan onder andere om een sluitende BC, zodat inschrijvingen kunnen worden beoordeeld op de oplossing die ze aandragen, de kosten van het realiseren en implementeren van die oplossing (TCI) en de kosten en opbrengsten daarna (TCO en ROI).
Kleine(re) partijen, die met innovatieve oplossingen en toepassingen bezig zijn, hebben nu een re?le kans een concurrerende BC te bouwen en daarmee de opdracht voor realisatie (het feitelijke project) in de wacht te slepen. De regie blijft op deze manier steviger in handen van de business, en bovendien op basis van een veel sterkere casus.
Is dit niet oud nieuws?
Hoelang horen we al niet dat projecten te vaak te positief worden ingeschat?
Niet alleen ICT projecten maar allerlei type projecten. Heeft de heer Flyvbjerg ons dat niet met een groot international onderzoek aangetoond?
Trouwens een goede lezer kan uit diverse onderzoeken (Bijvoorbeeld: het Nationaal Projectmanagement Onderzoek Bedrijfsleven van Twynstra Gudde, het Benchmark Projectmanagement van Atos Consulting en het Onderzoeksrapport naar PPM in Organisaties van Van Aetsveld) opmaken dat er doelbewust (soms domweg uit onwetendheid) sprake van incorrecte informatie is: kosten worden stelselmatig onderschat en opbrengsten stelselmatig overschat.
Dit is toch allang bekend? Dat is toch geen nieuws meer?
Hier de bedrijven de schuld geven die een te rooskleurige Business Case is mijns inzien veel te simpel. Goed het zegt iets over het moraal, de ethiek van deze heren die een te rooskleurige Business Case opstellen. Maar na de krediet crisis moet ons dit toch ook niet verbazen.
Zal men niet moeten controleren of de aannames in de Business Case wel kloppen? En waar ligt hier de verantwoordelijkheid???
Het komt er op neer dat er een positieve business case wordt ?gecre?erd? waardoor het mogelijk is om projecten op te starten die niet aansluiten bij de strategie van organisaties en/of geen waarde toevoegen aan de organisatie.
CONCLUSIE: Er vindt dus geen strenge toetsing op de aannames en risico?s plaats!
Dit is een aanwijzing dat business cases blijkbaar onvoldoende worden gevalideerd. Hierdoor worden veel projecten door organisaties gestopt die achteraf gezien nooit hadden mogen worden opgestart.
In het bankwezen toetst men wel de risico?s en de aannames van Financieringen (voor projecten). Wie naar de bank gaat voor een lening om een bedrijf op te starten, moet met een goed onderbouwd businessplan hebben. Dit businessplan wordt dan door professionals streng gekeurd (gevalideerd), alvorens de bank de lening verstrekt.
Kortom: Valideren die Business case!
Het opstellen van de Business Case is 1, deze valideren is 2.
Wil je het beter doen dan menig ander bedrijf dan zal je de Business Case moeten monitoren (3) en achter af moeten evalueren(4).