Ict-project CBR valt miljoenen euro's duurder uit dan begroot

Een groot ict-project bij het CBR kost miljoenen euro's meer dan verwacht en loopt jaren vertraging op. Door vertragingen in het project slaat het CBR gevoelige informatie op in sterk verouderde systemen.

Dat blijkt uit onderzoek van Zembla. Het tv-programma kreeg interne documenten van het Centraal Bureau Rijvaardigheidsbewijzen in handen. Volgens Zembla zou het CBR de werkelijke kosten van het project achterhouden voor het ministerie van Infrastructuur.

Het CBR startte in 2014 het ict-project 'Rijgeschiktheid aan het stuur'. Met dat project moesten medische keuringen en verklaringen voor rijgeschiktheid worden gedigitaliseerd. Dat zou in totaal zeven miljoen euro moeten kosten en in 2017 moeten worden opgeleverd. Het project is nog niet af en kost uiteindelijk naar schatting 34 miljoen euro. Eerder bleek al dat vertraging van het systeem ertoe leidde dat beroepschauffeurs vaak werkloos thuiszaten, omdat hun rijbewijs niet op tijd verlengd werd.

Door de vertraging werkt het CBR intern nog steeds met verouderde systemen. Dat zijn computers met Windows XP. Volgens het CBR zijn die computers wel air gapped en zijn ze niet op internet aangesloten. Medische dossiers van autobestuurders staan daarnaast opgeslagen in een Oracle 9-database. De verlengde ondersteuning voor Oracle 9i Release 2 eindigde in 2010. Het is niet bekend of het CBR net als veel overheidsorganisaties nog betaalt voor extra beveiligingsondersteuning. Het Bureau was niet direct bereikbaar voor commentaar.

Volgens Zembla wist het CBR al in 2013 van de stijgende kosten. De minister werd daar echter pas vanaf begin 2017 van op de hoogte gesteld. Volgens een woordvoerder van het ministerie was er vóór die tijd niets bekend over de stijgende kosten.

Reacties (246)

[Scheeringa]

Jeetje als ik de reacties lees dan bekruipt bij mij het gevoel dat heel weinig Tweakers ooit daadwerkelijk hebben meegedraaid in een ICT-project van formaat.

Dergelijke overschrijdingen is meestal een gevolg van de klant die niet precies weet wat zij wilt.
Je kunt honderden uren besteden aan requirement sessie, FO's,TO's, verzin het om alsnog te horen "oh we zijn dit vergeten" of "dit gaat/moet toch anders", met een RFC tot gevolg en je bent weer een sprint/fase verder. Natuurlijk vergist men zich ook wel eens in de planning of worden er fouten gemaakt maar buiten een in het contract opgenomen tolerantie op tijd/geld wordt dit niet doorberekend aan de klant.
Feit dat dit wel gebeurd doet mij vermoeden dat dit veelal wijzigingen en nieuwe wensen zijn.

[CAPSLOCK2000]

Jeetje als ik de reacties lees dan bekruipt bij mij het gevoel dat heel weinig Tweakers ooit daadwerkelijk hebben meegedraaid in een ICT-project van formaat.

Dergelijke overschrijdingen is meestal een gevolg van de klant die niet precies weet wat zij wilt.
Je kunt honderden uren besteden aan requirement sessie, FO's,TO's, verzin het om alsnog te horen "oh we zijn dit vergeten" of "dit gaat/moet toch anders", met een RFC tot gevolg en je bent weer een sprint/fase verder. Natuurlijk vergist men zich ook wel eens in de planning of worden er fouten gemaakt maar buiten een in het contract opgenomen tolerantie op tijd/geld wordt dit niet doorberekend aan de klant.
Feit dat dit wel gebeurd doet mij vermoeden dat dit veelal wijzigingen en nieuwe wensen zijn.

Van de andere kant gezien is het voor de klant onmogelijk om precies alles van te voren vast te leggen.
Dat is een klassiek "waterval"-design en daarvan is al tientallen jaren geleden vastgesteld dat het niet werkt.
De enige manier om alles exact vast te leggen is om het zelf te programmeren, dat is natuurlijk zinloos, dan hoef je niemand meer in te huren.
En dat los van het feit dat wensen, eisen en omstandigheden nu eenmaal veranderen door de tijd, zeker als een project jaren loopt.
Als er bv een nieuwe wet wordt aangenomen dan zal je de software moeten aanpassen om daar mee om te gaan.
Aangezien zo'n beetje ieder project zo gaat zou je hopen dat daar rekening mee wordt gehouden in de prijsstelling en afspraken.
Maar ja, dan lijk je veel duurder dan alle concurrenten en verlies je de aanbesteding, dat doen bedrijven dus niet.
Methodes als Agile proberen daar wel mee om te gaan, maar opdrachtgevers willen graag van te voren weten wat het gaat kosten en wat ze dan krijgen en dat past niet echt bij Agile.
Daarom geloof ik niet zo in het idee dat je maatwerksoftware kan bestellen zonder zelf programmeurs in dienst te hebben om het voortouw te nemen.

[Pep7777]

Methodes als Agile zorgen ervoor dat je precies weet wat het kost. Maar niet precies WAT je allemaal krijgt. Stap voor stap implementeer en test de aannemer en de klant functionaliteit en besluit wat in de volgende fase het belangrijkste is. Dan heeft de klant als het goed is aan het eind van zijn budget de belangrijkste zaken in ieder geval vast.

En ja dat aanbesteden lijdt ook tot over optimisme... er is lijkt het een eindeloos vertrouwen in de "sunk cost falacy".

[K-aroq]

Je moet Agile dan ook totaal anders aanpakken dan traditionele projecten. Het belangrijkste wat je moet bepalen is hoeveel je jaarlijks aan (in dit geval) ICT wilt uitgeven. En binnen dat kader ga je dan kijken wat je wilt doen. Een veel gemaakte fout met agile is, is dat men agile wil werken maar wel een afgebakend project met begin en einde wil doen (en aan het einde alles wil hebben wat nodig is). Je moet agile veel meer zien als een continu programma waarbinnen je zaken levert die nodig zijn en binnen de budget (praktisch gezien: het aantal mensuren) kan worden gerealiseerd. Het vereist dan ook een extreem goede samenwerking tussen alle stakeholders.

Helaas past die niet in de Nederlandse aanbestedingsregels. Dat is nog steeds gebaseerd op een in steen gehouwen scope.

[CAPSLOCK2000]

Methodes als Agile zorgen ervoor dat je precies weet wat het kost. Maar niet precies WAT je allemaal krijgt.
<knip>
Dan heeft de klant als het goed is aan het eind van zijn budget de belangrijkste zaken in ieder geval vast.

Met Agile verplaats je de verantwoordelijkheid maar wordt het probleem niet echt opgelost.

Het probleem is dat klanten niet zo denken. Die denken alleen over wat ze nodig hebben, ze hebben geen idee wat het kost. Ze weten dat ze X, Y en Z nodig hebben, bv omdat de wet dat zegt. Als aan het einde van het budget blijkt dat alleen X af is dan is het project mislukt. Dat is echter niet acceptabel want er is een wettelijke verplichting om ook Y en Z te hebben. Dan zal er geld bij moeten.

Klanten weten vaak ook niet echt wat belangrijk is of prioriteit moet hebben. In de ogen van de klant kan een mooi startscherm heel belangrijk zijn terwijl 2FA en of een goede logfile niet op de radar staan. Natuurlijk hoop je dat klant & opdrachtnemer goed samenwerken en naar elkaar luisteren, maar uiteindelijk is de programmeur de professional terwijl de klant weinig weet van software-ontwikkeling.

[gitaarwerk]

Het kan helpen, maar is het niet altijd een probleem met grote projecten dat je de juiste mensen moet hebben en de prioriteiten goed moet hebben? Al is 't maar voor een sprint of twee/drie. Mijn oude ceo wilde dat een project niet initieel langer dan 3 sprints zou zijn(1,5 maand) om zsm inzichten in resultaat te krijgen. Impediments die tevoorschijn komen zijn dan ook vaak een indicatie van extra complexiteit in het gehele traject).

Met waterval met gigantische planning is rustig 25-50% verspilde moeite. Allebij hebben overig sterke kanten. Agile is echt niet altijd de oplossing

[Gomez12]

Methodes als Agile zorgen ervoor dat je precies weet wat het kost. Maar niet precies WAT je allemaal krijgt.

Er is een reden dat Agile zo nooit verkocht wordt, je zegt namelijk compleet duidelijk dat je enkel de prijs weet en niet of het ook maar enigszins iets doet (laat staan naar wens)

Stap voor stap implementeer en test de aannemer en de klant functionaliteit en besluit wat in de volgende fase het belangrijkste is. Dan heeft de klant als het goed is aan het eind van zijn budget de belangrijkste zaken in ieder geval vast.

Je vergeet hetgene wat altijd voor het belangrijkste komt, namelijk de essentiele dingen.
Je verkoopt het nu als : De aannemer verkoopt een paleis en de klant kan besluiten over wat voor kleur de deurknopjes moeten zijn, ongeacht wat heeft de klant een paleis.
Terwijl de realiteit vaker is : De klant moet genoegen nemen met een paar op elkaar gestapelde gipsblokken want het cement was nog niet droog maar de sprint was wel al af. Maar hij mag idd ergens kiezen wat voor kleur de deurknopjes moeten zijn op niet bestaande deuren als hij daar maar genoeg belangrijkheid aan geeft

[TweakerNummer]

En toch hebben heel veel grote organisaties hele oude grote systemen staan die jarenlang geleden gemaakt zijn door externe partijen. En juist deze systemen zijn nog jarenlang onderhouden om ze te kunnen blijven gebruiken.

Misschien is het nuttiger als men gewoon eens nadenkt wat er echt fout zit en wat er echt beter kan. Helaas zal je dan een hele legacy aan "vooruitgang" de deur uit moeten gooien, en toegeven dat heel veel tot niks geleidt heeft (wat we eigenlijk nu ook al doen).

En omdat ik het eigenlijk vrijwel overal onder kan plakken waar men Agile roept, doe ik het hier maar:
https://www.computerweekl...iled-for-Universal-Credit

[Reactie gewijzigd door TweakerNummer op 23 juli 2024 04:39]

[Zoop]

Klinkt herkenbaar. Oud project moderniseren, zou wezenlijk vrij simpel moeten zijn. Grotendeels kan je het qua werking 1 op 1 overnemen, je hebt een prima voorbeeld van wat de wens is.
Belangrijk is dan dus om vast te leggen wat er niet goed was aan het oude programma, dus minieme aanpassingen.
Probleem is vaak dat er al te veel aandacht besteedt wordt aan nieuwe features waardoor de basis functionaliteit verloedert. Dit soort projecten moeten dan daarom ook in logische fases, fase 1: bouw het ding na, fase 2: nieuwe functionaliteiten toevoegen.
Is er veel beter zicht op wat er precies moet gebeuren, en wellicht is de wens ineens niet zo belangrijk meer als blijkt dat de core functionaliteit al goed genoeg werkt etc.

Er wordt een hoop op een eisen-stapel gegooid tijdens het traject en wordt die stapel alleen maar groter ipv kleiner. Mijn ervaring is dat daar vaak de fout zit. Er wordt wild ge brainstormed over allerlei nieuwe zaken, er is nu ten slotte toch budget voor, maar vaak vliegt dat zijn doel voorbij.

[Creesch]

Oud project moderniseren, zou wezenlijk vrij simpel moeten zijn

