Overzicht toetsaspecten risicogebieden

Businesscase, baten en financiering

Businesscase en baten

  1. Er is een duidelijke aanleiding, probleemstelling en doelstelling voor het project.
    Er is een duidelijke aanleiding, probleemstelling en doelstelling voor het project.
    Deze onderwerpen zijn helder, beknopt en eenduidig geformuleerd, zodat voor alle (interne en externe) betrokkenen duidelijk is wat het belang van het project is.
     
  2. De businesscase onderbouwt de meerwaarde voor de organisatie, eindgebruiker, burger en maatschappij.
    De verwachte kosten en baten zijn onderbouwd en tegen elkaar afgewogen. De businesscase maakt onderscheid in baten voor de eindgebruikers/burgers, de organisatie en de maatschappij.
     
  3. Kwantitatieve baten zijn vertaald in financiële termen.
    Baten kunnen kwalitatief en kwantitatief van aard zijn. Tenminste kwantitatieve baten zijn vertaald naar financiële consequenties.
     
  4. Kwalitatieve baten zijn zodanig gespecificeerd dat ze achteraf te verifiëren zijn.
    Ook baten die niet gekwantificeerd kunnen worden, moeten zoveel mogelijk meetbaar worden gemaakt.
     
  5. Het is duidelijk wie verantwoordelijk is/zijn om de baten van het project te realiseren.
    De verantwoordelijke persoon of rol binnen de organisatie heeft een duidelijk (intern of extern) belang bij het behalen van de baten, zodat deze intrinsiek gemotiveerd is het project tot een succes te maken. De realisatie van de baten is bijvoorbeeld vastgelegd in managementafspraken. Het is daarbij duidelijk wanneer baten gerealiseerd worden.
     
  6. De verantwoordelijke(n) heeft/hebben sturingsmogelijkheden om de baten te realiseren.
    Indien voor de realisatie medewerking van andere partijen nodig is, dan is medewerking van deze partijen verzekerd of is ten minste draagvlak bij deze partijen aangetoond.
     
  7. Scenario’s met alternatieve oplossingen zijn opgesteld, onderbouwd en afgewogen.
    De voor- en nadelen van verschillende scenario’s, inclusief een ‘nul-scenario’, zijn onderbouwd en afgewogen. Ook bij het vervangen van een bestaande applicatie zijn verschillende alternatieve oplossingsrichtingen afgewogen, inclusief renovatie en gedeeltelijke vervanging. Bij de beoordeling van alternatieven wordt onder meer gebruik gemaakt van de kostenhistorie van bestaande applicaties.
     
  8. Impact van de oplossing op uitvoeringsorganisaties, burgers en bedrijven zijn onderzocht.
    Uitvoeringsorganisaties hebben de uitvoerbaarheid van de gekozen oplossingsrichting onderzocht, inclusief de impact op burgers en bedrijven. Impact van algoritmes en automatische besluitvorming op burgers en bedrijven zijn onderzocht op bijvoorbeeld transparantie, controleerbaarheid en representativiteit.
     
  9. De businesscase is actueel en wordt gebruikt bij besluitvormingsprocessen.
    De kosten, baten en voortgang worden minimaal na elke fase of significante wijzigingen van het project geactualiseerd. Verschillen ten opzichte van de oorspronkelijke versie van de businesscase worden verklaard. De actuele businesscase wordt als instrument gebruikt bij besluitvorming.
     
  10. In de businesscase is aantoonbaar rekening gehouden met toepasselijke wet- en regelgeving.
    In de businesscase is opgenomen welke wet- en regelgeving van toepassing zijn en op welke wijze naleving is geborgd.

Financiering

  1. Er is financiële dekking voor de looptijd van het project en de beheerfase.
    Projecten worden alleen geïnitieerd indien de opdrachtgever daarvoor in de benodigde middelen voor de gehele levenscyclus kan voorzien.
     
  2. Voor wijzigingen gedurende de looptijd van het project is voldoende financiële ruimte.
    Geen nadere toelichting opgenomen.

