IMPACT

Kwaliteitsbeheersing voor projecten

De centrale vraag bij het beheersen van de kwaliteit van een project is: wat moet je allemaal doen en waar moet je rekening mee houden, zodat het projectresultaat ook voldoet aan de door de opdrachtgever gestelde eisen? Kwaliteit is een ruim begrip, waarbij diverse onderdelen worden onderscheiden: inhoudelijke kwaliteit, kwaliteit van het managementproces, configuratiemanagement (zekerheid dat je aan de juiste producten werkt), veiligheid in de projectomgeving, kennismanagement (lessons learned, ervaringen uit het verleden) en juridische aspecten (contracten, contractvormen en aanbesteding etc.). Dit artikel gaat over de inhoudelijke kwaliteit.

De inhoudelijke kwaliteit heeft betrekking op de kwaliteit van het uiteindelijke projectresultaat en op de kwaliteit van de tussenproducten (de resultaten van iedere projectfase). Het eindproduct is meestal fysiek tastbaar. Dit hoeft echter niet altijd zo te zijn, denk bijvoorbeeld aan een onderzoeks- of adviesrapport of aan de ontwikkeling van een dienst of software. De tussenproducten zijn meestal documenten, maar zijn mogelijk ook fysiek tastbaar, zoals het geval is bij een prototype of een testopstelling. Om de kwaliteit van een op te leveren product te garanderen, moet het volgende worden ingericht c.q. aanwezig zijn:

  • Duidelijke specificaties (kwaliteitseisen) en acceptatiecriteria van het tussen- en eindproduct; lees: het projectfaseresultaat en het project(eind)resultaat;
  • Gedefinieerde normen en standaards;
  • Gekwalificeerde projectmedewerkers/reviewers/experts;
  • Onafhankelijke beoordelingen van de projectfase- en projecteindresultaten;
  • Het borgen van wijzigingen m.b.t. de kwaliteit (change control).


Projectfasering, PDCA-cyclus en kwaliteit

Een project begint met een idee en eindigt met het opleveren en gebruiken van het projectresultaat. Hierbij doorloopt een project verschillende fasen. Stapsgewijs krijgt het projectresultaat zijn vorm, van globaal naar detail, met duidelijk vastgestelde tussenresultaten en beslismomenten. Iedere fase heeft haar eigen kenmerken en op te leveren resultaten. De projectfasen met enkele voorbeelden van faseresultaten staan figuur 1.


Ieder projectfase doorloopt de Plan-Do-Check-Act-cyclus. Het op te leveren projectfaseresultaat wordt vastgelegd in de scope (of works) van die fase. Hiervoor wordt dit projectfaseresultaat uitgesplitst in concrete op te leveren producten, de PBS (Product Breakdown Structuur), die op het einde van de betreffende fase klaar moeten zijn. Het gaat dus om het opleveren van de scope (de PBS) van de betreffende projectfase volgens vooraf afgesproken kwaliteitscriteria binnen een afgesproken tijd en binnen een voor de projectfase vastgesteld budget.

Figuur 1: Fasering en (verschillende voorbeelden van) projectfaseresultaten

Bij de beheersaspecten scope, kwaliteit, tijd en geld horen vaste afspraken en eventueel een norm (met toleranties), waarbij van de beheersaspecten tijd en geld ook tussentijds een prognose wordt gemaakt tot aan het einde van de projectfase en het gehele project. Het dilemma van het opleveren van de scope volgens afgesproken kwaliteit binnen de afgesproken tijd en budget wordt ook wel het duivelsvierkant genoemd (figuur 2). Dit duivelsvierkant refereert aan de manier waarop deze beheersaspecten zich tot elkaar verhouden. Een beslissing in het voordeel van geld (dus goedkoper, een besparing) leidt mogelijk tot een nadeel voor de scope (niet alles wordt opgeleverd) of de kwaliteit (slechtere kwaliteit van het eindproduct) of de tijd (het zal langer gaan duren) of een combinatie daarvan. Een beslissing in het voordeel van de tijd (het duurt korter) betekent eventueel een nadeel voor de scope (niet alles wordt opgeleverd) of de kwaliteit (slechter) of het budget (duurder). Waar het om gaat, is dat als bij een van deze beheersaspecten iets verandert dat gevolgen kan hebben voor de andere beheersaspecten. Deze beheersaspecten en de gevolgen van wijzigingen (changes) moeten dus steeds worden bekeken en bewaakt.

Figuur 2: Het duivelsvierkant

Het voordeel van dit dilemma is flexibiliteit, die weer kan worden gebruikt bij value engineering. Hierbij gaat het erom te kijken welke specificaties met welke kwaliteitseisen kunnen worden opgeleverd voor een vastgesteld budget.


Het kan gebeuren dat afgesproken eisen of wensen tijdens de uitvoering van het project moeten worden gewijzigd. Dit kan verschillende oorzaken hebben. In de meeste gevallen hebben dit soort veranderingen gevolgen voor de doorlooptijd en/of de kosten van het project. Om te voorkomen dat hierover later misverstanden ontstaan (de opdrachtgever wil een verandering (b.v. betere kwaliteit) en is later ontevreden over de daardoor ontstane hogere kosten), is het belangrijk dat de verandering pas wordt doorgevoerd als de consequenties bekend zijn en de opdrachtgever expliciet akkoord is gegaan met de wijziging.


