Checks & Balances
Hoe gebruikt een opdrachtgever zijn eigen kennis en ervaring om effectief invulling te geven aan zijn rol met een minimum aan tijd en zonder zich in de inhoud te verdiepen?
De processtappen zoals genoemd in het voorgaande regiemodel kunnen hem hierbij helpen. Maar ook een speciaal voor dit doel, door Wortmann en Kremer, ontwikkeld model dat gebaseerd is op het principe van ‘checks & balances’ kan hem hierbij helpen. De achtergrond van het ‘checks & balances‘ model wordt gegeven het model van de Trias Politica.
Het model
In het model van ‘checks & balances’ gebruiken we drie partijen die de gebruikers, de specialisten van de opdrachtnemer en het management vertegenwoordigen. De laatste partij uiteraard in zijn rol van opdrachtgever. Als voorbeeld wordt hier gebruikt de processtap van het opstellen van de businesscase.
In de doelstelling van een organisatie wordt in feite vastgelegd wat een organisatie wil. Deze behoefte (of noodzaak) wordt, onder leiding van een eigen projectmanager, door de eigen medewerkers verder uitgewerkt in specifieke eisen en wensen. Op enig moment zal hierbij gebruik gemaakt gaan worden van de kennis en kunde van specialisten. Dit kan zijn de eigen ICT afdeling, maar ook een externe dienstverlener. Op dit niveau vindt in zekere zin een confrontatie plaats tussen het pakket aan eisen en wensen en wat de techniek eventueel kan bieden om dit te realiseren. Het gaat dan primair om de functionele eisen. Door deze confrontatie zal blijken welke mogelijkheden er zijn. Deze worden gedefinieerd als een aantal mogelijke scenario’s of oplossingen. De rol van de opdrachtgever is op deze manier beperkt tot degene die het proces bewaakt en de voorwaarden stelt. Dit laatste heeft dan vooral te maken met de impact die de oplossingen of scenario’s hebben op de organisatie. Het gaat dan om het definiëren en het beoordelen van niet-functionele eisen en criteria (de zogenaamde ’ilities’), maar ook om de omgevingsfactoren die van invloed zijn op de scenario’s. Het gaat bijvoorbeeld om de beschikbaarheid en de doelmatigheid. Maar ook om eisen op het gebied van de schaalbaarheid, de betrouwbaarheid en de haalbaarheid. Uiteraard zijn er nog meer niet-functionele eisen, maar we gaan daar verder niet op in. Hieronder wordt een voorbeeld gegeven van de ‘ilities’ in een ict omgeving.
Besluitvorming
De uitkomsten van de beoordeling van de niet-functionele eisen en criteria van elk scenario zijn bepalend voor de besluitvorming. De eerdergenoemde omgevingsfactoren maken duidelijk welke eisen er aan een goede regievoering moeten worden gesteld. Belangrijk is te weten wie de spelers zijn die het project positief of negatief kunnen beïnvloeden en welke acties vervolgens nodig blijken.
Tussen de mogelijke scenario’s kan vervolgens een afweging worden gemaakt door de belangrijkste stakeholders: dit kan een keuze zijn maar ook een bijstelling van wat een organisatie wil. In het laatste geval begint een volgende ronde. De opdrachtgever heeft in dit proces een centrale rol maar is minimaal betrokken bij de inhoud. Op enig moment zal er voor een scenario worden gekozen. Dit scenario vormt de basis voor de businesscase en daarmee voor de goedkeuring van het project. Maar het gekozen scenario vormt ook de basis voor een goede regievoering door de opdrachtgever richting overige stakeholders. De rol van opdrachtgever is zo beperkt tot degene die het proces bewaakt en de voorwaarden stelt.
Relatie met regiemodel
Het principe van ‘checks & balances’ biedt de opdrachtgever een uitstekend middel om een centrale rol te spelen met een minimum aan tijd en kennis. Het principe is in het voorbeeld hierboven gebruikt voor het opstellen van een businesscase, maar het kan gebruikt worden in elke processtap van een investeringstraject, ook gedurende de realisatie van het project. Bijvoorbeeld tussen stap 3 (de businesscase) en stap 5 (uitvoeren project). De afweging ligt in het laatste geval op het niveau van de stuurgroep. Maar ook tijdens de realisatie van een project moeten keuzes gemaakt worden en kan het principe van ‘checks & balances’ worden gebruikt (binnen het besturingsprincipe zoals aangegeven in het schema). De scope wordt voor een belangrijk deel bewaakt door wat de organisatie wil en kan. Zoals gedefinieerd in de businesscase als een haalbare optie. Maar het kan ook zijn dat bepaalde aannames in de businesscase moeten worden herzien.
Niet functionele eisen
Een voorbeeld voor mogelijke niet-functionele eisen, de zogenaamde ‘ilities’ wordt in bijgaande figuur gegeven. Dit is een voorbeeld zoals deze ik een ict omgeving gebruikt kan worden. Uiteraard hangt het sterk van de omgeving af, welke van deze eisen relevant zijn. Ook is het normaal dat er aan elk criterium of eis een wegingsfactor wordt toegekend. Deze wegingsfactoren wordt in gezamenlijkheid door de belangrijkste stakeholders bepaald. Onder regie van de opdrachtgever.
Voor meer ilities verwijzen wij naar de wikipedia over dit onderwerp. Verder wordt er in een internationale standaard, de ISO 9126, een checklist gegeven met bruikbare kwaliteitseigenschappen. Hoewel deze laatste tot stand gekomen is voor het beoordelen van de software ontwikkeling, is deze op onderdelen zonder meer bruikbaar voor andere doeleinden. 
Zoals al aangegeven is het voor elke situatie belangrijk na te gaan welke van deze niet-functionele eisen relevant is. De opdrachtgever heeft hierin een allesbepalende rol