Opdrachtgever en projectorganisatie

Opdrachtgever

  1. De opdrachtgever is verantwoordelijk voor het budget en de businesscase.
    De opdrachtgever is verantwoordelijk en heeft het mandaat binnen de grenzen van de businesscase. De opdrachtgever is en voelt zich verantwoordelijk en draagt de visie uit naar zijn of haar stakeholders.
     
  2. De opdrachtgever is inhoudelijk betrokken bij bepalende keuzes.
    De opdrachtgever is inhoudelijk betrokken bij keuzes die bepalende impact hebben op de visie, doelstelling, financiën, scope, risico’s, planning en kwaliteit.
     
  3. De opdrachtgever is verantwoordelijk voor de consequenties van bepalende wijzigingen in het project.
    De opdrachtgever beschikt over voldoende deskundigheid en overziet de impact van bepalende wijzigingen in het project.
     
  4. De opdrachtgever is inhoudelijk op de hoogte van de voortgang van het project.
    De opdrachtgever is op de hoogte van de voortgang in termen van onder andere projectresultaten, kwaliteit, kosten, risico’s en planning.

Organisatie

  1. De rollen, taken, verantwoordelijkheden en bevoegdheden in de projectorganisatie zijn vastgelegd en ingevuld.
    Het is voor belanghebbenden bij het project duidelijk welke bijdrage van hen wordt verwacht en wat hun mandaat is.
     
  2. De projectorganisatie bestaat uit mensen met voldoende kennis en ervaring.
    Leden op sleutelposities hebben aantoonbare ervaring met projecten van vergelijkbare omvang en complexiteit binnen een vergelijkbaar domein en vergelijkbare veranderingsopgave en technologie.
     
  3. De organisatiecultuur bevordert open communicatie en samenwerking.
    Open communicatie en een effectieve samenwerking binnen het project en met belanghebbenden zijn essentieel om onder meer tijdig te kunnen bijsturen.
     
  4. Er is aantoonbaar en structureel ruimte voor ‘tegendenken’ en een kritische blik.
    Er is voorzien in een frisse blik van buiten het project. Ook is binnen het project voldoende ruimte voor discussie en tegenspraak.
     
  5. De kwaliteitsborging in het project is ingeregeld.
    Afspraken over de kwaliteit zijn vertaald in concrete standaarden, procedures en maatregelen. De invulling en resultaten van de kwaliteitsborging zijn zichtbaar voor de opdrachtgever.
     
  6. Interne en externe toetsmomenten op relevante mijlpalen en producten zijn bepaald.
    In de planning wordt rekening gehouden met logische momenten waarop resultaat kan worden gemeten en kan worden bijgestuurd.

Risicobeheersing en projectafhankelijkheden

Risicobeheersing

  1. Het project heeft risicobeheersing verankerd.
    Het project heeft structureel oog voor risico’s. Dit kunnen risico’s zijn op zowel politiek, bestuurlijk en organisatorisch niveau, als op operationeel en technisch niveau. Op basis van een gedegen risicoanalyse worden de mitigerende maatregelen bepaald.
     
  2. Het project bewaakt de effectiviteit van de getroffen mitigerende maatregelen.
    Omdat de omgeving en het project in de tijd veranderen, is het van belang om de effectiviteit van mitigerende maatregelen structureel te monitoren en indien nodig maatregelen bij te stellen.
     
  3. De organisatiecultuur bevordert openheid en transparantie over risico’s.
    Het bevorderen van gedeeld inzicht in risico’s stelt het project in staat om deze risico’s effectief te identificeren, toe te wijzen en te mitigeren.

