Falende projecten zijn helaas nog steeds aan de orde van de dag. Vele onderzoeken zijn gedaan en veel conclusies worden getrokken. En de aanbevelingen en adviezen worden in groten getale gegeven. Dit proces is al decennialang gaande, maar heeft tot op heden niet geleid tot betere resultaten. Ondanks diverse initiatieven aan, voornamelijk, de de kant van het ict domein. Zie hierover de kritische beschouwingen van Wortmann en Kremer. Zie ook het model "Oorzaak en Gevolg".

Met name het Eindrapport van de Tijdelijke ICT Commissie Elias (15 oktober 2014) heeft ons aan het denken gezet wat betreft het referentiekader die de verschillende onderzoekers hanteren. Dit referentiekader is uitermate belangrijk bij het trekken van de conclusies en het geven van aanbevelingen. Dit is weer eens overduidelijk gebleken bij de Commissie Elias. Om de conclusies en aanbevelingen van de diverse onderzoeken beter te kunnen interpreteren, kan het nuttig zijn om een tweetal referentiekaders te onderscheiden. 

Wij maken dan ook onderscheid tussen de volgende twee referentiekaders:

• het "investering-denken"
• het "project-denken"

Een kort toelichting van elk van de referentiekaders. 

Het "investering-denken"

Bij het denken in investeringen gaan we uit van de volgende 3 stadia: initiatie, realisatie en exploitatie. Het zijn de stadia van een levenscyclus van een systeem. Elk van deze stadia kent zijn eigen verantwoordelijkheden en aandachtsgebieden. Onderkend wordt dat de 3 stadia een sterke afhankelijkheid hebben tot elkaar, maar onafhankelijk van elkaar worden uitgevoerd. Voor een succesvol investeringstraject, en dus ook het project, moet elk van deze stadia zorgvuldig worden doorlopen.  Het is een manier van denken die in de bouw en de engineering redelijk veel wordt gehanteerd. In de, relatief jonge bedrijfstak van de ict komt het helaas nog te weinig voor. Voor meer informatie zie het Investerings model.

Het "project-denken"

In tegenstelling tot de theorie van een project, gaat men bij het "project denken" vooral uit van het starten van een project waarbij er amper onderscheid gemaakt wordt in de verschillende stadia van een levenscyclus van een systeem. Alles wordt in het project "gestopt" onder verantwoordelijkheid van één persoon. Ook het ontstaan van een project is minder duidelijk omschreven en kan  zowel vanuit de businsess komen als dat van de interne ict afdeling (de interne opdrachtnemer). Het project wordt gezien als 'wondermiddel' om op een snelle manier een resultaat te bereiken in de vorm van een geautomatiseerd systeem. De borging van het project is minder duidelijk dan bij een investeringstraject het geval is. Veel verantwoordelijkheid wordt neergelegd bij de eigen ict afdeling. Rolvervaging komt bij deze manier van denken veelvuldig voor. 

Het "project-denken" komt bijzonder veel voor in organisaties in zowel de private als de publieke sector.  Het is een tamelijk traditionele manier van denken die geleidelijk aan is ontstaan vanaf het begin van de automatisering enkele decennia geleden. Niet in de laatste plaats wordt dit versterkt door het oneigenlijk gebruik van methodieken voor projectmanagement: te snel en te gemakkelijk worden verantwoordelijkheden naar het project doorgeschoven, ook daar waar het eigenlijk niet kan. Velen zitten min of meer "gevangen" in deze manier van denken. Het is in feite het standaard referentiekader voor iedereen die te maken heeft met ict.

In onze kritische beschouwingen over de rol van opdrachtgever van projecten, gaan wij uit van het referentiekader volgens het "investering-denken". Vanuit dit denken zijn dan ook vooral de verschillende modellen ontstaan die de rol van opdrachtgever binnen een organisatie kunnen verduidelijken. Voor degenen die uitgaan van het "project denken", zullen deze modellen moeilijk te interpreteren zijn. 

Vergelijking van de twee referentie kaders

Ter verduideling wordt hieronder een vergelijking gegeven van een aantal aspecten voor de verschillende referentiekaders:

Investering binnen de overheid

In de private sector kent men het fenomeen afschrijvingen. Binnen de publieke sector, waar meestal sprake is van een kasstelsel, hanteert men dit begrip niet of nauwelijks. De kosten van een project worden jaarlijks gebudgetteerd. Het is een vorm van financiering van het project die afwijkt van die in de private sector. Toch kan men in dit geval ook spreken van een investering. De kosten zijn op de korte termijn gemaakt en de kwalitatieve of kwantitatieve baten hiervan zullen op de langere termijn zichtbaar zijn. Ook nu gaat het om de bijdrage die geleverd wordt aan de doelstelling van de organisatie. In het borgingsmodel kennen we in dat geval het beleidsniveau, het uitvoerend niveau en het resultaatleverend niveau. Op dit laatste niveau heb je de realisatie van het project. In de twee andere speelt zich de investerings beslissing af. 