Er zijn dus kwaliteitseisen voor de faseproducten en het eindresultaat (datgene wat klaar is op het einde van de realisatiefase). De kwaliteitseisen en acceptatiecriteria van het faseproduct staan in het plan van aanpak van die projectfase bij het beheersaspect kwaliteit. De kwaliteitseisen van het eindproduct worden vastgelegd in het Programma van Eisen, een document dat wordt opgesteld tijdens de definitiefase van een project.

Kwaliteit projectresultaat

De kwaliteit van het eindproduct wordt tijdens de definitiefase vastgelegd in het PvE (Programma van Eisen). Eindproducten zijn bijvoorbeeld apparaten, machines, auto’s, wegen, bruggen, gebouwen, installaties, computersystemen, een evenement, maar ook software, boeken, rapporten en adviezen.

In het PvE worden eisen en wensen geformuleerd, waarbij aan eis voldaan moet worden. Het gaat dan om eisen en wensen met bijbehorende acceptatiecriteria op het gebied van:

  • functionaliteit – de prestaties van het projectresultaat. Bijvoorbeeld, de auto moet een snelheid kunnen halen van 200 km/uur binnen 10 seconden of het huis moet een dak hebben met een hellingshoek van 24 graden;
  • operatie – de gebruiksvriendelijkheid van het projectresultaat. De bestuurder moet gemakkelijk, zonder het stuur los te laten, de radio kunnen bedienen of de rolluiken worden in huis elektrisch bediend;
  • techniek – een bepaalde techniek die moet wordt toegepast, bijvoorbeeld een bepaald type transmissie of het huis wordt verwarmd met aardwarmte;
  • materiaal – bijvoorbeeld de carrosserie moet bestaan uit aluminium of de ramen hebben een bepaalde isolatiewaarde;
  • onderhoud – hierbij gaat het om het onderhouden van het projectresultaat. De lampen moeten gemakkelijk te vervangen zijn. Dit betekent dat geen onderdelen weggenomen hoeven te worden om een koplamp te vervangen of er moet een revisieopening worden gemaakt voor de riolering;
  • ontwerp/design, uiterlijke verschijningsvorm – de auto mag niet langer zijn dan 3 meter en moet in de kleuren rood, blauw en groen leverbaar zijn of de voordeur moet van hout zijn met glas.
  • veiligheid tijdens gebruik en onderhoud – de auto moet voor alle inzittenden een airbag hebben of de ramen op een eerste verdieping moeten een balustrade hebben.

Er worden acceptatiecriteria vastgelegd om de eisen en ook verwachtingen van de klant te kunnen managen. Dit is een lijst met meetbare kwaliteitsverwachtingen waaraan een product moet voldoen voordat de klant het accepteert. Ook wordt de manier waarop dit wordt getest vastgelegd. Soms is de lijst van eisen en wensen erg lang. De vraag is: is dit allemaal wel nodig en is het haalbaar in de tijd en met het budget? Het is daarom nuttig de eisen te prioriteren. Dit helpt ook bij het nemen van beslissingen als er gezien tijd en budget concessies moeten worden gedaan. De MoSCoW-methode is hiervoor zeer geschikt:

  • must have – een echte eis, essentieel voor het succes van het project;
  • should have – is zeer gewenst, maar een vergelijkbare eigenschap is ook goed genoeg;
  • could have – deze eis mag alleen meegenomen worden als er voldoende tijd voor is;
  • won’t have – deze eis zal nu niet aan bod komen.

De kwaliteit van een projectresultaat is goed als het voldoet aan de specificatie en acceptatiecriteria (eisen van de klant), geschikt is voor gebruik en de klant tevreden stelt. Bij het beheersen van kwaliteit gaat het er vooral om veilig te stellen dat het projectresultaat uiteindelijk voldoet aan de eraan gestelde inhoudelijke eisen en wensen, niet meer en niet minder (“goed is goed genoeg”).

De inhoudelijke kwaliteit wordt uiteindelijk beoordeeld aan het einde van de realisatiefase. Er wordt dan gekeken of het eindresultaat voldoet aan de vastgestelde specificaties en acceptatiecriteria (uit de definitiefase). Natuurlijk worden er tijdens de realisatiefases ook al zaken getest, wordt het materiaal gecontroleerd en worden deelopleveringen afgenomen.

Kwaliteit projectfaseresultaat

De producten die aan het einde van de diverse projectfasen worden opgeleverd, de tussenproducten, zijn meestal documenten. De kwaliteit van een tussenproduct wordt vastgelegd in het plan van aanpak van die fase bij het beheersaspect kwaliteit. Zo worden in het plan van aanpak van de definitiefase de kwaliteitseisen van het PvE zelf vastgelegd. Enkele kwaliteitseisen voor het PvE zijn bijvoorbeeld dat alle soorten eisen van het eindresultaat (functioneel, operationeel, onderhoud etc.) zijn opgenomen en/of dat een expert hierover een advies of second opinion geeft. Een manier om de kwaliteit van de opgeleverde rapporten te controleren is de toepassing van de inspectiemethode die door M.E. Fagan (1986) is ontwikkeld (zie figuur 3). Deze methode verloopt als volgt.