Projectafhankelijkheden

  1. Het project heeft grip op de belangrijkste afhankelijkheden.
    Het project heeft inzicht in afhankelijkheden van bijvoorbeeld andere projecten, ketenafspraken, releases van andere applicaties, koppelingen en wet- en regelgeving. Afspraken over rollen, planning, verwachtingen en verantwoordelijkheden zijn helder en partijen handelen overeenkomstig de afspraken.
     
  2. Het project heeft alle betrokken partijen en hun belangen in kaart gebracht en passende maatregelen getroffen.
    Alle interne en externe partijen die iets te maken hebben met het project (inclusief eventuele maatschappelijke partijen) zijn bekend. Partijen die belang hebben bij het mislukken van het project hebben zo min mogelijk invloed. Als die invloed groot is, is dit expliciet benoemd in de risicoanalyse en zijn passende maatregelen getroffen.

Samenhang werkprocessen en ICT-oplossingen

  1. De werkprocessen en de ICT-oplossing sluiten op elkaar aan.
    In de aanpak van het project is expliciet aandacht voor de aansluiting van de werkprocessen en de ICT-oplossing.
     
  2. De werkprocessen en de ICT-oplossing worden in samenhang uitgewerkt en getest.
    Het project houdt bij de uitwerking van de (nieuwe) werkprocessen rekening met de mogelijkheden en beperkingen die de ICT-oplossing biedt en de benodigde organisatieverandering. Indien het project kiest voor een standaard pakketoplossing worden de werkprocessen in principe aangepast aan het standaardpakket. De aanpak om tot deze samenhang te komen, is gedefinieerd.
    Indien de daadwerkelijke invoering van de gewijzigde werkprocessen pas mogelijk is met het nieuwe systeem, dan zijn de nieuwe werkprocessen uitgewerkt en gevalideerd voordat begonnen wordt met selectie of bouw van de ICT-oplossing.
     
  3. De werkprocessen worden uitgewerkt in afstemming met de gebruikersvertegenwoordiging.
    De gebruikersorganisatie is ruimschoots betrokken bij de uitwerking van de (nieuwe) werkprocessen. Indien de ICT-oplossing een belemmerende factor is voor de gewenste aanpassing van de werkprocessen wordt in afstemming met de gebruikersorganisatie naar alternatieven gezocht.

Beheersing van de scope

Minimale scope bij de start

  1. De scope van het project is beschreven in termen van te behalen resultaten. Deze scope is aantoonbaar zo klein mogelijk gehouden, gegeven de gestelde doelen.
    Te behalen resultaten zijn bijvoorbeeld een geïmplementeerde en beheerde ICT-oplossing, met bijbehorende werkprocessen, bij een bepaalde gebruikerspopulatie en/of specifieke bedrijfsprocessen. De resultaten zijn gerelateerd aan de doelstellingen.
    De initiële scope is – gegeven de doelstellingen – beperkt tot noodzakelijke functionaliteit, organisatiewijzigingen, procesaanpassingen en gebruikers(groepen). Het opstellen van een Minimum Viable Product (MVP) kan helpen bij het bepalen van de minimale scope.
     
  2. Als het project te groot en/of te complex wordt, wordt gekozen voor een opdeling zodat de doelen in stappen kunnen worden behaald.
    Het project is te groot en/of te complex als er bijvoorbeeld te veel afhankelijkheid van verschillende partijen bestaat of als er te veel functionaliteit in één keer in gebruik wordt genomen. Ook aanpassing van te veel processen, een grootschalige uitrol binnen korte tijd of een te lange doorlooptijd voordat eerste resultaten worden behaald, maken het project te groot en/of complex.

Beheersing scope tijdens de uitvoering

  1. Opdrachtgever is de enige die, na de start van het project, de scope kan wijzigen.
    Het betreft hier wijzigingen die de te behalen einddoelen of belangrijke resultaten raken.
     
  2. Wijzigingen in de scope zijn traceerbaar en worden alleen goedgekeurd als de volledige impact inzichtelijk is.
    De impact is beschreven in termen van tijd, kosten, kwaliteit, risico’s en baten. Het mandaat voor wijzigingen ligt bij de opdrachtgever.

