Rik Marselis en Erik Brouwer laten in ‘Testen binnen Prince II’ (Computable, 23 april 2004) de fundamenten van deze methodiek trillen, meent J.H.E. Roos.
Ik onderschrijf dat Prince II in Europa steeds meer een de facto standaard voor projectenmanagement wordt, dat er gecontroleerd en getest moet worden, en dat het Prince II-handboek geen hoofdstuk bevat over testmethodieken.
Prince II laat je vrij in de keuze van je testmethodiek, maar vraagt wel hiervoor de aandacht bij het samenstellen van het projectkwaliteitsplan. Dit plan is onderdeel van het pid (project initiatie document). In dit plan staat beschreven hoe de kwaliteit van de te realiseren producten geborgd wordt, zodat voldaan wordt aan de kwaliteitsverwachtingen van de klant volgens de afgesproken kwaliteitsstandaarden.
Verloren
Het projectkwaliteitsplan bevat: kwaliteitsverwachtingen van de klant; acceptatiecriteria; kwaliteitsverantwoordelijken; van toepassing zijnde kwaliteitsstandaarden; een kwaliteitsmanagementsysteem ten aanzien van projectmanagement, werkzaamheden van specialisten, de wijzigingsprocedure en het configuratiemanagementplan; en de toe te passen kwaliteitsmethoden en -technieken (bijvoorbeeld kwaliteitsbeoordelingen of bepaalde type tests).
Marselis en Brouwer van CMG Logica dragen hun eigen testmodel rrbt aan en proberen dit te verweven of te verkopen met de Prince II-methodiek. Dit verschijnsel is een groot risico voor het Prince II-model, omdat eenvoud en eenduidigheid (naast de vele andere voordelen) het zo populair maken. Aantasting van deze fundamenten zal de gemeenschappelijke methodiek verloren laten gaan, met alle kwaliteitsrisico’s van dien.
Ik ben meer een voorstander van aanvulling dan van verwevenheid. Het voordeel is dat de gemeenschappelijke ( Prince II-)projectbasis blijft, maar per projectorganisatie technieken aangevuld en afgesproken worden. Je kunt ook mogelijke verbeteringen aandragen bij de Prince II-commissie die zich bezighoudt met de ontwikkelingen. Acceptatie van een idee betekent dat een en ander wereldwijd gestandaardiseerd wordt.
Rechtvaardiging
Ik begrijp niet wat de auteurs bedoelen met de zakelijke rechtvaardiging of ‘business case’ van de (sub)producten in een testproces. Eén van de kenmerken van Prince II-projecten is de aandacht voor de zakelijke rechtvaardiging. De ‘business case’ geeft de zakelijke rechtvaardiging waarom een project nodig is in concrete meetbare en objectieve waarden, dus niet de (sub)producten.
Het is voor een project essentieel om te weten hoe de kosten zich verhouden tot de inkomsten, wat de opdrachtgever beoogt te bereiken met het projectresultaat en hoe groot daarbij de risico’s zijn. Wegen de kosten en de risico’s niet op tegen de te verwachten baten, dan is er geen valide zakelijke rechtvaardiging en dus geen reden om met het project te starten of door te gaan. Uitgangspunt binnen Prince II is dat een valide zakelijke rechtvaardiging een voorwaarde is om met het project te starten. Is die er niet, dan moet niet aan het project begonnen worden. De (sub)producten hebben hier niets mee te maken.
De redenering is zelfs andersom. Er mag pas goedkeuring worden gegeven om met een project te starten als er expliciet een positieve zakelijke rechtvaardiging is. Er is dus eigenlijk sprake van een nogo/go-situatie en niet van een go/nogo-situatie.
Ramingen
Wat heeft een ‘product breakdown’ en het productgericht plannen hiermee te maken? De productdecompositiestructuur geeft een hiërarchische decompositie van alle op te leveren producten. Dit zijn de eindproducten, de tussentijdse producten en de producten die derden aanleveren om de realisatie van de uiteindelijke eindproducten mogelijk te maken.
Bij een productdecompositie wordt onderscheid gemaakt tussen de specialistische- en de managementproducten. De specialistische producten omvatten alle producten die nodig zijn om het projectresultaat op te leveren. Dit zijn dus de producten die in aanmerking moeten komen voor een test. De managementproducten zijn de producten die nodig zijn om het project in te richten en te managen. Onder de managementproducten vallen ook de kwaliteitsproducten, zoals gedefinieerd binnen de NEN/ISO. De kwaliteitsproducten zijn de managementproducten die direct het kwaliteitsproces borgen.
De meeste moderne projectmanagementmethoden zijn gebaseerd op productgericht plannen. Waarom? Er valt geen goed inzicht in de uit te voeren werkzaamheden en de te besteden tijd en kosten te verkrijgen als niet eerst wordt bepaald welke producten moeten worden geproduceerd en opgeleverd, wat de inhoud ervan is en wat de volgtijdelijkheid ervan en de onderlinge relatie ertussen zijn. Ook is het niet mogelijk een goede inschatting te maken van de voortgang als er geen (tussen)producten aan het plan ten grondslag liggen. Ramingen van nog te besteden tijd en kosten op basis van nog te verrichten activiteiten zijn vaak onnauwkeurig en meestal aan de optimistische kant als er geen duidelijke referentie is naar de verschillende producten. Het bovenliggende managementniveau kan ramingen op basis van activiteiten ook niet of nauwelijks controleren. Het definiëren van (tussen)producten maakt het mogelijk deze producten tussentijds te toetsen en te testen.
Zo is in een vroeg stadium (al bij een eerste projectfase) vast te stellen of hetgeen dat geproduceerd wordt voldoet aan de kwaliteitscriteria van de klant. Ook zijn gewenste veranderingen vroegtijdig te signaleren en kan je zonodig een wijzigingsprocedure starten.
Verantwoordelijk
Marselis en Brouwer wijzen al naar werkpakketten, het leveren van de vooraf gedefinieerde producten door de teammanager en diens verantwoordelijke taak. Hadden ze zich verdiept in de projectorganisatie, rollen, bevoegdheden, taken en mp 1, 2 en 3, dan hadden ze de ultieme antwoorden gevonden voor het testmoment en de verantwoording van de teammanager. De taak van de teammanager omvat: het accepteren en aannemen, het uitvoeren en het opleveren van het werkpakket met de productbeschrijvingen inclusief de kwaliteitscriteria.
De teammanager is verantwoording verschuldigd aan de seniorleverancier, die namens de leverancier contractafspraken heeft gemaakt (dp3) met de klant voor het realiseren van de op te leveren producten. Om het werkpakket verantwoord te kunnen aannemen moet de teammanager een teamplan en een eigen risicoanalyse opstellen.
De werkzaamheden van een teamleider zijn: het (laten) uitvoeren van de werkzaamheden binnen het budget, de afgesproken tijd en de afgesproken kwaliteit; het managen van de risico’s tijdens de uitvoering; het escaleren van ‘project issues’ naar de projectmanager; het zonodig doorvoeren van overeengekomen wijzigingen; het laten testen met testmethode x, y of z van de op te leveren producten; het bijwerken van het kwaliteitslogboek; en het rapporteren over de voortgang.
Acceptatie
De teammanager legt de resultaten van de uitgevoerde testen vast in het kwaliteitslogboek. Met het voortgangsrapport rapporteert hij periodiek aan de projectmanager.
Het opleveren van het werkpakket aan de projectmanager door de teammanager omvat: het opleveren van de gerealiseerde producten zelf; het melden van de oplevering van de producten aan de projectmanager; het overdragen van de opgeleverde producten en ervoor zorgen dat alle bijbehorende documenten, dossiers en bestanden geactualiseerd zijn; en ervoor zorgen dat het opgeleverde werkpakket wordt afgetekend door de projectmanager.
De teammanager levert de gerealiseerde producten op aan degenen die deze moeten gaan gebruiken in het vervolg van het project. Ook moet hij ervoor zorgen dat de gebruikers de producten accepteren. Acceptatie is een andere zaak dan testen en goedkeuren. Acceptatie van de gerealiseerde producten is een vervolg op het laten testen en goedkeuren van de producten in het subproces mp2. Door de gebruikers in te schakelen bij het testen van de producten in mp2 kan de teammanager ervoor zorgen dat de acceptatie ervan door de gebruikers soepel verloopt. Als externen het werkpakket uitvoeren, is het aftekenen van het opgeleverde werkpakket door de projectmanager vaak een voorwaarde om te mogen factureren.
Onwaarheden
De teammanager is verantwoordelijk voor dit proces. Hij draagt de verantwoording voor de acceptatie van het werkpakket, de uitvoering en het laten toetsen ervan en de overdracht van het opgeleverde werkpakket aan de projectmanager. Daarnaast is hij verantwoordelijk voor het actualiseren van de verschillende dossiers en voor de afstemming met de configuratiemanager ten aanzien van de configuratiedatabase.
Ik kan niet op alle halve of hele onwaarheden in het artikel van Marselis en Brouwer ingaan. Er ontstaat een Pino-gehalte (Prince in name only) en het blijkt voor velen moeilijk te zijn om de theorie in praktische zin te gebruiken. De grootste valkuilen voor een Prince II-project blijven dit soort initiatieven zonder kwalitatieve toetsing. In Nederland zijn buiten mij genoeg instituten die een kwaliteitsbeoordeling kunnen doen. Denk aan Prince II Benelux, Prince User Group en de vele geaccrediteerde opleidingsinstituten.
Kortom, er moet nog veel gebeuren om te kunnen spreken van een echt Prince II-project. Kwaliteitsbeoordeling en coaching zijn noodzakelijk om op de Prince II-rails te blijven.< BR>
J.H.E. Roos
