Een PersoonsGebonden Budget (PGB) is beschikbaar voor mensen die door ziekte, handicap of ouderdom bijvoorbeeld hulp in de huishouding nodig hebben. Andere vormen van zorg waarvoor een PGB beschikbaar gesteld kan worden zijn jeugdhulp, langdurige zorg en verpleging/verzorging.

 

De budgethouder (‘zorgvrager’) kiest zelf de zorgverlener(s) door wie zij of hij geholpen wilt worden. Sinds 1 januari 2015 betaalt de Sociale Verzekeringsbank (SVB) de zorgverlener, in plaats van dat de betaling via de budgethouder loopt; dit laatste bleek fraudegevoelig te zijn. De gevolgen van deze wijziging van de manier van betalen was onder andere dat de zorgvragers het nieuwe systeem niet begrepen en dat de zorgverleners niet betaald kregen. 

 

De staatssecretaris beloofde beterschap, onder andere door een betere website te laten ontwikkelen. Toen deze niet van de grond kwam bood zorgverzekeraar DSW aan om deze website te ontwikkelen. Het ontwerp was klaar in september 2016. Door allerlei complicaties was de website eind september 2017 nog niet operationeel. 

 

Deze complicaties over opdrachtgever-/opdrachtnemerschap en IT-ontwikkelmethodiek kunnen een eventuele volgende keer voorkomen worden met DirectIT projectmanagement-principes:

• Benoem formeel één opdrachtgever en één opdrachtnemer
• Opdrachtgever en opdrachtgever kiezen bij aanvang expliciet een IT-ontwikkelmethodiek.

Hieronder vind u een analyse van achterliggende complicaties en een uitleg van de DirectIT oplossingen.

 

Analyse van complicaties

 

Geen expliciete opdrachtgever/opdrachtnemer

Dit project kent veel belanghebbenden, in willekeurige volgorde:

• PerSaldo, belangenvereniging budgethouders (zorgvragers)
• DSW, zorgverzekeraar in de hoedanigheid van IT-ontwikkelaar website
• Zorgverzekeraars, financiers van de website
• Ministerie van Volksgezondheid, via de staatssecretaris
• VNG, Vereniging Nederlandse Gemeenten, namens de gemeenten
• SVB, Sociale VerzekeringsBank.

Dit hoeft op zich geen probleem te zijn, maar het is wel een probleem dat niet expliciet bekend is wie van deze belanghebbenden de formele opdrachtgever is. DSW zou je als opdrachtnemer kunnen zien als IT-ontwikkelaar, echter DSW heeft ook een belang als één van de zorgverzekeraars.

 

Geen consensus over zorgvuldigheid versus planning

Een project moet zorgvuldig uitgevoerd worden, dat is evident. Maar dit hoeft geen excuus te zijn voor het niet halen van een planning. Een planning is gebaseerd op aannames en als die aannames anders uitpakken dan kan dat gevolgen hebben voor de planning. Maar als die aannames niet expliciet zijn, dan ziet de een het niet halen van een planning door een veranderende aanname als geen probleem, maar een ander wel. Toegepast: DSW ontwikkelt met een ontwerp van de website dat afgerond is in september 2016. SVB en de gemeenten melden op 10 mei 2017 met 325 punten. DSW ziet die punten als nieuwe eisen, VNG als een nadere invulling van bestaande eisen. Het ministerie en de SVB propageren zorgvuldigheid. De financiële consequenties van deze 325 punten zijn onvermeld.

 

Oplossingen

 

Formeel één opdrachtgever en één opdrachtnemer

Benoem formeel één opdrachtgever en één opdrachtnemer.

 

Het feit dat dit project vele belanghebbenden kent, is een gegeven; daar valt weinig aan te doen. Waar wel wat aan te doen is, is het benoemen van precies één formele opdrachtgever en precies één formele opdrachtnemer, waarbij de opdrachtgever verantwoordelijk is voor de financiering en beiden voor het binnen budget blijven.

 

Deze ene opdrachtgever is de vertegenwoordiger van alle belanghebbenden. Het is aan de opdrachtgever hóe hij dit organiseert. Idealiter worden alle projectbeslissingen genomen in goed overleg met alle belanghebbenden, maar ervaring leert dat er zich kwesties voordoen waarover er geen consensus gevonden kan worden. Het hebben van één opdrachtgever bewijst in dit soort situaties haar nut, doordat de formele opdrachtgever dan de knoop doorhakt. Aan de andere kant luistert de opdrachtnemer zo mogelijk naar alle belanghebbenden, maar als het er op aan komt hoeft hij alleen naar de (beslissing van de) opdrachtgever te luisteren.

 

Expliciete keuze IT-ontwikkelmethode

Opdrachtgever en opdrachtgever kiezen bij aanvang expliciet een IT-ontwikkelmethodiek.

 

Grofweg bestaan er twee ontwikkelmethodieken, ‘waterval’ en ‘iteratief’ (moderne benamingen voor de laatste zijn ‘Scrum’ en ‘Agile’). Voor beiden valt wat te zeggen, zelfs voor een expliciete mix ervan. Maar het is wel cruciaal dat de opdrachtgever en de opdrachtnemer er vanaf het begin eens zijn over welke methodiek gekozen wordt; niet in de minste plaats om financiële discussies te voorkomen. Immers, de waterval-methodiek probeert wijzigingen te voorkomen, de iteratieve methodiek is juist gegrondvest op wijzigingen.

 

De waterval-methodiek kenmerkt zich door eerst volledig te specificeren wat de specificaties van de – in dit geval – de website zijn. Zodra die klaar zijn gaat de IT-ontwikkelaar de website volgens die specificaties bouwen. Iteratief ontwikkelen kenmerkt zich door een begin te maken van wat de website moet kunnen. Vervolgens bouwt de IT-ontwikkelaar op basis van dit begin een eerste versie van de website en bekijkt de opdrachtgever wat er anders moet en wat de website nog meer zou moeten kunnen. Dit resulteert in versie twee, wijzigingen/aanvullingen benoemen, versie drie etc. 

  

Bron: NRC Handelsblad 30 september 2017