Een rapport of document (b.v. haalbaarheidsstudie, PvE, ontwerptekeningen) wordt opgesteld volgens een afgesproken standaard. Op het moment dat het document af is, wordt door de inspectieleider (moderator) een inspectie georganiseerd (plannen review, 1). De rol van inspectieleider kan b.v. door de projectcontroller worden uitgevoerd. Bij een inspectie zijn de volgende personen aanwezig: de inspectieleider, de auteur(s) van het te inspecteren document (producer), enkele mensen die het document gaan inspecteren (reviewer, gewoonlijk twee tot drie) en een schrijver (scribe) die de gevonden fouten noteert. De mensen die het document inspecteren zijn bijvoorbeeld de leden van het projectteam, leden van de klankbordgroep of onafhankelijke experts.

De volgende stap is de kick-off (2). Tijdens de kick-off legt de inspectieleider de methode/werkwijze uit aan diegenen die er nog niet mee bekend zijn. Tevens worden enkele documenten uitgereikt. Het uitgereikte materiaal bestaat uit het document dat geïnspecteerd gaat worden, de standaard volgens welke het document is opgesteld, een checklist waarmee het document wordt gecontroleerd en indien aanwezig het document dat bij de voorgaande projectfase hoort. De leden van het inspectieteam bereiden zich individueel (3) voor op de inspectiebijeenkomst. De inspectieleden bestuderen het document en zoeken daarbij naar fouten. Ze leggen de fouten vast op het individuele bevindingenformulier.

Tijdens de inspectie screenen de deelnemers het document (gezamenlijke reviewsessie, 4). Het is de bedoeling om fouten in het document op te sporen. Iets is fout als een inspectielid iets als zodanig kwalificeert. De beoordeling is subjectief. Een fout wordt in een van de volgende drie klassen ingedeeld:

  1. minor (m) – fouten die variëren van spelfouten tot fouten in de zinsconstructie;
  2. major (M) – fouten die, als ze niet ontdekt waren, tot aanpassingen aan het uiteindelijke product hadden geleid;
  3. super major (SM) – fouten die, als ze niet ontdekt waren, een geheel nutteloos product zouden hebben opgeleverd.

De schrijver legt de fouten vast die door de inspectieleden zijn gevonden. Ten slotte zal de auteur van het geïnspecteerde document de fouten corrigeren en een nieuw document uitbrengen (5). De verbeteringen worden teruggekoppeld (6). Eventueel wordt besloten om het document opnieuw te inspecteren. Het is gebleken dat het oplossen van fouten in de latere projectfasen of als het project zelf helemaal af is, tien- tot honderdmaal meer kost dan dat het kost om inspecties in de eerdere projectfasen te houden.

Figuur 3: Fagan-inspectie: kwaliteitsreview van documenten

Het borgen van kwaliteit

De inhoudelijke kwaliteit van een project moet worden geborgd. De projectmanager is integraal verantwoordelijk voor het project en ook verantwoordelijk dat er reviews en testen plaatsvinden. Hij kan zich hierbij laten ondersteunen door een project controller, die b.v. een quality review organiseert. De eerste stap bij het borgen van de kwaliteit is echter het maken van een kwaliteitsplan. Een kwaliteitsplan bestaat uit drie onderdelen:

  1. De kwaliteitseisen van het project(fase)resultaat
  2. De acceptatiecriteria (o.a. normen en standaarden) voor het beoordelen van de kwaliteitseisen
  3. De methoden/instrumenten om te meten of (fase) resultaat ook werkelijk aan de norm voldoen.


Het kwaliteitsplan is opgenomen in het plan van aanpak van een projectfase als het gaat om de kwaliteit van het faseproduct en in het Programma van eisen als het gaat om de kwaliteit van het eindproduct.


Gedurende het project kan de opdrachtgever de gewenste kwaliteit wijzigen. Als dat het geval is, zal duidelijk moeten worden vastgelegd wat de gevolgen daarvan zijn. Dit gebeurt ook door middel van een wijziging, een change. De gevolgen worden in kaart gebracht en de opdrachtgever moet deze quality change accorderen voordat die wordt uitgevoerd. Periodiek wordt het beheersaspect kwaliteit aan de opdrachtgever teruggekoppeld via een voortgangsrapportage.

Tabel 1: In te bouwen control in de PDCA-cyclus

In tabel 1 staat in het kort per stap uit de PDCA-cyclus samengevat welke controls er moeten worden ingericht om het beheersaspect kwaliteit in de grip te houden.

Over de auteur:

Ir. Guido Fröhlichs RC (CAP-able) is zelfstandig organisatieadviseur, licensed NLP-coach en auteur van het boek “Projecten en projectportfolio in control: mens, methoden en proces”, guido@cap-able.nl en www.cap-able.nl.

Volgende artikel: Rewind