Minister stopt ontwikkeling ict-systeem voor NVWA wegens kostenoverschrijdingen

Carola Schouten, de minister van Landbouw, Natuur en Voedselkwaliteit, heeft de ontwikkeling van een ict-systeem voor voedselveiligheidstoezichthouder NVWA per direct stopgezet. Volgens haar wordt het zogeheten Inspect-systeem te duur en wordt de deadline niet gehaald.

De minister baseert zich op een advies van het Bureau ICT-toetsing. Daarin adviseert het bureau te stoppen met de verdere ontwikkeling van het computersysteem Inspect, omdat het programma naar verwachting 'tientallen miljoenen meer gaat kosten dan de begrote 95 miljoen euro'. Van dat budget is nu nog 30 miljoen euro over. Waarschijnlijk zou eind 2021 als einddatum voor de ict-vernieuwing ook niet worden gehaald. Op basis van deze bevindingen heeft de minister het advies overgenomen en de Nederlandse Voedsel- en Warenautoriteit de opdracht gegeven per direct de ontwikkeling te staken. Overigens werd er oorspronkelijk 36 miljoen euro begroot voor het vernieuwen van de ict, schreef de NOS, maar Schouten liet de Kamer in juni vorig jaar weten dat de kosten met 59 miljoen euro hoger zouden uitvallen.

Inspect is de naam voor een ict-systeem waarmee bij de NVWA het toezicht en de informatievoorziening naar opdrachtgevers en samenleving worden ondersteund. De applicatie zou toezichthouders gaan ondersteunen in het uitvoeren van de werkzaamheden en risicogericht toezicht beter mogelijk maken. Met dit systeem zou er niet meer toezicht zijn gekomen, maar volgens het ministerie 'effectiever toezicht'. Het doel van dit systeem is onder meer het versterken van de informatiepositie van de NVWA. Daarmee wil de toezichthouder de beschikbare capaciteit zo effectief mogelijk inzetten bij het toezicht. Het systeem moest er onder meer voor zorgen dat inspecties uniform worden uitgevoerd en bevindingen, waaronder fotomateriaal, zorgvuldig en herleidbaar worden vastgelegd.

"Inspect had als doel om een effectieve, efficiënte en gelijkmatige manier van werk onder toezichthouders en keurders te realiseren. Samen met de NVWA ga ik vaststellen hoe we met beheersbare, kleine stappen verbeteringen in de bestaande systemen kunnen aanbrengen en deze doelen alsnog kunnen bereiken", aldus de minister. Volgens de minister komen de inspecties en het toezicht op voedselveiligheid en dierenwelzijn met deze stap niet in gevaar, al laat ze wel blijken dat een dergelijk systeem nodig is om toezichthouders ook in de toekomst hun werk goed te kunnen laten uitvoeren.

Reacties (259)

[wildhagen]

'tientallen miljoenen meer gaat kosten dan de begrote 95 miljoen euro'.

Die 95 miljoen was al een verhoging, want het oorspronkelijke begrote budget was 35 miljoen euro...

Is bekend welke partij hierbij betrokken was? Vermoedelijk CapGemini of Ordina, zoals bij veel mislukte ICT-projecten de laatste jaren?

Ik vind dit onderhand een beetje de spuigaten uitlopen. Een enkel project dat mislukt, dat kan gebeuren. Maar nu begint het zowat de default te worden dat projecten mislukken voor tientallen miljoenen. En het wrange is dat het voor de betrokkenen, zowel personen als bedrijven, vrijwel nooit grote gevolgen heeft....

Hoe serieus gaan ze bij de overheid met ons belastinggeld om?

[Laurian]

Ik snap dat je die vraag stelt . Het persbericht en kamerbrief zijn niet volledig.
Wat er in het bericht niet bij staat is (maar wel in de stukken daarachter):
- Alle inspecteurs die inspecties uitvoeren in de domeinen HAP, Alcohol en Tabak kunnen sinds mei
vorig jaar werken met het nieuw ICT-systeem (staat in Voortgangsrapportage bij de kamerbrief)
- Het project is agile aangepakt (staat in BIT advies)
- De code heeft een hoge kwaliteit. In het BIT-advies staat onder andere:
“Volgens de benchmark zou u in dit geval zo’n 25.000 fouten moeten hebben gevonden. Uit de software-administratie leiden wij af dat tot nu toe ongeveer 3.500 fouten zijn gevonden. Het is dan ook zeer waarschijnlijk dat een groot deel van de fouten nog niet is gevonden.”
Het is wel knap dat die inspecteurs er al een jaar mee werken als er zoveel fouten in zitten.

Er worden blijkbaar te weinig fouten gemaakt.
Als er veel testbevindingen waren geweest was dat het probleem.
Op die manier kun je elk project afschieten.

[Reactie gewijzigd door Laurian op 23 juli 2024 04:28]

[SpiceWorm]

Je gaat voorbij aan de vraag van wildhagen, hoe kan het dat overheids ict projecten stelselmatig grove kostenoverschrijdingen kennen en dat daar nooit consequenties op staan?

Dan kan je in de verdediging springen dat het ditmaal anders is, maar ik denk dat wildhagen een terechte vraag stelt.

[Wulfklaue]

Als iemand met kennissen dat vroeger werkte in een bepaalde overheidsdienst in België, kan ik wel enkele vragen beantwoorden.

Het probleem zit hem niet enkel bij de overheid maar ook de firma's dat aangesteld worden.

1. Er word een uitbesteding gemaakt. We willen X voor Y. Vaak zijn deze specificatie nogal mistig.

2. Dan komen er een aantal firma's dat hun aanbod doen. De prijs word dan vaak onder de actuele kostprijs van de specificatie geduwd. Het gevolg is dat de firma's dat volop liegen ( en ze weten dat hun prijs onder de actueel kostprijs zit ) op de offertes winnen. Vaak zijn die offertes ENORM specifiek geschreven.

Een firma met meer correct offertes word snel afgeschreven als "te duur".

3. Het project word getekend en men begint aan het werk. Op dit moment begint de geldkraan naar de Firma al te lopen. Het project begint vooruit te gaan maar dan begin je zaken te zien als:

3a. Bij de overheid ontdekt men dat bepaalde features dat ze in hun kop hadden, maar nooit deftig gedetineerd hebben, niet in het contract staan. De komt uit op de vergadering, er word een beetje gediscuteerd maar men is al bezig met de ontwikkeling. De firma maakt een extra offertje voor de "extra" features.

3b. De overheid zal de overheid niet zijn, als er niet meerder departementen gemoeid zijn. Bijvoorbeeld, een departement dat de offerte uitschrijft wilt X maar dan komt een ander departement van "hey, die software dat gemaakt word voor jullie, kunnen we daar Y bijvoegen zodat we dat ook kunnen gebruiken".

Meer offertjes, meer rommel voor de programmeurs van die firma want ineens moet hun code structuur anders. De firma zegt niet nee tegen meer werk want de verkoper casht zijn bonus/percentage op de verkoop en het kan hem echt NIET schelen dat die nieuw aanpassingen een ram zijn voor de programmeurs.

3c. Intern is de Firma zelf vaak ook een soep want men heeft wel programmeurs, leuke projectjes maar wanneer je firma's krijgt dat speciaal gaan prijs gutting doen want men weet dat je dat later terugverdient met overheid contracten wegens A en B. Dan heb je vaak in de firma's ook een nogal "stinkende" ondergrond met hoe men omgaat met hun personeel. Meestal zit de druk volop bij de programmeurs om meer en meer code te produceren maar niet op de kwaliteit ervan.

4. Na een tijd gaat men voorbij de tijd planning. De firma roept dan "heeeeela, we hebben een contract voor X maar jullie wilde Y, Z erbij", ... $$$$ op de tafel aub. Intussen zijn al honderdduizenden of miljoenen in het project gegaan. Sunk Costs ... Het gevolg is dat men ook nog een politiek verlies kan leiden als een departement niet goed loopt en men zal bijna NOOIT een project stopzetten. Tot het zover de spuigaten uitloopt, dan men niet anders kan.

5. Intussen zijn enkel jaren verstreken. De interne diensten gebruiken de code maar deze code veranderd nog volop met de punten in 3. Men ontdekt bugs, introduceerde bugs, en het is een ellen lange straat. Vaak heeft er zich ook een wissel voorgedaan in de politiek waarbij bepaalde linkse, middel of rechtse partijen van overheid diensten veranderd zijn en dan besluit men eens goed kuist te maken want de nieuw mannen, willen HUN projecten zien, niet die oude rommel dat niet deftig werkt.

6. ... Ga naar START (1), neem geen 200 Euro en herhaal ...

Dit is de bulk hoe het misloopt. In de praktijk moet je er nog favoritisme, semi corruptie, eer, politiek, enz tussen smijten.
..................................

Hier zijn een paar verhaaltjes waar ik van afweet:

* Dienst F... laten we het een dienst noemen dat met de burger zijn centjes inzit. F ontwikkeld voor jaren een stuk software. Aangezien de aard van de dienst, MOETEN de programmeurs iedere dag op de kantoren van die dienst gaan werken. Natuurlijk rekent die Firma nog extra $$$ omdat de programmeurs op locatie moeten werken.

Na jaren kwam men tot de conclusie door Punt 3, het is een soep, men betaalde 1000 euro plus / programmeur ( en daar zat een half dozijn of meer ), we spreken over de programmeur, niet over de totaal project, dat is nog een andere rekening. Het gevolg is dat men uiteindelijk foert gezegd heeft na miljoenen in het project te smijten. En de dienst? Die gingen terug naar hun oude DOS programma. Nooit echt in het nieuws gekomen *lol*

* Andere leuke ... Het hoofd van de ICT vertrekt. De persoon met de meeste jaren ICT en enorme ervaring neemt de boel over als tijdelijk directeur. De man begint is rond te zien en merkt op dat ze nog 100de ISDN/dial-up verbindingen "huren" van een bepaalde Belgische Telecom. Men betaalde daar een zot bedrag voor want die contracten gingen terug 10+ jaar. Ze betaalde de originele dial-up bedragen nog altijd, terwijl gans België al op ADSL/Cable zat. Hij schaft dat af ( en neem gerust aan, de Telecom firma hebben tegengewerkt ). Spaarde de staat een paar mans lonen uit iedere maand. Hij nam nog andere beslissingen dat in goede aard vielen bij het personeel want hij kende de dienst, hij had 20+ jaar IT ervaring, iemand die wist wat echt nodig was.

En je kan raden ... de politieke wind draaide al snel want men moest nu een "manager" hebben. Hij werd snel terug op zijn plaats gezegd als programmeur en de nieuwe "manager" komt binnen en besluit om alle Linux servers te gaan omzetten naar Windows servers. Met als gevolg dat iedereen mocht herleren, enorme licentie kosten ( MS was de goede vriend aan huis ineens ). Het geld vloeide de deuren uit links en rechts. Tot de manager terug naar de privé ging en de kater achterbleef.

Wat is er gebeurt met die man dat tijdelijk directeur was. Hij was zo gedeguteerd dat hij vertrokken is ( getransfereerd ) is naar een andere dienst en hij is er gaan carotten trekken ( dialect ). Gevolg was dat men nog een competente man verloren heeft en die is nu de zoveelste "If you can not beat them, join them" attitude aangenomen heeft. En hij is nog nooit zo gelukkig geweest, verlost van de stress.

* De dienst? Tja ... Daar kreeg men het leuke idee om "open room" concept te gaan doen, alle programmeurs, Helpdesk mensen, enz samen in een "open vloer concept", niemand een vaste bureau, iedereen met laptops en lawaai ... De perfect omgeving om IT zaken te realiseren bij de overheid.

Maar ze konden plaats sparen voor bureaus... Ik moet niet eens gokken om te weten dat de ziektedagen omhoog gaan schieten als een peer. We spreken niet over een man of 5 tezamen, we spreken over Google "open bedrijf concept". ** Nota: Enkel van toepassing voor het personeel. De dienst management en hoger hebben natuurlijk hun privacy nodig...

Je kan raden hoe dat spelletje gegaan is. Ja, de overheid is niet bang om te experimenteren en wie zegt dat de overheid oud is/geen moderne werkwijzes aandurft is mis. Het probleem is dat men vaak TE VEEL experimenteerde omdat de wind constant links of rechts draait wegens de politiek.

* ... Ik kan nog verder gaan met verhalen maar denk dat deze post te lang is. U hebt gevraagd hoe het misloopt, hier heb je een paar voorbeelden

Duft niet te vaak zeggen hoe verveeld je bent als je een dag moet gaan stemmen bij de val van een regering of de nieuwe verkiezing.

Denk liever eens aan de arme ambtenaren dat de zoveelste windrichting mogen ondergaan. Als je een ambtenaar voor je krijgt dat je zuur aankijkt, neem maar gerust aan dat het niet enkel is omdat hij je kop niet kan uitstaan. Vaak zit er veel meer achter dan je denkt. Het idee dat alle ambtenaren lui zijn is al lang achterhaald. Vaak is hun situatie dezelfde als bij een moderne firma of soms nog erger.

Beeld je in een moderne firma, waar men om de paar jaar management veranderd. Nu weet je hoe het daar echt aan toe gaat. En die IT projecten, zijn gewoon een extensie van al die miskleun. En er zijn geen oplossingen voor zo lang politieke partijen de diensten overnemen bij iedere verkiezing of wissel.

[Oyxl]

Jaren voor overheid gewerkt. Projecten worden per definitie, moedwillig, ernstig onder budget begroot, omdat het anders nooit van de grond komt, ivm te duur. Daarom lopen letterlijk alle ICT projecten ruim buiten oorspronkelijk begroot budget.

In my opinion of course.

Schijnt er tegenwoordig bij te moeten

[Reactie gewijzigd door Oyxl op 23 juli 2024 04:28]

[MSalters]

Dat is overigens niet uniek aan ICT projecten. Vraag maar in Utrecht hoe het met hun tram gaat. Ook al zo'n drama-project, waar ambtenaren bewust bepaalde kostenposten uit de offerte-aanvraag weglieten om een politiek acceptabele prijs te krijgen. Ze wisten toch wel de de volgende generatie wethouders akkoord zouden gaan met de meerprijs.

Dit soort trucs moeten in het strafrecht opgenomen gaan worden. Als er niet een aantal personen voor jaren achter de tralies verdwijnen, dan blijven we dit soort faal-projecten houden.

[laptopleon]

Dit lezen we hier wel vaker bij vergelijkbare nieuwsberichten en ik geloof het meteen, maar het blijft toch moeilijk te geloven dat 1) de doorgaans zeer goedbetaalde topambtenaren van de betrokken departementen dit mechanisme nog steeds niet begrijpen, 2) daar niets aan kunnen of willen doen en 3) daar steeds mee weg komen.

[Wulfklaue]

1) Zoals met vele bedrijven, het personeel begrijpt vaak meer dan de bazen. Het verschil is dat bij een slecht lopend bedrijf, ze onderuit gaan na een tijd en het is ermee gedaan ( de oneerlijk mannen beginnen dan terug een firma op naam van de vrouw of broer maar dat zijn andere verhalen ).