Wat betreft de baten blijken er ook veel misverstanden te zijn. Bij baten denken veel mensen aan kwantitatieve baten (bijvoorbeeld geld). Maar uiteraard gaat het in veel gevallen ook om de andere baten: kwalitatieve baten of toegevoegde waarde van een investering. De laatste soort baten kunnen voortkomen uit een wettelijke verplichting of een beleidsmaatregel. Ook in dergelijke gevallen is het de moeite waard de baten te benoemen. Dat maakt de communicatie naar de verschillende stakeholders beter. 

• checks & balances
• voorbeeld
• Ilities

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 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 elders op deze website

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.

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.

voorbeeld

voorbeeld van een breakdown van niet-functionele criteria in een ICT omgeving

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

Ilities

Hieronder geven wij een lijst met niet-functionele criteria. In het Engels, met een Nederlandse vertaling. Een korte omschrijving per 'ility'. Zal in de loop der tijd aangepast en aangescherpt worden. De relevantie en toepasbaarheid is sterk afhankelijk van de omgeving waarin de criteria worden gebruikt.

Een overzicht van te gebruiken Ilities

Dit deel is in ontwikkeling

De taken, verantwoordelijkheden, bevoegdheden en samenstelling van een stuurgroep worden in een zo vroeg mogelijk stadium vastgesteld door de leidinggevenden van de opdrachtgever van een project. Een voorbeeld is hieronder gegeven.

Alternatieve benamingen:
Product Breakdown: is in principe hetzelfde als een Work Breakdown,omdat bij de laatste elke activiteit op het laagste niveau namelijk gerelateerd is aan een resultaat.

Doel:
Het doel van een Work Breakdown Structure (WBS) is om het werk te verdelen in beheersbare werkpakketten die apart begroot, ingepland en gevolgd kunnen worden. Elk van deze pakketten kunnen worden toegewezen aan een verantwoordelijke persoon of afdeling.

Omschrijving:
De Work Breakdown Structure (WBS) is de ruggegraat van elk project! Merkwaardig genoeg krijgt dit onderdeel weinig aandacht in de literatuur over projectmanagement. Oorspronkelijk komt dit hulpmiddel vooral uit de bouw. Maar het is ook uitstekend bruikbaar bij alle andere projecten. Ongeacht of het een ICT project, research project of een verbeterproject is. De WBS is niets anders dan een opsplitsing van het project in meerdere, onderling samenhangende activiteiten. Moeilijk is te bepalen op welk niveau je gaat stoppen met de opsplitsing. Een kwestie van ervaring. Hoewel de work breakdown de ruggegraat van elk project is, in principe het terrein van de projectmanager, is het ook van wezenlijk belang voor de opdrachtgever. En wel om twee redenen. De eerste is dat de WBS het startpunt moet hebben vanuit de organisatie: de opsplitsing van activiteiten zal op het hoogste niveau de aansluiting moeten hebben bij de organisatie. Wat wil ik veranderen? En hoe wil ik het veranderen. De WBS kan hierbij helpen concrete invulling aan te geven. Ten tweede is een WBS belangrijk voor het sturen van het project. Scopebeheersing, kwaliteitsbewaking, risicomanagement, planning en kostenbeheersing. De work breakdown vormt de basis voor het managen van het project.

Toepassingsmogelijkheden

De Work Breakdown Structure is in principe in elke project omgeving toe te passen. Belangrijk is het moment op welk niveau gestopt wordt met de WBS. Dit is tevens het laagste planningsniveau. Activiteiten of acties binnen het laagste niveau van een WBS worden niet meer gepland, maar hiervan wordt de uitvoering bepaald op basis van prioriteit.

Synoniemen

Project Breakdown Structure, Product Breakdown Structure

Voordelen

Voordelen van een Work Breakdown Structure:

• een betere mogelijkheid om gebruik te maken van het systeem van 'checks and balances' en audits
• een betere mogelijkheid om gebruik te maken van contra expertise
• een betere controle op vooraf gedefinieerde werkzaamheden
• een betere verdeling van het projectbudget over de verschillende onderdelen
• een betere mogelijkheid om het werk te delegeren in afgebakende delen
• een betere inschatting van benodigde budget voor het betreffende onderdeel
• een betere risico inschatting en beheersing
• een betere mogelijkheid voor what-if scenario's
• een betere communicatie tussen betrokkenen

Componenten

De belangrijkste componenten van de WBS zijn:

• Structuur aanbrengen.
• Methoden van onderverdeling.
• Nummering of codering systeem.
• Niveaus van detaillering aanbrengen.
• Oprollen van gegevens
• Integratie van de WBS en OBS (Organization Breakdown Structure) om daarmee de verantwoordelijkheden te verdelen

Benadering

Belangrijk voor een opdrachtgever is om in een vroegtijdig stadium betrokken te worden bij de opzet van de Work Breakdown Structure. Voor hem is het belangrijk dat de WBS wordt opgezet vanuit een voor hem begrijpelijke en werkbare insteek. Hiermee wordt bedoeld dat de eerste stappen in een WBS aansluiten op zijn belevingswereld of in zijn werkdomein. En niet dat van de opdrachtnemer. Deze laatste zijn vaak geneigd een WBS op te zetten vanuit hun belevingswereld. Een opdrachtgever die zich niet in een vroegtijdig stadium met het opzetten van een WBS bemoeit, laat een belangrijke kans liggen. Een eenvoudig voorbeeld is hieronder gegeven voor het opzetten van een geautomatiseerd systeem voor de ondersteuning van de financiele processen, de marketing processen en de hrm processen (personeel). Het eerste voorbeeld is het opzetten van een WBS vanuit de wereld van de opdrachtnemer. Het tweede voorbeeld een benadering van de belevingswereld (werkdomein) van een opdrachtgever.

Nogmaals, het is een eenvoudig voorbeeld. Maar het gaat om het principe. In de werkelijkheid zal het vele malen ingewikkelder zijn om een goede WBS op te zetten, gezien vanuit het perspectief van een opdrachtgever. Laat deze kans echter niet liggen.

Numeriek voorbeeld

In de vorige paragraaf is aangegeven dat het voor een opdrachtgever belangrijk is dat de structuur van de WBS aansluit bij zijn belevingswereld. Ter illustratie een eenvoudig voorbeeld uit de bouw voor een project van vier huizen waarbij gebruik gemaakt wordt van het principe van de Terugverdiende Waarde Methode (of Earned Value). Een opdrachtgever wil in een oogopslag kunnen zien wat de voortgang per huis is. Een aannemer daarentegen is meer geïnteresseerd in de voortgang van de onderaannemers. Er kunnen op deze manier twee wezenlijk verschillende Work Breakdown Structures ontstaan.

Eerst het voorbeeld van de WBS voor de aannemer:

En het voorbeeld van een WBS voor de opdrachtgever:

Typische WBS

In onderstaande tabel staat een voorbeeld van een mogelijke opsplitsing in verschillende niveaus, de bijbehorende resultaten en een mogelijke doorlooptijd. Alles in relatie tot elkaar. Maak een planning niet onnodig ingewikkeld door tot op het laagste niveau te plannen. Een redelijke planning voor een opdrachtgever gaat tot 3 a 4 niveaus: de masterplanning. Detailplanningen zijn voor binnen het project. Uiteraard zullen de masterplanning en de detailplanning wel op elkaar aan moeten sluiten. Op het niveau van dagen en uren wordt normaliter met prioriteiten gewerkt.

Performance indicatoren

Als de WBS voor een project is bepaald, is het een volgende stap om de verantwoordelijkheden en bevoegdheden op elk niveau van de WBS vast te leggen. Als dit is gebeurd, worden afspraken gemaakt over de doelstellingen waaraan elk niveau van de WBS moet voldoen en over de performance indicatoren die bij deze doelstelling horen. Schematisch is e.e.a. in onderstaand schema weergeven. Ook voor een opdrachtgever is het belangrijk aan te geven over welke performance indicatoren hij gerapporteerd wil worden indien hij gebruik wil maken van de mogelijkheid in te zoomen tot op elk niveau van een WBS. In dit kader is de Terugverdiende Waarde Methode een uitstekend hulpmiddel voor een opdrachtgever.

Besturing

Zoals al eerder aangegeven is de WBS de ruggegraat van elk project en is belangrijk bij het aansturen van elk project. Voor een opdrachtgever, die niet zich niet te veel in detail met het project wil (en kan) bemoeien, is het een uitstekend middel om vanaf een hoog niveau in te zoomen tot op het laagste niveau van een project. Zonder dat hij zich inhoudelijk met de betreffende activiteit bezig houdt. De basis voor de besturing van een project, of de onderliggende activiteiten, bestaat uit drie processen: een plannend proces, een uitvoerend proces en een controlerend proces. Binnen elk uitvoerend proces herhaald de cyclus zich. De normstelling binnen een controlerend proces wordt op een hoger liggend niveau vastgelegd en kan niet zonder meer worden veranderd. In onderstaand figuur is het principe van besturing weergegeven.