De rol van kwaliteit bij de slaagkans van een project

Een vak apart
Eén van de meest uitdagende, maar ook minst gewaardeerde beroepen in het gebied van mangement is de discipline van project management. Het verschil tussen een project manager en een functionele manager is dat een project manager geen vast omlijnd team heeft. Een functionele manager, bijvoorbeeld het hoofd van een marketingafdeling, heeft altijd dezelfde mensen onder zich en het mag aangenomen dat hij een heleboel technische kennis heeft over marketing. Een project manager daarentegen werkt met mensen uit verscheidenene afdelingen: business, IT, compliance, marketing, finance, etc. Meestal heeft een project manager geen directe autoriteit over de mensen die aan een project werken en dat maakt van project management een moeilijke discipline als het aankomt op het managen van mensen. Een bijkomende moeilijkheid is dat project managers liefst over een brede kennis beschikken. Niet alleen business of IT, maar ook over de wetgeving waarin een project fungeert, de financiën van een project en andere factoren. De projecten zelf kunnen ook verschillen in complexiteit. Een project dat min of meer hetzelfde is als tien voorgaande projecten is een stuk simpeler dan een project dat op meerdere locaties wordt uitgevoerd over de organisatie heen.

In een organisatie worden project managers meestal in het middenkader geplaatst, net onder het niveau van de functionele managers. De reden hiervoor is omdat functionele managers een directe beslissingsbevoegdheid hebben over middelen, maar project managers niet. Een functionele manager kan bijvoorbeeld schuiven met mensen bij verscheidene projecten, terwijl de project manager leidzaam moet toezien. Zo beschikt een project manager ook niet over een direct budget. Zijn taak is om toe te zien dat de geraamde kosten niet worden overschreden. Het is dus als project manager niet zomaar mogelijk om extra middelen aan te wenden. Functionele managers groeien gemakkelijker door in de hiërarchie, terwijl project managers het glazen plafond van het topkader nauwelijks of niet kunnen doorbreken, tenzij ze eerst van functie verwisselen, bijvoorbeeld functioneel manager.

Kans op falen
Dat project management geen gemakkelijk vak is, bewijzen de cijfers uit onderzoek. Maar liefst zeventig procent van de projecten worden later als gefaald omschreven. Gefaald wil overigens niet zeggen dat een project totaal mislukt is. Een gefaald project kan talloze redenen hebben: de kosten zijn zo hoog opgelopen dat de voordelen dit niet meer kunnen dekken, het project heeft te lang geduurd waardoor de concurrentie eerder op de markt is, de beloofde voordelen van het project worden in de realiteit niet verwezenlijk, klanten zijn niet tevreden over het afgeleverde product, etc. Ontevreden klanten zijn misschien wel de ergste reden waarom een project mislukt. Dit komt omdat kwaliteit het allerbelangrijkste aspect van een project is, terwijl er in de praktijk relatief weinig aandacht aan wordt gespendeerd.

Een project wordt meestal gemanaged via de triple constraint. Deze drie beperkingen (tijd, kosten en scope) bepalen de omvang en grenzen van een project. Als een SAP-project vijf miljoen euro kost en één jaar duurt, worden de lopende resultaten altijd vergeleken met deze eindpunten. Het reeds gespendeerde budget wordt dus vergeleken met de geschatte kosten van vijf miljoen euro. Dit geldt evenzeer voor de tijdsduur. Aan de scope wordt minder aandacht geschonken. De scope komt enkel in beeld wanneer er geld- en/of tijdsnood is en besloten wordt om een deel van de scope links te laten liggen. De triple constraint wordt meestal in een driehoeksvorm weergegeven om aan te geven dat een beslissing op één aspect (bijvoorbeeld kosten) een invloed zal hebben op één of twee andere aspecten (in dit geval tijd en scope). Als een project manager beslist dat de kosten te hoog oplopen, kan hij besluiten om een deel van de scope niet uit te voeren, zodat er een deel van de tijd vrijkomt. Kwaliteit is verbonden aan deze drie aspecten en elke beslissing op tijd, kosten of scope heeft een impact op de kwaliteit. Helaas spenderen project managers weinig aandacht om kwaliteit omdat dit volgens de meesten onmeetbaar is.

Quality baseline
Het is inderdaad moeilijk om kwaliteit te meten omdat het nu eenmaal geen exacte wetenschap is. Voor persoon a kan kwaliteit synoniem zijn voor goed genoeg, terwijl persoon b totale perfectie eist. Aan deze subjectieve beoordeling van kwaliteit kan een organisatie niet onderuit en moet het rekening houden met wat klanten zeggen. Daarom zeggen zaken zoals enquetes over klantentevredenheid en aantal klachten veel over de kwaliteit van een bedrijf en bijgevolg ook de projecten. Bovendien kan kwaliteit gemeten worden aan de hand van het aantal defects. In een software project is dit bijvoorbeeld het aantal bugs dat wordt gevonden tijdens de testfase.

Al deze dingen kunnen beschreven worden in de quality baseline. Dit is een document waarin de gewenste kwaliteit staat beschreven en dit wordt vergeleken met de behaalde resultaten tijdens het project. Dit klinkt als een complex proces, maar er bestaan klant-en-klare oplossingen hiervoor. Denk maar aan het kwaliteitsproces dat Prince2 gebruikt. Dit beschrijft hoe je kwaliteit definieert, vaststelt, meet en vergelijkt. Het bevat het plannen en controleren van kwaliteit, maar je kan het ook gebruiken om kwaliteit te verbeteren in een organisatie.

Geen heilige graal
Prince2 staat gekend als een rigide procesmodel, maar niets weerhoudt een project manager ervan om de beste en meest relevante onderdelen hiervan uit te lichten en het toe te passen in een project. Het probleem hierbij is dat wanneer dit niet eerder werd gedaan, de kans bestaat dat het project gaat verdrinken in de goede bedoelingen als er te veel in één keer wordt geïmplementeerd. Bij een eerste implementatie kan een project manager zich beperken tot de absolute noodzakelijkheden zoals een quality strategy (of plan) en technieken om dit te meten. Dit hoeft zeker niet ingewikkeld zijn. In een software project kan worden beschreven hoeveel bugs er per deadline mogen aanwezig zijn en welke impact dit heeft op het project. Het is een erg eenvoudige aanpak met een verrassend sterk resultaat. Van hieruit kan men dan verder bouwen om het kwaliteitsaspect van een project te verbeteren. Het voorgaande voorbeeld is zo simpel dat verreweg de meeste organisaties dit al doen, maar hebben dan moeilijkheden om dit verder te verbeteren.

Het is aanlokkelijk om met een heleboel methodologieën af te komen zoals CMMi, maar dit garandeert niet altijd succes. Het is door een combinatie van ervaring opdoen, de juiste expertise in huis hebben, gezond verstand hebben en over het juiste proces beschikken dat de kwaliteit in een project verbeterd kan worden.