Roos reageert in de Computable van 14 mei 2004 op Rik Marselis en Erik Brouwer van Logica CMG ('Testen binnen Prince II', 23 april 2004). Hij zou dat artikel eens moeten herlezen om te ontdekken dat de punten die hij aandraagt reeds behandeld zijn door Marselis en Brouwer. Een groot deel van zijn verhaal is een uiteenzetting van de Prince II-theorie. Ik ben niet gaan muggenziften om op alle eventuele slakken zout te kunnen leggen.
De kern van Roos' betoog is dat het ultieme testmoment onderdeel is van het Prince II proces 'managing product delivery/executing a workpackage' (mp2). Brouwer en Marselis onderkennen dit voor bijvoorbeeld de 'unit'- en systeemtest. Roos haalt zijn eigen argumentatie onderuit zodra hij stelt dat de teammanager als taken van zijn team heeft "testen met testmethode x, y of z van de op te leveren producten". Juist door het definiëren van het tussenproduct 'software, gereed voor test' verkrijgt de 'project board' een extra stuurmoment. Dit moment ontbreekt indien bouw en test in dezelfde fase en in één werkpakket of product worden samengevoegd. Roos zelf schrijft "het definiëren van (tussen)producten maakt het mogelijk deze producten tussentijds te toetsen en te testen". De crux zit hem in de balans tussen veel kleine en enkele grote fasen en de omvang van het project.
Onbegrip
Roos geeft voorts aan niet het verband te begrijpen tussen testproducten en de zakelijke rechtvaardiging (business case). Hij beschrijft terecht dat één van de taken van de teammanager het escaleren van 'project issues' aan de projectmanager is. Juist deze kwesties geven aanleiding tot bijwerken van de zakelijke rechtvaardiging (issue log als input voor sb3), hetgeen Brouwer en Marselis naar ik aanneem bedoelen. De (sub)producten hebben hier wellicht niets mee te maken, de kwesties die kunnen voortkomen uit of tijdens het creëren van deze producten (mp2) wel.
Het noemen van NEN/ISO begrijp ik op mijn beurt niet (Prince II zegt niets expliciet over toepassing van dergelijke standaarden). Ook dat de specialistische producten getest zouden moeten worden (de management producten niet?) is mij niet duidelijk. Een document dat bij uitstek 'getest' zou moeten worden (bijvoorbeeld middels een kwaliteitsbeoordeling) is het pid. Hoe een veranderde organisatie te test zou zijn weet ik niet.
Overigens, zowel Roos als Marselis en Brouwer noemen product-gebaseerd plannen in tegenstelling tot activiteit-gebaseerd. Prince II kent wel degelijk het identificeren van activiteiten en hun afhankelijkheden (pl3). Het is niet 'in plaats van' maar 'met nadruk op'.
Filosofie
Het aanhalen van 'Pino' (Prince in name only) en het refereren aan "halve of hele waarheden" komt op mij over als heel hard 'boe' roepen, maar waarom? Marselis en Brouwer adresseren een punt waar menigeen mee worstelt en zij stellen een aanpak voor die heel goed past binnen de filosofie en structuur van Prince II. In de praktijk zie ik echter 'Prince II'-projecten waar de stuurgroep (?) regulier bijeenkomt (not managing by exception), waar fasering niet bestaat (en zelfs geen onderscheid wordt gemaakt tussen 'initiating a project' en de rest van het project; geen fasering betekent geen Prince), waar koste wat kost het eind gehaald zal worden (zakelijke rechtvaardiging?) en waar het onderscheid tussen uitvoeren en besturen vaag of afwezig is. In die situaties is Pino veel meer op zijn plaats. Roos gebruikt de term iets te populair, zeker in het licht van zijn eigen betoog.
Hij geeft blijk van gedegen Prince II-kennis, maar heeft in zijn reactie de plank volledig misgeslagen. Hij vergeet tevens het principe van geneste Prince II-projecten te beschouwen. In Prince II is de projectmanager onderdeel van de klant-organisatie, in tegenstelling tot vele ict-projecten waar de projectmanager deel uitmaakt van de leverancier. In Prince II-termen is een projectmanager van een leverancier (ict-afdeling van de organisatie of externe leverancier) vaak de teammanager in het (al dan niet Prince II) project van de klant. Deze teammanager kan echter zijn eigen Prince II project voeren en daarin de rol van projectmanager hebben. Een teammanager kan een werkpakket aannemen waarin de productbeschrijving "getest systeem(onderdeel)" is. De input van het team is dan bijvoorbeeld "gebouwde software, gereed voor test".< BR>
Andr� Hoekstra, IBS Systeemontwikkeling, Rabobank Nederland
Om te kunnen beoordelen moet u ingelogd zijn: