“Prince II staat bol van de kwaliteitsgedachte en het beheersen daarvan”, stelt Anthony Louws. Testen inbedden in een Prince II-structuur gaat bijna vanzelf, daar is geen testmanagementmethodiek voor nodig voor nodig, meent hij.
Rik Marselis en Erik Brouwer beschrijven in ‘Testen binnen Prince II’ (Computable, 23 april 2004) hoe lastig het volgens hen soms kan zijn om de activiteit testen onder te brengen in de productgerichte aanpak van Prince II. Ze betogen dat er nog weinig ervaring is met het succesvol inrichten van testen binnen de Prince II-structuur en gaan uit van het door Logica CMG ontwikkelde rrbt-testmanagementmodel (risk & requirement base testing). Met rrbt als testmanagementmethodiek op zich valt prima te werken, hoewel deze methodiek – ondanks belangrijke verschillen – a priori niet beter of slechter is dan tmap.
Door te zoeken naar dezelfde uitgangspunten, zoals productgerichtheid, een strikt besturingsmodel en een duidelijke zakelijke rechtvaardiging (business case), wordt het testproject echter teveel als alleenstaand project gezien. Dit suggereert dat er ook projecten zijn waar het testen geen onderdeel van uitmaakt en waarvan de kwaliteit bij oplevering niet vaststaat. Dergelijke projecten zullen ongetwijfeld voorkomen, maar die zijn in ieder geval niet met Prince II gemanaged.
Kwaliteitsbeheer
De zakelijke rechtvaardiging van een project moet voortkomen uit de toegevoegde waarde van de op te leveren producten voor de organisatie. Die producten zullen deze toegevoegde waarde slechts kunnen waarmaken als ze voldoen aan de gestelde kwaliteitseisen. Niet voor niks wordt in Prince II gesteld dat een product pas af is als het voldoet aan die eisen.
Naast de overbekende processen beschrijft Prince II ook componenten die de bouwstenen voor die processen vormen. Een van die componenten is kwaliteitsbeheer. Kwaliteitsbeheer draagt ertoe bij dat de door de gebruiker verwachte kwaliteitseisen worden bereikt. Zie hier de inbedding van het testen in Prince II. Het meten (is testen) van deze kwaliteit kan van zeer uiteenlopende aard zijn. Bij producten als een presentatie voor de hoofddirectie of ontwikkeld cursusmateriaal zullen beoordelingen de geëigende methode zijn. Als een product een stuk software is, kan een acceptatietest een van de meetmethodes zijn.
Al bij het starten van een project (SU4: preparing a project brief) krijgen de kwaliteitsverwachtingen van de klant en de acceptatiecriteria ruim aandacht. Direct na het mandaat om de pid (product identification document) te beginnen staat het kwaliteitsplan op de rol. Het belangrijkste ingrediënt hiervan is hoe ervoor gezorgd gaat worden dat de opgeleverde producten van de juiste kwaliteit zijn. Zie dit in een zuiver it-project als een mastertestplan. In een it-project met enige omvang zal de projectmanager hier al snel een testmanager voor inschakelen. Waar staat in de Prince II-methodiek dat de projectmanager geen testmanager mag aanstellen, met eigen deelverantwoordelijkheden, die naast de teammanagers aan de projectmanager rapporteert?
De pbs (product breakdown structure) met specialistische producten bevat de producten die het project moet opleveren. Kwaliteit is geen intrinsiek product, je spreekt uitsluitend over de kwaliteit van een ander product. Als in een pbs een ordersysteem voorkomt, is het niet nodig om een ‘acceptatie getest order systeem’ in de pbs op te nemen om je acceptatietest een plekje te geven. Het ordersysteem is immers pas af als het aan de door de gebruiker gestelde kwaliteitseisen voldoet. De producten die de testmanager oplevert (detail testplannen, testspecificaties, testresultaten en adviezen) worden beschreven bij de kwaliteitsproducten en opgeslagen in de ‘quality-file’.
Inbedden
Om de verantwoordelijkheden in het project goed te krijgen moet je vooral niet teveel denken in ommuurde teams die volledig op eigen kracht een product aan de projectmanager moeten opleveren. Marcelis en Brouwer maken onderscheid tussen een specifiek testproduct en een product op lager niveau waar het testen onderdeel van het werk aan dit product is. In de Prince II-gedachte is het testen echter altijd onderdeel van het werk aan een product. Nogmaals: een product is pas af als het aan de gestelde eisen voldoet. De testmanager is verantwoordelijk voor de kwaliteitstoets. Eventuele testcoördinatoren vallen onder de testmanager en kunnen door een teammanager ingehuurd worden om de uitvoering van een specifieke test te leiden. De teammanager is verantwoordelijk voor de oplevering van het product en levert dus op zodra het de kwaliteitstoets heeft doorstaan.
Samenvattend: Prince II staat bol van de kwaliteitsgedachte en het beheersen daarvan. Het inbedden van testen in een Prince II-structuur gaat bijna vanzelf, daar is geen rrbt voor nodig. Het opnemen van specifieke testproducten in je pbs met specialistische producten is geen goed idee, die horen thuis bij de kwaliteitsproducten. Dat je die kwaliteitsbeheersing vervolgens op een gestructureerde manier wilt aanpakken en daar rrbt of tmap voor gebruikt spreekt voor zich, maar dat kan prima samengaan met Prince II als projectmanagementmethodiek voor het hele project.< BR>
Anthony Louws, projectmanager bij Inter Access