Hangt ook weer helemaal af van welk onderdeel er gemoderniseerd moet worden. Gaat het om een project wat grotendeels hetzelfde moet doen maar met nieuwere technologie dan is het inderdaad relatief simpel. Het is overigens nog een behoorlijk uitdaging om logica goed over te nemen en door te testen maar dat is even een ander verhaal.

Moet er echter meer gebeuren of moet het vernieuwde project de uitgangspositie worden van toekomstige vernieuwingen aan bijvoorbeeld een process dan is het al wat lastiger. Je kan natuurlijk je software dusdanig opnieuw bouwen dat het makkelijker is om in de toekomst andere functionaliteit toe te voegen of logica aan te passen. Op dat punt moet je namelijk al nieuwe specificaties gaan opstellen over hoe dat gerealiseerd zal worden in de toekomst en daar zit dan weer een risico.

Daarnaast zijn er altijd zaken die je wel moet vernieuwen, zo wil je bijvoorbeeld interfaces naar de buitenkant met andere applicaties ook weer toekomst geschikt maken. Dat betekend dat informatiestromen op een andere manier naar afnemende applicaties ontsloten moeten worden. Dat betekend dat afnemende applicaties ook mee moeten met de verandering. In princiepe is dat mogelijk totdat je met derde partijen zit. Ik heb ook al een keer mee mogen maken dat het systeem succesvol vernieuwd was maar het legacy systeem nog jarenlang heeft mee staan schaduwdraaien omdat een belangrijke derde partij het maar niet voor elkaar kreeg het systeem aan hun kant te vernieuwen.

Dan is het nog het oude systeem waarvan de business logica toch niet helemaal volledig blijkt te zijn gedocumenteerd.

Ben het verder met je eens hoor en het is in mijn ogen de betere manier om systemen te vernieuwen maar dan nog blijven er een hoop haken en ogen die vaak voor kosten zorgen en niet beoogd zijn toen het budget werd goedgekeurd.

[Zoop]

Wellicht dat ik het wat simpel heb verwoord, want zo simpel is het niet altijd natuurlijk.

Maar ik bedoel meer, net zoals je aangeeft, het "namaken" van de applicatie zit al genoeg werk in, en mogelijke haken en ogen. Maar vaak voordat we zover zijn, zijn er al tig nieuwe features bij verzonnen, dat zou (imo) echt in zijn eigen fase moeten.

[CAPSLOCK2000]

En toch hebben heel veel grote organisaties hele oude grote systemen staan die jarenlang geleden gemaakt zijn door externe partijen. En juist deze systemen zijn nog jarenlang onderhouden om ze te kunnen blijven gebruiken.

Ik zeg niet dat je geen software extern kan kopen. Ik zeg vooral dat het erg duur en lastig is, zeker als je zelf geen programmeurs in dienst hebt. De vraag is of die projecten goedkoper waren dan de alternatieven en of ze het beter hebben volgehouden.
Het kan ook zo zijn dat ze nog steeds draaien omdat blijkt dat het onmogelijk is om ze te vervangen of te moderniseren omdat het zo'n antiek warboel is.

Er is ook nog zo iets als survivor bias. Alle oude systemen die tegenwoordig nog draaien moeten wel goed zijn, anders waren ze al lang stuk gegaan. Alle oude systemen die in de tussentijd wel stuk zijn gegaan zien we niet meer. Dat heeft niet noodzakelijk iets te maken met hoe ze gemaakt zijn, of dat binnen budget was en of alle beoogde features zijn geimplementeerd.

En omdat ik het eigenlijk vrijwel overal onder kan plakken waar men Agile roept, doe ik het hier maar:
https://www.computerweekl...iled-for-Universal-Credit

Exact hetzelfde probleem. Agile combineren met een verplichte featurelijst werkt niet.

[TweakerNummer]

Wordt het makkelijker als we zeggen dat Waterfall-Maintenance Agile is?

[airell]

Ach, loops in het waterval model tussen design, coderen en testen zijn wel ingebouwd (als het goed is). Alleen het betrekken van de klant eerder in het proces, (deel) deployents en opnieuw de eisen tegen het licht houden en aanpakken 'is nieuw'. Wat je zegt, agile is niet fixed, maar 'big-bang' is lastig te overzien.

Aan de andere kant kan de klant (vaak) niet volledig van te voren vertellen wat ze willen, spreken x af (laten we zeggen 100%) en betalen daar hun budget voor (zo slim zijn de verkopende uitknijpers wel). Daarna blijkt dat het 10% meer tijd kost én(/of) ze toch nog 25% details of meerwerk te willen en het kost ze 50% extra (want zo slim zijn de verkopende uitknijpers ook natuurlijk).

[mphilipp]

Methodiek is eigenlijk onbelangrijk. Alles is goed, zolang je maar doet wat de methodiek voorschrijft. Voordat er Agile en al die hippe shit was, waren er ook succesvolle projecten én projecten die tegenvielen. Nu zijn die er ook. Na 30 jaar ICT zie ik vrij weinig verschil. Er wordt nog steeds dezelfde rommel opgeleverd, te laat en te duur. Uiteraard gechargeerd, maar in wezen komt het daar wel op neer.

Dit verhaal zal ongetwijfeld genuanceerder zijn dan die paar regels onthullen. Wat ik me als Oracle-boer afvraag is wat er zo bijzonder is aan hun omgeving dat het op Oracle 9 moet. Want tenzij je het met een hele oude ontwikkeltool maakt die alleen nog maar met Oracle 9 werkt, zie ik geen reden. Die is er volgens mij ook helemaal niet. Je hebt altijd meer dan genoeg tijd voor een migratie als je iets obscuurs gebruikt. Het lijkt wel of steeds meer intstanties ervoor kiezen om met ouwe meuk te blijven werken totdat ze niet anders meer kunnen. Wat ze zich niet realiseren is dat je dan vaak voor gigantische extra kosten en inspanningen komt te staan en het resultaat vaak niet is wat je had gehad als je gewoon meegegaan was met de update cycle.

Maar ja, dat zijn weer beslissingen boven mijn paygrade....

[CAPSLOCK2000]

Ik werk voor een tent die pas net van Oracle 9 af is.
Daar waren verschillende redenen voor, in willekeurige volgorde:

De database-beheerders en de applicatie-beheerders niet dezelfden.
Om de database te upgraden zullen de applicatie-beheerders ook iets moeten doen.
De applicatie-beheerders hebben er geen last van dat er een antieke database draait en zijn dus niet gemotiveerd om iets te doen. Ze hebben het al druk genoeg.

Sommige applicaties zijn ingekocht en worden niet meer ondersteunt door de leverancier. Er is geen budget of tijd om daar iets aan te doen.

Planningen en deadlines worden nooit gehaald. Volgens de planning had applicatie X allang vervangen moeten zijn, maar de deadline is niet gehaald en we kunnen het niet maken om X uit zetten want dan kan de hele tent hier wel dicht.
Tegen de tijd dat het besef komt dat het zo niet verder kan is het al te laat.

De huidige baas/directeur/manager heeft geen zin om een groot deel van z'n budget aan één legacy-applicatie op te offeren, die zingt het wel uit tot z'n contract afloopt. De volgende manager heeft geen zin om een groot deel van z'n budget te offeren aan de erfenis van z'n voorganger. Dat zou ook niet geaccepteerd worden de managementlaag er boven.

Software wordt opgezet met de belofte/suggestie dat het tijdelijk is. Dat is nooit waar. Vervolgens zit je met een applicatie die niet te beheren is. Idem voor dingen dubbel uitvoeren of het opzetten van een goede OTAP-straat.

Jan-en-alleman koopt tegen alle adviezen, beloftes en afspraken in zelf IT in, na een paar jaar komt dat toch bij de centrale IT-afdeling terecht die dan weer met een onbeheerbare applicatie zit.

Aan de voorkant ziet niemand de problemen van een oud systeem. Geen enkele gebruiker vraagt ooit om die oude server te upgraden.

Hoe ouder zo'n systeem, hoe lastiger het wordt om er nog van af te komen.

[mphilipp]

Ja, zo heeft iedereen zijn eigen smoes. Het klinkt een beetje als overheid... (ik spreek uit ervaring).

Ik begrijp werkelijk niet dat het zo moeilijk moet zijn. Iemand (baas, manager, hoofd, weet ik wie) moet toch met de vuist op tafel kunnen slaan en eisen dat men iets doet. Dat heet plannig. Je weet jaren van tevoren dat de support verloopt. Er is méér dan genoeg tijd. Dat applicatiebeheerders geen tijd hebben is in principe nonsens. Als ik in 2005 al weet dat er in 2010 een nieuwe database komt, is dat riant tijd om je voor te bereiden.

Ik heb ook bij zo'n overheidstoko gezeten waar we moesten upgraden. Op één machine konden we niet eens de Oracle Installer starten omdat ze 2 Gold Packs van HP achter liepen op dat systeem. Een andere klant (geen overheid, maar ze maken pindakaas, dè pindakaas) had een Oracle 8 database op een niet langer supported Sun systeem met een Forms applicatie met user exits...ga dát maar een overzetten. Maar ja, eigen schuld. Je zadelt jezelf op met een gigantisch probleem later. Wie dat soort dingen bedenkt moeten ze ontslaan en geen recht op uitkering geven. Dat soort mensen zijn een gevaar voor de samenleving.

[CAPSLOCK2000]

Ik begrijp werkelijk niet dat het zo moeilijk moet zijn. Iemand (baas, manager, hoofd, weet ik wie) moet toch met de vuist op tafel kunnen slaan en eisen dat men iets doet. Dat heet plannig. Je weet jaren van tevoren dat de support verloopt. Er is méér dan genoeg tijd. Dat applicatiebeheerders geen tijd hebben is in principe nonsens. Als ik in 2005 al weet dat er in 2010 een nieuwe database komt, is dat riant tijd om je voor te bereiden.

Het budget is beperkt, daar verander je niet zo veel aan. Met het geld en de mensen die je hebt moet je kiezen uit de 100 prioriteiten die er zijn. Dat is de pijnlijke realiteit. Gebruikers/klanten hebben geen idee van wat er op de achtergrond speelt en zijn niet echt geinteresseerd in veiligheid, goed ontwerp, beheerbaardheid of budget, en die moet je toch tevreden houden want daar doe je het allemaal voor.

[mphilipp]

Ik ken al die argumenten, maar het is een kwestie van plannen. Dit soort zaken komt niet op als poepen. Als je dat niet in je meerjarenplanning opneemt, komt het er inderdaad nooit. Werken met tè oude software is gewoon met geen enkel argument goed te praten. Je verschuift problemen en maakt ze alleen maar groter. Dus bespaar me de argumenten die de bobo's al eeuwen lang gebruiken om dingen goed te praten, want die ken ik. Maar ik zou er niet mee kunnen werken.

Waar ik het tegenkwam, was het steeds in het traject waar je dit moest op zien te lossen. En die kostten altijd teveel tijd en geld omdat het dan zo moeilijk is. Het is dus gewoon een kwestie van goed bestuur. Al die argumenten die je opnoemt zijn gewoon lulkoek.

[Operativus]

Ik vind budget anders een heel goed argument.

[mphilipp]

Inderdaad. Een goed argument om het eerder te doen ipv later.

[Kevinp]

Of en dat is het ook vaak.

De klant wil iets krijgt het. En heeft iets beters dan wat hij al heeft.

Alleen er is (bijna) geen ondersteuning. Dus niemand wil het gebruiken. Vaak met een of ander slecht excuus. Dat wordt gemaakt immers we zijn al zo ver.

En dat gaat maar door tot het uiteindelijk klaar is.Maar je wel iets veel beters (of in ieder geval meer) had dan het project eigenlijk zou moeten omvatten.

[SuperDre]

Nee, probleem is niet dat de klant niet weet wat die wil, probleem is dat het ICT bedrijf niet goed uit de klant kan krijgen wat de klant nodig heeft. Probleem ligt bij het ICT bedrijf, die moet de kennis hebben om uit de klant te halen wat nodig is, en dat is een vak apart, maar HEEL veel ICT bedrijven missen zulke personen, en hebben vaak alleen maar een blikje functioneel ontwerpers die zelf alleen maar simpel vragen aan de klant 'wat wil je?' en verder kijken ze niet. 'wat wil je?' is natuurlijk de basisvraag, maar daarna is het aan jou om te bedenken wat die nou werkelijk wilt en het antwoord dus gebruikt als uitgangspunt. Een goede zou dus eigenlijk een psychiater zijn. Een goede ICT-er weet namelijk dat de klant niet weet wat die nu werkelijk wil.

[Gomez12]

Het is treffend hoe jij het hier neerschrijft, want je geeft perfect de essentie weer waarom het zo vaak fout gaat : Sprints / Fases / Scrum.

Daarin hoeft de klant namelijk expliciet niet te weten wat hij wil, Sterker nog, als een devver een goede dag heeft en een idee wat nergens in de specs staat dan kan hij dit voordragen bij de klant et voila "de klant" wil op dat moment iets anders.

En met sprints/fases kan je geen toleranties opnemen op tijd/geld omdat je uberhaupt geen schatting vooraf kan geven omdat het inherent is aan sprints dat je dingen moet kunnen opgeven en erbij krijgt.
Je kan niet zeggen voor 7 miljoen kan het wellicht dit maar wellicht ook veel minder of veel meer.

En andersom, het is vrij algemeen bekend dat overheidsprojecten overschrijden. Oftewel als je een schatting moet afgeven zonder dat je je ook maar in de basis hebt ingelezen dan is dat voor veel partijen geen enkel probleem, elk probleem / verkeerde planning wordt toch wel betaald door de overheid.
Dus tja, ik weet nog wel een aantal partijen die amper moeite doen om te schatten hoor...

[Kevinp]

En wanneer is een project dan klaar?

Leuk sprints om naar een einddoel te werken. maar je moet weten wanneer iets klaar is (zeker wanneer je het extern laat maken).

Als je scrum / sprints/waterval gebruikt komen er steeds andere dingen bij, en ben je nooit klaar.

Er is geen heilig middel want mijn ervaring is dat de verkeerde mensen vaak besluiten wat de gebruiker wil hebben. (of beter gezegd eigenlijk toch niet).

[thePiett]

Je bent nooit klaar. Klaar zijn met het ontwikkelen van een softwarepakket is een illusie die veel mensen helaas nog altijd bij zich dragen.

[Kevinp]

Niet mee eens. Feature wise kan je klaar zijn. Bugs zullen er altijd zijn. Die kan je oplossen.

Zoals @Gomez12 zegt. Er is geen goede oplossing. Bij scrum krijg je featues die vooral luxe zijn. Bij waterval misschien niet alles, of sommige dingen matig.

Mara vooraf moet wel duidelijk zijn wat het moet kunnen en wat het moet vervangen. Anders ben je nooit klaar. En dan krijg je dit.

Overigens een te grote scope is vaak ook het probleem. We gaan software maken. Ow dan is nieuwe hardware nodig, ow dan is windows 10 nodig. Ow dan zijn nieuwe servers nodig.

Allemaal dingen die bij een project komen die eigenlijk los uitgevoerd moeten worden.

[thePiett]

Waarom zou je "luxe features" krijgen als je agile werkt? Dan doe je het verkeerd, mits de klant duidelijk aangeeft dat ze alleen maar luxe features willen

Zie ook thePiett in 'nieuws: Ict-project CBR valt miljoenen euro's duurder uit dan be... en thePiett in 'nieuws: Ict-project CBR valt miljoenen euro's duurder uit dan be... .

[Gomez12]

En wanneer is een project dan klaar?

Als de basis er is en daarbovenop genoeg fancy dingen zijn gebouwd voor de klant.

Maar ik ben noch voorstander van 100% waterfall noch van 100% scrum.
Bij 100% waterfall zie ik altijd de specs halverwege uitlopen.
Bij 100% scrumm zie ik elke 2 weken geneuzel over welke luxe features we in dit stukje willen zetten terwijl er nog 30 basis-stukken te bouwen zijn.

Ik heb altijd meer zoiets van bouw eerst waterfall een basale basis met tussentijdse opleveringen, zodat de tijd te overzien is en het "geheel" werkt. Daarna kan je per onderdeel gaan scrummen en kan je ook dingen laten liggen omdat je minimaal de basale basis al hebt liggen.

[thePiett]

Als je elke sprint geneuzel hebt over luxe features dan doe je het verkeerd. Je moet je backlog prioriteren in overleg met de klant en daarmee vul je je sprint. Heel simpel.

[Gomez12]

Verkeerd is een ruim begrip, in het voorbeeld van dit nieuwsbericht krijgt de uitvoerder 34 miljoen ipv 7 miljoen. Is dat verkeerd?

De klant gaat niet weglopen, de klant kan jou bij een volgend project niet passeren.

Oftewel sommige mensen bij de klant vervloeken je, maar je hebt 27 miljoen extra en het volgende project hoef je enkel te zeggen dat het nu toch echt anders gaat en je gaat gewoon weer verder

[beerendlauwers]

Bij 100% scrumm zie ik elke 2 weken geneuzel over welke luxe features we in dit stukje willen zetten terwijl er nog 30 basis-stukken te bouwen zijn.

Dan heeft je product owner de moed niet om de stakeholders die al die luxe shit willen, af te houden. Als dev team moet je soms dan de PO helpen doen inzien waarom de basis blokken belangrijker zijn, wat niet altijd leuk werk is (en voor vele devs simpelweg uit hun comfortzone).

[Gomez12]

[...]
Dan heeft je product owner de moed niet om de stakeholders die al die luxe shit willen, af te houden. Als dev team moet je soms dan de PO helpen doen inzien waarom de basis blokken belangrijker zijn, wat niet altijd leuk werk is (en voor vele devs simpelweg uit hun comfortzone).

Lol, "de moed niet hebben"...
Het zijn juist de PO's die volgens jou de moed niet hebben die een project van 7 miljoen optrekken naar 34 miljoen omdat de klant een niet werkend product heeft als hij de zit niet uit blijft zitten.

[thePiett]

Dus jij wil dit soort projecten maar waterfall gaan realiseren? Veel succes

Sprints / Fases / Scrum is één van de weinige manier om succesvol een stuk software te ontwikkelen in samenwerking met een klant. Ik ben zelf freelance ontwikkelaar en heb van alles geprobeerd en gezien bij klanten.

Het probleem is alleen dat er sales-figuren rondlopen die dit principe niet willen snappen. Die trekken namelijk liever een waterfall project van 7M binnen in plaats van een Scrum project waarvan je de uiteindelijk omzet nog niet weet. Voor een klant is die methode ook lastig te doorgronden. Je gaat iets bouwen, maar je weet eigenlijk nog niet precies wat het gaat kosten.

In het geval van het CBR zal het wel een aanbesteding geweest zijn, en dan is het natuurlijk al helemaal lastig om een Scrum-achtig project te offreren.

[Reactie gewijzigd door thePiett op 23 juli 2024 04:39]

[Gomez12]

Dus jij wil dit soort projecten maar waterfall gaan realiseren? Veel succes

Het probleem is veelal dit soort zwart-wit houdingen, of alles waterfall of alles scrum.
Terwijl juist bij projecten van deze grootte het grootste gedeelte simpelweg waterfall is en vastligt vanwege de vereiste functionaliteit en koppelingen etc.

Als er bijv. nieuwe wetgeving komt dan moet daar simpelweg aan voldaan worden, dan kan je niet zeggen : We maken wel even 2 sprints en wat niet af is dat laten we zitten.

Sprints / Fases / Scrum is één van de weinige manier om succesvol een stuk software te ontwikkelen in samenwerking met een klant. Ik ben zelf freelance ontwikkelaar en heb van alles geprobeerd en gezien bij klanten.

Waarom kan het alleen succesvol zijn als jij geen risico loopt en enkel maar uurtje factuurtje schrijft.
Waarom zou ik van een ontwikkelaar niet een bredere blik dan 2 weken mogen verwachten?

Imho weet de gemiddelde klant voor 70% wel wat die wilt hebben, 20% heeft hij geen goed idee over en komt later en de andere 10% is waarin het geimplementeerd moet worden.
Oftewel 70% kan waterval en als de ontwikkelaar ook nog eens advies uitbrengt over waarin het geimplementeerd moet worden dan houdt je nog maar 20% scrummen over.

[thePiett]

In jouw 70 / 20 / 10 situatie loopt dus 70% van het project sowieso in de soep. Waterval werkt alleen in uitzonderlijke gevallen.

Natuurlijk maak je, ook als je alles in kleine stukjes opdeelt, of scrumt, of hoe je het dan ook wil doen (in ieder geval niet een een grote hap) vantevoren een schatting van de doorlooptijd en de totale kosten. Maar daar vertel je ook heel duidelijk bij, dat als ondertussen de requirements wijzigen, dit natuurlijk consequenties heeft voor de doorlooptijd en de kosten. Requirements wijzigen namelijk continue. Zo doe ik het al jaren en dat werkt perfect. Klanten blij, ik blij. Als klanten deze werkwijze niet zien zitten, dan wens ik ze veel succes en sla ik de opdracht af. Ze mogen dan lekker bij Bedrijf X tekenen bij het kruisje voor een gigantisch bedrag waarvoor ze sowieso niet gaan krijgen wat ze willen, maar daar komen ze natuurlijk later pas achter

Ik snap dat dat voor overheidsorganisaties lastig werken is, en ook niet werkt met aanbestedingen, maar zoals het nu gaat is het overduidelijk dat het ook niet werkt. En dat kost ons minstens 1 miljard par jaar.

[Reactie gewijzigd door thePiett op 23 juli 2024 04:39]

[theduke1989]

Ik kan me voorstellen dat veel tweakers niet constant aan projecten doen van grote schaal. Maar ik heb wel een vermoeden dat de overheidsprojecten voor iedereen meer een lust voor geld is dan echt een product neerzetten;) Want de klant hoort vrijwel nooit drastisch van zijn eigen plan/concept te gaan jij bent er alleen om het te realiseren meer niet.

Ik heb genoeg ervaring en projecten uitgevoerd. En mijn doel is om een product te leveren aan de klant. Maar met ''bijzondere wensen'' niet te ver van het project komen te zitten.

Requirement document - Haal zoveel informatie van de klant met wat hij echt wilt. Teken in kaart wat het moet doen en hoe het moet werken. Ga dit niet alleen doen maar met meer mensen omdat ze ''feedback'' ter plekke kunnen geven.
Plan van aanpak - Hoe je het gaat uivoeren, en de rest zoals de tijd scope etc. Bij mij speelt de scope binnen het project en buiten het project echt een belangrijke rol. Wanneer iets buiten de scope valt moet je dit aankaarten en zo aankaarten dat het niet 10-20,- duurder is maar 500-1000-3000,- duurder is want zo schep je een beeld van de gebruiker of die echt serieus is met de buiten de scope of niet. Mocht de klant alsnog akkoord gaan moet je alleen aankaarten hoe ver je buiten de scope gaat en dit het ''eind resulaat ook is''

Zo heb je als beide kanten ''vraag & aflevering'' voltooid. Maar goed dit is in Luxembourg voor mij nu.
Ik kan me voorstellen dat het er anders aan toe gaat in Nederland. ben al ene tijd niet meer geweest.

[Reactie gewijzigd door theduke1989 op 23 juli 2024 04:39]

[Verwijderd]

Je vergeet alleen 1 ding, de overheid. Daar sta je dan met je perfecte PvA en requirements. Aan de slag maar... En dan loopt het vast..

Wisseling in personeel want niemand werkt daar voor vast (allemaal deta) en de personen waar je het van moet hebben zijn keiharde ambtenaren. Rennen hard weg bij het woord verantwoordelijkheid als je ze überhaupt kan vinden want wie weet waar ze uithangen of wanneer hun werktijden zijn. Wisseling van functie en management is ook orde van de dag. En maar hopen dat ze niet een totaal incompetent persoon hebben gepromoveerd omdat hij 'aan de beurt was'. Die requirements? Die lopen vertraging op.. ja, niemand kan ze intern invullen maar ze hebben hiervoor een aanbesteding uitstaan. Komt vast goed. Wanneer? Geen idee, zo snel mogelijk uiteraard. De rest van de requirements zijn in de organisatie verdeeld. Wanneer ze opgeleverd worden? Geen idee, wanneer men er aan toe komt denk ik. Trouwens, we hebben net dit project tussendoor gekregen en een politiek poppetje x heeft besloten dat dit voor gaat.. jij kan wel even op de bank zitten met je ploeg programmeurs, toch? Wordt gewoon doorbetaald hoor, foutje aan onze kant.

Ik kan zo nog wel even doorgaan.

[theduke1989]

Er moeten altijd ''managers'' of aanspreekpunten zijn voor interne projecten en die er verstand van hebben.
Ook bij ons is 90% consultant en 10% managers per devisie. Lijkt me dom om zelfs helemaal niemand intern de overheid te laten draaien. Als dat zo is dan ben je echt verkeerd bezig.

Daarom ik doe dit al jaren van 10 man tot 150,000 personeel nooit last van kleine migraties tot super complexe rafinijen export - import tot aan vracht lucht, water noem maar op.

Je moet het gewoon dichttimmeren en de scope zo klein mogelijk maken .) maar hier ging het gewoon puur om lust van geld meer niet. Jammer genoeg.

Project management - analyst - IT expert zijn is een vak apart. Het zijn de afspraken die je met de klant maakt. Ik maak ze altijd zo compleet en klein mogelijk. Al wil de klant iets anders. De klant weet niet beter dan dat die bijvoorbeeld van iemand iets hoorde en het ook wilt. Maar die andere een compleet andere infra heeft. Is net als met autos verkopen bij veel instanties.

[Reactie gewijzigd door theduke1989 op 23 juli 2024 04:39]

[ninjazx9r98]

Als het een aanbesteding is, wat vaak het geval zal zijn, dan kun je niet of nauwelijks informatie halen. Die kaart wat het moet doen en hoe het moet werken bestaat ook al (want die heeft de klant geschreven of laten schrijven) en jij mag een offerte maken op basis van de informatie die er al is. Uitgezonderd een of meer vragenrondes kun je verder geen informatie krijgen en succes met je offerte.

[theduke1989]

Informatie is er altijd halve informatie is ook informatie. En vanuit dat kan je vaak de mensen omheen om antwoorden vragen. Research heet dat.

Ik doe niks met de Nederlandse overheid maar vaak met België / Luxemburg / Frankrijk. En daar heb je 1 groot probleem dat mensen vaak "gesloten" zijn alsnog gathering of answers. Some 1-3 maanden totdat ik een fatsoenlijke antwoord kan krijgen. Maar goed ik vindt dat de overheid te laks is en dat veel bedrijven gewoon lust naar geld hebben als ze een project voor de overheid hebben. Helaas Atos en Capgemini hier precies het zelfde in Luxemburg. Wordt een beetje moe.

[ninjazx9r98]

Leuk en aardig maar dergelijke research mag niet zomaar tijdens een aanbesteding, iig niet bij de opdrachtgever. Doe je dat wel ben je met een beetje pech direct uitgesloten van deelname.
https://vhadvocaat.nl/blo...-contact-met-aanbesteder/

Die 1-3 maanden heb je mogelijk ook niet. Een aanbesteding heeft een sluitingsdatum voor inleveren, een minuut te laat en je doet niet mee.

[Reactie gewijzigd door ninjazx9r98 op 23 juli 2024 04:39]

[jongetje]

Een paar extra sprints duren niet 2 jaar langer en 26 miljoen meer! Kan me best voorstellen dat een project wat langer duurt maar op zo'n grote schaal is niet normaal. Klinkt als een stuk workflow met document management om beslissingen te ondersteunen. Je kunt het best ingewikkeld praten maar dat hoeft het niet te zijn.

[bbob]

Je zal deels gelijk hebben maar ontrekt me ook niet aan de indruk dat in sommig ict land de overheid een leuke melkkoe is en men dankbaar ge/misbruik maakt van de fouten die de overheid maakt.

Het zal dus ergens in het midden liggen, overheid die niet goed aangeeft c.q binnen de overheid en mensen die ermee werken weten het eigenlijk ook niet. ict bedrijf dat misschien ook proactiever moet zijn maar ja overheid betaald gewoon netjes.

[dehardstyler]

Ik vraag mij eerder af in wat voor projecten jij normaal mee draait, dat je een overschrijding van 5x denkt te kunnen rechtvaardigen.

[Jerie]

Als dat vaak voor komt, kun je het meenemen in je begroting. Of je kunt de klant er voor waarschuwen. Het probleem hierbij is dat het geheim wordt gehouden, en de daders wordt de hand boven het hoofd gehouden (gebrek aan verantwoordelijkheid nemen).

[Soldaatje]

ik snap het niet helemaal, als je afspreekt dit is het bedrag en daar doe je dit voor, en als je dat niet doet dan krijg je nog een boete ook. No cure, no pay. het kan dus wel, maar om een of andere reden willen de overheden dit niet.

[GerritGekke]

Ik draai ook grote projecten en ik weet ook dat opdrachtnemers hier heel slim gebruik van weten te maken. Dan schrijven ze niet meer met de vork maar met de hooivork. De opdracht is immers aanbesteed en de opdracht is binnen. Daar begint de ellende! Met zulke grote projecten zijn er weinig die mee kunnen/mogen doen met aanbestedingen, dus je beland altijd met de zelfden in het aanbestingsproces. Het zijn niet altijd alleen maar wijzigingen en wensen, de opdrachtnemer ziet ook altijd apen en beren op de weg!

Het is een schande dat de projectleider (opdrachtgever) in spe het zo ver laat komen dat een project zoveel overschrijd!

[t link]

In princiepe zou je daarom als bedrijf ook van tevoren een percentage bovenop de offerte geven voor mogelijke uitbreidingen dan kan het alleen maar lager uitvallen of in extremere gevallen hoger.

[armageddon_2k1]

Iets met stuurlui en wal :-) Je hebt helemaal gelijk hoor.

[djs909]

Jeetje, als ik jouw reactie lees bekruipt mij het gevoel dat jij het allemaal maar normaal vindt, dat er honderden miljoenen over de balk worden gepist door incompetente overheidsinstanties.

[SomerenV]

Van 7 miljoen naar 34 miljoen euro. Hoe dan Ik kan daar echt met m'n hoofd niet bij. Wat ik ook niet begrijp is dat ze hier altijd maar mee weg lijken te komen. Stel je huurt een bedrijf in om je badkamer te vernieuwen. Begroting op 10.000 euro, maar tussentijds laten ze weten dat ze qua kosten al over de 45.000 euro heen zitten. Daar gaat toch geen mens mee akkoord? Waarom werkt dat niet bij dit soort projecten?

Kijk, dat je een beetje over het budget heen gaat kan ik nog snappen, maar bijna 5x over het budget heen? Dan ruikt enorm naar mismanagement of een paar slimme lui die hard hun zakken aan het vullen zijn.

[burne]

Je weet heel goed hoe het werkt, want we hebben het er al vaker over gehad. Jij vroeg in de offerte om Gamma huismerk, maar toen je de wc-pot zag veranderde je van mening en moest het Villeroy & Boch worden, en dan gelijk venticello, de duurste die ze hebben. En halverwege moest het muurtje tussen het bad en de wc een halve meter opzij, ook al lag de vloer van Nero Marquina er al in. Ik heb je nog gewaarschuwd voor de kosten, maar jij wilde niet luisteren. En daarom kost je badkamer bijna 70.000 euro en is de oplevering meer dan een jaar te laat.

[TaranQQ]

Ik geloof niet dat je het zo kunt vergelijken. In jouw vergelijking weet je als klant dat je duurder kunt gaan maar de functionaliteit blijft hetzelfde. Bij dit soort ICT projecten beseft de klant vaak niet vooraf wat er allemaal bij komt kijken en wat er precies voor nodig is. Er moeten dus achteraf zaken bij / in die echt wel nodig zijn maar vooraf niet voorzien. Het zou een mooie taak zijn voor de bedrijven die zich hierop inschrijven om daar vooraf inzicht op te geven.
In jouw geval ik vergeet die wc-pot, dan zou het handig zijn als de aannemer in kwestie (ondanks dat hij zonder de wc pot een mooie offerte heeft gemaakt) even erbij zegt "hey ben je die wc-pot niet vergeten? Als je die erbij wil dan kost dat x extra.
Ik ben absoluut geen ICT expert maar met mijn gezond verstand gaat dit er bij mij totaal niet in, dit ruikt gewoon verdacht veel naar 'we maken een goed prijsje en romen de boel dan achteraf wel eens goed af!'
Want als het zo gaat dan hoef je helemaal geen prijsopgave te laten maken, dan kun je net zo goede een goede firma laten komen en zeggen doen maar we zien wel wat het kost....

[burne]

Ik geloof niet dat je het zo kunt vergelijken

Aan een te automatiseren handeling kun je twee dingen aanpassen: de opzet (merk badkuip) en de uitvoering (waar staat het muurtje). ICT-projecten lopen uit de hand omdat men tussentijd dingen aanpast. Vaak is dat voortschrijdend inzicht. Als je eenmaal op de pot kunt zitten kom je er achter dat je geen ruimte meer hebt voor de toiletrolhouder en moet eigenlijk het muurtje een stuk opzij, en sommige kleine aanpassingen kunnen grote gevolgen voor de rest van het project hebben.

Ik ben absoluut geen ICT expert maar [..]

Ik werk sinds 1985 met computers en sinds 1995 met genetwerkte computers (zeg maar internet) en ik doe nu een jaar of 12 klusjes voor de overheid, dus je hoeft het niet eens met me te zijn, maar je kunt er op vertrouwen dat ik wel weet waar ik over praat.

[ninjazx9r98]

Je kunt niet zomaar even iets melden in een aanbesteding. De klant publiceert een opdracht waarin staat wat jij moet bouwen en aan de hand van die informatie maak je een offerte om precies datgene te bouwen en geef je antwoord op en veelvoud aan vragen. In een vragenronde zou je kunnen vragen of er geen wc-pot bij moet en krijg je daar hopelijk een duidelijk antwoord op waarbij alle vragen en antwoorden gedeeld worden met alle inschrijvers. Met gunningscriteria wordt dan gekeken welke offerte het beste past bij de vraag en wordt een keuze gemaakt waar de andere inschrijvers weer bezwaar tegenin kunnen brengen.
Een aanbesteding is echt geen standaard offerte traject waarbij je even met elkaar om tafel gaat en dan een verhaal op papier zet. Tijdens het hele traject mag je niet eens contact hebben met de klant op straffe van uitsluiting.

[TaranQQ]