De overheid daartegen heeft een constante stroom van inkomsten waar je niet "nee" tegen kunt zeggen of je vliegt met je achterste het gevang in.

Het gevolg is dat de ambtenaren vaak weten waar de kaas stinkt maar geen macht hebben. Zij dat hoge op geraken zijn vaak niet de mensen dat klaagde in hun carrière.

2) Zie hierboven. De mensen dat vaak de boot schudden, zijn vaak de eerste dat eruit vallen. Er is veel vriendjes politiek zoals overal. En laten we eerlijk zijn, wil gij je baan opblazen om iets te melden? Het is niet zo makkelijk meer om een baan bij de staat te krijgen. Examens, contractueel is tegenwoordig de norm. De mensen met onbeperkte vastgestelde plaatsjes gaan echt niets doen om dat kwijt te raken. Je kan lui zijn, een 2de job uitoefenen op je "werk" en heel wat zaken mee wegkomen. Maar effen de "rat" gaan uithangen ... Men zal snel die 3 jaar rapporten hebben waar je een negatief krijgt. Of je naar de buitendienst sturen waardoor je ineens een paar uur per dag onderweg bent naar job.

3) Yep ... Omdat het na een tijdje gewoon een grote rommel word waar niemand nog deftig aan uit geraakt.

Het grote probleem is dat "whistleblowers" niet geapprecieerd worden. Zelf al komt je naar buiten met problemen in een dienst, als het uitkomt wie lekte, die kan zich verwachten aan heel wat gevolgen. Is het niet van je baas, dan van die boven je baas.

Ik zeg niet dat het volop corruptie is maar je hebt echt veel incompetentie gecombineerd met politiek en andere toestanden. En soms is de lijn tussen incompetentie en corruptie in de grijze zone. Je kan verdenken dat iemand een vriend beloont met bepaalde werkjes maar bewijzen is iets anders.

Tussen haakjes: Als je wilt werken bij de overheid, zorg dat je bij een vakbond gaat. Als je daar op goede termen mee staat, heb je enorme bescherming in het overheids orgaan. En nog meer als toevallig dezelfde politieke partij de vlag zwaait. Vakbonden en politiek neutraal, mijn achterste! Disclaimer: Van horen zeggen he

Bij de overheid is het net zoals bij een firma. 95% mensen dat gewoon hun werk willen doen, hun kop naar beneden houden en iedere dag zonder zorgen naar huis kunnen gaan, met op einde van de maand hun loontje. De rest is een combinatie van incompetentie, macht, vriendjes politiek, enz. En dat is niet anders dan bij veel firma's.

Mensen zoals ons, dat hun mond open doen, die houden het niet lang vol of geraken er niet binnen. Heb ooit gesolliciteerd voor een baan bij de overheid. Ging goed tot er 1 persoon met een politiek kaart zwaaide en vroeg "wie is de minister van deze dienst". Ik zei "X". Antwoord: Nee, dat was de vorige ( was juist verkiezingen en weeral de zoveelste wissel ).

En ik zo dom om te antwoorden: "Wat heeft dat te doen met deze job interview". De miserie dat ik op men kop gehaald heb. *hahaha*. Men kansen zijn direct naar 0 gegaan want die persoon maakte de job interview een politiek kleurtje en het kon me geen reet schelen welke partij de vlag zwaaide op de dienst. Groen, Links, Rechts, Katholieke... maakte me niks uit want dat heeft niet te doen met de job als ITer!!!

Was snel duidelijk dat men kandidatuur van enorm positief ( kende men IT ) naar nul gegaan was. De rest van de mensen zaten daar met een grim op hun mond maar durfden niks zeggen. Heb blijkbaar op een paar teentje getrapt bij die vrouw. Was snel gedaan met het interview. En ja, dat was echt een geval van puur politiek maar ja, niks nieuws in het leven.

[eekhoorn12]

Nog wat meer informatie staat in het volledige rapport, dat bevat nog veel meer informatie dan de kamerbrief.

Het hele rapport is hier in te zien https://www.bureauicttoet...rnieuwing-informatie--ict

[F-I-X]

Brrr het leest als een horror boek.
Lijkt ook alsof er telkens dezelfde fouten worden gemaakt. Teveel mensen erbij betrokken die vanuit hun management positie proberen te sturen ipv van gerichte kennis. En maar dingen blijven wijzigen gedurende het ontwikkel proces...

Alleen aan de gebruikt terminologie lees je wat voor omgekeerde piramide in organisatie ook deze overheidsdienst weer heeft.

[gimbal]

Immer veranderende (en fout benoemde) specs en onvoorzien werk zijn de nekslag van elk IT project - ik kan me voorstellen dat bij multimiljoen projecten dat helemaal escaleert.

Ik snap hem wel hoor, het is al bijna onmogelijk om een kleinschalig project van enkele duizenden tot misschien een paar 100k binnen budget te houden. De eerste paar iteraties is alles fantastisch en dan ineens valt de bom; wat gespecced is gaat effectief nooit werken in de realiteit want ze waren vergeten om pietje ook om een mening te vragen - en pietje is de enige die daadwerkelijk begrijpt hoe alles werkt. Budget keer twee, eerste ronde.

Maanden later wordt men boos want er zit niet genoeg voortgang in; mensen met verantwoording raken overspannen. Meneer Sjoerd Atanisch die ooit een sergeant in het leger was wordt de product owner en zijn eerste beslissing is: alles moet anders want het is allemaal niet goed. Budget x3, tweede ronde.

[Reactie gewijzigd door gimbal op 23 juli 2024 04:28]

[Laurian]

Het is ook een terechte vraag.
Het probleem is dat alles aanbesteed moet worden.
En dat het binnen een bepaalde tijd klaar moet zijn omdat het management/kabinet redelijk vaak rouleert.
Zodra er weer een nieuwe manager/bewindspersoon komt veranderen de prioriteiten.

[Reactie gewijzigd door Laurian op 23 juli 2024 04:28]

[Vayra]

Een deel van het antwoord staat wel in zijn reactie.

De scope is niet duidelijk omschreven, de overheid / ambtenarij leeft volgens de oude wereld / de werkwijze wordt niet begrepen.

Dat zie je ook bij bedrijven... Er ligt hier denk ik ook een taak voor ICT bedrijven om een realistisch beeld te scheppen. Onder elk contract staat meer dan één handtekening.

[Reactie gewijzigd door Vayra op 23 juli 2024 04:28]

[Elefant]

Dat smoesje gebruiken ze nu al 30 jaar. De grote IT bedrijven melken de overheid leeg met medewerking van de ambtelijke organizaties die al dat geld ook heerlijk vinden. Dat het project weer gestaakt wordt hoort ook bij de planning want dan kunnen de ze volgende mislukking weer opstarten.

Politiek vindt het ook niet erg. Vaak starten partijen zulke projecten op, die door de duur vanzelf weer bij een minister van een andere partij belanden, die ze dan weer kunnen afschieten. Niemand (behalve de burger die niets te zeggen heeft) heeft belang bij een goed verloop, dat is het hele probleem. Daarom mislukken meer projecten dan er slagen.

Dat krijg je als je door een old-boys-netwerk geregeerd wordt, die denken vooral na hoe ze geld kunnen aftappen van de overheid. Zo een mislukt projectt als de Fira is voor hen ook geen mislukt project, maar dik verdienen. Dat hebben mensen niet door. Er wordt veel meer verdiend op mislukkingen dan op effieciente geslaagde projecten. Daarom wordt geld dat bedoeld is voor meer agenten op straat liever in mislukkende ICT-projecten gestopt. Politiek, ambtenarij en grote bedrijven werken hierin samen.

Iemand die daar uitgebreid over geschreven heeft is René Veldwijk. Hij heeft er een site aan gewijd. Lees onder andere:
BRP: Een nieuw leven voor een oud ICT-debacle
De SVB en het wandelende PGB-skelet

[Reactie gewijzigd door Elefant op 23 juli 2024 04:28]

[invic]

idd, de overheid wilt niet van de fouten leren omdat bij de aanbestedingen altijd voor de grote bedrijven worden gekozen met het argument dat ze betrouwbaar zijn. De aanbesteding wordt opgesteld door een duur extern bureau, waar onafhankelijkheid discutabel is, en zodanig opgesteld dat alleen grote bedrijven kunnen inschrijven. Het is een manco dat de ambtenaren niet hard durven optreden tegen de externen en leveranciers. Vaak te weinig kennis en te veel leunend op externe adviseurs cq. projectleiders. Eigen schuld dikke bult. Helaas jammer dat het onze belastinggeld is! Ik ben van overtuigd dat er genoeg MKB ICT bedrijven zijn die deze soort projecten ook kunnen doen. Alsof groot equivalent is met kwaliteit en voorspelbaarheid. De historie bewijst keer op keer dat het gebakken lucht is dat de grote bedrijven opleveren...

[djwice]

Klinkt gek wellicht, maar 400 gebruikers en 30.000 verwerkte transacties klinkt heel weinig als je dit vergelijkt met bijvoorbeeld een website.
Hoog over vertaal je dit als: login systeem, formulieren met meerdere stappen, upload van foto's, invullen moet ook offline werken op mobiel (progressive web app), ontvangen informatie verwerken tot rapportage naar verschillende ontvangers.

Kun je aangeven wat er zo uniek is dat dit project zo complex maakt?

[Bux666]

Ik val ook echt van mijn stoel. Op mijn werk heeft 1 developer binnen een half jaar een soortgelijke webapplicatie gemaakt voor gemeentes. Compleet met wijken uittekenen op interactieve plattegronden, een discussiesysteem, een archief per project waarin alles is terug te vinden, dynamisch, modulair, responsive, etc.

Dit project zal zeker groter zijn, maar zet 10 goede fullstack webdevelopers een jaar bij elkaar en je zit makkelijk alles wat je wilt. En dan betaal je misschien een miljoen...

[koelpasta]

Dit project zal zeker groter zijn, maar zet 10 goede fullstack webdevelopers een jaar bij elkaar en je zit makkelijk alles wat je wilt.

Hah! Nee!
Zet 10 developers aan 1 project en ze moeten opeens met elkaar gaan communiceren.\
Je haalt dan bij lange na niet de efficientie die je van die ene developer was gewend.

[stealthgun]

Ik denk dat je even onderschat hoe ministeries in elkaar zitten. Ik kan er niet verder op ingaan, maar neem van mij aan dat het niet eenvoudig is als "even een applicatie in elkaar zetten" er zit jammer genoeg aanzienlijk wat bureaucratie aanvast, zelf denk ik dan ook dat een deel van deze overschrijding meer met het ministerie zelf te maken heeft en dat hun eigen werkwijze niet goed werkt voor complexe IT projecten.

Iedereen die op een of andere manier wel eens bij EZK een IT project heeft gedaan zal waarschijnlijk gelijk snappen waar ik het over heb.

[djwice]

Iedereen die op een of andere manier wel eens bij EZK een IT project heeft gedaan zal waarschijnlijk gelijk snappen waar ik het over heb.

Ik heb 4 projecten gedraaid bij EZK, wel al ruim een decennium geleden. Mijn ervaring is anders, Ik negeerde simpelweg de interne slow motion en zorgde dat ik de toegang had die nodig was voor de realisatie. Dan gewoon maken, mee kletsen of er niets veranderd, dan gewoon out of the blue werkend presenteren aan opdrachtgever. En klaar is Clara.

Nu nog weten ze mijn naam in positieve zin (staat ook in de code ;-) ).

[Reactie gewijzigd door djwice op 22 juli 2024 17:43]

[geekeep]

Wat dacht je van de tientallen domeinen waarin de NVWA actief is, met ieder hun eigen wet- en regelgeving? Succes met dat in "een website" bouwen.

Als je 'de overheid' een beetje kent, weet je ook dat het zwaar geclusterd is. Ook bij de NVWA zullen dus vele subsystemen en backoffices zijn waarmee gekoppeld wordt/moet worden. Inspectie A via systeem 1 met protocol Z naar groepje 3, en zo tientallen andere routes voor inspecties B t/m Z.

[djwice]

Als je dit niet modulair in een web app kunt bouwen, dan is óf de kennis van web beperkt, óf de opdracht überhaupt niet in een applicatie te maken. Dat laatste lijkt me onwaarschijnlijk.

[latka]

(van de zijlijn, ken dit project niet): bij BIT zie je welke onderaanemers meedoen. Een daarvan is IAM4 een rule-engine leverancier. Ik vermoed dat ze een soort van business-regels in een rule-engine oplossing maken en dat kan best, maar dan moet je de business heel dicht op de rules weten te krijgen. 400 gebruikers/30.000 transacties kan best veel zijn als men een transactie definieert. Het is ook volledig niet vergelijkbaar met een web-oplossing die grotendeels stateless is met hier en daar een sessie.

[djwice]

Een keuring lijkt mij typisch iets dat ter plaatse op locatie wordt uitgevoerd. Een web oplossing die offline op een diversiteit aan devices hetzelfde werkt lijkt mij dan een logische keuze. Vandaar de vergelijking.

[latka]

Door het gebruik van een rule-engine en de setup van keuringen in NL zal dit eerder een risico beoordelingssysteem zijn: wie gaan we controleren. Branch X heeft veel problemen om situatie Y onder controle te krijgen. Ipv. een controlleur met de pik op iets krijg je nu gestuurd te horen waarheen voor welk onderzoek.

[djwice]

Het lijkt me inderdaad slim om data gedreven activiteiten te plannen. En met 400 gebruikers, die ook foto's uploaden, lijkt het me toch echt dat de mensen actief controles uitvoeren.

[latka]

Ik sluit ook niet uit dat het data entry deel hierbij zit, maar dat zal maar een klein deel van de oplossing zijn. Je zult moeten registeren, maar ook opvolgen (waarschuwing gegeven, nogmaals langsgaan). Tevens zal er iets in moeten zitten dat aan bewijsopbouw doet mocht het tot een rechtzaak of dispuut komen. Rapportages dus. Dan nog een hele shitload aan rechten (je mag hopen dat niet iedereen bij alle data kan). Dan nog een flink stuk auditing (we hebben X gezien en dan achteraf aanpassen). Affijn, het pure 'crud in het veld deel' zal maar een klein stukje zijn.

[djwice]

Klinkt nog steeds niet heel exceptioneel, wellicht dat ik te veel met AWS serverless componenten werk en de voorbeelden die je geeft direct map op die architectuur, waardoor ze simpel te implementeren zijn.

[Reactie gewijzigd door djwice op 23 juli 2024 04:28]

[latka]

Oh, individueel is het allemaal eenvoudig, alleen moet je ook overal kruisverbanden kunnen leggen (gewonnen rechtzaak in branche X geeft een extra stimulans om onderzoeken naar gerelateerde bedrijven in branche X te doen). Serverless Lamba AWS is leuk, maar je hebt nog steeds heel veel shared state en daar is weinig serverless aan: daar heb je gewoon een dikke DB voor nodig.

[djwice]

Step-Function er bij voor orgestratie. state in DynamoDB of op S3 en dan Athena om cross state op te halen.

[latka]

