Managed hosting door True

SVB trekt stekker uit project Capgemini

 

De Sociale Verzekeringsbank (SVB) heeft definitief de stekker uit het project met Capgemini getrokken voor de bouw van het multi-regelingen-systeem (mrs). Dit systeem - begroot op 32 miljoen euro - zou eind 2013 worden opgeleverd, maar kan niet wegens technische mankementen in productie worden genomen. Capgemini is over dit besluit vandaag in kennisgeving gesteld, bevestigt een woordvoerster van de automatiseerder. Vanmiddag stuurt de SVB een brief hierover naar de Tweede Kamer.

De zegsvrouw van Capgemini verwijst voor een inhoudelijke reactie naar de SVB, maar die was nog niet in staat te reageren op een verzoek om terug te bellen. Naar aanleiding van de problemen bij de ontwikkeling van het multi-regelingen-systeem (mrs) werd een externe commissie onder leiding van Lieneke Sneller, hoogleraar toegevoegde waarde it, ingesteld die moest onderzoeken of het huidige systeem voldoet aan de technische kwaliteitsnormen. Onduidelijk nog is of de resultaten van dit onderzoek de directe aanleiding zijn voor het definitief stopzetten van mrs of dat de SVB zelf dit besluit heeft genomen.

In 2005 ging het project voor de bouw van het mrs van start. Eind 2013 leverde Capgemini, dat in 2009 na een aanbesteding als ontwikkelaar werd geselecteerd, volgens de geplande termijn het systeem op, maar SVB meldde afgelopen mei dat het systeem door onvoldoende kwaliteit niet in productie genomen kon worden. 

Opsouperen

Volgens ingewijden zou Capgemini het systeem in drie 'business releases' worden opgeleverd. Na business release 1 was van het budget van 32 miljoen reeds 80 procent opgesoupeerd. Van de talloze 'best practices' die deze release bevatten, werd er uiteindelijk maar één door de SVB geaccepteerd. Die best practice ging om het invoeren van rekeningnummer.

De SVB meldde in mei dat het voornemens is om de implementatie en het beheer van het systeem in eigen hand te nemen. Dat voornemen lijkt nu op losse schroeven te staan, nu het project is gestopt. De dienst stelde toen ook dat de problemen geen gevolgen hebben voor de lopende systemen: de kinderbijslag en AOW kunnen gewoon worden uitgekeerd doordat het nieuwe systeem buiten de productie-ontwikkeling om wordt ontwikkeld. 

.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5157870). © Jaarbeurs IT Media.

7,4


Lees meer over



Lees ook


 

Reacties

Ik lees: "Van de talloze business cases die deze release bevatten, werd er uiteindelijk maar één door de SVB geaccepteerd".

Talloze business cases??? Wat betekent dit? Wie heeft dit gezegd? Ligt hier de kern van het probleem? Weer eens wat aan ICT gedaan omdat ICT dat zo'n leuk idee vond en er vervolgens geforceerd een business case bij gezocht?

CapGemini zal wel verklaren dat de regie rol volledig bij het SVB lag en dat hun wederom niets te verwijten valt.

Ik als onafhankelijk informatiearchitect zal dolgraag eens zo'n mislukking willen doorakkeren.
Vrijblijvend! Wie doet er mee?

@Nico: Ik vermoed dat er "Use Cases" ipv Business Cases bedoeld werd. Als dat zo is, is het wel heel bijzonder dat er maar 1 acceptabel was.
Overigens is een project dat een geplande termijn van 8 jaar heeft naar de eerste release van de zotte - zal wel niet niet helemaal kloppen

Het is jammer dat potentiële klanten vaak kiezen voor de grote ICT reuzen in plaats van de kleinere specialistische bedrijven die sneller zijn, goedkoper en innovatiever.

Het heeft ook te maken met durf om te kiezen voor de kleinere partijen, alleen blijkt het keer op keer weer dat de raad van besturen en commissarissen van de overheid bv's en de grote ICT reuzen regelmatig samen dineren en een balletje slaan.

Groter is niet per definitie beter.

