Toetskader
Het Adviescollege ICT-toetsing oordeelt over de slaagkans van ICT-projecten of -programma’s binnen het Rijk en geeft adviezen ter verbetering.
Een BIT-toets van het Adviescollege beantwoordt twee vragen:
- Streeft het project een helder doel na of lost het een probleem op (zakelijke rechtvaardiging)?
- Is het project zo ingericht dat er vertrouwen is dat het doel ook wordt gehaald (slaagkans)?
Het Adviescollege gebruikt een toetskader om alle aspecten en onderdelen van het project te toetsen en de risico’s te inventariseren. Als blijkt dat er risico’s zijn voor de slaagkans van het project, stelt het Adviescollege in het BIT-advies maatregelen voor om die te beperken.
Het toetskader bestaat uit 13 onderwerpen.Deze onderwerpen zijn bij (vrijwel) alle projecten aan de orde.
Toetskader (versie 1.1 september 2015)
Er is een duidelijke doelstelling en een business case die dit onderbouwt. In de business case zijn kosten en baten van het project tegen elkaar afgewogen. De meerwaarde van het project voor de organisatie, de eindgebruiker en/of de samenleving wordt door de business case aangetoond. De baten zijn waar mogelijk vertaald in financiële termen; als dat niet kan zijn de kwalitatieve baten concreet gespecificeerd op een wijze die achteraf geverifieerd kan worden. Er is (meerjarige) financiële dekking voor het project en voor de beheerfase. Het project past binnen de afgesproken kaders (geld, mensen, middelen). De opdrachtgever voor het project is ook verantwoordelijk voor het budget.
De rollen, taken, verantwoordelijkheden en bevoegdheden in de projectorganisatie (opdrachtgever, projectmanager, projectteam, stuurgroep, projectsupport) zijn helder vastgelegd en worden ingevuld door mensen met voldoende kennis en ervaring. In en rond de projectorganisatie is aantoonbaar en structureel ruimte voor tegendenken en een kritische blik. In het projectplan is de kwaliteitswaarborging beschreven op basis waarvan de interne en externe toetsmomenten op de relevante projectmijlpalen/producten zijn beschreven.
Voor de start van de uitvoering is goed zicht op de afhankelijkheid van andere projecten en releases van bestaande applicaties (inhoud en planning). Het is duidelijk hoe hierover afspraken zijn/worden gemaakt. De belangrijkste risico’s van het project zijn in kaart gebracht en het risicomanagement is geborgd in de projectbeheersing.
In de aanpak is expliciet gedefinieerd hoe de werkprocessen en automatisering in samenhang tot stand komen. Werkprocessen zijn een integraal onderdeel van de oplossing en zijn idealiter gedefinieerd en gestandaardiseerd voordat begonnen wordt met de realisatie van het nieuwe systeem. Indien de daadwerkelijke invoering van de processen pas mogelijk is met het nieuwe systeem, dan zijn de nieuwe werkprocessen afdoende getoetst voordat begonnen wordt met selectie of bouw van het nieuwe systeem. Indien wordt gekozen voor een standaard pakketoplossing dan worden de werkprocessen in principe aangepast aan het pakket.
De omvang (scope) van het project is beschreven als op te leveren producten. Deze scope is aantoonbaar zo klein mogelijk gehouden, gegeven de gestelde doelen. Als de complexiteit te groot wordt en/of de doorlooptijd te lang, wordt gekozen voor een projectfasering waarbij de doelen aantoonbaar in stappen worden bereikt.
Alleen de opdrachtgever kan na de start van het project nog aanvullende eisen stellen aan het eindresultaat. Aanvullende eisen worden goedgekeurd op basis van een wijzigingsvoorstel waarin de impact is beschreven op tijd, kosten, kwaliteit, scope, risico’s en baten. De opdrachtgever is verantwoordelijk voor alle consequenties van goedgekeurde wijzigingen en heeft hierdoor voldoende financiële ruimte.
Het is duidelijk wie verantwoordelijk is om de baten van het project te realiseren. De verantwoordelijk(en) heeft/hebben een duidelijk (intern of extern) belang om de baten te realiseren en de autoriteit en sturingsmogelijkheden om dit voor elkaar te krijgen. Indien voor de realisatie medewerking van andere partijen nodig is dan is medewerking van deze partijen verzekerd of minstens draagvlak bij deze partijen aangetoond.
De gekozen architectuur verdeelt het nieuwe systeem optimaal in componenten die apart opgeleverd en getest kunnen worden. Indien componenten door verschillende partijen worden gerealiseerd dan zijn de benodigde koppelvlakken (interfaces) vooraf gedefinieerd (technisch en semantisch), of is 1 partij geautoriseerd om deze voor de benodigde koppelvlakken te definiëren. De benodigde inspanning voor de realisatie van elk koppelvlak is in kaart gebracht.
Voor zover van toepassing wordt gebruik gemaakt van de voor de rijksoverheid vastgestelde standaarden. Het project geeft invulling aan het principe: hergebruik vóór koop vóór bouw. Er wordt gebruik gemaakt van gangbare en volwassen technologie en zowel de organisatie als de geselecteerde marktpartijen hebben ervaring met de gekozen technische oplossingen. De haalbaarheid van het totaal aan functionele wensen is getoetst. Voor zover in het kader van het project nieuwe applicaties moeten worden ontwikkeld is de omvang hiervan bij benadering bekend, bijvoorbeeld door een functiepuntenanalyse.
Alle stakeholders bij het project zijn helder in kaart gebracht (inclusief de eventuele maatschappelijke groeperingen). Eventuele organisatorische en bestuurlijke risico’s worden voordurend helder in beeld gebracht en vertaald in maatregelen. Partijen die belang hebben bij het mislukken van het project, als ze er zijn, hebben geen invloed op het welslagen van het project. Als dit wel het geval is, dan is dit expliciet benoemd in de risicoanalyse en zijn adequate maatregelen getroffen.
De ontwerp-, bouw- en testfase van het project is zo kort mogelijk gehouden of is geïntegreerd in een Agile/Scrum aanpak. Na uiterlijk 2 jaar is de implementatie bij eindgebruikers begonnen. De implementatie wordt binnen één jaar afgerond. De eerste baten van het project zijn dan tevens gerealiseerd.
Grotere, langer durende projecten zijn verdeeld in helder afgebakende fasen die aan bovenstaande doorlooptijden voldoen en die elk een positieve business case hebben, of minimaal leiden tot concreet bruikbare producten voor eindgebruikers.
De gekozen aanbestedingsstrategie balanceert de risico’s tussen de opdrachtgever en marktpartij(en) en koppelt betaling aan de behaalde en door de opdrachtgever geaccepteerde resultaten. De eenduidigheid en volledigheid van de (functionele) eisen is vóór de definitieve gunning aantoonbaar grondig getoetst, waarbij optimaal gebruik gemaakt is van pilots en/of prototypes om bruikbaarheid en acceptatie van het systeem te waarborgen.
De voorgenomen aanbesteding, inclusief de belangrijkste aanbestedingsdocumenten, zijn vooraf in de markt getoetst en de resultaten van deze toetsing zijn in de aanbesteding verwerkt. Voor zover is afgeweken van de uitkomsten van deze toetsing is de motivatie hiervoor vastgelegd. De contractering is zodanig dat de bij de uitvoering betrokken marktpartijen er belang bij hebben dat het project tijdig en conform de initiële afspraken wordt opgeleverd. Er zijn reguliere overlegmomenten gepland waarin betrokken partijen in een zakelijke en coöperatieve sfeer de gemaakte afspraken evalueren.
In het projectplan is voldoende tijd en geld gereserveerd voor documentatie, training (inclusief ontwikkeling van trainingen, train de trainers) en overdracht aan en ingebruikname door de lijnorganisatie. Dat geldt ook voor de transitie naar de fase van beheer en onderhoud (inclusief afspraken met eventuele externe leverancier). De lijnorganisatie inclusief de beheerorganisatie en onderhoudsorganisatie zijn aantoonbaar betrokken geweest bij het optellen van deze plannen en hebben deze geaccepteerd. Er is dus duidelijk gedefinieerd en afgesproken wie de ICT-producten in beheer neemt en of hiervoor de benodigde resources beschikbaar zijn gesteld. Er is rekening gehouden met een nazorgfase.
In het projectplan is duidelijk beschreven hoe de op te leveren producten worden getoetst en geaccepteerd en wat de acceptatiecriteria zijn. Tevens is aangegeven onder welke voorwaarden aan het project decharge wordt verleend door de opdrachtgever.