Tja ik heb dat hele verhaal van aanbesteding nooit helemaal begrepen. Dat de goedkoopste de opdracht krijgt. Voor mij is minstens zo belangrijk wie de opdracht uitvoert, heeft men voldoende kennis, wat is de achtergrond vd firma etc. Anders kun je die wc-pot ook laten zetten door de toevallig in zijn busje passerende pool ....

[Verwijderd]

Exact hoe het gaat, jammer dat ze wel hiermee opnieuw de term "ICT project" elke keer zwart maken.

[3raser]

Tel daarbij op dat het project eerst begroot wordt op een bepaald bedrag maar dat deze tussentijdse wijzigingen weer een compleet nieuw tarief krijgen. Het is net als met een aannemer die een huis bouwt. De bouwkosten staan vast maar het meerwerk daar betaal je dubbel voor.

Dan nog is het bijzonder dat een project meer dan 5 keer over de kop gaat. Dat komt er ongeveer op neer dat van de originele aanbesteding vrijwel niets meer overeind staat.

[FreezeXJ]

Die originele aanbesteding is vaak te optimistisch (want dan wordt ie goedkoper en is de kans groter dat je em daadwerkelijk mag bouwen), en tegen de tijd dat de knelpunten duidelijk worden (klant geeft niet aan dat ie met een oude Oracle werkt vol met triggers, stored procedures en special views, die allemaal mee moeten) ben je al een jaar verder en is er getekend. En dan moet dat toch echt gefikst worden, ook al was bij aanbesteding geroepen dat die database maar een weekje werk zou zijn. Extra kosten dus, en aangezien de klant geen idee had dat het moeilijk zou worden, mag die betalen.

Daarna heb je het kreng eindelijk omgebouwd naar een nieuwe Oracle 12, en dan wil de klant in verband met voortschrijdend inzicht naar een Cassanda. Boem. Weer weken werk, en dan gaat de klant opeens de hele scope ondersteboven gooien, want het moet echt anders. Gek genoeg werkt de sunk costs fallacy dan heel erg goed, en moet er doorgewerkt worden. Dan maar massaal over budget. Daar doen mensen minder moeilijk over dan een nieuwe aanbesteding op basis van nieuwe inzichten.

[Reactie gewijzigd door FreezeXJ op 23 juli 2024 04:39]

[ninjazx9r98]

Zo werkt een aanbesteding dus niet. De klant stelt een definitie op wat er geleverd dient te worden en op basis daarvan maak je een offerte. In een vragenronde kun je dan een en ander vragen en de antwoorden plus vragen worden met alle inschrijvers gedeeld. Verder contact met de klant om vragen te stellen en dergelijke is niet toegestaan en betekent uitsluiting.
Als de klant niets meldt over die oude Oracle en jij er (dus) ook niet naar vraagt kun je het ook niet weten en loop je er tegenaan op het moment dat je bezig bent.

[Gomez12]

Op zich is dit niet zo erg, dit soort wijzigingen valt ook gewoon in te plannen (binnen bepaalde marges).

Je negeert alleen eventjes dat terwijl jij zat te wachten om het gamma huismerk in de aanbieding in te kopen, dat ding er bij de gamma uitgemieterd is en dus niet meer leverbaar. En dat je nu vandaag een beslissing moet hebben omdat je vandaag wilde inkopen om morgen te plaatsen...

Of die wettelijke verplichting die verkeerd is geinterpreteerd door de programmeur en de tester waardoor er 3 maanden werk weggemieterd kan worden.

Teveel "Planningsmeesters" gezien die op het moment dat ik het fixed price op hun planning wilde doen zonder wijzigingen of iets, dat dan toch het tarief met minimaal 2,5 vermenigvuldigd moest worden om hun risico's af te dekken...

[Sando]

Maar aangezien dit keer op keer op keer gebeurt, en het product vaak ondanks de aanzienlijke kostenoverschrijding alsnog zo onbruikbaar is dat het naar de prullenbak wordt verwezen, kunnen we dan niet voorzichtig stellen dat er iets moet veranderen?

Het gaat gewoon overal mis. Belastingdienst, UWV, OV-Chipkaart, Patientendossier, C2000, Defensie, Politie, Gemeentelijke Basisadministratie, CBR, NVWA. Al 20 jaar lang. Ik las onlangs in het AD dat we tot 5 miljard per jaar weggooien gaan falende ICT projecten. Voor dat geld hadden we ook gratis OV kunnen hebben. Of het eigen risico in de zorg afschaffen. Of rendementsbelasting 4 keer afschaffen. Of uitstel van twee Brexits vetoën en alle Nederlandse bedrijven na een hard Brexit schadeloos stellen. Falende ICT kost elke werkende Nederlander €500 per jaar.

Ik snap niet zo goed waarom bij elk artikel op Tweakers er zo lakoniek over gedaan wordt. In plaats van 4 jaar vergaderen over de cookiewet zou dit wat mij betreft vrij hoog op de agenda moeten staan. Het is niet dat er een foutje wordt gemaakt; de overheid en ICT zijn gewoon rampzalig bezig. Ok, heel goed dat we hier op Tweakers precies weten hoe dat komt. Laten we dan nu een lijst met aanbevelingen opstellen om dit te voorkomen.

[Reactie gewijzigd door Sando op 23 juli 2024 04:39]

[CAPSLOCK2000]

Ik snap niet zo goed waarom bij elk artikel op Tweakers er zo lakoniek over gedaan wordt. In plaats van 4 jaar vergaderen over de cookiewet zou dit wat mij betreft vrij hoog op de agenda moeten staan. Het is niet dat er een foutje wordt gemaakt; de overheid en ICT zijn gewoon rampzalig bezig. Ok, heel goed dat we hier op Tweakers precies weten hoe dat komt. Laten we dan nu een lijst met aanbevelingen opstellen om dit te voorkomen.

Het heeft niks met de overheid te maken. Bijna overal gaat het zo, maar bij de overheid is het erg zichtbaar omdat de overheid transparant is en gigantische projecten met enorme budgetten heeft.

Wat ik niet durf te zeggen is hoe groot het verschil tussen ICT en andere sectoren is. Ik spreek wel eens met een bouwvakker en daar lijkt de ellende soms net zo groot. Het verschil is misschien wel dat we een paar duizend jaar ervaring hebben met bouwen en daarom strenge eisen met ruime marges hanteren om daar mee om te gaan.

IT is een stuk complexer dan veel andere gebieden. Je hebt maar weinig te maken met fysieke grenzen. Alles kan met alles interacteren, en hoe meer van die interacties je hebt, hoe complexer het systeem wordt.

Wat ook niet helpt is het beeld dat IT snel & goedkoop is. Er heerst toch een beetje het beeld van Whizzkids die in een half uurtje een heel IT-systeem uit de grond stampen waarna een afdeling van 60 medewerkers kan worden ontslagen. Mensen verwachten dat IT snel en goedkoop is. Als je ze vertelt dat het project even veel kost als 5 jaar salaris voor die 60 medewerkers dan vindt iedereen dat belachelijk.

[Sando]

Ik ben het eens met het tweede deel van je analyse. Niet met het sentiment dat de hoeveelheid overschrijding en mislukking niet enorm buiten de boot valt.

Het is interessant om het rapport Lessen uit ICT-projecten bij de overheid (2007) van de algemene rekenkamer er eens bij te nemen. In 2007 zijn de voornaamste problemen bekend, en wordt aangegeven dat ook toen al de oplossingen al eerder bekend waren. Helaas wordt hiermee niks gedaan. Je zou heus wel wat regels en verplichtingen en verboden kunnen instellen bij dergelijke projecten. Een verbod om elke maand je plannen te wijzigen bijvoorbeeld.

[JMS 450]

Het beheren van de scope (hoeveelheid afgesproken werk) en wijzigingen daarop is een vak apart. Al heel wat projecten gezien die verlies leden omdat de klant of aannemer hun zaakjes niet op orde hadden.

Klant; Oh ik wilde dit toch anders.
Aannemer; Oke dat is een wijziging, x uur extra werk akkoord?
Klant; Ja

Klant houd niet bij hoe vaak hij/zij van gedachten veranderd en hopla verder over budget dan verwacht. (is 5 keer over budget nog steeds erg knap)

[Bosmonster]

Het is bijna alsof ze daar iets voor uitgevonden hebben. Ow ja, Agile!

edit:
Even een verduidelijking dan, aangezien agile dus juist een projectmethodiek is die ervoor zorgt dat de opdrachtgever ZELF de verantwoordelijkheid krijgt over de scope-creep en prioriteiten. En het probleem dat geschetst wordt van "klant houdt niet bij hoe vaak hij/zij van gedachten verandert" dus toonbaar wordt gemaakt.

Daarnaast werk je allereerst naar een MVP toe (ipv documentatie), omdat je altijd bezig bent op basis van prioriteiten, niet functionaliteiten, wat de kans op een niet bruikbaar product na een afgelopen termijn verkleint.

[Reactie gewijzigd door Bosmonster op 23 juli 2024 04:39]

[JMS 450]

Beetje onterecht dat je -1 krijgt. (inmiddels al +1)

Agile is een project organisatie tool. Vooral aan de uitvoerings-/engineers-kant om de omvang van het werk op te delen in behapbare brokken en je engineers aan te sturen. Een overkoepelende organisatie (kan idd ook klant zijn) bepaalt de prioriteit van de brokken werk en elke vaste interval is er een leveringsmoment.
De scope is het afgesproken stuk werk bij aanvang van een project. Dit is dan ook vaak de som waarvoor het project wordt uitbesteed en wat ter verantwoording wordt opgedragen en waar toestemming voor wordt gegeven. Als daar een wijziging op komt verandert ook de verwachte duur en prijs. Iemand moet hier verantwoording over afleggen aan iemand anders. Uitvoerder aan klant, en klant aan stakeholders.

Het belang van het bijhouden van wijzigingen op de totale scope is vrij uniform voor alle, ook niet agile, projecten.

Scope creep (elke keer een kleine wijziging) is de doodsteek voor elk project, en elke projectmanager. Vooral als je je engineers (volledig) loslaat (of als je ze tegen je in het harnas hebt gejaagd) en vrij met de klant laat praten krijg je het "oh ja dat doen we wel even" probleem. elke meeting met de klant een uurtje er bij.
Zelfde geld ook andersom dat je als klant niet elke meeting een beetje extra werk geeft dat genotuleerd en gefactureerd wordt.

On topic; zat net het originele artikel te lezen. Zembla gaat terecht over hun stekker dat het ministerie pas op de hoogte werd gesteld nadat het project 3 jaar liep al was op gelopen tot 23.75 miljoen tov het budget van 7 miljoen...

[Reactie gewijzigd door JMS 450 op 23 juli 2024 04:39]

[F-I-X]

Meer gezond verstand en weten wat je moet doen. En dat mag je wel verwachten voor de salarisschaal die bij deze projecten betrokken is.
Wat voor flitsende term je dan ook mag gebruiken "agile" "Lean" whatever.

[CAPSLOCK2000]

Even een verduidelijking dan, aangezien agile dus juist een projectmethodiek is die ervoor zorgt dat de opdrachtgever ZELF de verantwoordelijkheid krijgt over de scope-creep en prioriteiten. En het probleem dat geschetst wordt van "klant houdt niet bij hoe vaak hij/zij van gedachten verandert" dus toonbaar wordt gemaakt.

Agile helpt om de klant zelf de keuzes te laten maken, maar het voorkomt niet dat projecten hun budget overschrijden. Als X, Y en Z nodig zijn om aan de wettelijke verplichtingen te voldoen dan zal de klant doorgaan tot X, Y en Z bereikt zijn, ook al was na drie maanden duidelijk dat het budget te krap is.

[theduke1989]