Architectuur, functionele haalbaarheid en technische maakbaarheid

Eisen en functionaliteiten

  1. De kwaliteit van de belangrijkste functionele en niet-functionele eisen is getoetst.
    Belangrijkste eisen zijn eisen die grote impact op het fundament kunnen hebben. Bijvoorbeeld eisen ten aanzien van verwachte levensduur, gegevensopslag en te verwerken volumes.
    Eisen moeten onder andere volledig, consistent, actueel, eenduidig en verifieerbaar zijn. Toetsing van eisen kan plaatsvinden door onder meer reviews, workshops of geautomatiseerde analyses.
     
  2. Eisen zijn traceerbaar naar relevante afgeleide ontwikkelproducten.
    Relevante afgeleide ontwikkelproducten zijn bijvoorbeeld ontwerpen, softwarebroncode en testgevallen.
     
  3. Er is vanaf het begin structureel aandacht voor privacy en informatiebeveiliging.
    Toepasselijke eisen zijn onderkend om de privacy en informatiebeveiliging te waarborgen (‘security en privacy by design’).
     
  4. De haalbaarheid en geschiktheid van de functionaliteit van de ICT-oplossing zijn getoetst.
    Toetsing van haalbaarheid en geschiktheid vindt bijvoorbeeld plaats door middel van prototyping of pilots.

Architectuur

  1. Het project geeft invulling aan het principe: hergebruik vóór koop vóór bouw.
    Hergebruik van componenten die bij een organisatie of rijksbreed in gebruik zijn en die passend zijn voor de ICT-oplossing, kan mogelijk het risicoprofiel verlagen ten opzichte van kopen of bouwen van nieuwe componenten.
     
  2. Het project maakt gebruik van relevante standaarden.
    Relevante standaarden zijn standaarden die men mag verwachten binnen het domein waarbinnen de organisatie opereert en binnen de eisen die aan de oplossing worden gesteld. Afwijken van relevante standaarden kan alleen met een gedegen motivatie.
     
  3. De architectuur is passend voor de ICT-oplossing, ook binnen het bredere ICT-landschap.
    Bij een passende architectuur zijn architectuurkeuzes gemotiveerd en toegelicht vanuit meerdere perspectieven (zoals business, proces, beveiliging, data en infrastructuur). De keuzes zijn getoetst aan de belangrijkste functionele en niet-functionele eisen. Ze zijn duidelijk vastgelegd en traceerbaar naar eisen.
    Er is daarbij rekening gehouden met het bredere ICT-landschap: aanpalende/gekoppelde systemen, gerelateerde systemen en ontwikkelingen binnen het landschap, en betrokken ketens.
     
  4. De voor- en nadelen van inzet van generieke componenten zijn afgewogen.
    Generieke componenten zijn componenten die op meerdere plekken kunnen worden gebruikt voor soortgelijke processen. Voordelen kunnen onder andere zijn voorspelbare kwaliteit, mogelijkheid tot hergebruik en hogere productiviteit. Nadelen kunnen onder andere zijn de complexiteit van de realisatie, afhankelijkheden en onderhoudbaarheid.
     
  5. De ICT-oplossing is in componenten opgedeeld die apart kunnen worden opgeleverd en getest.
    Functies zijn optimaal en logisch gegroepeerd over de verschillende componenten. De omvang van componenten dient zo klein mogelijk te worden gehouden als het passend is. De componenten zijn op een afgewogen manier ontkoppeld (maximale samenhang, minimale koppeling).
     
  6. Koppelvlakken zijn gedefinieerd.
    Koppelvlakken zijn voor alle betrokkenen duidelijk en waar mogelijk gestandaardiseerd.
     
  7. De ICT-oplossing faciliteert een beheerste en stapsgewijze overgang naar de nieuwe situatie.
    Indien sprake is van een oplossing in meerdere stappen, zijn afzonderlijke stappen onafhankelijk af te ronden.
     
  8. De omvang van de ICT-oplossing is bij benadering bekend en wordt bij wijzigingen herijkt.
    De functionele omvang kan bijvoorbeeld worden bepaald met behulp van functiepuntanalyse. Een globale functiepuntanalyse kan al worden uitgevoerd op gebruikersfuncties en gegevensverzamelingen.