En dat uitleggen aan het team wat het beheer na jou mag doen

[djwice]

Is niet lastig, gewoon lucidchart, goede readme en alles met cloudformation en codepipelibe en een boel notificaties via cloudwatch.

Vervolgens alles verwijderen en ze het from scratch zelf neer laten zetten. Zodat ook duidelijk wordt waar de overdracht gaten zitten.
En ze daarna het zelfde laten doen bij een ander team, dan pas weet je zeker dat ze het voldoende onder de knie hebben om het te beheren.

Maar in scrum is het volgens mij de bedoeling dat het team dat het bouwt het ook zelf beheerd...

[latka]

Maar in de praktijk wordt een scrum team naar binnen gefietst voor een project en vliegen ze daarna heen. Zeker als het teams zijn die dit soort zaken neerzetten omdat het qua CV beter is om vooral veel nieuwe dingen te blijven doen. Geen waardeordeel maar een observatie (een deel van mijn projecten is het onderhouden van hippe scrum legacy projecten).

[latka]

Ik denk dat het BIT kijkt naar 40 jaar software bouwen (ook gezien de telling in functiepunten). En ik loop nu een kleine 30 jaar mee en ik kan je vertellen dat business systemen maken in een mature taal (zoals cobol of een of andere 4GL) goedkoper is dan in een hippe nieuwe agile aanpak techniek. Alleen is er geen hond die dat wil (klant wil het niet want groene schermen en dure mensen, programmeurs willen het niet want het is voor fossielen). Er is geen enkele fundamentele verandering in de techniek geweest in de afgelopen 30 jaar waardoor het aantal fouten omlaag gaat (integendeel: typing is vaak weer vies, dus untyped languages zijn weer populair en laat strong-typing nou een hele klasse van fouten tegenhouden). Dus ik snap de redenatie van BIT wel.

[P_Tingen]

Nou, volgens mij komt de halve wereld al weer een beetje terug van untyped languages, er is natuurlijk een reden dat TypeScript steeds populairder wordt.

Daarnaast ben ik het niet helemaal eens (maar ook niet persé helemaal oneens) met je stelling dat er geen fundamentele veranderingen zijn geweest, want de tooling is in de loop der tijd vele malen beter geworden. Het probleem is alleen dat het hele plaatje veel complexer wordt met moderne talen. Als je kijkt wat je tegenwoordig nodig hebt aan framework, mappers, compilers, precompilers, dependency checkers en weet ik wat dan is een groot deel van de vooruitgang weer opgegaan aan complexiteit van de ontwikkelstack

[Stoelpoot]

De applicatie zou toezichthouders gaan ondersteunen in het uitvoeren van de werkzaamheden en risicogericht toezicht beter mogelijk maken.

Hierbij moet ik ook opmerken dat de verwachtingen van gebruikers en opdrachtgevers eveneens hoger is geworden, waardoor de ontwikkelingen zoals hierboven ook net zo goed nuttige toevoegingen aan het ontwikkelproces zijn geweest. Het is zonder twijfel op veel manieren complexer geworden, maar als je moderne software wilt schrijven met de tooling van vorig decennium, dan ben je vele malen langer bezig dan met de complexe nieuwe tooling.

[latka]

Ja, maar de grap is dat business processen niet wezenlijk veranderd zijn alleen de verwachtingen van gebruikers (ik moet hetzelfde kunnen doen op mobiel en als ik thuiskom afmaken op een webscherm en als echte roadwarrior moet ik dan de melding kunnen aanvullen vanaf een thais strand via een VPN op een hotel computer).
De essentie (doe een melding) is niet veranderd. De gebruiker verwacht nu echter veel meer flexibiliteit. Dit is iets waar functiepunt analyse tekort schiet (veel minder gegevens van beschikbaar), maar de vraag zou je ook kunnen stellen of web-based material design PWA/SPA etc. allemaal nodig zijn of dat die complexiteit er voor zorgt dat je (geforceerd) naar minder volwassen tools en technieken moet grijpen omdat je dit idd. niet voor elkaar krijgt met je RPG/Cobol/4GL/Visual Basic oplossing.

[latka]

Ik heb gewerkt met redelijk wat tools maar ik vind het allemaal erg meevallen qua verbetering. De standaard IDEs lijken ontzettend op elkaar met hier en daar een extra wizard of refactoring. Ja, als ik het vergelijk met TurboC is de tooling beter geworden, maar dan leg je de lat ook niet erg hoog. En inderdaad, de omgeving is complexer geworden (deels omdat de klantwensen veranderen en deels omdat het sexy is (sql is niet gaaf dus een OR mapper ertussen, XML is nasty dus JSON en wat hacks voor schema erop, eventdriven is cool maar messaging-systemen zijn antiek, dus eigen queueing oplossing bouwen met matige tools/support). Functies overal van het internet trekken en gebruiken en er dan achter komen dat de QA op die libraries minder goed is dan gehoopt en moet je upgraden (maar wat is de impact, dus weer analyse tools erop). Ik zeg niet dat het niet leuk is (sterker nog, dit is mijn werk), maar we doen het onszelf af en toe wel een beetje aan.

[Bazi]

ik kan je vertellen dat business systemen maken in een mature taal (zoals cobol of een of andere 4GL) goedkoper is dan in een hippe nieuwe agile aanpak techniek.

Alleen hebben die twee dingen nauwelijks iets met elkaar te maken. Welke taal je gebruikt staat los van de aanpak. Je kunt "agile" met COBOL werken, of niet-agile met één of andere hippe nieuwe taal.

[latka]

Correct, was ook meer gericht op de continue dwang tot veranderen van techniek en aanpak. Als je er vanuit gaat dat het 3 tot 4 jaar kost om ergens heel goed in te worden is het verbazingwekkend dat de techniek zo snel veranderd.

[Bazi]

En dat ben ik helemaal met je eens! Zeker in web development zijn er veel die elke keer op een nieuw framework of hippe tool duiken, alleen vanwege "het is nieuw en hip".

If it ain't broke, don't fix it.

[SJCE]

Er is geen enkele indicatie dat static typing helpt bij software ontwikkeling, behalve een heel klein meetbaar effect bij documentatie kwaliteit.

[latka]

Er is wetenschappelijke literatuur die je tegenspreekt en ik vind wat blogs die je ondersteunen. Er zijn effecten bij het executeren/compilen, refactoren (tool support). Als je een goed type-systeem hebt (dus niet het brakke C verhaal met typedefs en defines) dan is er geen reden waarom je _meer_ bugs zou hebben met static typing en documentatie is zowiezo een ondergeschoven kindje en vrij handig als je met meer dan 1 persoon bent. Maar ik ben benieuwd welke bronnen je hanteert.

[SJCE]

Dan Luu kijkt daar naar: https://danluu.com/empirical-pl/
De tool support voor refactoren is in Smalltalk veel beter dan in mainstream languages, met de rewrite engine, en gebruik maken van dynamische type informatie van de aanwezige objecten. Er is nog geen praktisch type-systeem dat incrementeel en iteratief werken met een korte cycle tijd (paar honderd ms) ondersteunt, en dat heeft veel meer consequenties voor de kwaliteit van software.

[latka]

Ik ben gestop met lezen toen ze C++ (en C) in klasse van weakly typed gooiden.
Toch nog even doorgegaan. In de bronnen die ze citeren staat dan weer dat het wel helpt (https://ieeexplore.ieee.org/document/6240483). Dat gecombineerd met een redelijk circlefest van jezelf citeren maakt het niet erg sterk. Vandaag nog een leuke aan de hand gehad: een multicurrency boekhoud pakket met een functie die GetBedrag() heet en een double teruggeeft. Fout op minimaal 2 punten
1) Money is geen double
2) De ene keer krijg je een dollar bedrag en de andere keer een euro bedrag.

Opgelost de introductie van een Bedrag type op deze functie en dan alle callsites aflopen en repareren. Geen feest, maar double's volgens door een stuk software is nog veel minder leuk.

[Reactie gewijzigd door latka op 23 juli 2024 04:28]

[SJCE]

Dan kun je maar beter nog even verder lezen over types

[Znorkus]

Bedankt voor deze aanvulling. Je zou anders haast denken dat er 60 miljoen echt regelrecht de prullenbak in is gegaan zonder dat er ook maar 1 minuut werk aan verricht is.

[Sando]

Is het misschien verstandig om te verklappen dat dit sarcasme was?

[Znorkus]

Nee ik dacht het echt ;-) Geen idee dat er al volop mee gewerkt werd. Ik dacht dat het 'in ontwikkeling' was en dus nog niet gebruikt werd.

[Stoelpoot]

Die indruk kreeg ik ook, ja. Zeker vanwege zinnen als: "De applicatie zou toezichthouders gaan ondersteunen in het uitvoeren van de werkzaamheden en risicogericht toezicht beter mogelijk maken" leek het artikel te zeggen dat het nog geen praktische resultaten had opgeleverd.

[Bazi]

Uit het rapport van het Bureau voor ICT-toetsing:

Het nieuwe systeem zou voor 23 "inspectiedomeinen" gebruikt gaan worden. Inmiddels werken 3 van die domeinen met het systeem. Twee andere zijn in ontwikkeling, de overige 18 zijn nog niet opgestart. Daar is zelfs nauwelijks van bekend wat de functionaliteit moet gaan worden.

Omdat die eerste 3 domeinen al 2,5 jaar hebben geduurd (en nog niet helemaal af zijn), schat het BIT in dat de overige domeinen ook nog wel een tijdje gaan duren.

Als dit inderdaad zo is, kan ik me wel voorstellen dat men het somber inzag.

[MSalters]

Dat klinkt alsof je 3 kleinere projecten had moeten opstarten, met 3 kleine bedrijven. Kijk wie het beste product oplevert, laat die winnaar de volgende 22 doen, en gooi het product van de 2 verliezers weg. Ja, dat is jammer van de moeite, maar zoiets kun je goed begroten. De huidige manier levert je vooral onverwachte kostenoverschrijdingen op.

[CH4OS]

Heb je toevallig een linkje naar dat rapport?

[Koekiemonsterr]

Ja inderdaad 36 miljoen, dat document vond ik niet meer op de site van het ministerie, maar heb daar alsnog wat over toegevoegd.

[wildhagen]

De NOS meldt het ook in hun artikel (https://nos.nl/artikel/22...9-miljoen-bij-nvwa.html):

Bij aanvang van de vernieuwing werd uitgegaan van een kostenpost van 36 miljoen euro. Uit de brief van de minister blijkt nu dat de kosten op 95 miljoen euro uitkomen. Ze spreekt van een forse overschrijding.

Ik vind een verdrievoudiging nou niet een gewone overschrijding meer, zoals zij het omschrijft....

Dit zijn gewoon absurde bedragen, als je 3x het originele budget nodig hebt (en achteraf blijkt zelfs dát nog niet genoeg), dan klopt óf je budgettering niet, óf je project wordt gewoon slecht geleid (of een combi van beiden).

Ik vind het dan ook onverklaarbaar waarom steeds dezelfde toko's dit soort opdrachten krijgen, als blijkt dat ze keer op keer blijven falen. Bizar.

[Reactie gewijzigd door wildhagen op 23 juli 2024 04:28]

[CAPSLOCK2000]

Ik vind het dan ook onverklaarbaar waarom steeds dezelfde toko's dit soort opdrachten krijgen, als blijkt dat ze keer op keer blijven falen. Bizar.

Volgens mij omdat die bedrijven goed zijn in aanbestedingen winnen.
Als eerste komen kleine softwarebedrijfjes er natuurlijk nooit tussen bij zo'n aanbesteding van tientallen miljoenen, daarbij doen alleen de grootste spelers mee. Daar zijn er niet zo veel van, dus zie je steeds dezelfde namen terug keren. Zelfs als zo'n partij het een keer goed verknalt dan kun je er bij de volgende aanbesteding eigenlijk niet om heen, als de wet het al toe staat om zo'n partij uit te sluiten.

Volgens de gebruikelijke regels wint de goedkoopste aanbieder. Al die bedrijven doen er dus alles aan om de prijs zo laag mogelijk te houden, zelfs als dat onrealistisch laag is.
Dat doen ze omdat ze er op rekenen dat de kosten omhoog gaan zodra ze binnen zijn. Zo'n eerste begroting is namelijk nooit het laatste woord, er is altijd ruimte voor meerwerk. Dat moet ook wel, want de politiek kan de wet op ieder moment veranderen.

Daar komt bij dat het ontzettend moeilijk is om precies in detail vast te leggen wat software moet doen. Het kan wel maar dan ben je het zelf aan het programmeren. Dus wordt er met brede contracten gewerkt met veel ruimte voor interpretatie. De klant trekt daarbij typisch aan het kortste einde, die moet namelijk opboksen tegen de professionele IT'ers van de aanbesteder. Dat is eigenlijk altijd zo want als de klant zelf genoeg bekwame IT'ers in huis had dan was de hele aanbesteding niet nodig geweest. Ieder keer als er iets mis gaat kan de uitvoerder zeggen "maar dat stond niet in het contract, als dat knopje 2 pixels naar links moet dan moeten we meerwerk rekenen".

Extra probleem is dat de overheid ook gewoon vrij uniek is. Voor sommige taken is er nu eenmaal geen kant-en-klare software en zijn er geen programmeurs met relevante ervaring en de schaal is al snel gigantisch groot. En als het probleem niet in de nieuwe systemen zit dan zit het wel in de lappendeken aan oude systemen en applicaties waar mee samengewerkt moet worden.
Systemen zijn vaak erg vervlochten en dat maakt het moeilijk om ze te vervangen omdat je alles in één keer moet doen. Je moet het dus van te voren goed uitdenken want als je eenmaal begonnen bent is het erg lastig om nog een andere kant op te gaan. Als er toch iets verkeerd gaat kan dat ene onderdeel vervangen erg lastig zijn en onevenredig veel kosten.

Alles bij elkaar zijn er maar een paar bedrijven die dit soort projecten kunnen aannemen, en die kennen het systeem en hun klant van voor tot achteren.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 04:28]

[lonewolf2nd]

Het kan heel simpel opgelost worden. 3 strikes and you are out systeem. Dus verkloot je een opdracht zoals deze heb je nog 2 kansen om iets goed wel goed te doen. Op een gegeven moment blijft alleen een goed ict bedrijf over om opdrachten te doen voor de overheid. En middel grote ict bedrijven kunnen dir soort opdrachten ook wel aan. Dus als de grote niet meer mogen, komt er een middel groot bedrijf van zelf bij de grote, alleen dan door kwaliteit te leveren.

[COW_Koetje]

De enige echte oplossing is fixed price.
Dan is het de aannemer er alles aan gelegen om binnen het budget te gaan werken.
Het enige effect dat dat geeft is de kwaliteit radicaal naar beneden gaat, en veel features het niet halen.

Maar goed kiezen tussen een systeem dat nog door ambtenaar pietje op een XP machine draait met excel macro's en een systeem dat op een fatsoenlijk systeem draait met de helft aan functionaliteit is helaas nog steeds een gelopen zaak voor de excel spreadsheet met macro's.