Zeer jammer het had zo'n mooie showcase kunnen worden. De eerste overheidsorganisatie die van volledig legacy naar nieuwe technolgieën over zou stappen. Een fraaie oplossing voor multi-regelingen waarmee alle uitkeringen, toelages etc uitgevoerd kunnen worden .... goed in het kader van de compacte overheid en noodzakelijke korting op de overheidsuitgaven.
De oorzaak zal ergens in het midden liggen.

@AlbertRomeo

Dit heeft, ben ik bang, niet zozeer te maken met durf, maar vooral met het hele aanbestedingsproces wat voorafgaat aan dit soort projecten.

Kleinere bedrijven missen de juridische kennis die vandaag de dag (helaas) nodig is om een aanbesteding binnen te halen, en kunnen vaak minder scherpe prijzen bieden

@ Pa Va Ke
helaas zitten overheden met handen en voeten vast aan aanbestedingsprocedures. Soms met ongewenste uitslagen en resultaten.

@AlbertRomeo: Voor een deel ben ik met je eens: té vaak zie ik ook die grote jognens zich verslikken in megaprojecten waarvan ik denk 'dat kan toch niet zo heel moeilijk zijn?'
Aan de andere kant betekent met een kleine partij in zee gaan wel vaak dat je een zeker risico neemt: als de (hoofd-)programmeur er de brui aan geeft, dondert het hele project in elkaar.
Niet dat dat nu dan niet gebeurt na vele verspilde miljoenen, maar de garantie dat het wél lukt met een kleine partij heb je ook niet en het extra risico vanwege de beperkte schaalgrootte zit er wél per definitie ingebakken...
Maar er gaan voor mijn gevoel wel heel veel megaprojecten de mist in de laatste tijd. Is de zaak niet té complex, té veelomvattend geworden dat het gewoon niet meer in code te vangen is? Moeten we niet veeleer vanuit een centrale techniek en gedachte beginnen met duidelijk omschreven deelprojecten die overzichtelijk zijn en later door die centrale techniek langzaam maar zeker, module voor module aan elkaar gevlochten worden in plaats van één allesomvattend project dat aan zijn eigen gewicht ten onder gaat?

Natuurlijk zal SVB een terechte claim indienen bij CAP GEMINI na deze wanprestatie en wordt het volledige bedrag vergoed. Natuurlijk zal dit niet worden betaald uit onze belastingcenten ..........

Een ICT-project van 32 mio met een looptijd van 8 jaar en ook nog eens bij de Overheid. Gedoemd te mislukken als er niet voldoende tussentijds wordt geëvalueerd. Een project moet binnen één jaar - en bij voorkeur zelfs binnen een half jaar - een correct werkend onderdeel kunnen opleveren dat door de opdrachtgever wordt geaccepteerd. Daarna dient het systeem stap voor stap te worden uitgebouwd en iedere keer te worden geaccepteerd. Alleen op deze manier houd je controle. Zowel opdrachtgever als opdrachtnemer moeten het lef hebben na iedere stap het project te stoppen als de resultaten niet voldoen.

Toch vraag ik me onwillekeurig af of de beroerde kwaliteit van het werk dat CapGemini kennelijk aflevert iets te maken heeft met de beroemde calibratiegesprekken van afgelopen tijd.

Dit klinkt beetje als gevalletje Equihold (Berkleef / 1-2-Focus).
Een eerste versie opleveren terwijl 80% van het budget al verbrand is.

Wat ik niet begrijp is dat een opdrachtgever betaald kan krijgen terwijl er niet geleverd wordt.

Ik zeg: Gooi die broncode eens live, dan kunnen anderen er naar kijken. Bang voor pikken hoef je niet te zijn want:

A) Het werkt niet
B) Het is volstrekt maatwerk

Als ik niet lever word ik ook niet betaald.

Natuurlijk besef ik me dat een opdrachtgever ook grote fouten kan maken, dit is echt geen eenzijdig verhaal, maar uiteindelijk ben ik wel van mening dat dit voornamelijk een leverancier probleem is. Als de klant niet precies weet wat ie wil, dan moet je dat achterhalen. Eerder ga je niet bouwen, of anders dan moet het agile.