Technologie

  1. De ICT-oplossing maakt waar mogelijk gebruik van gangbare en volwassen technologie.
    Gangbare technologie past bij het domein van de oplossing en wordt nog geruime tijd ondersteund. Binnen de markt is voldoende kennis beschikbaar over deze technologie.
    Volwassen technologie betekent dat deze reeds geruime tijd, breed is ingezet.
     
  2. Betrokken partijen hebben voldoende ervaring met de gekozen technische ICT-oplossingen.
    Betrokken partijen hebben representatieve referentieprojecten uitgevoerd.
     
  3. Voordat nieuwe technologie breed wordt ingezet, is deze beproefd in kleine gecontroleerde omgevingen.
    Nieuwe technologie is relatief jonge technologie die (nog) niet breed wordt gebruikt binnen een vergelijkbaar domein.

Realisatie en planning

Realisatie

  1. De ontwerp-bouw-test-cyclus is zo kort mogelijk gehouden.
    Het realisatieproces faciliteert kortcyclische oplevering van concreet bruikbare deelproducten die voldoen aan de gestelde eisen.
     
  2. De ontwikkelwerkwijze faciliteert tijdige betrokkenheid van eindgebruikers om opgeleverde functionaliteit te toetsen.
    De ontwikkelwerkwijze omvat alle activiteiten voor specificeren, ontwerpen, configureren/bouwen en testen om tot een werkende oplossing te komen.
     
  3. De ontwikkelwerkwijze is passend en er is voldoende ervaring mee opgedaan.
    De ontwikkelwerkwijze is duidelijk voor de belanghebbenden binnen en buiten het project, en passend bij de aard van de opgave, het type ICT-oplossing, het type project en de context. Daarbij hebben betrokken mensen voldoende ervaring met de werkwijze en juiste toepassing.
     
  4. Voor alle (deel)producten zijn de kwaliteitseisen bekend.
    Deze eisen hebben betrekking op kenmerken zoals beheerbaarheid, beveiliging, continuïteit, controleerbaarheid, gebruikersvriendelijkheid, herbruikbaarheid, onderhoudbaarheid.

Planning

  1. De planning bevat een onderbouwde tijdsinschatting van alle onderdelen van de realisatie.
    De tijdsinschatting van de onderdelen op de planning is onderbouwd en getoetst aan de hand van referenties ter onderbouwing van de mijlpalen. Activiteiten op korte termijn zijn verder uitgewerkt dan activiteiten op langere termijn.
     
  2. De planning is afgestemd met betrokken partijen.
    De planning maakt duidelijk wat wanneer en door wie wordt opgeleverd. De planning houdt rekening met externe afhankelijkheden.
     
  3. De planning biedt ruimte voor tegenvallers.
    Geen nadere toelichting.