Vele malen dit soort trajecten meegemaakt en het eerste dat de aannemer zegt bij binnenkomst. Dat budget kunnen we zeker 3x over de kop laten gaan voordat we weer vertrekken. Ik heb dit soort uitspraken letterlijk gehoord en nog wel andere gelijksortige.
De cap's en ordina's van deze wereld hebben de beste mensen in dienst om dit soort aanbestedingen te winnen terwijl ze geen enkel respect hebben voor de klanten. En ik heb het niet over de techneuten want meestal krijg je bij de overheid zeker niet de beste mensen van dat bedrijf en zijn het gewoon uren schrijvers.

[Chrotenise]

Dat is een nonoplossing. Een fixed price wordt gedaan op basis van een lijst aan requirements. Gezien de overheid vaak niet precies weet wat het wil, gaat het daar al fout. Alles wat ze van tevoren niet op papier hebben vastgelegd, kost namelijk klauwen met geld.

Ik persoonlijk zou liever zien dat systemen decentraler worden opgeleverd. Niet één grote verzamelbak die 2000 taken doet, maar 1000 applicaties die 1-2 taken doen.

Nu wordt het ene na het andere megaproject opgetuigd om de gehele ICT behoefte van een departement te vervullen. Niemand weet echter alles van alle processen en heeft daarbovenop nog een technisch inzicht. Dus zo'n project is bij voorbaat niet te budgeteren.

[COW_Koetje]

Dat is precies wat ik ook bedoel en daarbij zou het dus wel beter passen.
je kan niet een hele departement in 1x van nieuwe software voorzien.
Doe het in fases met kleine behapbare brokken die je van te voren voor een fixed price opleverd.
Iedereen is er dan bij gebaat om alles goed van te voren inzichtelijk te maken.
De opdrachtgever omdat hij zijn einddoel wil halen en de aannemer omdat hij niet voor overwerk wil betalen.
Mijn (misschien onterrechte) aanname is dat dus aannemer zich dus meer betrokken gaat voelen en daarom betere intakes gaat doen, maar ook dus de opdrachtgever gaat helpen in het proces.

[F-I-X]

Jouw oplossing gaat over de manier waarop iets moet worden opgebouwd.
Het is niet de oplossing van het grootste probleem zoals dat in het rapport en hier al door andere mensen worden aangehaald. De aanbesteding is niet specifiek genoeg gemaakt om een afbakening te hebben wat gerealiseerd moet worden voor welke prijs. Het andere probleem is dat er teveel "manager" inspraak hebben in de wensen ná de aanbesteding. Juist dat meerwerk en grote veranderingen in "visie" en de daarbij behorende aanpassingen in de software zijn het probleem.

Ik kan me goed voorstellen dat zon grote organisatie met veel regelgeving en verschillende markten een enorme kluif is om in één slag te programmeren.
Daarom is de gedachte om het in delen te doen voor een vast bedrag niet eens zo slecht. Zorg dat je een goede basis hebt die je daarna, met een nieuwe aanbesteding kan aanvullen met modules.

[SpiceWorm]

Je bedoeld dat software ook modulair wordt voor de gebruikers?

Dat iemand die een beetje handig is met phyton de verschillende softwaremodules aan elkaar knoopt, door bestanden (data) te verplaatsen in het filesystem waardoor de gegevens effectief verplaatst worden tussen modules? Zoiets?

[MSalters]

Ik persoonlijk zou liever zien dat systemen decentraler worden opgeleverd. Niet één grote verzamelbak die 2000 taken doet, maar 1000 applicaties die 1-2 taken doen.

Optimistisch.

Weet je wat je dan voor vinger-wijzen kunt krijgen ? Systeem A werkt samen met systeem B behalve wanneer systeem C input van systeem D heetf gekregen.

Dit soort grote projecten falen niet doordat ergens een programmeur een bugje in een functie maakt. Dat soort risico's zijn te managen. Nee, dit faalt op de high-level arhitectuur. En jouw voorstel is eigenlijk de afwezigheid van een high-level architectuur. 1000 brokstukjes die spontaan samen moeten werken.

[Chrotenise]

Dit faalt niet op high-level architectuur. Dit faalt op requirements. _Niemand_ binnen zo'n departement weet vaak wat zo'n systeem allemaal moet kunnen op zowel technisch als organisatorisch gebied. Laat staan als er nog tig andere departementen / stakeholders zich ermee gaan bemoeien.

De enige manier om dat werkbaar te houden is dus specifieke applicaties voor iets te bouwen zodra ze het identificeren. Dan heb je misschien meer overhead maar is het wel makkelijk om onderdelen om te wisselen wanneer dat nodig is.

Zeker als je gewoon business rules hebt opgesteld waar al die applicaties zich aan moeten houden qua conventies en gebruikte programmatuur is dat prima te doen. Zou juist vanwege de simpliciteit het onderhoud ook overgedragen kunnen worden aan intern dev team / ander bedrijf, mits je de source krijgt en dit goed archiveert.

[bakkerl]

fixed price is alleen leuk als je vooraf als opdrachtgever ook de scope goed kunt bepalen.
En dat wil nog wel eens mis gaan. En dat meerwerk wat buiten de scope van de opgegeven fixed price valt, dat heeft een enorm prijskaartje. En als je het 'handig' speelt, ook meteen invloed op de scope van het originele project, waardoor die fixed prijs ook niet meer te handhaven is en aangepast moet worden. Meestal naar boven.

[Tomba]

Het kan heel simpel opgelost worden. 3 strikes and you are out systeem. Dus verkloot je een opdracht zoals deze heb je nog 2 kansen om iets goed wel goed te doen. Op een gegeven moment blijft alleen een goed ict bedrijf over om opdrachten te doen voor de overheid. En middel grote ict bedrijven kunnen dir soort opdrachten ook wel aan. Dus als de grote niet meer mogen, komt er een middel groot bedrijf van zelf bij de grote, alleen dan door kwaliteit te leveren.

En uiteindeljk houd je dan geen enkel ict bedrijf meer over bedoel je denk ik. Ik denk dat @CAPSLOCK2000 t prima samenvat. De opdrachtgever heeft geen flauw benul wat de huidige lappendeken van systemen allemaal precies doen en zal steeds nieuwe eisen op tafel leggen. Zo wordt het systeem groter en groter en daarmee dus ook duurder.
Dit is overigens niet alleen bij de overheid zo maar ook bij de meeste ‘normale’ bedrijven. Wie heeft immers het overzicht wat er nu allemaal kan, wat de werkwijzen zijn en helemaal wat er voor wensen ter verbetering zijn. De systemen worden te complex voor 1 persoon om te overzien, dus kan er ook niemand vooraf bepalen wat er precies nodig is... Bij de overheid valt dit echter meer op omdat het om publiek geld gaat.

[SpiceWorm]

Moet er niet mee begonnen worden om de regelgeving veel simpeler te maken? Zoals uitvoering studiefinanciering, uitkeringen etc?

[divvid]

Gezien de looptijd van dit soort projecten fuseren die bedrijven of wordt er een aparte bv opgericht. Sta je dan met je three strikes. Welke ga je toepassen?

[MSalters]

Oh, simpel. Nieuwe BV? Mag je met een 1000 euro klusje beginnen om je te bewijzen.

Kijk, zelfs bij Cap lopen er nog wel competente mensen rond. Het probleem is dat dit soort mega-projecten gebruikt worden om bergen laaggekwalificeerd personeel op te schuiven. De schuld van het falen is toch niet aan één persoon toe te wijzen.

[SJCE]

Nee, want er zijn hier meerdere negatieve spiralen die op elkaar inwerken. Simpele maatregelen kunnen niet individueel helpen, er moeten meer maatregelen tegelijkertijd genomen om de negatieve spiralen te doorbreken. Dat bleek al uit de ICT-hoorzittingen van de tweede kamer. Jammer dat de kwaliteit van de analyse zo slecht was. Daar heb ik al wel eens wat over gezegd https://vimeo.com/160369769

[brabbelaar]

Het is niet zo dat prijs hèt criterium is. Er kunnen allerlei eisen gesteld worden waar aanbieders aan moeten voldoen. Kwaliteit, aantoonbare know how, realistische planningen zijn daar onderdeel van.

[CAPSLOCK2000]

Het is niet zo dat prijs hèt criterium is. Er kunnen allerlei eisen gesteld worden waar aanbieders aan moeten voldoen. Kwaliteit, aantoonbare know how, realistische planningen zijn daar onderdeel van.

Andere aspecten tellen zeker mee, maar die zijn vaak erg lastig om te beoordelen. Al die bedrijven hebben jarenlange ervaring, gecertificeerde mensen, kennis van het vakgebied, etc... Veel van die aspecten zijn ook alleen door andere IT'ers te beoordelen en dan niet op grond van drie kantje tekst van een of andere pre-sales-consultant.
In alle aanbestedingen waar ik aan mee heb gedaan was prijs tenminste 50% van het eindoordeel.

[flowerp]

> Volgens de gebruikelijke regels wint de goedkoopste aanbieder. Al die bedrijven doen er dus alles aan om de prijs zo laag mogelijk te houden, zelfs als dat onrealistisch laag is.

Precies, de regels vragen hier ook gewoon om.

Bij veel interne projecten en zelfs helemaal in het kleinste geval van een enkele ticket voor een enkele sprint gaat het al zo.

Stel je werkt aan coole feature X, en je schat het realistisch (tot zoverre dat kan) op 12 story points (ik zeg maar wat), dan gooit de PM het meteen uit de planning. Maar je team genoot die misschien nog wel een grotere feature beschreven heeft en/of moet inschatten, schat het vrolijk op 6 story points, en de PM trapt er altijd bij elk bedrijf gewoon in. Altijd, elke PM, elk bedrijf. Dus wat doet een beetje doorgewinterde dev tegenover een PM, die schat iets van 12 sp in op 6 sp.

Vervolgens gaat de PM nog afdingen op het aantal SP zodat het 4 komt, maar dan gaat er nog een overhead percentage overheen en uiteindelijk komt het in de sprint als een ticket met 5 sp. Het aantal sp heeft meestal op dat moment geen enkele relatie meer met de echte inschatting.

[djwice]

Gekke PMs ken jij. In mijn team hebben afgesproken dat boven een bepaalde complexiteit we meer refinement doen en stories opslitsen, zodat je per stukje ze beter kunt schatten en het overzichtelijk is voor elk team lid wat er gedaan moet worden. Ook al kom je dan soms op meer punten totaal uit dan in die ene grote.
Ook schatten we met het hele team in, zit er verschil van meer dan 1 stap, dan gaan gaan we een refinement in.

Product Owner moet toch naar value kijken - aantal punten zegt niets over value.

Bij ons hebben we ook een andere reeks kaarten dan jij zo te zien hebt; 1,2,3,5,8,13,20 zijn de enige valide waardes, dus 12, 6 en 4 komen bij ons niet voor. Ook doen we niet aan overhead of andere opslagen. Voor mij allemaal bijzondere aanpak die je beschrijft.

[Reactie gewijzigd door djwice op 23 juli 2024 04:28]

[flowerp]

Ik werk bij meerdere bedrijven op locatie, maar idd de fibonacci reeks zie ik ook vaak.

Om enigszins in te schatten moet je vaak met een ticket aan de slag gaan. Het is niet realistisch in te schatten of nog niet op te delen.

B.v. grote Java code base op JDK11+ compileerbaar krijgen. 2 projecten, grofweg even groot (paar miljoen regels elk). Op wat schat je zoiets? In fibonacci dan, 13? Waarop baseer je het? Je moet eigenlijk het gewoon doen om te ontdekken wat er niet werkt op JDK 11. Ene project duurde enkele weken, bleek zeer complexe SSL code in project 1 voor te komen die verwezen was met sun classen en heel lastig om daar vervanging voor te zoeken, plus nog een hele nare dependency die in een bepaald geval "gek" gedrag vertoonde, en bijna 50% van de tijd kosten om op te lossen.

Project 2 echter was nog geen dag werk. Na een hele snelle scan voor sun.* classes waren het er grofweg even veel als project 1, maar toevallig allemaal dingen die triviaal te vervangen bleken te zijn.

Andere ticket, het zenden van een bericht tussen 2 servers met een bepaalde library. Hoe moeilijk kan dat zijn? 2 sp? 3 sp voor de zekerheid? Blijkt in de praktijk dat de berichten niet goed aankomen. Hele ticket gaat meer dan 2 weken lang, 8 uur per dag, in zitten. Bizarre complexiteit vanwege de server setup (een JBoss server die op alle netwerk adapters luistert, en daarom het eigen return IP address niet goed pakt), en de netwerk setup (geen multi-cast en wazige time-outs).

En dan zijn maar twee voorbeelden.

Estimations vind ik persoonlijk dan eigenlijk vrij waardeloos. Prioriteit is veel belangrijker, en aan het einde van de (korte) sprint kun je bepalen of een ticket die nog steeds niet af is nog belangrijk genoeg is om weer mee te gaan naar de volgende sprint.

[Chrotenise]

Wat je zegt klopt tot op zekere hoogte. Er zullen altijd tickets tussen zitten die je niet van tevoren kan inschatten. Daar moet je realistisch over zijn tegen je PM: ik kan zonder onderzoek niet een schatting geven. Dan wordt, afhankelijk van hoe hoog de prioriteit is, bij een goede PM een ~4/8u onderzoek ingepland in deze week, waarna het ticket alsnog met een redelijk realistische schatting de backlog van een volgende sprint in kan. PM's willen namelijk ook geen onafgeronde sprints hebben of tickets die 4 weken uitgesteld afgehandeld worden.

Verder zijn de dingen die jij noemt natuurlijk uitzonderingen. Een backlog zit veel vaker vol met 'ik wil een nieuwe knop die x doet' of 'via schermpje y bij z uitkomen.' Daar zal doorgaans geen wezenlijk verschil tussen estimate en eindresultaat zitten.

[Reactie gewijzigd door Chrotenise op 23 juli 2024 04:28]

[flowerp]

>Verder zijn de dingen die jij noemt natuurlijk uitzonderingen. Een backlog zit veel vaker vol met 'ik wil een nieuwe knop die x doet' of 'via schermpje y bij z uitkomen.

Het hangt natuurlijk van het project af, maar in backend/engine achtige omgevingen is het helaas eerder regel dan uitzondering, tenminste in mijn bescheiden ervaring.

[Chrotenise]

Je kan zien dat ik weer denk vanuit en meer werk met systemen waar directe eindgebruikers achter zitten.

Je hebt inderdaad gelijk dat backendprojecten hier relatief vaker mee te maken zullen krijgen omdat de featureset meestal wel redelijk vaststaat en het dus voornamelijk technische change requests zijn.

Mijn inziens is zo'n project echter ook weinig Agile geschikt. Wat is er immers tussentijds te bespreken? Het werkt met de gewenste technische specificaties of het werkt niet.

[Reactie gewijzigd door Chrotenise op 23 juli 2024 04:28]

[sjoerdmekenkam]

