Businesscase, baten en financiering

Businesscase

  1. Er is een duidelijke aanleiding, probleemstelling en doelstelling voor het project. Deze onderwerpen zijn helder, beknopt en eenduidig geformuleerd, zodat het belang van het project voor alle (interne en externe) betrokkenen duidelijk is, waaronder burgers en bedrijven.
  2. De businesscase onderbouwt de meerwaarde voor de organisatie en betrokkenen. De verwachte kosten en baten zijn onderbouwd en tegen elkaar afgewogen. De verwachte kosten omvatten interne en externe kosten, zowel voor het project als daarna. De businesscase maakt onderscheid tussen baten voor de organisatie, burgers, bedrijven en de maatschappij.
  3. Scenario’s met alternatieve oplossingen zijn opgesteld, onderbouwd en afgewogen. De voor- en nadelen en risico’s 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. Indien mogelijk is een vergelijking gemaakt met soortgelijke projecten bij andere overheidsorganisaties.
  4. De impact van de oplossing op uitvoeringsorganisaties, burgers en bedrijven is onderzocht.
    Uitvoeringsorganisaties hebben de uitvoerbaarheid van de gekozen oplossingsrichting onderzocht. De impact op burgers en bedrijven is daarin expliciet meegenomen met in ieder geval aandacht voor de aspecten toegankelijkheid, navolgbaarheid, en de mogelijkheid om bij beslissingen maatwerk voor burgers en bedrijven toe te passen. Impact van het gebruik van kunstmatige intelligentie (AI) en/of algoritmes en automatische besluitvorming op burgers en bedrijven zijn onderzocht op bijvoorbeeld transparantie, ethiek, controleerbaarheid en representativiteit.
  5. De impact van de oplossing op strategische digitale veiligheid is meegewogen. Indien de ICT-oplossing van strategisch belang is, wordt voldoende weerstand geboden tegen aanvallen door statelijke actoren, georganiseerde criminaliteit en andere dreigingen.
  6. 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.
  7. In de businesscase is aantoonbaar rekening gehouden met geldende wet- en regelgeving. In de businesscase is opgenomen welke wet- en regelgeving van toepassing is, welke deadlines in (nieuwe) wetgeving relevant zijn, en op welke wijze naleving is geborgd. Indien relevant is bij Europese wetten gekeken hoe andere landen het aanpakken.

Baten

  1. Kwantitatieve baten zijn vertaald in financiële termen. Baten kunnen kwalitatief en kwantitatief van aard zijn. Kwantitatieve baten zijn waar mogelijk vertaald naar financiële consequenties.
  2. Kwalitatieve baten zijn zodanig gespecificeerd dat ze te verifiëren zijn. Ook baten die niet gekwantificeerd kunnen worden, moeten zoveel mogelijk meetbaar worden gemaakt.
  3. 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.
  4. De verantwoordelijke(n) heeft/hebben sturingsmogelijkheden om de baten te realiseren. Indien voor de realisatie van de baten medewerking van andere partijen nodig is, is medewerking van deze partijen verzekerd of is ten minste draagvlak bij deze partijen aangetoond.

Financiering

  1. Er is financiële dekking voor de looptijd van het project en de beheerfase. Projecten worden alleen geïnitieerd als de opdrachtgever daarvoor in de benodigde middelen voor de gehele levenscyclus kan voorzien.
  2. Er is voldoende financiële ruimte voor wijzigingen gedurende de looptijd van het project. Voor de meerjarige financiële dekking is rekening gehouden met het feit dat gedurende de looptijd van een project wijzigingen kunnen plaatsvinden.

Opdrachtgever en projectorganisatie