Daarom plan je ook een plan van aanpak met een scope wat binnen het project val en wat er buiten valt.
Als je de scope wat er buiten valt zo danig beperkt dat de klant niet zoveel kan eisen. Kan je een project afmaken.

Maar nee alles draait om geld en dan is het ja we kunnen alles maar tegen duurder bla bla. Het is ook niet altijd de schuld van de klant. Maar ook van die uitvoerder alles draait om geld maar niet om succesvolle producten af te handelen.

Per j aar doe ik ongeveer 5-15 migratieprojecten daarbij komen dit soort vragen ook altijd bij. En ik breng eerst in kaart hoe ver ze van de scope kunenn en hoeveel het kost en vaak gaan ze akkoord. Als jij niks afspreekt tja dan is het dus puur lust vvoor geld.

[Reactie gewijzigd door theduke1989 op 23 juli 2024 04:39]

[Praetextatus]

Och niet alleen de klanten hoor. Ik heb zelf meegemaakt dat externen word ingehuurd die alles bij elkaar liegen en beloven enkel om een contract binnen te halen.
Hierna is het allemaal excuses zoeken om extra budgetten vrij te krijgen of planningen te wijzigen.

[Mastermind]

Denk dat 80% aan de strijkstok blijft hangen inderdaad.
Ik begrijp ook niet hoe dit kan. Kan geen ander voorbeeld bedenken waar het bedrijf tussentijds zegt "oh het wordt toch 5x zo duur" en je daar dan gewoon mee akkoord dient te gaan.

[Seth_Chaos]

Nee, de ingehuurde bedrijven kaderen heel goed af wat er binnen en buiten het contract valt. Dat staat zwart op wit. Door mismanagement aan de klant kant wordt er niet goed vast gesteld wat er allemaal in dat contact moet staan. Met als gevolg dat gedurende het project er steeds weer zaken moeten worden toegevoegd aan het contract. Met als gevolg dat het budget dus ook voortdurend moet worden bijgesteld.

Bedrijven zijn daar heel scherp in, want alles binnen het contract, dat langer duurt dan begroot, kost ze operationele winst. Een ambtenaar bij de overheid spendeerd zijn budget en houdt vervolgens zijn hand op bij zijn directe leidinggevende, en krijgt dan meer budget. Het heeft geen directe gevolgen voor die manager. En wanneer men het punt bereikt heeft dat, dat wel het geval is. Worden ze op straat gezet met een hele aardige ontslag premie en een mooie staat op hun CV, waarmee ze zo weer aan de slag kunnen bij de volgende instantie. Want die zijn immers ook weer opzoek naar een manager nadat hun vorige manager er net zo'n zooi van gemaakt heeft.

Het is een eeuwige cyclus van mismanagement. En niemand in dat cirkeltje heeft er baat bij die cirkel te doorbreken.

[Reactie gewijzigd door Seth_Chaos op 23 juli 2024 04:39]

[droner]

Sympathie voor de risico's van bedrijven is in deze wel een gotspe, dit zijn gasten die opdrachten 4x, 5x over de kop zien gaan wat allemaal betaald wordt. Hele volksstammen aan IT managers zeilen met privéjachten de Stille Zuidzee af met dat geld.

Je moet niet vergeten dat de opdrachtnemer ook vaak als adviseur fungeert: je geeft advies om het zus en zo te doen en vervolgens sleep je die opdracht binnen als concept plus uitvoering. Opdrachtnemers kunnen overheidsmanagers zo heel handig richting een eindeloos verhaal manipuleren en dat gebeurt ook.

[Seth_Chaos]

Die bedrijven leveren dan ook een hoop extra werk voor die hogere kosten. Als ze dat werk niet verricht hadden bij instantie A, dan hadden ze die tijd en dat geld geinvesteerd in instantie B. Die bedrijven doen het geen waar ze voor betaald worden. Dat kun je niet zeggen van die MT leden van die (semi)overheidsinstellingen. Die maken er gewoon een puinhoop van.

De prijs voor een enkele gedetacheerde programmeur voor de duur van 5 jaar loopt al op tot ver boven de 1,5 miljoen euro. Maak daar een heel team van, en gooi daar het support contract nog eens boven op, en dan is er al niet heel veel meer over voor één privejacht. Misschien een bijbootje.

[droner]

Ja, extra werk wat je zelf creëert door de klant handig in die richting te manipuleren. Enig idee wat een voordeel het oplevert om 5 jaar lang voor 1 en dezelfde klant te kunnen werken zonder tijd te hoeven investeren in het binnenhalen van nieuwe opdrachten - en dan helemaal een klant met lage eisen en die geweldig goed van betalen is? Vaak een veelvoud van het aantal uren voor hetzelfde tarief of zelfs een veel hoger tarief dan waar je dat oorspronkelijk veel kleinere project voor aanbood ('Wij bieden u een hele mooie korting. Ja bij meerwerk moeten we wel ons normale tarief hanteren, maar dat proberen we natuurlijk samen te voorkomen!')?
Zo'n overheidsklus is een goudmijn, mensen lopen radicaal binnen.

NB: ik wil zeker niet suggeren dat het allemaal oplichters zijn, maar ik weet uit ervaring dat deze praktijken plaatsvinden en zeker niet bij de meest obscure aannemers, om het zo maar te zeggen.

[Reactie gewijzigd door droner op 23 juli 2024 04:39]

[bbob]

5 jaar 1,5 miljoen euro. Dat is 300.000 euro per jaar.
Misschien ligt het aan bij maar 3 ton per jaar voor 1 iemand. Dat moet dan toch iemand zijn die extreem goed is. Tenzij het idd paar keer over de kop gaat en er veel in de organisatie blijft hangen.

[MadEgg]

5 jaar 1,5 miljoen euro. Dat is 300.000 euro per jaar.
Misschien ligt het aan bij maar 3 ton per jaar voor 1 iemand. Dat moet dan toch iemand zijn die extreem goed is. Tenzij het idd paar keer over de kop gaat en er veel in de organisatie blijft hangen.

Dat laatste dus. De consultant zelf krijgt misschien 25% tot 50% van wat er voor hem/haar gerekend wordt.

[bbob]

Tja dan blijft er dus ergens aardig wat hangen.

[Gomez12]

Nee, de ingehuurde bedrijven kaderen heel goed af wat er binnen en buiten het contract valt. Dat staat zwart op wit. Door mismanagement aan de klant kant wordt er niet goed vast gesteld wat er allemaal in dat contact moet staan.

Deels mismanagement en deels simpelweg oplichting van de bedrijven.

Mondeling toezeggen dat je iets begrijpt, schriftelijk toezeggen dat je iets begrijpt en dan in het contract opnemen dat het gebouwd wordt zoals het begrepen wordt. Dan staat er dus niets in het contract.

Of zeggen dat een ditje of een datje maar max een weekje werk is en dat dat dus niet in het contract hoeft als de klant er nog niet 100% uit is, simpelweg wetende dat het gewoon een half jaar werk is.

Of trajecten waarbij het testen erbuiten gelaten wordt, of trajecten waarbij de goedkeuring afhankelijk is van de tester (terwijl de tester bij het bedrijf zit).

Je hebt zat overheidsmensen die het wel beter willen hoor, alleen dan moeten de bedrijven ook wel mee gaan doen.

[n8n]

Omdat cliënten als de badkamer bijna af is bedenken dat ze een wijziging willen waardoor 2/3 van de badkamer opnieuw gedaan moet worden, en voor het huis waar het in staat een nieuwe fundering nodig is.

[bbob]

Probleem lijkt me soms eerder dat overheid aanbesteding doet en de adviseur die deels ook alles opstelt de uitvoerder is.

Stel een adviseur aan betaald die en maak die verantwoordelijk. Als deze verkeerd geadviseerd heeft, heeft hij een probleem als de bedragen hoger worden.
Als adviseur en uitvoerder 1 zijn, tja dan ligt het altijd aan de klant.

[joke_name]

Het grote probleem met de soort projecten zijn de volgende dingen:

Overheid heeft heel vaak maatwerk nodig.
- Want er bestaat geen tweede CBR / NVWA in nederland.
- De overheid stelt soms onhaalbare eisen.

Bijvoorbeeld bij een SAAS applicatie minimaal laadtijd van 2 seconden in 90 procent van de gevallen
5 procent tussen 2-4 seconden en 5 procent tussen 4-6 seconden.

Hier wordt op getest en haalt je dit niet mag het weer terug naar de tekentafel.

[Supercop]

Dat niet alleen, maar het zijn politiek gedreven organisaties. Ik werk zelf ook als consultant bij een overheidsinstelling.

De ervaring die ik op dit moment heb (x aantal jaar werkzaam binnen de overheid)

-Specificaties (wetgeving) is dermate ingewikkeld, waardoor het soms erg lastig is dit te vertalen naar juiste userstories.
-Wetgeving & interpretatie daarvan kan regelmatig wijzigen door hernieuwde inzichten of door er op een andere manier naar te kijken
-Wettelijk vastgestelde termijnen (bijv bezwaartermijnen) of verjaringstermijnen beinvloeden het 'agile' proces, waardoor er keiharde deadlines worden neergezet ipv een gewenste einddatum, dit resulteert vaak in half werk (want er is geen tijd om alles 100% te doen)
-Berichtgeving rondom projecten (vooral negatieve) veroorzaken paniek op hoog management/politiek niveau (een kat in het nauw verhaal) waardoor de scope drastisch kan wijzigen( we gaan het vanaf vandaag allemaal anders doen) dit heeft een negatief effect op het uitvoerend personeel..

Ik kan zo nog wel even doorgaan.De cultuur die op die moment heerst in de politiek, namelijk, de verantwoordelijk altijd op een ander proberen af te schuiven om je eigen vel te redden, veroorzaakt vooral bij IT projecten, die al vaak negatief in het nieuws komen, erg veel problemen.

[TweakerNummer]

Begrijp ik je goed en worden wetten daadwerkelijk vertaalt naar userstories?

[Supercop]

niet 1 op 1, maar het zijn wel de kaders waarin je moet werken.
Neem als voorbeeld.
De burger kan gegevens van een onderneming invoeren op een aangifte formulier. Dan gelden er allerlei wet en regelgevingen.
-Wat definieert een onderneming, bsn? rsin? of mag de burger ook gewoon adresgegevens invoeren
-Welke rechtsvorm is de onderneming? BV? dan mogen/moeten er weer tal van aanvullende gegevens invoerd worden (volgens de wet) het lijkt allemaal zo makkelijk, maar we hebben soms te maken met wetten uit de jaren 50 (successierecht bijv) die in de hedendaagse samenleving anders geïnterpreteerd kunnen worden...zo zijn er tal van voorbeelden

[burne]

Als gewone burger wil ik makkelijk online controleren of ik een omgevingsvergunning nodig heb. En de bijbehorende satisfied requirement.

[TweakerNummer]

Wat is er makkelijk aan "Is de voorgenomen activiteit in strijd met het bestemmingsplan, de beheersverordening, het exploitatieplan, regels op grond van de provinciale verordening, regels op grond van een AMvB of regels van het voorbereidingsbesluit?"?

[BvH]

https://www.cginederland.nl/nl/artikelen/nieuwsbrief/move-smarter/2014-06/cbr

In ieder geval dit bedrijf is er bij betrokken.

[droner]

Pagina is heel haastig offline gehaald, netjes hoor.
Iets te verbergen?

[BvH]

Google cache is your friend

[Hatsjoe]

Misschien wordt het tijd om de offerte bindend te maken voor de partijen die de offerte doen. Valt het duurder uit dan je dacht? Jammer joh, dat wordt op de blaren zitten. Denk dat we op deze manier een stuk eerlijkere offertes krijgen en bevordert ook de marktwerking.