als toevoeging; er zitten allerlei neveneffecten bij dit schatten en prioriteren welke potentieel erg nuttig zijn: het delen en uitdagen op argumenten. Niet degene met de grootste waffel duwt zijn idee erdoor, maar er is een terugkerende 'time out' waarbij iedereen kan bijdragen en informatie kan delen. Best handig als iemand verstand van zaken heeft en bijvoorbeeld van de genoemde SSL-code weet (en de inschatting deelt) dat zoiets pokke-ingewikkeld is.

[flowerp]

> Best handig als iemand verstand van zaken heeft en bijvoorbeeld van de genoemde SSL-code weet (en de inschatting deelt) dat zoiets pokke-ingewikkeld is.

In theorie inderdaad, in de praktijk... het komt mijn inziens -te- weinig voor. Als je zeg 60 tickets voor een sprint hebt (team van 7 a 8 man), komt het in de praktijk weinig voor dat iedereen elke ticket tot op de detail gaat bestuderen om een redelijke inschatting te maken.

En dat er ingewikkelde SSL code in het project is dat is misschien wel bekend, maar dat precies die gebruik maakt van interne JDK code die moeilijk te vervangen is, is weet je eigenlijk toch echt pas als je er mee aan de gang gaat.

Nog een voorbeeld uit de praktijk, bij een ander bedrijf; we zijn met Eclipse based tooling bezig, en een issue vraagt om iets toe te voegen aan custom nodes onder de Java navigator. Weer, hoe moeilijk kan het zijn? Extension point voor dat ding opzoeken, custom handler class, en je eigen ding toevoegen. 2 sp? 3 sp? Zeker als je al enigszins bekend bent met Eclipse plug-ins en extenions en eerder custom dingen hebt toegevoegd.

Alleen, na het wat lijkt triviaal toevoegen, refreshed het nare ding niet. Gewoon niet. Niemand weet waarom niet, dus dat wordt debuggen. Waar te beginnen? Op zoek naar andere plug-in die iets soortgelijks doet en code vergelijken? Oh, maar die doet ook 100 andere dingen die je mentaal moet wegfilteren. Dan maar debuggen door Eclipse code heen, maar ook hier weer, waar te beginnen? Uiteindelijk probeer je wat, en probeer je nog wat, en na paar dagen kom je steeds dichter bij het probleem en uiteindelijk los je het op.

PM staat alleen op koken, want je had "beloofd" (ja, daar gaat het vaak al fout), dat het maar 2 sp was, en 2 sp is een middag, dus 4 uur max (en ja, daar gaat het alweer fout, ik weet het, maar te veel PMs redeneren zo).

Eenmalige issue? Want volgende keer weet je hoe de JavaNavigator in Eclipse werkt en schat je beter in? Nee hoor, volgende keer heb je weer -totaal- andere issues.

[MSalters]

Je moet dan ook op tijd weten wanneer te stoppen. 6 uur verbrand en geen einde in zicht? Stoppen, en in voor de volgende planning een aangepaste taak maken.

Het klinkt alleen also je een PM hebt die uit z'n omgeving is. In een webschermpjes-maken omgeving is "sorry, werkt niet" een hoge uitzondering. Ik werk in de R&D, "werkt niet" is hier de normaal. Daartussen heb je blijkbaar een probleem. Tijd om een PM uit een R&D omgeving te halen, deze functioneert niet.

Mag je overigens best hard in zijn, ook richting hoger management. Voetbalclubs vervangen ook sneller trainers dan spelers, dat is nu eenmaal makkelijker. En op het moment is het ook makkelijker om 1 PM te vinden den 10 programmeurs.

[sjoerdmekenkam]

PM/PO zit vaak wat sneller politiek getint in de wedstrijd. Soms schemert er toch wat ouderwets teamleider-gedrag doorheen. Niet goed!

[djwice]

Klinkt als te weinig vooraf kijken wat je aanpakt, waardoor je geen goede inschatting geeft van de complexiteit.

[sjoerdmekenkam]

ik vind wat je beschrijft een sterk voorbeeld en de reactie van MSalters idem. Zodra de varieteit en onvoorspelbaarheid toeneemt, wordt de toegevoegde waarde van schatten minder. Ik heb zelf bij een grote financiele instelling met een groot aantal ontwikkel-teams heel lang gezocht naar een soort van ideale tijdsverdeling. Ik herken de situatie die je beschrijft en ook de beperkte toegevoegde waarde van schatten (als we er weer eens een factor 100 naast zaten).

Wat wel hielp;
-onderkennen dat het kennelijk erg onvoorspelbaar was
-collega's eerder uit een onmogelijke missie trekken, of hulp inschakelen
-afnemers/gebruikers/'de business' sneller informeren als iets anders liep dan verwacht.

Vooral die laatste was boeiend. Daar kwam de PM aan bod. Niet het leukste gedeelte van z'n baan, maar beter dan heel lang geen nieuws.

[latka]

Je kunt alleen vragen om estimates op bekend gebied. Als je iets nog nooit hebt gedaan heeft een estimation geen enkele waarde. De volgende PM die je vraagt dit te doen moet je dan de tegenvraag stellen om even een schatting te maken van het maken van een huis. Doen ze niet, want dat weten ze toch niet.

[djwice]

Als een code base onbekend is bij een team is het duidelijk nog geen situatie waar je via scrum in terecht bent gekomen.

Je kunt immers pas eigenaarschap nemen als je weet waar je over praat.

Het zelfde geldt voor het endpoint voorbeeld, je geeft duidelijk aan dat de kennis over de server en de netwerk laag ontbrak.

In zo'n situatie geeft ik het team eerst stories die er voor zorgen dat ze wél bekend raken met de situatie. Dat is simpelweg in het belang van de kwaliteit van de implementatie en vermindert de kans op problemen in productie aanzienlijk. Bovendien is de kans groot dat het team ook anders dingen ontdekt welke ze graag zouden willen verbeteren of aanpassen aan de applicatie om hem beter te laten werken. Ook zorgt het er voor dat mijn team toekomstige vragen dan beter kan inschatten. En ik dus beter kan inschatten hoeveel value ik kan leveren met mijn team.

Een PO die zijn team blind het veld in stuurt en weken laat aanmodderen past niet in mijn beeld van hoe je scrum zou moeten doen.

[latka]

Dat betekent dat ze alleen aan de voorkant meten maar de velocity van het team niet meenemen. Dat is een beetje zoals afrekenen op Lines-of-code: stom en achterhaald.

[flowerp]

Helemaal grappig als dan de beste programmeurs in het team een negatieve lines of code hebben!

(b.v. omdat ze allemaal troep weggehaald hebben en onzinnige classes van zeg 5k regels (ja, ze bestaan, en nog wel erger ook) hebben teruggebracht tot zeg 1k.)

[Q]

in hoeverre is de overheid medeschuldig aan deze problematiek. Worden ze gepiepeld door de bekende usual suspects of maken ze het zelf ook lastig om externe partijen succesvol te laten zijn?

[Znorkus]

Volgens de gebruikelijke regels wint de goedkoopste aanbieder.

Misschien moeten de betreffende heren/dames beleidsmakers ook eens een boekje Nederlandse Zegswijzen op hun nachtkastje leggen. Dan kom je pareltjes tegen als 'Goedkoop is duurkoop'.

Verplicht met de aller-allergoedkoopste in zee te gaan? Hoe ongelooflijk dom kun je zijn?

[CAPSLOCK2000]

Verplicht met de aller-allergoedkoopste in zee te gaan? Hoe ongelooflijk dom kun je zijn?

Zo simpel zijn ze ook weer niet. Typisch schrijf je een hele rij eisen en wensen op en dan mogen bedrijven daar op reageren. Vervolgens kies je van de bedrijven die het beste scoren de goedkoopste aanbieder. Het gevaar is dat alle aanbieders zo veel op elkaar lijken dat het grootste verschil in de prijs zit. Tegen iedere prijs de beste nemen (als je al weet wie dat is) kan ook niet de juiste oplossing zijn.

[kramer65]

Ik ken toevallig wat mensen die hier nog wel eens mee te maken hebben. En na een uurtje naar hen geluisterd te hebben begrijp ik wel waarom dit altijd zo in de soep loopt. Er liggen een paar problemen aan ten grondslag.

1. Partijen moeten aan kunnen tonen dat ze van een bepaalde grootte zijn (dus maar een paar bedrijven kunnen meedingen).
2. Dit is misschien wel de grootste. De kennis is bij overheden intern meestal op z'n best treurig, wat resulteert in allerhande conflicterende opdrachten die na een vraag om verduidelijking of feedback, alleen maar vager worden. Het is vaak niet duidelijk wie binnen het relevante overheidsorgaan de juiste kennis heeft en wie er over mag of moet beslissen. Ik hoorde een verhaal van een programmeur die ik ken die in een interne meeting zat waar een ruzie ontstond wie iets moest doen. Diegene die eigenlijk verantwoordelijk was werkte er namelijk al lang niet meer. Na een tijd heen en weer geruziet te hebben stond er uiteindelijk een kerel op die zei: "ok, ik neem de verantwoordelijkheid op me, maar ik ga het niet doen."
3. Partijen kunnen zich bij een aanbesteding inschrijven. Vaak is het enige criterium prijs. Met een hogere prijs (want te laag is niet realistisch) win je niet, dus winnen alleen de bedrijven die de klus laag in schatten en daarna met verhogingen komen.

Kortom, het aanbestedingssysteem is gewoon verkeerd en moet aangepast worden. Geen idee hoe precies. Ik hou me het liefste verre van overheidssystemen.

[Swerfer]

3. Partijen kunnen zich bij een aanbesteding inschrijven. Vaak is het enige criterium prijs. Met een hogere prijs (want te laag is niet realistisch) win je niet, dus winnen alleen de bedrijven die de klus laag in schatten en daarna met verhogingen komen.

En dit is wat je prima in een contract kan wegzetten. Vaste prijs afspreken onder voorwaarde dat het eisenpakket duidelijk is en reeel en waarbij een grondige 'intake' plaats vind waarbij de developers exact weten wat voor data ze aangeleverd krijgen en wat er met die data moet gebeuren. Deze intake mag best wat kosten als daar tegenover staat dat er een vaste prijs kan worden afgesproken voor het gehele project.

[kramer65]

Je klinkt niet alsof je ervaring hebt met grote softwareprojecten.

Je kan een heleboel vastleggen, maar er komt áltijd maatwerk bij kijken. In de tijd dat zo'n project loopt (jaren) veranderd er intern van alles bij de deeloverheid waar je mee te maken hebt. Hun softwaresystemen staan ook niet stil, de techniek staat niet stil, en dan heb je nog voortschrijdend inzicht. Daar komen nog security issues overheen, vernieuwde eisen (het moet ook op de nieuwste telefoon X en Y draaien, het moet binnen NL draaien, het moet "in de cloud", oh nee het moet on premise!) en wetgeving die verandert en waaraan voldaan moet worden. En dat alles moet eindeloos gedocumenteerd, gedetailleerd en goedgekeurd worden zodat niemand later de schuld kan krijgen van iets.

Software definiëren is helemaal top, maar het kan net zo'n grote rem zijn op het project..

[Reactie gewijzigd door kramer65 op 23 juli 2024 04:28]

[catfish]

Sorry, maar in mijn ervaring met de overheid (toch al 15 jaar ondertussen) is er inderdaad vaak weinig kennis in huis over een onderwerp of te weinig mensen om het project te kunnen opvolgen. Vervolgens wordt het opmaken van het bestek/studie uitbesteed aan 1 van de bekende toko's en wordt het daarna in de markt gezet om uitgevoerd te worden door andere toko's.
Naar mijn mening perfect vergelijkbaar met: "ik bouw een huis en huur een architect in".
Heel vaak blijkt toko 1 helemaal niet zo competent als ze zich voordoen waardoor toko 2 heel de tijd op problemen (en dus extra kosten) stuit.
Ik heb echter nog nooit meegemaakt dat een toko 1 voor de rechtbank werd getrokken (hoewel ik al meerdere keren zwart op wit bewijs heb gezien van zware fouten). Die toko's worden gewoon een hand boven het hoofd gehouden. Niet meer niet minder.

[aidanl]

Aanbestedingssysteem is leuk idee, maar de overheid heeft vaak al een idee van de partij waar ze in zee mee willen. Al vaker gezien dat bij presentatie's de aanwezigen meer aandacht hadden voor hun telefoons als daadwerkelijk op de presenterende partij aan het letten waren. Het is dus een verplicht process maar wordt niet of nauwelijks serieus gehanteerd. Hierdoor zie je dat keer op keer weer Cap of Ordina de opdracht krijgen en keer op keer vol over budget heen gaan.

Een ezel stoot zich geen twee keer aan dezelfde steen. De Nederlandse overheid blijkbaar wel vaker.

[hmartino]

Het is toch niet erg om een idee te hebben van de partij die een presentatie geeft. Dat doet iedereen, of je nu ambtenaar bent of niet. Wellicht is de presentatie zo saai dat iedereen op zijn telefoon gaat staren. Als je een goede presentatie geeft gaan mensen echt wel opletten. En blijkbaar was (jullie) de 'offer' al niet interessant genoeg. Dan moet je van goede huize komen wil je dit rechttrekken met een presentatie.

Wat betreft je aanname dat de Nederlandse Overheid zich niet twee keer stoot aan dezelfde steen. Het is niet een persoon hoor. Maar een heleboel mensen. Ik denk echter wel dat de grote organisaties hierop slim inspelen. Een overheids onderdeel doet eenmaal een grote aanbesteding. Bij de grote organisaties zijn het dezelfde mensen vaak die zich hiermee bezig houden. Een verbeterpunt!
Maar we moeten niet alles over een kam scheren. Immers het is eenvoudiger om met iedereen mee te praten dat alle overheids ICT projecten misgaan. Zij doen blijkbaar nog alles op papier als ik al dit soort berichten mag geloven. Ik zie echter genoeg succes. Je weet waarschijnlijk waar ik op doel. Of stuur jij nog brieven naar de 'Nederlandse Overheid'?

ps Ik ben wel van mening dat het aanbestedingsbeleid op de schop mag om meer concurrentie te bevorderen en niet altijd op prijs wordt gezocht en nog een paar argumenten

[HakanX]

Er is maar één oplossing. Stoppen met de aanbestedingen en een eigen IT afdeling opzetten. Idioot dat Nederland in 2019 nog altijd geen apparte ministerie voor IT heeft. Heel de wereld draait om IT en het is bij ons nog altijd een subcategorie binnen de overheid zonder know how binnen de overheid zelf.

[Budha]

Dat lost niets op. De oorzaak van die grote overschrijdingen is zelden dat de IT specialisten niet competent genoeg zijn.

Problematischer zijn andere oorzaken zoals het gebrek aan kennis binnen de overheid aangezien er zoveel wordt uitbesteed (zoals bijvoorbeeld het Ministerie van Infrastructuur en Milieu). Daarnaast worden dit soort grote projecten vaak aangestuurd vanuit verschillende overheidsorganisaties en dat draait eigenlijk altijd uit op een gebrek aan regie.

[MSalters]