Opdrachtgever

  1. De opdrachtgever is verantwoordelijk voor het budget en de businesscase. De opdrachtgever heeft het mandaat binnen de grenzen van de businesscase. De opdrachtgever is en voelt zich verantwoordelijk en draagt de visie uit naar de stakeholders.
  2. De opdrachtgever is inhoudelijk betrokken bij bepalende keuzes. De opdrachtgever (en de stuurgroep) 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 (en de stuurgroep) 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 (en de stuurgroep) 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. Ook zijn de beoogde beheerorganisatie en eindgebruiker goed en met voldoende mandaat vertegenwoordigd binnen de projectorganisatie.
  2. De projectorganisatie bestaat uit mensen met voldoende kennis en ervaring. Leden op sleutelposities hebben aantoonbare ervaring met projecten van vergelijkbare omvang, complexiteit en informatiebeveiliging binnen een vergelijkbaar domein en met een vergelijkbare veranderingsopgave en technologie.
  3. De organisatiecultuur bevordert open communicatie en effectieve 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. Risicoanalyses worden met regelmaat uitgevoerd. Dit kunnen risico’s zijn op zowel (geo)politiek, bestuurlijk en organisatorisch niveau, als op operationeel en technisch niveau. Op basis daarvan worden er mitigerende maatregelen doorgevoerd die continu worden bijgesteld. Daarbij moet telkens inzichtelijk gemaakt worden welke restrisico’s geaccepteerd worden.

  2. Het project weegt het actuele dreigingsbeeld mee in risicoanalyses. Het project kijkt welke dreigingen van toepassing zijn op de organisatie en de aanwezige (gevoelige) informatie. Het kan daarbij ook gaan om nieuwe technologische, maatschappelijke, of geopolitieke ontwikkelingen.

  3. Het project bewaakt de effectiviteit van de getroffen mitigerende maatregelen. De omgeving en het project veranderen in de tijd. Hierdoor is het van belang de effectiviteit van mitigerende maatregelen structureel te monitoren en deze maatregelen, indien nodig, bij te stellen.

  4. De organisatiecultuur bevordert openheid en transparantie over risico’s. 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, wet- en regelgeving, en het bredere ICT-portfolio. 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. Als 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. 
    Als 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 ontworpen vanuit het perspectief van de burger. Het perspectief en interactie met de burger staan centraal en is uitgangspunt voor het ontwerp van de werkprocessen. Daarnaast is de gebruikersorganisatie ruimschoots betrokken bij de uitwerking van de (nieuwe) werkprocessen. Er is adequate ondersteuning voor de monitoring van het gebruik en voor meldingen van burgers en bedrijven.

  4. In het ontwerp is rekening gehouden met navolgbaarheid voor burgers en bedrijven. De ICT-oplossing faciliteert voldoende transparantie zodat beslissingen navolgbaar zijn voor de belanghebbenden.

  5. De ICT-oplossing faciliteert het kunnen ingrijpen bij automatische besluitvorming en de toepassing van maatwerkbeslissingen. Indien nodig kan bij automatische besluitvorming worden afgeweken zodat maatwerkbeslissingen voor burgers en bedrijven mogelijk zijn.

  6. Bij uitwerking of wijziging van werkprocessen wordt rekening gehouden met aanvalsscenario’s door kwaadwillende actoren. Er is in kaart gebracht op welke wijze interne of externe actoren misbruik kunnen maken van de ICT-oplossing of processen.

  7. Er is aandacht voor de continuïteit van de werkprocessen in samenhang met de ICT-oplossing. De organisatie houdt rekening met (langdurige) uitval van de ICT-oplossing en de gevolgen voor de werkprocessen. Op basis van het risicoprofiel wordt een passende bedrijfscontinuïteitsstrategie toegepast.

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. De opdrachtgever heeft het mandaat om na de start van het project de scope te kunnen 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. Er wordt ook rekening gehouden met het bredere ICT-portfolio en ICT-landschap. 

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, informatiebeveiliging en veiligheid. Toepasselijke eisen zijn onderkend om de privacy, informatiebeveiliging en - indien van toepassing – functionele veiligheid te waarborgen (‘security, privacy en safety by design’). Gemaakte beveiligingskeuzes zijn passend voor de vertrouwelijkheid van de data. Het beveiligingsbeleid heeft voldoende aandacht en waarborgen voor het continu up-to-date houden van de ICT-oplossing (patch- en kwetsbaarhedenbeheer).
  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 of 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 aantoonbaar gebruik van relevante standaarden. Relevante standaarden zijn standaarden die men mag verwachten binnen het domein waarin 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 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 zijn onder andere: 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 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. Als er 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. Er is speciale aandacht voor de strategische digitale veiligheid van de nieuwe technologie.

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. In de ontwikkelwerkwijze zijn eindgebruikers nauw betrokken. De ontwikkelwerkwijze omvat alle activiteiten voor specificeren, ontwerpen, configureren/bouwen en testen om tot een werkende en veilige 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, toegankelijkheid, herbruikbaarheid, en onderhoudbaarheid.
  5. Testen worden uitgevoerd op basis van een risicoanalyse. De testaanpak houdt rekening met het risicoprofiel van de ICT-oplossing, waarbij ook informatiebeveiliging wordt meegenomen.

Planning

  1. De planning bevat een onderbouwde tijdsinschatting van de 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. Ook biedt de planning ruimte voor tegenvallers.
  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.