Je houdt als klant toch regie op zo'n project? Ik weet dat veel grote overheidsorganisatie (te) weinig kennis van IT hebben en veel vertragen door besluiteloosheid of aanpassingen door voortschrijdend inzicht. Laten we dus waken om de schuld meteen bij Capgemini te leggen. De waarheid zal vast in het midden liggen.

@Henri

Het is een beetje kip-ei verhaal.

Als de opdrachtnemer met een hele crew 2 jaar moet werken om een eerste werkende versie op te leveren, kan ik me voorstellen dat de opdrachtnemer niet 2 jaar kosten voor wil gaan schieten.
Aan de andere kant heb je ook een heel valide punt dat opdrachtgever moet betalen terwijl er nog niets werkends geleverd is.

De Agile methodiek met sprints zou hier wellicht soelaas kunnen bieden; betalen per sprint met max. 1 sprint vooruit betalen.

De achtergrondstukken staan inmiddels op http://www.rijksoverheid.nl/documenten-en-publicaties/kamerstukken/2014/09/02/kamerbrief-ontwikkelingen-rond-het-veranderprogramma-svb-tien.html

Allemaal tamelijk politiek correct geformuleerd. Toch veel herkenbare 'ongelukjes' kenmerkend voor overheidsprojecten met al-dan-niet-ICT. Te groot, te complex, te hoge eisen, onduidelijke regie.
Maar dat tussen partijen discussie bestaat over kwaliteit en implementatie is onthutsend. Dat wijst op een fundamentele weeffout in de programma-opzet.

Dit was te verwachten. Van talloze projecten die stoppen is al heel veel investering verband. De risico's waren mogelijkerwijs al in een vroege stadium te voorzien maar blijkbaar was dit parade paardje een speeltje van iemand. Je kan IT nooit de schuld geven omdat het ondersteunend is. Het zijn voornamelijk de besluit nemers die de fout maken. Een menselijke fout. Politiek, Reputaite, Macht en Hebzucht maakt het mogelijk dat de meeste projecten stranden. Het gaat niet om het resultaat maar wat iemand eraan kan verdienen en welke vriendjes hij kan maken.

Jammer maar goed. Het blijft een menselijk operatie en de IT is alleen ondersteunend.

Ik ben benieuwd wat Cap gedaan heeft om de opdrachtgever te waarschuwen dat het project gaat vastlopen of flink uit begroting lopen?
Welke proactieve houding heeft Cap in dit verhaal aangenomen? Cap zou moeten weten dat dit project haar naam gaat beschadigen, wat hebben ze gedaan om dit te voorkomen?

Ben benieuwd hoe de beeldvorming gaat worden als we het verhaal vanuit de kant van Cap gaan bekijken!

Het Rijks ICT-dashboard stond voor het Veranderprogramma SVB TIEN - per peildatum 30-04-2014 - met 98% dik in het groen :
https://www.rijksictdashboard.nl/content/project/veranderprogramma-svb-tien

Opleverdatum 31-12-2013
Mmmm, toch handig zo'n dashboard

@P.J
Dat je nog op Rijks ICT-dashboard kijkt :-)
Kijk maar wat we in 2011 hierover gezegd hebben en.....ook mijn opmerking over kosten van een project :-)

http://www.computable.nl/artikel/achtergrond/management/4107508/2379250/ictdashboard-zegt-burger-helemaal-niks.html

@Reza : kijken mag toch wel? Iemand houdt dat ding bij, en er zijn mensen die in dashboards geloven. l-J
'Leugens - Grote Leugens - Statistieken - Excel - Dashboards' ?