Het idee van zo'n ministerie van ICT is niet dat ze 100% van het werk doen. Je wil er de high-level architecten hebben zitten. Pas als die intern het idee hebben dat een project duidelijk genoeg gedefinieerd is laat je hen de aanbesteding uitschrijven.

Zo'n NVWA project kan dan klein gehouden worden. 23 vakgebieden waarvan er 20 nog onduidelijk zijn? Kan gebeuren, maar dan besteden we niet alles aan. Het ICT-ministerie zelf kan dan de high-level architectuur opzetten, en 3 deelprojecten voor 2 miljoen elk uitbesteden.

[veltnet]

Ik zou hier graag een ding aan willen toevoegen: Grote projecten opsplitsen in kleine agile projecten zodat deze
1) Onder de aanbestedingsnorm blijven
2) Overzichtelijk blijven qua projectduur en scope.

[HakanX]

Je hebt helemaal gelijk met het opsplitsen. Alleen moet dit niet zijn om mazen te gebruiken in je eigen wetgeving, want dan ben je echt incompetent als een overheid. Dan pas je maar de wet aan, je bent de wetgevende macht.

[veltnet]

Vooral opsplitsen om zaken overzichtelijk en beheersbaar te houden...Agile/Scrum/whatever

[kazz1980]

Klopt. een héél groot deel van het probleem zit in de regelgeving rond aanbestedingen...
Veel bedrijven weten precies hoe ze de relevante bedragen in zo'n aanbesteding laag kunnen houden om vervolgens via de achterdeur toch veel meer geld te vangen! Bekende trucs zijn allerlei zaken buiten het contract houden (waarvan de aanbiedende partij al lang weet dat deze absoluut wel noodzakelijk gaan zijn om het project tot een succesvol einde te brengen) of op bepaalde functies héél laag aanbieden omdat de aanbiedende club weet dat ze die mensen toch niet hebben (en daar dan een eventuele boete op voor lief nemen wanneer de vraag toch komt).

Probleem is dat dit systeem enkel kijkt naar de cijfertjes en maar heel beperkt naar het verhaal. Wanneer je als consultancy club met een hoger bedrag komt maar met een goed verhaal delf je vaak toch het onderspit tegen de grote jongens die met lage prijzen zwaaien in wurgcontracten waarvan iedereen met enig gezond verstand kan zien dat het totaal uit de klauwen gaat lopen....

[SJCE]

Dit is veel te simpel. Als je de interviews van de ICT-hoorzittingen gezien had, had je kunnen weten dat er veel meer negatieve spiralen tegelijkertijd optreden. Die kun je alleen met een samenhangend geheel van maatregelen ombuigen. Zie https://vimeo.com/160369769

[Koekiemonsterr]

Ja die link heb ik ook gebruikt

[Naj_Geetsrev]

Ik vermoed omdat het aanbesteed moet worden. En ze volgens de aanbesteding het beste uit de bus komen.

[CH4OS]

Ik vind het dan ook onverklaarbaar waarom steeds dezelfde toko's dit soort opdrachten krijgen, als blijkt dat ze keer op keer blijven falen. Bizar.

Dat heeft met het aanbestedingsproces te maken. Overheden moeten daarbij een afweging maken, kosten versus features, waarbij de nadruk vooral ligt op kosten. Dus hoewel de overheid best zal willen, is het ook gebonden aan de (eigen?) Europese regels.

[Saint2Saint]

Volgens mij kan je hier meer info vinden over dit project. Ook over andere grote projecten bij de overheid staat hier informatie. https://www.rijksictdashboard.nl/projecten/530125

[djwice]

Lol
* project start 1 jannuari 2018
* projectplan is van 26 augustus 2018
* kwaliteit controle 29 augustus 2018

Actie minister aan de hand van kwaliteit controle : april 2019.

[eekhoorn12]

Hier is trouwens het hele rapport in te zien, en niet alleen het de kamerbrief van de minister https://www.bureauicttoet...rnieuwing-informatie--ict

[renevanh]

Ik vind dit onderhand een beetje de spuigaten uitlopen. Een enkel project dat mislukt, dat kan gebeuren. Maar nu begint het zowat de default te worden dat projecten mislukken voor tientallen miljoenen.

Kostenoverschrijding is standaard bij overheden. Dat betekend zeker niet altijd een mislukking, maar het is wel een soort 'normaal' geworden. Dat weet het bedrijfsleven donders goed en daar gaat het bedrijfsleven zelfs geheel bewust van uit.
Je schiet de goedkoopst mogelijke offerte in (exclusief meerwerk uiteraard) en laat daar zoveel mogelijk in weg, wat je later als meerwerk gaat rekenen:

Wegenbouw is zo'n voorbeeld.
Gemeente: "Hier moet een weg"
Wegenbouwer: "Ok, die weg kost zoveel, exclusief meerwerk"
Gemeente: "Jij bent de goedkoopste, bouw die weg!"
- bouw bouw bouw -
Gemeente: "Mooie weg, lekker binnen het tijdschema ook, wanneer komen de lantaarnpalen, stoeprandjes en belijning?"
Wegenbouwer: "Oh, moet dat ook? Regelen we! Wordt het wel stukje duurder".

Websitebeheer net zo.
Webbouwer: "Wij maken jullie website voor weinig"
Gemeente: "Top, doe maar!"
- bouw bouw bouw in standaard framework met makkelijke backend -
Gemeente: "Joh, wij hebben een extra pagina nodig voor [vul maar in]"
Webbouwer: "Prima, regelen we! Kost wel 10.000,- per pagina!"

Beide situaties vanaf de eerste rij mogen meemaken en dit is structureel zo bij heel veel middelgrote en grote bedrijven. Overheid? Normale offerte maal 3 en zoveel mogelijk weglaten en als meerwerk berekenen.

Het probleem? Inkopers zonder inhoudelijke kennis die alleen gefocust zijn op het bedrag onderaan de streep. Als de gemeentes, provincies en landelijke overheden vakkundige freelancers zouden inschakelen voor specifieke inkooptrajecten zou het jaarlijks miljarden aan belastinggeld schelen.

[Reactie gewijzigd door renevanh op 23 juli 2024 04:28]

[FreezeXJ]

Het probleem is garanderen dat die freelancers niet het neefje van de manager zijn, en garanderen dat ze niet in bed liggen met een grote leverancier die ze daarna (tegen een leuke vergoeding) binnenhalen. Vooral dat garanderen is een hel, dus dan vereis je certificaten, een volledig audit-traject en een inzichtelijk rapport. Ik ken weinig freelancers die dat kunnen leveren, dus kom je weer op de (grotere) consultancy-toko's uit, die dat wellicht wel kunnen garanderen, maar gegarandeerd ook niet onafhankelijk zijn.

[renevanh]

Per project willekeurig uit het vakgebied selecteren, klaar.

Natuurlijk moet je zorgen voor mensen met de juiste kennis, maar als ik naar mijn eigen vakgebied kijk (evenemententechniek) zie ik hier lokaal uitgaven voorbij komen die 3x hoger zijn dan noodzakelijk.
Een gesubsidieerd cultureel programma wat in de duurste zaal van de gemeente zit met een technisch leverancier die 3x de reguliere prijzen rekent... Dat doet pijn om te zien.

Hetzelfde gebeurd op ICT gebied, bij wegenbouw etc.

[MSalters]

En wie bepaalt de grenzen van het vakgebied? Moet je voor (zeg) belastingdienst.nl willekeurig selecteren uit iedereen die wel eens eeh HTML pagina heeft gemaakt?

[renevanh]

Iemand die weet waar het over gaat. Dus nee, iemand die wel eens HTML bekeken heeft is niet geschikt voor een complex webportal, maar iemand met 10 jaar ervaring in de ontwikkeling van dat soort portals heeft goed zicht op wat een reëel en vooral compleet aanbod is zodat er niet een offerte van 25 miljoen gemaakt wordt met een soort garantie op meerwerk van 100 miljoen. Dat structurele gegraai in belastinggeld door bedrijven moet eens afgelopen zijn.

Het is nog maar een idee natuurlijk, maar giet het in een vorm vergelijkbaar met het Amerikaanse jury systeem uitgebreid met categorieen aangaande kennis, evt met een inschrijfsysteem of als stukje verplichte participatie aan de samenleving door zelfstandige ondernemers ofzo... Mogelijkheden te over, kwestie van de juiste vinden.

[Reactie gewijzigd door renevanh op 23 juli 2024 04:28]

[Swerfer]

Wel moedig dat de overheid eindelijk eens besluit een ICT-project stop te zetten. Meestal blijft het dooretteren en steeds meer geld kosten, terwijl niet alleen de overheid er schuld aan heeft, maar natuurlijk ook de ICT-bedrijven. Die laatste moeten ook een keer voelen dat ze reeele deadlines en bedragen gaan noemen en niet denken dat de overheid toch wel betaald.

[Raventhorn]

Als de contracten dan ook boeteclausules zouden bevatten waarmee in een geval als dit (een deel van) het geld weer terug geëist zou kunnen worden, dan zeker ja. Maar nu is er wéér gewoon ~65 miljoen verbrand, zonder resultaat. (begroting van 95 miljoen, 30 miljoen over)
Overigens lijkt me dat ook geen reële oplossing, dan is er geen enkele leverancier meer die dit soort contracten aandurft, maar tegelijkertijd voelt/lijkt het wel rechtvaardig. Het lijken steeds dezelfde partijen te zijn die het verprutsen en 'ons' belastinggeld in de zakken steken.

In deze zal de 'schuld' aan beide kanten liggen, zowel de klant als leverancier maken immers deel uit van het proces. Als de klant niet duidelijk heeft wat er moet gebeuren en wie waar voor verantwoordelijk is, is het ook lastig om tot een fatsoenlijk resultaat te komen. Aan de andere kant heeft de leverancier ook de taak om de klant te begeleiden in het ontwikkeltraject; daar zijn ze immers de (duur betaalde) expert voor. En de reputatie van Cap doet vermoeden dat zakken vullen belangrijker is geweest dan tot een degelijk resultaat komen...

[TheVivaldi]

"(begroting van 95 miljoen, 30 miljoen over)"

Nee, de begroting was 36 miljoen; de rest was niet begroot en dus boven budget.

[catfish]

Boeteclausules klinken leuk, maar die boetes zijn geplafonneerd.
Als je bij problemen boetes begint uit te schrijven zit je voor je het weet aan het plafond en besef je dat die aannemer niet veel meer moeite gaat doen...
Er zijn zelf aannemers die bewust de grens opzoeken door slecht werk te leveren. Het probleem is dat je ze moeilijk kan weren uit de aanbesteding.

[MSalters]

Het is inderdaad handiger om pas te betalen bij oplevering. Maar dan hou je dus de problemen met scope creep - ik ga als leverancier niet wachten op mijn betaling omdat de overheid meer geleverd wil hebben.

[Richh]

Aan de ene kant wel, aan de andere kant ging dat systeem vast niet voor niks op de schop.
Op termijn is achterstallig onderhoud over het algemeen slechter en duurder.

[theduke1989]

@Capgemini het bedrijf wat alleen HBO / masters toe laat en alsnog zoveel problemen veroorzaakt nice.
Als dat zo is dan he.

[holoduke51]

Dat maakt opzich nog niet zoveel uit.
Grootste issue is dat al het uitvoerende werk door de net onervaren afgestudeerde worden uitgevoerd. De mensen in de lagen daarboven houden zich vooral bezig met onzinnige management taken, trainingen en sales. Want sales is uiteindelijk de core business van deze bananen partijen. Niet een mooi compleet product opleveren. Nee een zo duur , maar net goed genoeg product wat het liefst extreem veel aftercare nodig heeft.
Capgemini, Ordina etc. Met alle respect voor de mensen die er net werken, maar dit soort bedrijven zijn de absolute parasieten van software bedrijven.

[Cerulean]

Ik zie alleen geen enkele aanwijzing dat Cap of Ordina hier bij betrokken is. Gezien de gebruikte ontwikkelimgeving Bleuriq lijkt me dat ook onwaarschijnlijk

[johnkeates]

Dat zegt helemaal niks Diploma is leuk als je niks anders hebt om mensen op te selecteren, maar in de praktijk is dat na een paar jaar al niks meer waard.

Bij Cap gaat het mis om dat het bedrijf niet bestaat om goede oplossingen te maken, maar om zo veel mogelijk geld te verdienen.

[Lisadr]

Al jaren lees ik over mislukte ICT projecten bij de overheid. Lijkt niets te veranderen.

[Mmore]

Je denkt toch niet dat ieder succes project hier op Tweakers gedeeld wordt Dat is helemaal niet interessant, tenzij het heel innovatief is geweest. Ik denk dat de schaal van "de overheid" nog wel eens onderschat wordt.

Niet dat alles prima gaat hoor, de reacties onder dit artikel geven genoeg problemen aan. Lijkt vooral bij de aanbesteding mis te gaan met partijen die onder de kostprijs bieden omdat ze weten dat er op de meerprijs/extra werk genoeg te verdienen valt.

[Seth_Chaos]

Het heeft geen gevolgen voor bedrijven omdat die perfect kaderen wat wel en wat niet binnen het contract valt. De ambtenaren die verantwoordelijk zijn voor die projecten hebben kennis, nog de kunde om die projecten te leiden. En dat komt omdat ze weg komen met hun falen. Ja ze worden bij het falen vaak ontslagen, maar gaan vervolgens bij de volgende toko voor een nog grotere bak met geld weer aan de slag, met een leuke ontslag regeling toe. Niets bij de overheid is prestatie gericht.

[yzaazy]

Het is altijd wel makkelijk om projecten die niet werken af te schuiven op de ingehuurde partij. Maar er zou ook eens kritisch gekeken moeten worden naar het management beleid binnen de overheid. Er zijn veel te veel manager die allemaal belangen hebben bij hun eigen onderdeel en die graag andere dwars zitten en hiermee miljoenen verspillen. Doordat ze dwars zitten loopt het project vertraging om omdat bepaalde beslissingen niet gemaakt kunnen worden. Er zijn binnen de overheid te veel manager in relatie tot ontwikkelaars. Dit komt de ontwikkeling van vele applicaties niet ten goede.

[kazz1980]

Ordina? Die heb ik nog niet eerder gezien icm falende IT-projecten. Uiteraard is de kans erg groot dat er mensen van Ordina bij betrokken waren, net als van iedere andere grote detacheerder die actief is in de overheids branche...

Ik zie vaak dat de problemen vooral bij de partijen zitten die met wurgcontracten precies afdwingen wat ze wel, maar vooral ook niet doen. Zo hebben ze de prijs van de aanbesteding lekker laag kunnen houden. Uiteindelijk mag de overheidsinstelling alsnog gewoon betalen en loopt alles uit de klauwen. Dit soort wanpraktijken gebeuren veel en dan zijn partijen als Ordina en Cap Gemini zeker niet de clubs die zich daar het meest schuldig aan maken.... Daarnaast leert de overheid weinig van de eigen fouten. Ze blijven in cirkels rondzwemmen. Lekker vertrouwd doen wat ze altijd al doen en blind vertrouwen op een handjevol dure consultants die ze daar advies in geven (en dan met de noorderzon vertrekken). Dat exact datzelfde al tig keer mis gegeaan is is niet relevant. Gewoon weer doen. Nu gaat het vast wél goed! Maar verrassing: als je precies hetzelfde doet dat eerder tot problemen leidde, zal het nu ook weer tot problemen leiden! Op de één of andere manier wil dát kwartje bij veel overheidsdiensten niet vallen. En daar maken een aantal detacheerders en consultancy-clubs dankbaar misbruik van! (ik noem hier dan weer geen namen bij... vind dat weinig chique aangezien ik van dit falen geen idee heb welke partijen daar wel of niet bij betrokken waren... Wat mij betreft is dat op ongegronde basis bedrijven in diskrediet brengen en dus in feite een vorm van smaad...).

