Deel 3

Voorbeeld opzet handboek voor ict kwaliteit

1. Toelichting op dit document

Dit document is het derde deel van een voorbeeld van een kwaliteitshandboek ICT. Het voorbeeld is daadwerkelijk geïmplementeerd in de praktijk. Dit derde deel gaat in op systeemontwikkeling (waterval methode SDM-2), beheer (ITIL-based) en projectmanagement (ook mogelijk via Prince 2).
Het handboek is geschreven vanuit de behoefte van de bedrijfsprocessen en gebruikers en is bedoeld om de ICT-afdeling zo te laten werken, dat aan de gebruikers een adequate informatievoorziening wordt gegarandeerd. Er wordt dan vooral ook ingezoomd op de activiteiten die voor de gebruikers van belang zijn, zodat zij begrijpen, dat hun participatie cruciaal is om die adequate informatievoorziening te realiseren. Het maakt hierbij niet uit of het om een interne of externe ICT-afdeling gaat. Het handboek is ook zeker bruikbaar om tot een werkzame samenwerking te komen in het geval van outsourcing is , waarbij taken, verantwoordelijkheden en bevoegdheden zijn vastgelegd.

Om hergebruik gemakkelijk mogelijk te maken, is de bedrijfsnaam in dit document vervangen door PPPP. Via zoek en vervang kunt je hier uiteraard de naam van jouw eigen organisatie invullen.

Het handboek is gezien zijn omvang opgesplitst in drie delen om problemen met downloaden te voorkomen. In deel 1 vindt je de inleiding op het handboek, die bestaat uit de volgende hoofdstukken:

2. Inleiding: duidelijkheid als sleutelwoord

3. Duidelijke doelstellingen PPPP-IT

4. Het PPPP-IT kwaliteitssysteem

Deel 2 gaat in op:

5. De systeemontwikkelingsmethode

Deel 3

6. Inrichting van het project

In deel drie van dit handboek werken we de inrichting van het project verder uit.
Door een adequate inrichting van het project kan het opdracht- en het projectmanagement er zorg voor dragen, dat het project succesvol beëindigd wordt. Dit betekent: een effectieve beheersing waardoor het overeengekomen resultaat op tijd en binnen budget gerealiseerd kan worden.
Concreet moet het projectmanagement daartoe zorgdragen voor het normeren en bewaken van de volgende vijf beheersaspecten:

kwaliteit;
tijd;
geld;
organisatie;
informatie.

Figuur 11 geeft de samenhang tussen deze vijf beheersaspecten weer. Eén ding blijkt daaruit in één oogopslag: zeker ook als het om de beheersing gaat, staat het kwaliteitsaspect bij PPPP-IT centraal. Letterlijk en figuurlijk.

De beheersing van het aspect kwaliteit richt zich op het ontwikkelen en bewaken van de normen waaraan het proces en het projectresultaat moeten voldoen. Aangezien het resultaat samenvalt met het doel is de kwaliteit het centrale beheersaspect van het project.
De beheersing van het aspect tijd is gericht op de zorg om het projectresultaat op het afgesproken tijdstip gereed te hebben. Om dit mogelijk te maken moeten er afspraken worden gemaakt en bewaakt over de capaciteit en de inzetbaarheid van mensen en middelen.
De beheersing van het aspect geld betreft de zorg om het resultaat binnen de gestelde budgetten te realiseren.
De beheersing van het aspect organisatie richt zich op de interne en externe communicatie in en rondom het project. Hierbij valt te denken aan zaken als taken, verantwoordelijkheden, bevoegdheden, besluitvorming, relatiebeheer enzovoort.
De beheersing van het aspect informatie betreft de zorg voor het beheer en de distributie van de actuele informatie. Tot dit beheersaspect behoren zaken als documentatie, versiebeheer, rapportagestructuren, wijzigings- en goedkeuringsprocedures en projectadministratie.

De vijf beheersaspecten dekken de projectbeheersing op zowel operationeel als op voorwaardenscheppend niveau af.

Op operationeel niveau zijn primair tijd, geld en kwaliteit van belang en onderling uitwisselbaar. Voor de oplossing van bijvoorbeeld een tijdsprobleem kan ook gekozen worden voor het inzetten van meer capaciteit (geld) of voor het naar beneden bijstellen van de eisen aan de functionaliteit (kwaliteit).
Op voorwaardenscheppend niveau zijn primair kwaliteit, informatie en organisatie van belang en met elkaar samenhangend.

De inrichting en het functioneren van het kwaliteitssysteem worden in de paragrafen 3.1 (operationeel niveau) en 3.2 (voorwaardenscheppend niveau) nader uiteengezet.

6.1 Inrichting van het operationele niveau

De primaire verantwoordelijkheid van het opdracht- en projectmanagement is het bereiken van het overeengekomen resultaat binnen de gestelde randvoorwaarden, meestal tijd en geld. Dit impliceert dat de opdracht- of projectleider van te voren moet onderzoeken of het inderdaad mogelijk is om het gevraagde resultaat binnen de randvoorwaarden te realiseren.
In de eerste plaats zullen dan de voorwaarden vooraf getoetst moeten worden. Daarnaast zal de opdracht- of projectleider bij projecten van het opdrachttype 2 een drietal onderzoeken (laten) doen naar de kwaliteit van de uitgangssituatie, te weten:

een kwaliteitsaudit op het voorliggende product,
dit om er zeker van te zijn dat het voorgaande product als basis kan dienen voor de verdere ontwikkeling;
een risicoanalyse,
dit om zicht te krijgen op eventuele verstoringen tijdens het project;
een begrotingstechniek,
om te bepalen of het resultaat inderdaad binnen de randvoorwaarden gerealiseerd kan worden (in termen van Prince 2 de businesscase).

Levert één van deze onderzoeken een onbevredigend resultaat op, dan zal met de klant overlegd worden op welke wijze het gesignaleerde probleem opgelost dient te worden. Daarna kan worden overgegaan tot het afgeven van een realistische offerte, waarin ook alle op te leveren producten worden genoemd. In het Kwaliteitshandboek is een nadere omschrijving van deze producten opgenomen, zodat de klant ook nauwkeurig de tegenprestatie van PPPP-IT kent.
Nadat overeenstemming is bereikt over de opdracht, werkt de projectleider die opdracht uit in een plan waarin de norm wordt gesteld voor de verschillende beheersaspecten.
Na goedkeuring van dit plan door de opdrachtgever wordt de opdracht conform het plan uitgevoerd.
De projectleider bewaakt de beheersaspecten door ze te meten en te vergelijken met de norm. Eventuele afwijkingen worden geanalyseerd en bijgestuurd.

Het beslissen kan drie mogelijke uitkomsten hebben, te weten:

bijstelling van de norm voor één van de vijf beheersaspecten, vanzelfsprekend binnen de gestelde opdracht en randvoorwaarden;
directe actie op de uitvoering, bijvoorbeeld door het motiveren of begeleiden van medewerkers;
het geaccepteerd krijgen van een wijziging in de opdracht of de randvoorwaarden of bijsturing op de afgesproken inzet van de gebruikersorganisatie.
Daarnaast kan worden volstaan met niets doen, mits de afwijking maar binnen de grenzen blijft.

6.2 Inrichting van het voorwaardenscheppende niveau

Het doel van een project is het opleveren van een product dat aan de kwaliteitsnormen voldoet. Deze kwaliteitsnormen omvatten alle vastgelegde en vanzelfsprekende behoeften. Om het mogelijk te maken dat hieraan wordt voldaan, zullen de volgende zaken geregeld moeten worden:

Door zorgvuldige specificaties en richtlijnen worden voorzover mogelijk ook de vanzelfsprekende behoeften vastgelegd. De specificaties zijn veelal afkomstig van operationele medewerkers, terwijl de richtlijnen doorgaans afkomstig zijn van het management of zijn staf.
Door verificatie wordt geconstateerd of de producten op zich correct en onderling consistent zijn en of ze voldoen aan alle technische criteria en standaards. Deze validatie wordt op productniveau uitgevoerd door projectmedewerkers en op faseniveau door PPPP-IT onder verantwoordelijkheid van de ‘manager kwaliteitsborging’.
Door validatie wordt gecheckt of de vastgelegde specificaties inderdaad de behoeften afdekken en of de specificaties compleet zijn. De verificatie wordt uitgevoerd door materiedeskundigen uit de organisatie van de klant.
Door formele goedkeuring wordt duidelijkheid verschaft over de status (bevriezing) van de producten en de verantwoordelijkheid over de besluitvorming met betrekking tot wijzigingsvoorstellen. Door de formele goedkeuring van producten waarin functionele specificaties zijn vastgelegd, wordt bovendien de verantwoordelijkheid voor de acceptatie van het product overgedragen aan de fiatteur. Dit behoort dus de manager of staffunctionaris te zijn, die ook binnen de lijnorganisatie verantwoordelijk is/wordt voor deze zaak. Acceptatie vindt doorgaans alleen plaats bij mijlpaalproducten.

Voorts worden er in de projectopdracht een aantal randvoorwaarden genoemd waarbinnen de gewenste kwaliteit gerealiseerd moet worden. Deze randvoorwaarden betreffen meestal de aspecten tijd en geld. In de randvoorwaarden zit echter meestal een marge die de opdrachtgever in geval van problemen de mogelijkheid geeft om prioriteiten te stellen in de driehoek tijd, geld en kwaliteit.

6.2.1 Producten en beslismomenten

Om de voortgang van het gehele proces te kunnen meten, worden er in de loop van het proces meetpunten ingebouwd, waarop beslissingen genomen kunnen worden ten aanzien van een eventuele bijsturing. Deze meetpunten liggen op drie niveaus:

Productniveau
Producten zijn vooral bedoeld om te valideren en te verifiëren. Deze producten hebben primair een functie op project/werkgroep- niveau, mits de gebruikers hierin zitting hebben. Ze geven de projectleider de mogelijkheid om bij te sturen binnen de opdracht en randvoorwaarden.
Mijlpaalproductniveau
Mijlpaalproducten zijn enerzijds een ‘gewoon’ product en worden als zodanig behandeld, maar zijn anderzijds bedoeld als verantwoording naar de stuurgroep. De stuurgroep heeft de bevoegdheid om zowel op de inhoud als op de randvoorwaarden bij te sturen binnen haar mandaat. Acceptatie van een mijlpaalproduct betekent dat de in het product beschreven situatie bevroren wordt en slechts via de formele wijzigingsprocedure geamendeerd kan worden.
Faserapportniveau
Faserapporten zijn enerzijds ‘normale’ mijlpaalproducten, maar zijn anderzijds bedoeld als verantwoording aan de organisatie. De organisatie moet hierop een “go/no go” beslissing nemen en heeft het recht om te amenderen.

Uit al het bovenstaande blijkt dat een zorgvuldige toewijzing van taken, verantwoordelijkheden en evoegdheden van het grootste belang is om te waarborgen dat het resultaat conform de verwachting van de gebruikersorganisatie is. Allereerst betreft dit taken op uitvoerend niveau:

specificeren,
vastleggen van specificaties in producten,
valideren en
verifiëren.

Deze taken zijn onderdeel van het project. De uitvoerders van deze taken vallen dus (in de projectgroep of de werkgroep) onder de projectleider.
Daarnaast is er een tweetal verantwoordelijkheden op besluitvormend niveau:

De bewaking van de opdracht door de opdrachtgever binnen de randvoorwaarden. De projectleider legt hierover verantwoording af aan die opdrachtgever.
De formele acceptatie van de producten door de functionaris die na het project aangesproken kan worden op de inhoud ervan; de afdelingsmanager bijvoorbeeld op de functionaliteit van het systeem of de gegevensbeheerder op de integriteit van het datamodel. Om de acceptatiegraad te verhogen, verdient het aanbeveling om de producten niet alleen inhoudelijk maar ook qua opzet en vorm herkenbaar te maken voor de gebruikersorganisatie. Daarom behoort het geven van richtlijnen eveneens tot de taak van deze functionarissen. In sommige organisaties is het verstrekken en bewaken van richtlijnen uitbesteed aan stafafdelingen zoals een afdeling Kwaliteit of Personeelszaken.

Gezien hun verantwoordelijkheid dienen de functionarissen met de inhoudelijke verantwoordelijkheid bòven de projectleider gepositioneerd te worden in bijvoorbeeld een stuurgroep, maar ònder de coördinerende functie van de opdrachtgever. Die laatste is immers over alle betrokkenen heen verantwoordelijk voor de prioriteitsstelling.
In geval van onenigheid tussen stuurgroepleden zorgt de opdrachtgever voor een eenduidig standpunt van de stuurgroep.
Het spreekt vanzelf dat het niet nodig is voor de formele goedkeuring van elk product de voltallige stuurgroep bijeen te roepen.

6.2.2 Product/betrokkenen matrix

Om de taken en verantwoordelijkheden eenduidig toe te wijzen, wordt gebruik gemaakt van een product/betrokkenen-matrix, waarvan een voorbeeld op de volgende pagina is afgebeeld. Voor PPPP zal deze nog verder uitgewerkt worden. In deze matrix staat per op te leveren product beschreven wie welke taak en/of verantwoordelijkheid heeft.
In de product/betrokkenen matrices uit het Kwaliteitshandboek staat bij de betrokkene meestal aangegeven welke expertise vereist is. In het Plan van Aanpak moet dan worden vastgelegd of de expertise wordt geleverd door de klant of door het PPPP-IT en wie de betreffende ‘expert’ is.

Voor de uitvoerende taken is het van belang te zoeken naar de grootste materiedeskundigen of specialisten binnen de organisatie, mensen die als belangrijke eigenschap het vermogen moeten hebben in teamverband te kunnen functioneren.
Voor de beslissers zijn de desbetreffende verantwoordelijken uit de gebruikersorganisatie de meest aangewezenen.
Voor elk specifiek project, zullen met name de betrokkenen nauwkeurig gespecificeerd moeten worden. Voorbeeld product / betrokkenenschema mijlpaalproducten

7. Meer over kwaliteitsbeheer ICT

In het document ‘Checklist SDM-activiteiten‘ vindt je een checklist om producten te beoordelen.
Als je kiest voor iteratief ontwikkelen verwijzen we je naar het document ‘Iterative Application Development’ (IAD).
Meer over de inrichting van beheer conform ITIL vindt je in de rubriek ‘ Checklists review ITIL-processen‘.

8. Nawoord

Tot zover de Basismodule van het PPPP-IT Kwaliteitshandboek, waarin de algemene uitgangspunten en de essentie van PPPP-IT’s kwaliteitsstreven zijn uiteengezet.
De uitwerking van deze basisbeginselen in concrete normen en standaards vindt op het tweede niveau in een aantal modules plaats. Deze modules vormen samen ‘het hart’ van het Kwaliteitshandboek.
In het daarop volgende derde niveau vindt de gebruiker tenslotte ondersteunend referentiemateriaal van waaruit verder gewerkt kan worden.