Aanbestedingsaspecten

  1. De aanbestedingsstrategie is in lijn met de sourcingsstrategie en regelgeving.
    De gekozen aanbestedingsstrategie is in overeenstemming met onder meer de gemaakte keuzes ten aanzien van in- of uitbesteding,   aansturing, regievoering en samenwerking.
     
  2. De aanbestedingsstrategie zorgt voor een balans van de  risico’s tussen de opdrachtgever en marktpartij(en).
    Afspraken over welke partij welk risico draagt worden zo gemaakt en vastgelegd dat de partij die het risico het best kan beheersen het risico draagt.
     
  3. De aanbestedingsstrategie verkleint het risico van ongewenste afhankelijkheid van marktpartijen.
    Bij het bepalen van de scope van de opdracht is bijvoorbeeld rekening gehouden met omvang en complexiteit van het kavel en met afhankelijkheden van andere kavels.
     
  4. De gekozen aanbesteding is afgestemd op de omvang en complexiteit van de opdracht, en op de volwassenheid van de organisatie.
    De verschillende aanbestedingsprocedures bieden meer of minder mogelijkheden voor interactie met de potentiële leveranciers. Meer interactie kan wenselijk zijn indien er voor de uitvoering van de opdracht nog onduidelijkheden moeten worden weggenomen, maar vraagt wel om een bepaalde volwassenheid van de organisatie.
     
  5. De aanbestedingsstrategie geeft duidelijke kaders voor een transitie- en beheerfase.
    Er is een globale planning die een transitie- en beheerfase inzichtelijk maakt. Het kan verstandig zijn om de transitie te starten met een verificatiefase waarbij de geselecteerde leverancier aantoont dat de geoffreerde dienstverlening ook daadwerkelijk geleverd kan worden.
     
  6. De voorgenomen aanbesteding is vooraf in de markt getoetst.
    De belangrijkste aanbestedingsdocumenten en de beoogde aanbestedingsprocedure zijn vooraf in de markt getoetst (bijvoorbeeld met een marktconsultatie). De relevante resultaten van deze toetsing zijn in de aanbesteding verwerkt.
     
  7. Gunningscriteria zijn expliciet en balanceren kwaliteit, prijs en doorlooptijd.
    De gunningscriteria zijn zodanig geformuleerd dat deze concreet, eenduidig en objectief uitlegbaar zijn.
     
  8. Contractafspraken bevorderen dat marktpartijen er belang bij hebben dat projectresultaten conform de gemaakte afspraken worden opgeleverd.
    De betaling is bijvoorbeeld zoveel mogelijk gekoppeld aan de door de opdrachtgever geaccepteerde resultaten.
     
  9. De opdrachtgever beschikt over stuurmiddelen en competenties om de aansturing en samenwerking met de marktpartij(en) vorm te geven.
    De organisatie heeft voldoende kennis in huis om regie te voeren op de werkzaamheden van de marktpartij. Er zijn reguliere overlegmomenten gepland waarin betrokken partijen in een zakelijke en coöperatieve sfeer de gemaakte afspraken evalueren. Prestatieafspraken kunnen bijvoorbeeld worden gekoppeld aan een bonus-/malusregeling. Er is eveneens voorzien in escalatie tot op stuurgroepniveau en in een exit-scenario.

Acceptatie, implementatie en overdracht naar de lijn

  1. Het project voorziet in de implementatie van de ICT-oplossing bij de lijnorganisatie, inclusief de beheerorganisatie.
    Met implementatie wordt bedoeld dat overdracht en ingebruikname, inclusief plan voor functioneel, applicatie- en technisch beheer en onderhoud, en voor organisatorische wijzigingen zijn geregeld.
     
  2. De aanpak voor de implementatie is opgesteld in samenwerking met de lijnorganisatie.
    Geen nadere toelichting opgenomen.
     
  3. Er is duidelijk afgesproken wie de ICT-oplossing in beheer neemt.
    Dit omvat ook afspraken over planning van en voorwaarden waaronder ICT-oplossingen kunnen worden overdragen aan een beheer¬organisatie.
     
  4. De acceptatiecriteria en het acceptatieproces zijn gedefinieerd, en scheppen duidelijkheid over wijze en moment van toetsing van producten.
    Geen nadere toelichting opgenomen.
     
  5. Het project voorziet in een nazorgfase.
    In de eerste periode na ingebruikname van een ICT-oplossingen komen meestal incidenten/uitdagingen naar voren. Er kunnen dan ook nog kleine aanpassingen noodzakelijk zijn om de ICT-oplossing goed te laten landen bij de gebruikers.
     
  6. Dechargevoorwaarden voor afsluiting van het project zijn gedefinieerd.
    Het is voor opdrachtgever en opdrachtnemer duidelijk wanneer het project kan worden beëindigd.