[jpsch]

Gokje op basis van andere projecten

- overheid huurt bedrijf in om uitbesteding te schrijven, want kennis ontbreekt en dit is efficiënter
- bedrijf dat uitbesteding wint heeft ook aan plan meegeschreven
- budget is laag, want nieuw systeem moet geld opleveren
- eisen in plan zijn vaag, zodat elke aanpassing meerwerk wordt
- veel aanpassingen en vertragingen, want vaag omschreven en alles wordt in dit nieuwe project gefietst
- project vertraagd en veel eisen zijn verouderd
- overschrijdingen worden goedgekeurd
- boel loopt zo uit de hand dat project wordt stopgezet of gedeeltelijk wordt opgeleverd

[DropjesLover]

Je vergeet de nieuwe baas/manager die zich met de eisen of specificaties gaat bemoeien en/of functionaliteit er bij wil waardoor weer bijna van voor af aan moet gebeuren... En 2 jaar toch weer vertrokken is, waardoor de nieuwe manager [repeat]

[trogdor]

Aan welke partij was dit uitbesteed ?

[GuiltyNL]

Ben niet helemaal zeker, maar volgens mij is dit 'm (ondanks dat hij hier als afgerond staat):

https://www.rijksictdashb...0544/uitvoerende-partijen

CGI als software leverancier
Quitiq als sofware leverancier
DICTU als ICT-inhuur

En dit is dan de opvolger zo vermoed ik:

https://www.rijksictdashb...0125/uitvoerende-partijen

Daar zit IAM4 nog bij.

[Reactie gewijzigd door GuiltyNL op 23 juli 2024 04:28]

[DeAllerlangste]

Lijkt een ander overheidsprogramma te zijn. Het FD roept over deze vraag het volgende:

Private partners
Het ministerie maakt volgens een woordvoerder op dit moment niet bekend welke private partijen betrokken waren bij het mislukte ICT-project. In de brief aan de kamer valt vaak de naam van het Bossche bedrijf Blueriq. Dat is een dochter van Total Specific Solutions (TSS). Bij Blueriq en TSS staat de vraag om een reactie uit.

[GuiltyNL]

Zou goed kunnen, maar dan zie je meteen hoeveel meer geld er in dat soort projecten worden gepompt, de projecten die ik hier aanhaal, lopen dus parallel aan het mislukte project.

[Cebby]

Ik kwam de naam Blueriq tegen onder 'Beheer & Onderhoud' van het eerste project.
https://www.rijksictdashb...n/260544/beheer-onderhoud.

Dat lijkt overigens ook niet alleen de naam van dat bedrijf te zijn maar ook van software die ze maken, als je het in Google icm CGI kom je minimaal één 'Blueriq Business Engineer' op LinkedIn tegen.

[Reactie gewijzigd door Cebby op 23 juli 2024 04:28]

[Killjoy]

Het is inderdaad gebaseerd op Blueriq.

[flowerp]

Je komt verder nog deze vacature tegen van bedrijf LINKIT uit Utrecht:

De senior Blueriq Modelleur is lid één van de agile Scrum teams in de Maakplaats. De senior Blueriq modelleur is verantwoordelijk voor het realiseren de features en user-stories op basis van Blueriq in het systeem Inspect. Het is daarbij belangrijk dat er functionaliteit gerealiseerd wordt die onderhoudbaar, toekomstvast, veilig, performant, generiek en van voldoende kwaliteit. Van de senior Blueriq modelleur wordt verwacht dat hij het Blueriq versie/releasemanagement, test en ontwerp activiteiten uitvoert en zijn teamleden die minder ervaring hebben coacht.

[Shmorky]

Heb ook ooit met BlueRiq gewerkt. Ondanks dat dat soort "sleur en pleur"-pakketten voor mij als developer toch al vreselijk zijn, vond ik het ook gewoon een enorm slecht product voor in IT-ontwikkel omgeving. Een paar van de pijnpunten:
- Nauwelijks technische documentatie
- Losse installaties op dev-machines onmogelijk zonder een of andere licentie
- Geen noemenswaardige ondersteuning van BlueRiq
- Consultants van BlueRiq zelf hadden net zo goed bij de McDonalds kunnen werken - zoveel wisten ze van het product
- De engine vormt voor html id-tags een string gebaseerd op de modellen. Dat betekent dat als je een model wijzigt, alle html-id's wijzigen. Echt superleuk als je geautomatiseerde tests wil bouwen.

Dat project is ook faliekant mislukt trouwens. En BlueRiq stond zeker in de top 3 van redenen daartoe.

[Henk-Bakker]

Als IT manager in het bedrijfsleven sinds 20 jaar......: "WTF, hoe is dit toch telkens mogelijk???".

[FreezeXJ]

Dan zit je niet hoog genoeg in de boom, anders had je al begrepen dat dit weinig met de aanwezige IT te maken heeft en alles met besluitvorming door mensen zonder verstand van inhoudelijke zaken. Degene die hier een knoop moet doorhakken weet alleen wat z'n mensen hem vertellen, en dat zijn externe adviseurs, of mensen die met 20 jaar jaknikken en voorzichtig zijn alle reorganisaties hebben overleefd. I mean, waarom werk jij niet voor de overheid? Daarom dus...

[wimdebok]

Ik denk dat je daar een waar punt hebt en dat is ook mijn ervaring, maar ook de evaring van IT mensen om me heen. Hoe die beslissingen tot stand komen daar begint het al, de beslissing wordt op hoog niveau genomen met alle consultants en adviseurs erom heen en dan zijn niet altijd de beste beslissingen. Ik heb nog nooit gezien dat ze aan technisch uitvoerende mensen vragen: goh, wat vind jij er nou van? Zou echt helpen!

Er speelt meer mee, waar een hoop geld te verdelen is daar gelden andere wetten. Dan moet er uren en jaren gemaakt worden. En, dat is ook wat mijn ervaring, de grote alles is anders show. Bij dit project ook, niets deugt alles moet anders terwijl de kritiek ook is, had het niet handiger geweest uit te gaan van bestaande functionerende systemen?

Het is mensenwerk en misschien wel goed om er een punt aan te draaien en het nog een keer te proberen. Komt dit alleen bij de overheid voor? Nee, dat is niet mijn ervaring, ook bij grote organisatie waar het geld over de plinten heenklotst. Dure consultants, uitbesteden, verkeerde en oliedomme beslissingen. Ook daar.

Wel jammer dat kwaliteit van de oplossing niet meer relevant lijkt. Het gaat om geld en posities.

[Henk-Bakker]

Hilarisch antwoord. Geen probleem, je kent me niet.

Ik snap wat je zegt. Dat stukje realiseer ik me ook wel en maak ik aan den lijve mee. Alleen in mijn projecten keer ik dat tij. Verkeerde beslissers, extern advies, halfbakken consultants. Waarom gebeurt dat hier niet? Ook in dit soort projecten weet je toch hoe het werkt met al die lui die alleen een boterham willen verdienen en niet gaan voor de uitkomst van het project? Dat volk zie je al van mijlen ver aankomen... Toch? Dat is mijn vraag eigenlijk.

[Chinco]

Ook al ruim 20 jaar IT-er waarvan de helft ook IT-manager: amen to that!

[Mrjraider]

Kan iemand mij in Jip en Janneke taal uitleggen hoe het kan dat bij de (Nederlandse)overheid het keer op keer mis gaat met zulke projecten? Er worden letterlijk miljoenen in een put gepompt heb ik het idee.

[DigitalExorcist]

Vriendjespolitiek. Het aanbestedingsbeleid. Een IT-bedrijf wil perse de aanbesteding winnen dus gaan ze dik onder de daadwerkelijke kosten bluffen. Zodra ze het project binnengesleept hebben begint de teller alvast te lopen, bergen consultants worden erop gezet terwijl dat niet nodig is, maar omdat er dealtjes in de politiek gesloten worden met bevriende eigenaren van die bedrijven blijft het zo.

En de eisen van de klant (NVWA in dit geval, maar ook Belastingdienst en UWV bijvoorbeeld) veranderen zo vaak tijdens het project dat ook een IT-ontwikkelaar die wél zijn best doet daar niet altijd op in kan springen voor dezelfde kosten als wat het eerst had moeten worden. "Ineens" blijken er extra eisen en regelgeving te zijn waar rekening mee gehouden moet worden..

En dan heb je na jaren ontwikkeling alles klaar.....

.... en dan besluit Brussel ineens de winter- of zomertijd af te schaffen. Of er komen nieuwe belastingregels. En daar gáát je maatwerk weer.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 04:28]

[sys64738]

Ja natuurlijk veranderen de wensen en eisen gaandeweg. Waarom snappen mensen (zowel opdrachtgever als nemer) nou nog steeds niet dat je geen 5 jaar in de toekomst kunt kijken?

Niemand kan bij zo'n groot project het totaalbeeld overzien en alle wensen en eisen opnoemen zonder ook maar iet te vergeten. Zelfs al zou er in de wereld niets veranderen is dat al een onmogelijke opgave. Maar uiteraard veranderd de wereld om je heen ook als je ergens jaren over doet.

Dus gewoon kleinere projecten die wel behapbaar zijn. Waarom pas na 60 miljoen euro ergens de stekker uit trekken?!? Voor een miljoen euro kun je makkelijk een systeem in productie hebben dat al daadwerkelijk meerwaarde oplevert en het leven van de toezichthouders en keurders een stuk makkelijker had gemaakt. En voor zulke kleine projecten hoef je ook niet zo'n megalomaan aanbestedingstraject op te tuigen en kun je prima door kleinere partijen laten uitvoeren.

Ik hoop dat mijn bij de overheid ooit het licht gaat zien maar het is al zo vaak fout gegaan dat ik bang ben dat dit nooit gaat gebeuren.

En nog een groot probleem bij de overheid is dat heel heel veel betrokkenen iets te zeggen hebben over projecten. Dus je heb geen schip met 2 kapiteins maar eentje met een stuk of 30. Daardoor drijft zo'n project doelloos rond en gebeurt er niets. Heb 1 keer zelf deel uitgemaakt van zo'n project en ik werd gillend gek. Heb meerdere malen gevraagd/"gesmeekt" of we nu eindelijk eens iets mochten gaan bouwen.

[Reactie gewijzigd door sys64738 op 23 juli 2024 04:28]

[Dafader]

Je zou bijna kunnen zeggen dat de dealtjes niet gesloten maar gestolen worden.

[DigitalExorcist]

Deals worden gesloten op de golfbaan, niet op kantoren..

[MSalters]

Ik zou niet altijd vriendjespolitiek de schult geven.

Ik heb uit eigen ervaring in de overheid gezien dat IT onder "Interne Diensten" viel, net zoals de kantine. En promotie gebeurde op senioriteit. Daarom was de kantinebaas met 30 jaar ervaring gepromoveerd tot hoofd Interne Diensten, en was hij opeens ook verwantwoordelijk voor ICT. En alhoewel hij misschien nog kon beoordelen wat goede kaaskroketten waren, moest hij nu ook beslissen over de inhuur van ICt'ers. Dat werkte dus niet geweldig.

[Transportman]

Binnen het bedrijfsleven gaat het ook zo hoor, alleen blijft dat allemaal binnenskamers.

[Mrjraider]

En wij maar blijven betalen. Belachelijk eigenlijk

[krosis]

Mwahja, ik heb het consistente falen niet meegemaakt - mocht dat gebeuren gaan er koppen rollen. Granted, grootste bedrijf waar ik bij gewerkt heb was ~150 medewerkers.

[kikker81]

Grote onzin, geen bedrijf kan met zoiets wegkomen, ja misschien één keer, maar dan ben je failliet en doe je dus niks meer.
Het grote probleem bij de overheid is dat wij ze het geld met bakken naar binnen smijten waardoor ze hier mee weg komen.
Bedrijven zouden ook de verantwoordelijken ontslaan, dat doen ze bij ambtenaren niet, die mogen, wat er ook gebeurt, altijd blijven zitten.
Heb zelf meerdere malen als ICT'er bij projecten voor de overheid gewerkt, alles behalve het geld is gewoon van ontzettend lage kwaliteit.

[Sandor_Clegane]

Zie Lidl. Kan prima hoor, alleen een bedrijf is een stuk minder transparant hierover.

[FreezeXJ]

Omdat het verkrijgen van een aanbesteding een gigantische klus is, maar het verkrijgen van meer budget voor een bestaande aanbesteding een stuk simpeler. Daarom wordt er op de aanbesteding zelf onderboden, waarna ongeveer alles opeens 'meerwerk' wordt, dat tegen flinke meerkosten alsnog doorgefactureerd wordt. Er stond namelijk niet in de specificaties dat gebruikers ook een scherm met een knopje voor hun neus moesten krijgen, dus tja, helaas. Bijbetalen dan maar.

En cancellen, zoals hier nu wel gebeurd is, gebeurt maar zelden op tijd, want dan heb je helemaal niks. Ook nu is er dus al 50 miljoen van de originele 36 miljoen het circuit in gesluisd, en hoeft er daarvoor niks te werken, en maakt het dus niet uit of dat redelijk besteed is. De deal is al kaputt, en ongeacht of daarvoor 500 developers goede code hebben geklopt, of 10 managers een werkreisje naar een warm land geregeld hebben (met bijbehorende golf-training en gratis pina coladas), de centen zijn besteed. Ik wil even niet weten waaraan.

[Mrjraider]

Samengevat: meebieden op een “deal” terwijl je weet dat het gigantisch mislukt en vervolgens wel geld innen maar niks afleveren. Dit riekt naar corruptie maar dat mag je niet zeggen.

[SuBBaSS]

Dat mag je best zeggen hoor, maar of er ooit betrokkenen voor gestraft gaan worden?
Die gewiekste dienstverleners weten heel goed dat het geld bij de overheid te halen is.

Dan over dit artikel: wat me nou precies interessant lijkt voor de doelgroep is om iets te lezen over wat er mis ging? Daarover niets in het hele artikel.