[Xirt]

Het probleem hoeft niet te zitten in de tijd die gestoken werd in de activiteiten die beschreven werden in het initiele contract. Het kan best zo zijn dat de scope flink verandert is (daar zijn bedrijven heel goed in), dat er dingen gemist zijn of dat het veel te vaag is opgeschreven. In al die gevallen zal je dan toch moeten gaan kijken naar een addendum op het contract met bijbehorende extra kosten of / en langere tijdslijnen. Echter, in dit geval vraag ik me serieus af wie heb budget beheerde gezien de significante verschillen en het achterhouden voor het ministerie...

[koelpasta]

Valt het duurder uit dan je dacht? Jammer joh, dat wordt op de blaren zitten.

Maar dan krijg je dat de bedrijven niet meer flexibel omgaan met de aanbesteding.
Nieuwe features of halverwege project het allemaal anders doen omdat er nieuwe feiten opdoemen zit er dan niet meer in.
En dat gaat uiteindelijk nog meer geld kosten.

[JMS 450]

Een nieuwe feature is een wijziging. Een wijziging is extra geld. Geen enkele partij zal zomaar wijzigingen accepteren zonder dat het hem iets (extra's) oplevert.
Zie het als dat je een auto besteld en besluit dat je halverwege de lever tijd besluit dat wit ipv rood moet worden omdat rode auto's duurder zijn in de verzekering...

Probleem is het bijhouden van wijzigingen of nog erger wijzigingen op wijzigingen.
Als men dan op basis van dat overzicht ook daad werkelijk toezicht gaat houden dan beheers je dit soort processen.

[vanaalten]

Dan begin je dus met een openbare aanbesteding en je kiest de partij die het meest aantrekkelijke aanbod heeft (lees: goedkoopste is). Vervolgens begint het werk - en je kan er zeker van zijn dat er gedurende de looptijd wijzigingen komen. Dan zit je dus al vast aan de commercieele partij en die kan vervolgens absurde bedragen vragen voor kleine wijzigingen.

Dan beheers je het proces, maar niet het geld...

[3raser]

Volgens mij zijn ze zelfs verplicht om het goedkoopste aanbod te accepteren. Het is dan ook dikke business om als aannemer de aanbesteding zo goed mogelijk te controleren op fouten en gaten. Als het niet duidelijk omschreven is weet je van tevoren al dat er geld te verdienen valt. Op die manier kun je een goedkoper aanbod doen om achteraf dik geld te verdienen. En aangezien iedereen weet dat bij de overheid het geld toch niet op kan is dat de beste klant om te hebben. Er is niemand die klaagt en is wordt vrijwel nooit iemand voor afgestraft. De kans dat je niet betaald krijgt of dat het project gestopt wordt zijn klein.

Hoe los je dit als overheid op? Door je eisen veel beter vast te leggen. Steek veel meer tijd in het maken van de aanbesteding. Dat geld verdien je ruimschoots terug.

[ninjazx9r98]

Een dergelijke verplichting is er niet. Je geeft vantevoren met gunningscriteria aan hoe je de beste gaat kiezen, meer info op bijv
https://www.pianoo.nl/nl/...u-als-gemeente-daarmee-om

[koelpasta]

Geen enkele partij zal zomaar wijzigingen accepteren zonder dat het hem iets (extra's) oplevert.

Ja, maar dat gebeurt nu toch ook? Waarom denk je dat de projectkosten zo enorm stijgen?

[JMS 450]

Je hebt wijzigingen en foutjes.
Wijzigingen zijn dingen die de klant wilde maar nu niet meer of die niet mogelijk zijn
Foutjes zijn dingen die je als uitvoerder hebt gedaan en die je idd niet kunt door berekenen.

De eerste is een eis onvoldoende beschrijven zeggen dat de auto die je wil moet kunnen accelereren maar niet hoe snel. Later ben je niet tevreden omdat 0-100 km/uur 20 seconden duurt en het moet sneller.

De tweede is als je als bouwer van de auto het stuur aan de verkeerde kant zetten terwijl je weet dat ie voor Nederland is bedoeld.

Anders om als ik als klant weet dat ik misschien ga verhuizen naar Londen kan ik zeggen weetje dat stuur laat maar zitten en geef me 5% korting. Wijziging en acceptatie.

[Quilt]

De winnaar van de offerte gaat dan failliet. En dan kan je opnieuw beginnen.

[m3gA]

Als je alles goed op papier zet zal het wel loslopen. Wil je de scope veranderen? Scope change en bijbetalen.

[ninjazx9r98]

Bijbetalen zodat het "ineens" vele miljoenen duurder wordt? Dat was toch juist niet de bedoeling?

[Philip Ross]

En de volgende die een offerte aanbied denkt wel 2 keer na over vage omschrijvingen en pogingen je op te lichten.

[Von Helm]

En wat is het verschil met de situatie nu voor de overheid? In beide gevallen is het project niet af. Maar het incompetent ICT bedrijf is nu wel weg. Opgeruimd staat netjes.

[Bart ®]

Denk je serieus dat als het zó simpel was, dit niet allang gedaan werd .

[bytemaster460]

Dat is fixed price. Als een bedrijf daarvoor een offerte moet uitbrengen gaat men de risico's incalculeren en doorberekenen in de offerte. Daarnaast betaal je dan de hoofdprijs voor iedere afwijking t.o.v. de oorspronkelijke opdracht en de ervaring leert dat er gaandeweg heel veel nieuwe inzichten, voortschrijdend inzicht, slechte ontwerpen, nieuwe regelgeving, etc. opdoemen.

[F-I-X]

Volgens mij hebben veel wijzigingen meer te maken met uit welke richting de wind waait dan dat er werkelijk goed onderbouwde wijzigingen worden aangevraagd. Zoals met elke overheid en semi-overheidsorganisatie is de bestuursstructuur een omgekeerde piramide met veel teveel mensen die alleen denken in de mooie termen en nergens op worden afgerekend. Vrij van enige kennis hun zin doordrukken.

Een duidelijke Programma van Eisen en een lock nadien op wijzigingen zou met een vaste prijs bij aanbesteding het inschrijf bedrag realistischer maken en de ontwikkeltijd verkorten.
Helaas wordt bij zon ICT project ook tegelijk(!!) besloten dat er organisatorisch een boel moet worden omgezet en nieuwe werkmethodes worden ontwikkeld die dan dwars door de nieuwe ICT loopt, met alleen maar grotere wijzigingen en "de ICT lost het wel op"

Zoveel onkunde op de verschillende ministeries en overheidsorganen dat je gewoon niet meer weet hoe je dit ooit omgedraaid krijgt.

[CAPSLOCK2000]

Misschien wordt het tijd om de offerte bindend te maken voor de partijen die de offerte doen. Valt het duurder uit dan je dacht? Jammer joh, dat wordt op de blaren zitten. Denk dat we op deze manier een stuk eerlijkere offertes krijgen en bevordert ook de marktwerking.

Ik heb wel eens zo iets gesuggereerd en alle geinteresseerde bedrijven gaven aan dat ze dan niet zouden meedoen want dat risico willen ze niet dragen. Vol ongeloof vroeg ik aan mijn baas of wij het accepteren dat al die bedrijven eigenlijk zeggen dat ze vooraf al weten dat het budget overschreden gaat worden. Hij gaf aan dat die bedrijven zo veel werk hebben dat moeilijke klanten gewoon geweigerd worden, alleen gewillige slachtoffers kunnen software laten maken.

[MadEgg]

Dat werkt dus niet, want dan ga je er vanuit dat vooraf het volledige project juist ingeschat kan worden.De uitvoerders zullen dan geen wijzigingen toestaan wat uiteindelijk tot een onjuiste oplossing leidt wat wel geld gekost heeft, precies volgens budget, maar niet brengt wat het had moeten brengen.

Wel zou er eens zeer goed gekeken moeten worden waarom de wijzigingen aan het oorspronkelijke plan zich altijd opstapelen, en wellicht zou er strenger opgetreden moeten worden tegen wijzingen die budget en tijdspad in gevaar brengen. In veel gevallen zou het slimmer kunnen zijn om een deel van de wijzigingen af te wijzen en door te schuiven naar een vervolgproject.

Liever een project wat af is en redelijk binnen budget gebleven is waarbij de scope wat gelimiteerd gebleven is dan een megalomaan project wat in een keer alles moet oplossen en iedereen tevreden houdt maar daardoor nooit afkomt en veel te veel geld kost.

[Quindor]

En weer het zoveelste overheid ICT project wat tig miljoenen teveel kost. Ik roep het wel vaker, maar als de overheid een bedrijf zou zijn, zouden ze aan de ICT projecten alleen al failliet gaan.

In de normale bedrijfs sector kunnen dit soort dingen gewoon echt niet. Huur dan mensen in om die specificaties duidelijk te krijgen, maar het op deze manier doen, wtf.

Het ergste is nog, waarschijnlijk word er niemand ontslagen vanwege dit debacle dus kunnen ze het over een paar jaar nog een keer doen.

[einreb73]

In het bedrijfsleven gebeurd het ook en net zo vaak, daar is onderzoek naar gedaan :
https://www.theguardian.c...complex-software-projects
Bij de overheid komt het altijd in het nieuws vanwege de controle functie van de tweede kamer, bedrijven gaan hun vuile was natuurlijk niet buiten hangen.

[Niels1985]

In de normale bedrijfs sector kunnen dit soort dingen gewoon echt niet. Huur dan mensen in om die specificaties duidelijk te krijgen, maar het op deze manier doen, wtf.

En die mensen hebben er vervolgens alleen maar baat bij het project zolang mogelijk te laten lopen, zo vaak mogelijk te ping-pongen.

[mrFREDZ]

Helaas worden ze worden zelf gepromoot of krijgen andere top baantjes bij de overheid. Vroeger op ICT school hadden 2 type studenten 1 die van Computer hield en de andere die het voor het Geld deed.

[StephanVierkant]

Was het maar zo'n feestje, zo'n simpele wereld. De oplossing zou dan zijn om een paar goede manager in te huren en dan ben je er. Maar zo zit het helaas niet.

Ook bij bedrijven zijn er projecten (ICT-projecten incluis) met honderden procenten overschrijding of projecten die jarenlang uitlopen. Je kunt gaan bashen op 'de overheid' (verzamelterm voor diverse organisaties overigens), maar het gaat hier om complexe projecten en daar gaat wel eens iets mis. Bij bedrijven worden die afgeschreven of voor lief genomen.

Bij overheidsprojecten zijn er een aantal factoren die bij bedrijven niet of in mindere mate gelden. Om maar eens twee te noemen:

• Transparantie. Alles wat overheden uitgeven moet worden gerapporteerd aan volksvertegenwoordiging (gemeenteraad, parlement, Staten) en ook de Rekenkamer en vergelijkbare/verwante organisaties. Maximale transparantie dus. En dan heb ik de Wet Openbaarheid Bestuur nog niet eens genoemd. Ik ken commerciële projecten van tientallen miljoenen die faliekant zijn mislukt, maar waar niemand behoefte (laat staan de plicht!) heeft om die faalprojecten aan de buitenwereld te melden.
• Politieke besluitvorming. Geldt ook voor bedrijven, maar in mindere mate. Om een project van een zekere omvang van de grond te krijgen hebben allerlei stakeholders belang én de mogelijkheid om invloed uit te oefenen. Er is geen CEO of grootaandeelhouder die z'n stem kan doordrukken, iedereen moet z'n plasje er over heen doen. Mogelijk risico: waterige compromissen die in de uitvoering voor problemen zorgen

Natuurlijk gaan er dingen mis en moeten we daarvan leren. Maar lekker op 'de overheid' vloeken lucht misschien op en is goed voor je eigen ego, maar roepen dat de specificaties beter moeten en dat slechte managers moeten worden ontslagen, is een simplificatie die totaal geen recht doet aan een complex project met politieke en transparante besluitvorming.

[BeArt]

Misschien is het omdat ik Belg ben, maar wie of wat is het CBR?

[Verwijderd]

Centraal Bureau Rijvaardigheid.

[Wannial]

Centraal bureau rijvaardigheid.
Voor je rijexamens en rijvaardigheden etc.

[rg-mohwa]

Het Centraal Bureau Rijvaardigheidsbewijzen

https://www.rijksoverheid...jvaardigheidsbewijzen-cbr

[Wmm]

Centraal Bureau Rijvaardigheidsbewijzen.

Het Centraal Bureau Rijvaardigheidsbewijzen (het CBR) is een publiekrechtelijk zelfstandig bestuursorgaan (zbo). Het CBR is door de Nederlandse minister van Infrastructuur en Milieu belast met een verkeersveiligheidstaak: het beoordelen van de rijvaardigheid en medische geschiktheid van bestuurders en de vakbekwaamheid van professionals in transport en logistiek.

https://nl.wikipedia.org/...u_Rijvaardigheidsbewijzen. Ik heb geen idee hoe de Belgische versie heet (als er al iets is dat 1 op 1 vergelijkbaar is).

[Jermak]

Dat ZBO is het probleem. al 40 jaar is het een zooitje.

1) geen toezicht van de "overheid" mogelijk door ZBO status.
2) geen targets
3) geen sancties
4) te hoge tarieven.