Ik ben vooral getriggerd door het feit dat de verwachting en perceptie van de eindgebruikers significant bleek af te wijken van wat er door consultants (functioneel en technisch) is ontworpen en gebouwd. Hoe kan dit? Geen adequaat testprogramma? Geen Agile aanpak waarbij business (staande organisatie) en bouwteam ( projectorganisatie) volledig samenwerken en geaccepteerde en werkende deelfunctionaliteit opleveren in sprints? Traditionele waterfall aanpak waar de tijd tussen goedgekeurd ontwerp en werkelijke realisatie dermate lang heeft geduurd waardoor de 'business' werkelijk geen idee had wat er was afgesproken? Zinvolle vragen om een diepte onderzoek te starten. Andere valkuilen: onvoldoende uitgewerkte visie en stretegie, geen veranderstrategie, teveel focus op techniek. Dit soort aanpakken leiden in 80% tot falen. Lees ook Beenker 'Lead IT or loose IT'. Kennelijk is deze studie uit 2006 nog niet door elke grote organisatie gelezen (zowel opdrachtgever als systeemintegrator

Ik ben benieuwd of er net als bij het Equihold drama door Cap ook in India is geprogrammeerd voor dit project?

Bij Capgemini werken misschien nagenoeg geen mensen die in staat zijn boter-kaas-en-eieren te bouwen in een programmeertaal waarin hun baas claimt "best in class" of "best of breed" te zijn.

Cap is altijd goed in projectleiding en testen, zeker als de oorzaak van het niet tijdig gereed komen van het produkt aan anderen geweten kan worden....

Eerder onderzoek pleitte de aanbestedende organisatie volgens mij ook niet vrij van schuld:

http://www.inspectieszw.nl/Images/De-Sociale-Verzekeringsbank-Veranderprogramma-SVB-Tien_tcm335-342981.pdf

Krijg ondertussen de indruk dat Computable een 'naming and shaming' campagne is begonnen tegen Cap Gemini, als er ook maar iets negatiefs te roepen valt dan is de redactie er als de kippen bij.

SVB meldde...., SVB meldde...., SVB meldde......

Grappige is trouwens idee van multidisciplinaire teams, zoiets als een keeper strafballen laten nemen in plaats ze hem tegen te laten houden om even terug te komen op SAP-er-de-flap. Om nog maar niets te zeggen over het altijd aanwezig idee bij de overheid dat ICT de organisatorische problemen oplost.

Aanbestedingen nodigen uit tot prijsonderdrijven met prijsoverschrijding in het gegunde project als te nemen risico. Hangt van de projectmanager af of de stekker er op tijd uit gaat als de business case nooit meer gehaald kan worden. Ondanks het feit dat de rekening vast ergens bij de belastingbetaler komt te liggen: chapeau om het lef te hebben het project te stoppen om en nog veel groter debacle te voorkomen. (En het kost nu maar 17 euro per Nederlander).

Verbazingwekkend hoe er na zoveel jaren dit uit kan komen. Misschien dat de geaccepteerde de best practice "die ging om het invoeren van rekeningnummer" nog gebruikt kan worden?
@Ewout: ik ben het wel met je eens dat er soms te gemakkelijk wordt geoordeeld, maar het imago van Cap begint langzamerhand wel behoorlijk wat deuken op te lopen (http://www.nrcq.nl/2014/06/05/capgemini-vaakst-betrokken-bij-te-dure-ict-projecten-van-de-overheid)

Ewout,
Mee eens wat betreft Cap en Computable. Lees mijn reactie hierboven om 16:43
Ad,
Dat is waar! We zien inderdaad heel vaak dat de naam van Cap bij mislukte overheidstrajecten voorbij gaat.
Is het niet een soort vriendjes politiek waardoor grote trajecten naar Cap gaan? Worden de aanbesteding niet zo opgezet dat niemand anders met cap kan concurreren? Wat gebeurd er als Cap enige tijd niet aan de overheidsaanbestedingen mag meedoen? Zouden anderen grote bedrijven zoals Atos het beter doen dan Cap?

De kern van het probleem ligt naar mijn mening bij
- te grote omvang van dit soort projecten, dus meer risico`s en minder betrouwbaarheid in een zeer instabiele omgeving waar wetgeving per xx verandert,
- hoe dit soort grote projecten tot stand komen en hoe ze verder ontwikkeld/uitgevoerd/begeleid worden,
- de geschiktheid van de opdrachtgever
en nog meer ...

Jammer dat er geen framework komt voor het opstellen, begeleiden en uitvoeren van dit soort grote trajecten. We hebben toch genoeg mislukking gehad bij Belastingdienst, UWV, IND en nog meer andere overheidsinstellingen/organen. Wanneer gaan we daar iets van leren?

De reactie van S.E. Bowen hierboven geeft de kern van het probleem juist weer. Gecombineerd met een aanbesteding (op basis van EMVI) en semi-overheid is het een recept om te mislukken.

We hebben recentelijk een tijdelijke kamercommissie ICT onder leiding van Ton Elias gehad.
Voor wie er intressse in heeft, alle interviews door deze commissie gehouden zijn terug te vinden op youtube en ruwweg in twee catagorieen te verdelen.

- I hate to tell you, i told you so. But I told you so.
- Deftige heren die proberen hun gestuntel recht te breien.

Algemene conclusie was helaas dat zowel ambtenaren als leveranciers er persoonlijk het beste vanaf komen als een project faalt !

Verder kwam er weinig uit wat hier op computable niet al vele malen is aangekaart.
We weten allemaal wat het probleem is en hoe het op valt te lossen.
Echtger de belangen van de politicus en grote firma's wegen nu eenmaal zwaarder dan het slagen van het project.

Je hoort er ook niets meer over....
Over tot de orde van de dag, Business as usual

Naar aanleding van publicaties in de Telegraaf in juni werd ik door een betrokkene gewezen op het volgende document:

https://zoek.officielebekendmakingen.nl/blg-337115.html

Het betreft een rapport van de auditdienst Rijk.
Daarin zie ik heel wat adviezen staan op het gebied van communicatie en projectmanagement waar nogal wat mis is gegaan. Wanneer het daar mis gaat, dan kun je, je nog zo focussen op de kwaliteit van een systeem, maar dat wordt nooit wat, wanneer je de boel niet goed georganiseerd hebt.
Hieronder staan een flink tal adviezen waar vooral het advies: zorg voor een veilige sfeer toch wel schokkend is. Er wordt dus gestuurd op gewenste einddata en niet op realistische einddata. En zoals elke projectmanager zou moeten weten, dan ben je bezig met een heilloos traject. Dit is zowel te wijten aan de SVB als Capgemini. Managers die niet in staat zijn om te managen en doen aan wishfull thinking zullen nooit echt succesvol zijn en veelal falen. Wanneer je auto 100 km per uur rijdt, zul je met diezelfde auto nooit binnen 5 uur 1000 km ver komen. Zo simpel is het. Leuker kunnen we het niet maken (of was dat weer een andere overheidsorganisatie)

Onderstaande adviezen uit het rapport vind ik toch wel schokkend en helaas zie ik daar weinig reactie op komen, zowel vanuit de tweede kamer als in de media. Het eerste advies is volgens mij nu door 2 externen opgepakt, dat wel, en daar is 3 maanden over gedaan. Ben wel inhoudelijk benieuwd wat er precies in hun advies staat. En of ook alles genoemd wordt in de media.

Kortom, er speelt weer heel veel meer in dit project. Stop zetten lijkt me geen goede optie. Zorg ervoor dat je weet wat er nog gedaan moet worden, houdt het klein, communiceer goed, maak een reeële planning en zorg voor een sterke, communicatie goede, mensgerichte en luisterende projectmanager die zich niet laat overbluffen door een Raad van Bestuur, maar zelf zijn eigen planning maakt op basis van imput van deskundigen binnen het project. Dus de ontwerpers, architecten en bouwers. Zij weten hoe de vork in de steel zit en doe aub niet aan wishfull thinking, dan bereik je niets.

Advies
Wij adviseren u om op korte termijn zicht te krijgen op de inspanningen die nodig zijn om te komen tot een werkend MRS. Om dit inzicht te verkrijgen is tijd nodig. Op basis van onze ervaring met vergelijkbare trajecten schatten wij een doorlooptijd in van ongeveer 3 maanden. Heb daarbij oog voor de spanning in de duivelsdriehoek (tijd, geld en kwaliteit).

Adviezen
Wij adviseren u om alle relevante disciplines zo vroeg mogelijk bijeen te brengen om zodoende een integrale afweging van keuzes mogelijk te maken.

Advies
Zorg voor een veilige sfeer waarin medewerkers met kritische geluiden gehoord worden.

Advies
Zorg er voor dat besluiten worden onderbouwd door middel van analyse in de vorm van verschillende scenario’s waarin de voor- en nadelen per scenario in kaart zijn gebracht.

Advies
Zorg voor handhaving van een eenmaal gekozen methode (zoals waterval), ook onder tijdsdruk. Dit vereist een realistische planning.

Advies
Zorg er voor dat inzichtelijk en voor een ieder transparant is wat de voor- en tegens zijn binnen de te onderkennen scenario’s.

Advies
Wij adviseren een duidelijk en eenduidig taalgebruik, dat door door iedereen her-kend en erkend wordt.

Gartner geeft aan dat het team in de bouw- en testfase 107 FTE groot is. Dit is vragen om problemen. Hoe kun je een team van deze omvang een werkend systeem laten opleveren?

@ruud, 02-09-2014 14:30
Zeker bij een project van de grootte van €35m zou de opdrachtnemer (Cap dus) de opdrachtergever goed moeten begeleiden. Cap is immers deskundig. Als jij een nieuwe auto koopt die na een half jaar weggeroest is, verwijt je het dan ook de koper?

@MartijnH
Klinkt als een interessante opdracht. Eens kijken wat ze gemaakt hebben en hoe het aansluit bij de ontwerpdocumentatie.

Wat dat betreft zouden al dit soort overheidsprojecten gewoon open source te zijn zodat iedereen mee kan kijken en er wellicht ook wel wat goede suggesties komen. Je kan dan nog steeds de gevoelige onderdelen daarbuiten houden of alleen in gecompileerde vorm aanbieden.

http://webwereld.nl/datacenter/83736-cobol-redt-uitkeringsinstantie-na-falen-ict-project

Hierin staat dat de software in India gemaakt werd mbv Oracle en Cap was de PL. Dat verklaart best wel veel.

Ondertussen blijven ze gewoon COBOL door gebruiken. Draak van een taal maar onverwoestbaar als Smaug.

@JohanDuinkerken Mooi he! Cobol moet ze redden. Had er dan ook nooit aan begonnen als het werkt. Regel 1. En of India nu veel verklaart, ik denk niet als het gaat om de kwaliteiten van de Indiaase uitvoerend techneuten maar wel over hoe zo een project benaderd wordt. Het echte werk van een ICT project (bouwen) is de sluitpost en moet zo goedkoop mogelijk. Om verder voor een vermogen af te ouwehoeren in Nederland.

@PaVaKe Betalen per sprint? Ken een project waarbij de leverancier per regel code betaald werd. Het zou me als opdrachtgever niet interessereen of ze nu sprinten of niet. Ik zou zeggen, afrekenen per uur. Dan zie je snel genoeg of je over het budget van de planning heen gaat. Loopt het dan echt uit de klauwen, dan kan je leverancier asap de deur wijzen. Zou ook van de leverancier een specificatie van de uren willen hebben. Wat gaat er op aan vergaderen en consultatie en wat gaat er op aan echt werk (ontwerp, bouw, test).

@GerbrandvanHierden 107Fte teveel? Bovenop wat? Wat een hoeveelheid mensen zo een project doe je toch met een paar mensen? Hoe krijg je het voor elkaar en dan zou ik wel benieuwd zijn wat voor functie die mensen hebben. Maar ja, als het doel is zoveel mogelijk mensen, voor een lang mogelijke tijd en voor zo een hoog mogelijk tarief 'weg te zetten' dan is het een uitstekend project.

Wat ik vooral niet begrijp is als je nu in een korte tijd al bijna je heel budget verbrand dat je dan toch nog jaren en jaren gaat doormodderen. Verder valt me op dat het aandeel van 'oracle licenties' in het budget gigantisch is. Dat is iets wat ik erg vaak hoor, grote software bedrijven die ook enorm incasseren met licenties. Het liefst nog per core of per processor!

Dan lees ik ook her en der dat een agile aanpak gewenst is. Ik denk dat agile een gegeven is. Je weet op voorhand nooit alle antwoorden, software is nooit statisch en in het geval van de SVB gaat het over wet en regelgeving. Dat is hoe dan ook veranderlijk in de tijd en zal de software daarop aangepast moeten worden.

En verder, in dit soort projecten tellen hele andere belangen dan de inhoud. En er komt alles in samen wat in de ICT verhoren ook al voorkomt, opdrachtgever geen kennis meer, de cultuur van alles maar uitbesteden en een leverancier die met je aan de loop gaat. Want het is een falen van de overheid maar Cap maakt er ook een potje van.

Vraag blijft hoe je € 32.000.000 (of 80% daarvan) kunt spenderen zonder te weten of je het einddoel halen gaat. Vijf jaar ontwikkelen en dan tot de conclusie komen dat het gebouwde gewoon niet voldoet aan de behoeftes en/of verwachtingen van de SVB.
Met alle kwaliteit in organisatie (aan beide kanten), methode en techniek zit daar toch een fundamenteel probleem.

Er zijn volgens mij genoeg mensen die de belangrijkste problemen met MRS hadden kunnen voorkomen, maar de HR-managers kiezen steeds weer voor de verkeerde programma- en projectmanagers en die starten de verkeerde projecten op met partners met de verkeerde mentaliteit. Het wordt tijd dat instellingen zoals de SVB en bedrijven zoals Cap de verkeerde HR-managers gaan aanpakken.

MartijnH, dat lijkt me ook wel interessant. Het is ook een mooie afstudeeropdracht. Maar het kost wel veel tijd want je moet al die PINO-documenten doornemen en niet alleen de politiek-ambtelijke documenten die reeds op het internet staan.

Bas de Natris, de oorspronkelijke duur van het project was 4 jaar binnen een programma dat wat langer duurde, dus niet eens zo heel lang. Na een paar jaar kwam er drie jaar bij (toen het eigenlijk al misgegaan was) en vlak voor de implementatie nog een jaar. Nu houdt men rekening met een periode van nog eens vijf jaar na de herstart van het programma.

Christian, aanbesteden hoef geen probleem te zijn, maar aanbesteden is ook een vak en heel veel aanbesteders kunnen het niet (en ze verdommen het om dat goed uit te besteden).
Henri, je hebt gelijk, “als de klant niet precies weet wat ie wil, dan moet je dat achterhalen. Eerder ga je niet bouwen.”

AlbertRomeo, het blijkt dat bazen van grote bedrijven en instellingen liever voor grote projecten kiezen en daarom voor grote opdrachtnemers, met het grote risico op grote mislukkingen.

Ad Gerrits, Pascal, volgens mij heeft men gekozen om de zaak nu bekend te maken en niet onder de pet te houden vanwege de Tijdelijke kamercommissie ICT. Nu valt het minder op tussen de andere grote missers.

Pascal, politici hebben vaak moeite met grote projecten, maar hun persoonlijke assistenten en ambtenaren kiezen ervoor omdat grote problemen opgelost moeten worden. Politici durven dan niet nee te zeggen omdat ze niet weten wat het alternatief zou moeten zijn. Helaas wordt door mismanagement de oplossing vaak weer een nieuw groot probleem.

De SVB en implementatiepartner Capgemini zijn overeengekomen om door arbitrage - onder auspiciën van het Nederlands Arbitrage Instituut - tot een onafhankelijke beslechting te komen van het geschil :
http://www.rijksoverheid.nl/documenten-en-publicaties/kamerstukken/2015/04/02/kamerbrief-afwikkeling-overeenkomst-voor-ontwikkeling-van-het-mrs-bij-de-svb.html

Hieruit blijkt dat bazen echt wel degelijk nodig zijn.
Ze kwamen er misschien te laat achter, maar een baas is zeker wel nodig. Anders had het nog duurder geweest. Reken maar dat die baas kwaad is geweest. Ik ben blij dat ik daar niet werk, want ellende veroorzaken, nee dank je dat wil niemand.

Mooie uitspraak: mensen maken er een rotzooi van, maar om er een puinhoop van te maken heb je echt een computer nodig.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×