_{Nou ja, maar even in de bron gedoken.}
Ook daarin wordt niet specifiek besproken wat er precies fout ging, behalve dat de 'beheerslasten' uit de klauwen zouden gaan lopen.
Nou is 'grappig' hieraan, dat minister Schouten in de brief rept dat juist dat deel dat al wel van Inspekt gebruik maakt, dat zal blijven doen.
De ontwikkeling ervan wordt gestopt, maar toch blijft een deel in gebruik.
Nu gaan ze een 'bezinningsperiode' in, maar we gaan hier (net zoals over zovele andere ict projecten van de overheid) wel weer over horen.
En ik vrees toch weer op dezelfde manier. De overheid heeft toch weer de externe partijen nodig, aka. datzelfde circus krijgen ze allemaal opnieuw. Met allicht een gewiekste dienstverlener die in de toekomst aangeeft niets met Inspekt te kunnen om het alsnog helemaal te droppen.
Money well spent (ahem).
Hadden ze de kennis zelf maar in huis (wat weer een heel andere discussie is).

[erikdenv]

Het gaat ook heel vaak goed maar dat niet nieuwswaardig.

[testaankoop]

Ik heb het idee dat ICT bedrijven al deze software CTO maakt en dat de overheid te vast zit in een denkpatroon om kant en klaar van de plank te kopen. En dan heb ik het idee dat dit vooral in Nederland speelt.

Géén vaste consultants in dienst door 15 jaar aan zware bezuinigingen, kennis is reeds weggevloeid naar bedrijven die mee doen aan de aanbestedingen en wordt gretig gebruikt.

De overheid is een gemakkelijke prooi en in tenders beloven bedrijven gouden bergen voor de basis maar elk bijkomend element gaat tot wel 5000x over de kop.

[FreezeXJ]

De overheid kan natuurlijk niet anders dan Oracle databases, een mooie IBM middle layer en een peperdure prefab WebSphere container gebruiken, want die zijn gecertificeerd^tm, en worden warm aanbevolen door de grote software-boeren, die er een leuke korting op krijgen. Vendor Lock-in is populair genoeg, en de overheid werkt er graag aan mee. Goedkope oplossingen zijn niet gecertificeerd^tm, en kunnen dus helaas niet meedoen met aanbestedingen. Verder kunnen zij niet het gehele pakket aan gewenste diensten leveren, dus ook daarom vallen de betere opties af. Mocht er dan toch 1 doorheen glippen, dan is een dealtje op de golfbaan genoeg om die laatste goeie optie snel te laten afvallen, want toch net even duurder dan de afgesproken prijs van een grote jongen...

[erikdenv]

Veel gespeculeer maar geen bewijs. Ook de overheid werkt met Linux / Docker / Tomcat / Postgresql.
Men is echt niet dom maar de overheid zoekt wel garanties bij de leveranciers.

Als overheid doe je het toch nooit goed voor sommigen. Dat scheelt ook weer. Aan die notoire zeikerd hoef je je dan niet meer te storen.

[FreezeXJ]

De stukken overheid waar ik mee gewerkt heb hechten helaas nogal aan de grote namen... en nee, ik ga geen namen noemen (sorry, privacy enzo), maar helaas heb ik de genoemde stack al een paar keer in werking gezien... (overigens in alle gevallen met Linux, het gehalte Windows-servers is nog altijd nihil, en ook IBM's eigen mainframe platform verliest langzaam terrein)

Nee, de overheid zal het zelden perfect doen, dat verwacht ik ook niet. Echter kosten ze ons allemaal geld, dus ik zou wel verwachten dat ze met kostenbesparingen en tactisch inkopen voorop lopen.

[erikdenv]

Bij mijn vorige werkgever (rijksoverheid) ging het zoals jij schetst. Veel IBM en heel conservatief. Bij mijn huidige werkgever (ZBO) gaat het zoals ik schets. Ik ken beide kanten.

[FreezeXJ]

Mooi, en het zal ook best goed kunnen, maar daar horen we (te) weinig van. De grote blunders halen het nieuws, zoals ook hier weer.

[CAPSLOCK2000]

Ik heb het idee dat ICT bedrijven al deze software CTO maakt en dat de overheid te vast zit in een denkpatroon om kant en klaar van de plank te kopen. En dan heb ik het idee dat dit vooral in Nederland speelt.

Ergens hoop ik het, dan is er nog hoop
Ik denk eigenlijk dat andere landen (en bedrijven) het niet veel beter doet, maar dat we door de Nederlandse transparantie beter op de hoogte zijn van wat er mis gaat bij de overheid. Een hoop ministers en CEO's zouden dit soort nieuws liever verbergen.

Zonder dat soort cijfers echt met andere landen en organisaties te kunnen vergelijken is het erg moeilijk om te zeggen of we het hier nu goed of slecht doen. Een mislukking van tientallen miljoenen klinkt als enorm, maar de overheid werkt nu eenmaal met gigantische budgetten. De kleinste mislukking is dan al snel een dure grap.

Géén vaste consultants in dienst door 15 jaar aan zware bezuinigingen, kennis is reeds weggevloeid naar bedrijven die mee doen aan de aanbestedingen en wordt gretig gebruikt.

Dat is een groot probleem. Modern personeelsmanagement gaat er van uit dat iedereen vervangbaar is en alle kennis zo van de markt gehaald kan worden. Daarbij staat de overheid extra op achterstand omdat de salarissen lager zijn dan wat de markt kan bieden.

[BasSchouten]

Ik vraag me altijd af hoeveel mensen aan dit soort projecten werken, of dat dit soort dingen gewoon een heleboel lagen overhead overal en nergens tussen hebben zitten. Zelfs als je developers pak hem beet 150k per jaar gemiddeld verdienen, laten we zeggen x2 kosten, dus 300k per jaar. Dan kun je een jaar lang 70 developers aan het werk hebben voor 21 miljoen.. En dan heb je nog een dikke 10 miljoen over voor documentatie. Wat moet dat systeem allemaal wel niet kunnen dat het daarvan niet lukt?

Ik ga ervan uit dat er nog allerlei validatiestappen en dergelijke zijn die dan mee begroot worden, ik ben zeker geen expert op het gebied van dit soort grote aanbestedingen, maar het lijkt mij toch dat bij dit soort bedragen je beter zelf 20 fatsoenlijke developers in-house in dienst kan nemen en daarmee iets in elkaar kan zetten.

[SuperDre]

150k per jaar? waar kan ik dat als developer verdienen? Denk zelfs dat dat nog niet eens de kosten zijn voor 1 developer inclusief werkplek, zeker niet bij dit soort bedrijven.
Maar je stelling klopt wel hoor, ik vraag me ook af waar al dat geld daadwerkelijk naar toe gaat. Een paar designers, een zwik developers, een zwik testers en een paar managers..
Wel zal er een deel van het budget ook op gaan aan hardware, maar ook dat hoeft geen tientallen miljoenen euro's te kosten.

[R4gnax]

ik vraag me ook af waar al dat geld daadwerkelijk naar toe gaat.

Een flink deel aan Oracle licenties, wss.

[Cerulean]

De overheid heeft al het onderhoud, opzetten techniek, servers etc uitbesteed aan weer een andere partij. Groot deel van het budget is dus al weg voordat er een regel gecodeerd is. Systeem wordt ontwikkeld in Blueriq overigens, niet Oracle. Maar als database zal dat ook wel ergens in het project zitten.

[Reactie gewijzigd door Cerulean op 23 juli 2024 04:28]

[CAPSLOCK2000]

Zelfs als je developers pak hem beet 150k per jaar gemiddeld verdienen, laten we zeggen x2 kosten, dus 300k per jaar.
<knip>
maar het lijkt mij toch dat bij dit soort bedragen je beter zelf 20 fatsoenlijke developers in-house in dienst kan nemen en daarmee iets in elkaar kan zetten.

Je beantwoord eigenlijk je eigen vraag. Bij de overheid liggen de salarissen vast en zijn een stuk lager dan wat de markt kan bieden. Je hebt vast wel eens van de Balkenendenorm gehoord. Dat is de regel dat niemand bij de overheid meer dan 130% van een ministersalaris mogen verdienen. Daarmee zou je die 150k misschien net halen halen, maar in praktijk zijn dat soort salarissen niet voor het gewone personeel.

[MSalters]

Dat is niet helemaal waar; de Balkenende norm geldt voor de management laag (primair de Algemene Bestuursdienst). Specialisten kunnen daar van afwijken.

[computerjunky]

Het word tijd dat de overheid zijn ict pas gaat betalen na geleverde service voor het afgesproken bedrag. Sit haalt het risico in zijn geheel weg dat ststemen te duur worden en sat de begroting niet klopt wat 99% van de tijd het gaval is bij de overheid.

Zeg gewoon wij willen dit systeem en betalen daar x voor bij aflevering bied maar raak als je dit op wil zetten.

[Polydeukes]

Projecten zijn vaak zo veelomvattend en groot, dat geen enkel bedrijf dat risico neemt. Je gaat niet vijf jaar tijd en capaciteit investeren in een systeem met het risico dat de klant zegt: "voldoet niet, we betalen niet".

En dat is in mijn ogen ook het probleem. De overheid wil vaak 1 oplossing voor een megaprobleem. In plaats van in kleine behapbare stapjes langzaam richting de oplossing. Dus dan moet je alle requirements definiëren voor iets wat je over 5 jaar wil hebben. Dat lukt nooit, want de wereld verandert sneller dan je kunt voorspellen.
Ergo: je krijgt te laat wat je 5 jaar geleden nodig had. En dat voldoet niet. Dus wordt het duurder...
Nog even los van alle politieke spelletjes en incompetentie die ook een rol spelen.

[computerjunky]

Als er dus geen bedrijven gaan investeren en het uit willen voeren dan is of je bod te laag of het bedrijf niet capabel genoeg of je wensen/budget ontoereikend of onhaalbaar.
Dan zal je dus als overheid opnieuw moeten kijken naar een nieuw plan of nieuw budget (dus niet zoals de politiek geregeld dien hetzelfe opdienen via een andere weg) en dan nogmaals kijken of er dan wel interesse is.
Is er dan nog geen interesse dan moet je om de tafel gaan en overleggen wat het echte probleem is.

Waar een wil is is een weg maar de overheid is wat dat betreft net een 4 jarige kleuter.

Ik wil die
ik wil dat
ik wil nu
mamma zegt nee dan vragen we het aan pappa.
pappa zegt ook niet OMA?
En stampvoeten zonder oplossing als het nog niet lukt.

[Polydeukes]

Als er dus geen bedrijven gaan investeren en het uit willen voeren dan is of je bod te laag of het bedrijf niet capabel genoeg of je wensen/budget ontoereikend of onhaalbaar.

Dat lijkt me wel erg kort door de bocht. Zowel de overheid als de bekende IT-bedrijven zitten niet te wachten op dit soort debacles. Niemand wil geld verbranden en niemand wil een slechte reputatie opbouwen.

Wat mij betreft moeten de regels voor IT aanbestedingen (voor de overheid) gewoon drastisch anders om dit soort megalomane projecten te voorkomen voordat ze mislukken. Overigens makkelijker gezegd dan gedaan.

[Jeroenneman]

Alleen gaat dan niemand meer op zo'n aanbesteding in.

Of de prijzen worden in den beginne al tig maal hoger.

[Simon Weel]

Volgens mij heeft jaren geleden in Vrij Nederland gestaan waarom ICT projecten van de overheid zo vaak mislukken. Meestal omdat de overheid geen goed bestek heeft gemaakt. Of domweg teveel wil. De CapGemini's / Ordina's etc. vinden dat best - de meter loopt en de klant bepaald, toch?

Dat is ook de reden geweest dat Rijkswaterstaat het over een andere boeg heeft gegooid met grote projecten. Design-Build-Construct-Maintain is tegenwoordig een veel gebruikte methode. 'We willen een brug van hier naar daar, met 10 rijbanen. Doe maar een prijsopgave.'. Het hele traject voor risico van de aannemer. En dus gaan nu de Heijmansen, BAM's, Koop en andere grote infra-bouwers regelmatig nat met die grote projecten. Tsja, als je jarenlang zonder problemen de portemonnee van je opdrachtgever kan plunderen, dan moet je niet mekken als na de 7 vette jaren de 7 magere jaren zich aandienen.

[sjoerdmekenkam]

ik ken dit soort contracten, maar ook die zijn niet heilig. Stel je hebt een all-in-prijs voor 10 jaar (dus incl. ondehoud). Dan sta je met lege handen als op dag 10j+1 de constructie instort. Lekker gechargeerd, maar elke contractvorm heeft z'n achilles.

Wat echt werkt is intern de kennis opbouwen en mensen met diepe verstand van zaken de plannen laten beoordelen. Een klein gespecialiseerd team werkt in dat geval veel beter dan meer mankracht er tegenaan zetten

[MSalters]

Klopt, maar welke bouwer gaat het risico nemen dat de constructie na 10j-1 instort? Dan kunnen ze't hele zwikkie alsnog herstellen op eigen kosten.

Realistischer is dat de bouwers niet de moeite doen om glasvezel in de bewapening mee te storten. Dat is de aankomende 25 jaar nog niet nodig, het beton is ruim goed genoeg. Maar over 40 jaar is het érg handig om te kijken of de wapening gescheurd is. DBCM, dus de Rijksoverheid gaat er niet over.

[Anoniem: 42763]

Design Build Finance & Maintain. Financiering zie erbij in, Combinatie financiert het project, tijdens de onderhoudsfase wordt dan het project terug verdient een uiteindelijk de vooraf bepaalde winst behaald. Vaak wordt hierna nog 10 jaar garantie verlangd.

[FuZZbaLL]

Agile en scrum hadden dit soort problemen op moeten lossen. Niet alles in één megalomaan project op proberen te lossen en aan het eind er achter komen dat het niet werkt. Helaas lijkt wel ieder bedrijf te zeggen dat ze deze methodiek toepassen, maar in de praktijk blijkt dat niet het geval.

[CEx]

De randvoorwaarden die dit vereist zijn gewoon niet voldoende aanwezig bij de overheid. Een product owner is daar hooguit een rolnaam. Niet de daadwerkelijke eigenaar, laat staan de beslisser. Dan het agile probleem wat ontstaat wanneer men denkt dat er niet onder echte architectuur gebouwd moet worden: allemaal opgeleverde puisten in het systeemlandschap omdat PO x niet met PO y samen wilde nadenken over ketenoverschrijdende vraagstukken.

Nee ook Agile werken is geen garantie tot succes. Zeker niet met dergelijke partijen waar het eigen belang belangrijker is dan de klant en "multi disciplinair" eng is want dat past niet in de uitgestippelde loopbanen.

[MadEgg]

Agile helpt hier niet, want dat wordt als argument gebruikt om elke dag het plan volledig om te gooien want "jullie werken toch agile?".

[MSalters]

Agile? Dat betekent dat je in sprints werkt. De volgende sprint mag je omgooien. Mits je uiteraard een uitgewerkte lijst met nieuwe taken hebt. Taken die onvoldoende gedefinieerd zijn schop je in schatting&planning gewoon door naar de volgende sprint.

En dat is de vriendelijke methode. Je kunt ook gewoon issues closen als ze te vaag zijn. "Not salvageable".

[MadEgg]

Zo werkt dat als je een agile team hebt wat goed samenwerkt. Als je als consultant op locatie zit gaat dat net even anders. Wie betaalt, bepaalt. Je kunt best weglopen, natuurlijk. Maar dat verandert de houding niet.