Sourcing

  1. De keuze voor inbesteding, uitbesteding of een hybride vorm is herleidbaar en objectief onderbouwd. Alternatieven zijn onderzocht en op basis van vooraf vastgestelde beoordelingscriteria met elkaar vergeleken. De afweging is herleidbaar en gebaseerd op actuele en verifieerbare informatie. Het is inzichtelijk welke factoren, aannames en randvoorwaarden zijn meegewogen en hoe deze hebben bijgedragen aan de uiteindelijke keuze.
  2. Bij een uitbesteding is er een balans in 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 ook draagt.
  3. In een uitbesteding wordt expliciet rekening gehouden met risico’s op het gebied van strategische digitale veiligheid. Wanneer gevoelige en/of zeer vertrouwelijke informatie wordt verwerkt, wordt expliciet aandacht besteed aan mogelijke ondermijning van datasoevereiniteit en databeveiliging door buitenlandse regelgeving. Dit vertaalt zich in eisen ten aanzien van het omgaan met data, infrastructuur en beheer. Eisen die aan de leverancier worden gesteld dienen verifieerbaar door te werken in de volledige toeleveringsketen. 
  4. De aanbestedingsstrategie is in lijn met de sourcingstrategie en regelgeving. De gekozen  aanbestedingsstrategie is in overeenstemming met onder meer de gemaakte keuzes ten aanzien van in- of uitbesteding, aansturing, regievoering en samenwerking. 
  5. De aanbestedingsstrategie verkleint het risico van ongewenste afhankelijkheid van marktpartijen. De strategie biedt voldoende mogelijkheden om indien nodig te reageren op de dynamiek van de ICT-markt en beleidskaders. Bij het bepalen van de scope van de opdracht is bijvoorbeeld rekening gehouden met de omvang en complexiteit van het perceel en met afhankelijkheden van andere percelen. Ook worden waarborgen ingebouwd voor het tijdig signaleren van risico’s rond continuïteit, zeggenschap en concentratie van marktmacht in de hele toeleveringsketen en/of vanuit breder overheidsperspectief.
  6. Voor de beëindiging van of wijziging in een uitbesteding is een passende en uitvoerbare exitstrategie uitgewerkt. Een exitstrategie geeft concreet handelingsperspectief om tijdig te kunnen reageren op ongewenste marktontwikkelingen, risico’s rondom strategische digitale veiligheid, en wijzigingen in regelgeving of beleid. Duidelijk is hoe gegevens, kennis, middelen en dienstverlening kunnen worden overgedragen bij beëindiging van een overeenkomst, overstap naar een andere leverancier of terugname van de dienstverlening.
  7. De gekozen aanbestedingsstrategie 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 als er voor de uitvoering van de opdracht nog onduidelijkheden moeten worden weggenomen, maar vraagt wel om een bepaalde volwassenheid van de organisatie.
  8. 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 waarin de geselecteerde leverancier aantoont de geoffreerde dienstverlening ook daadwerkelijk te kunnen leveren.
  9. De voorgenomen aanbesteding is vooraf in de markt getoetst. De belangrijkste aanbestedings-documenten 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.
  10. Gunningscriteria zijn expliciet en balanceren kwaliteit, prijs en doorlooptijd. De gunningscriteria zijn zodanig geformuleerd dat deze concreet, eenduidig en objectief uitlegbaar zijn.
  11. Contractafspraken bieden een helder samenwerkingskader en bevorderen dat marktpartijen belang hebben bij het opleveren van projectresultaten conform de gemaakte afspraken. De gehanteerde contractvoorwaarden zijn consistent, toegankelijk en bieden duidelijkheid over de verdeling van taken, rollen en risico’s. Om nakoming door leveranciers te bevorderen is bijvoorbeeld de betaling zoveel mogelijk gekoppeld aan de door de opdrachtgever geaccepteerde resultaten.
  12. De gekozen aanbestedingsstrategie sluit aan bij de beschikbare regiecapaciteit en het volwassenheidsniveau van de organisatie om de 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 en de naleving van het contract te monitoren. Om kennisopbouw te waarborgen zijn de relevante competenties vroegtijdig betrokken bij het aanbestedingsproces. 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 beheer

  1. Het project voorziet in de implementatie van de ICT-oplossing bij de lijnorganisatie, inclusief de beheerorganisatie. Met implementatie wordt bedoeld dat het beheer en ingebruikname zijn geregeld. Dit is inclusief een plan voor functioneel, applicatie- en technisch beheer en onderhoud, en voor organisatorische wijzigingen. De aanpak voor de implementatie is opgesteld in samenwerking met de lijnorganisatie.
  2. Er is duidelijk afgesproken wie de ICT-oplossing in beheer neemt. Er zijn afspraken over de planning van en voorwaarden waaronder de ICT-oplossing in beheer wordt genomen. Hierbij is ook aandacht voor de afspraken over de invulling van het beheer inclusief taken en verantwoordelijkheden.
  3. De acceptatiecriteria en het acceptatieproces zijn gedefinieerd, en scheppen duidelijkheid over de wijze en het moment van toetsing van producten. Er is een vastgelegd acceptatieproces. De acceptatiecriteria zijn op drie niveaus uitgewerkt:
    - Functioneel - functioneert de ICT-oplossing zoals afgesproken?
    - Niet-functioneel - voldoet de ICT-oplossing aan de afgesproken kwaliteitseisen?
    - Proces - is de oplevering compleet, inclusief alle afgesproken documentatie?
  4. Het project voorziet in een nazorgfase. In de eerste periode na ingebruikname van een ICT-oplossing komen meestal incidenten/uitdagingen naar voren. Ook kunnen dan nog kleine aanpassingen noodzakelijk zijn om de ICT-oplossing goed te laten landen bij de gebruikers.
  5. Dechargevoorwaarden voor afsluiting van het project zijn gedefinieerd. Het is voor de opdrachtgever en opdrachtnemer duidelijk wanneer het project kan worden beëindigd.