Als de RDW zo zou werken als het CBR , dan had de belastingdienst allang ingegrepen.

CBR afschaffen en een nieuw orgaan opzetten.

[toxicsplatterz]

Het Centraal Bureau Rijvaardigheidsbewijzen, zij regelen de examens en het afrijden voor rijbewijzen.

[Remco0]

CBR is het Centraal Bureau Rijvaardigheidsbewijzen.

Dat is waar je, na het volgen van autorijlessen, examen aflegt om je rijbewijs te halen.
Verder vinden er ook controles op verlengingen en medische keuringen plaats en regelt het CBR alcohol en verkeersveiligheid cursussen die kunnen worden opgelegd door Justitie wanneer iemand met alcohol op achter het stuur wordt gepakt.

[hooibergje]

Dat is de reden dat buschauffeurs ontslagen worden omdat hun rijbewijs al maanden niet verlengd wordt. Beroepschauffeurs moeten elk jaar een keuring ondergaan. Geen OK, geen verlenging, geen rijbewijs. Het CBR loopt maanden achter, dus duizenden beroepschauffers zitten nu op de bank thuis mooi te wezen.

[RoJan]

Beroepschauffeurs zijn degenen die het keihard merken in hun dagelijkse werkzaamheden, maar alle chauffeurs die per se een gezondheidsverklaring moeten hebben zijn de pineut. Het duurt nu 19 (!!!) weken voordat je doktersverklaring wordt afgestempeld. En dan heb je het nog over een perfecte verklaring, zonder problemen. Ben je niet duidelijk genoeg of ontbreekt er een kruisje, ben je nog veel verder van huis. Betekent dus dat je het beste een half jaar voor het verlopen van je rijbewijs in actie kunt komen. Aangezien gemeenten gemiddeld 3 maanden van tevoren waarschuwen geeft dat grote problemen.
Komt nog eens bij dat de overheid nu voor alles wat los en vast zit gezondheidsverklaringen eist. Heb je ooit diabetes gehad? Elke 5 jaar een verklaring.

[hooibergje]

Een maat van doet nu de opleiding buschauffeur, maar die is stopgezet omdat hij nog geen goedkeuring heeft gekregen. Loopt sinds oktober. Hij heeft 8 jaar terug ritalin geslikt tegen ADD. Zijn ze pislink op, daar.
Het uitzendbureau betaalt hem nu dus niet meer. Dus hij doet nu effectief vrijwilligerswerk (voor het deel van zijn opleiding waar hij niet daadwerkelijk een bus voor hoeft te besturen) tot het CBR weer bij is.

[RoJan]

Bizar. Dit soort dingen beginnen echt een groot probleem te worden. Regel oké, maar dan wel binnen een redelijke termijn zelf die regels kunnen uitvoeren.
Ik heb zelf nog 2 weken, dan kan ik mijn auto laten staan en moet ik overal naar toe met openbaar vervoer. Lang niet zo erg als die maat van jou, maar bijzonder onhandig en - dat is het nog het ergste - volledig buiten mijn schuld. Maar jouw maat raakt het keihard in zijn inkomsten. Bizar.

[hooibergje]

Die maat van me heeft nog wel zijn gewone B, daar doen ze dan niet moeilijk over, maar voor beroepschauffeurs zijn ze veel strenger. Jij ook succes!

[Hatsjoe]

CBR (Centraal Bureau Rijvaardigheidsbewijzen). Deze instantie neemt rijexamens af.

[Reactie gewijzigd door Hatsjoe op 23 juli 2024 04:39]

[CasEbb]

Uitgifte doen ze niet, ze beoordelen alleen rijvaardigheid. Het Centraal Rijbewijzenregister valt onder de verantwoordelijkheid van de RDW.

[HKLM_]

Centraal Bureau Rijvaardigheidsbewijzen

[TijsZonderH]

Goed punt, ik moet nog even wennen aan het zuidelijke publiek Heb het toegevoegd!

[TijsZonderH]

Ik kom zelf uit Brabant dus voor mij is alles pas daaronder het zuiden!

[ericq]

Waarom gaat het altijd mis bij grootte overheids instellingen?
Twee dagen geleden was er al een gelijk bericht afkomstig van de NVWA. Hierbij waren de bedragen echter nog hoger!

[bytemaster460]

Dit gaat ook mis bij commerciële bedrijven, maar die hoeven het niet openbaar te maken. Overheid spant wel de kroon maar het geeft wel een vertekend beeld.

[burne]

Het gaat net zo vaak fout bij bedrijven, maar daar mag je er niets over zeggen, want dat is slecht voor de aandeelhouders.

[SomerenV]

Achterkamertjes ofzo? Persoon X kent persoon Y en die kan wel een en ander regelen omdat hij personen A en B weer kent bij een bedrijf waar hij regelmatig bij snabbelt. Wat leuke afspraken maken, om de zoveel tijd een lulverhaal ophangen waardoor kosten stijgen en van dat alles verdwijnt X procent in de zakken van wat slimme lui.

[SideShow118]

Een van de dingen die ik altijd mis zie gaan, en vaak niet wordt benoemd, is dat:

1: Er totaal niet duidelijk is wie (afdelingen) er betrokken zijn bij een project.
2: er meer mensen gebruik maken (en afhaneklijk zijn) van het systeem (of informatie daaruit) dan uberhaupt bekend is
3: Er teveel mensen betrokken zijn in het proces die beslissingen kunnen/mogen maken.

Deze problemen zijn bij bedrijven ernstig maar bij de overheid zo mogelijk nog extremer. Dit is de reden waarom het zo vaak fout gaat.

[NullCrayfish]

Ik word hier altijd zo verdrietig van. Van zelfs maar een fractie van dat geld zou je zo ontzettend veel kunnen doen.
Ik vraag me weleens af of degenen die dergelijke opdrachten en uitbreidingen daarop mogen weggeven niet onder de tafel het eea. terugkrijgen...

[JMS 450]

Ga er even niet van uit, is eerder een gebrek aan overzicht en planning.
Zelf geen ICT maar maritieme/civiele ervaring en als je als vak-idioot betrokken bent bij grote projecten sla je vaker tegen je kop wat er gebeurd.

Groot verschil tussen een opdrachtgever bij de overheid en een commerciële partij is de weging van kosten. Hoogste doel van de overheid is een dienst verlenen aan de burgers. Maar elke commerciële dienstverlener heeft concurrentie. Ik kan niet (zonder te verhuizen) switchen van overheid. Op politiek vlak mag ik elke 4 jaar kiezen maar de achterliggende dienstverlener (ambtenaren) blijft het zelfde.

[Iblies]

Bij commerciële partijen gaat het ook vaak mis waarbij het verdwijnt in een bodemloze put alleen krijg je dat niet altijd mee.

https://www.consultancy.n...ementatie-van-500-miljoen

Na zo’n €500 miljoen te hebben gespendeerd aan een SAP-implementatieproject, heeft de CIO van Lidl deze grote digitale transformatie geannuleerd omdat de voortgang daarvan fors achterliep op de planning, en van enige successen geen sprake was.

Wat je hebt zijn een aantal partijen die gruwelijk veel geld bij elkaar sprokkelen,
maar vervolgens nooit een fatsoenlijke dienst/product afleveren. Dit zijn opdrachten die maar door relatief weinig partijen kunnen worden opgepakt waarbij je elke keer hetzelfde patroon ziet terugkomen.

Structurele meerkosten en geen fatsoenlijk product.


De overheid zou er verstandig aan doen om dergelijke projecten te inventariseren bij al haar diensten,
en vervolgens een zwarte lijst opmaken.
Te snel is de overheid het zwarte schaap, en die valt ook iets te verwijten, maar de overheid is niet de enigste partij.

[lighting_]

Ict projecten worden gemanaged door managers die geen verstand van ict hebben. Die knikken ja en amen als iets voorgesteld wordt. Kritische vragen stellen kunnen ze niet.

[OkselFris]

Dat is een aanname, gelukkig zijn project managers ook geen eenheidsworst, wie weet hebben ze op dit project wel een zeer IT vaardige project manager.

[jongetje]

Huh? Hoezo dan? Als je een project ipv 7 miljoen 34 miljoen laat kosten en al 2 jaar uitloopt?

[OkselFris]

Heeft niks te maken met of ze IT vaardig zijn of niet. Dat kan ook gebeuren bij een zeer IT vaardig persoon.

De PM is hier hoogstwaarschijnlijk niet de oorzaak. Ten eerste staat de stuurgroep het toe, dus het lijkt er eerder op dat er goede business case, scope en definitie vanuit de project owner is neergezet.
Een PM rapporteert regelmatig op budget en schijnbaar is het orginele budget met akkoord steeds omhoog gebracht. Jij wijst naar de PM, ik vraag me af hoe thuis jij in project management bent, maar ik zou als eerste naar de project owner cq steerco wijzen, daar zit het waarschijnlijk fout. De PM voert het project namens hen uit.

Uit dit verhaal kan je geen enkele conclusie trekken over de kwaliteit van de PM.

[bbob]

vaardig of niet, goed betaald in ieder geval wel.

[lighting_]

omdat managers eenmaal geen ontwikkelaars zijn.
Enige waar ze naar kijken is de planning. Natuurlijk heb je een goed project management nodig maar uiteindelijk bepalen de werkelijke resultaten het succes van een project. Ook al heb je een mooi case beschreven.

[OkselFris]

Dus zodra er manager achter staats neem jij aan dat ze geen IT verstand hebben.
Project managers heb je in alle smaken, ook zeer technisch personen. Ik was tot voor kort een PM en behoorlijk technisch onderlegd. (Kom uit de IT operations) en voor bepaalde IT projecten uitermate geschikt en voor sommige juist niet.
De content kennen kan soms ook een enorm nadeel zijn. Soms heb je juist een PM nodig die verder van de content afstaat.

[lighting_]

Ik geef toch aan dat project management ook goed moet zijn?
Het gaat echt mis als de consultancy partijen wat beweren en de beslissers geen kaas van gegeten hebben. Simpel zat.