Ervaringen tijdens een Himalaya-expeditie

Dit voorjaar had ik het voorrecht voor één van onze grote klanten aan de slag te mogen met de vraag: “hoe krijgen we het productgericht plannen beter tussen de oren van onze project managers?” De aanleiding hiervoor lag in een aantal regelmatig terugkerende problemen rond projecten: gebrekkig gedefinieerde scope, beperkt zicht op relaties tussen producten en vertroebelde inzicht in voortgang.

De techniek van het productgericht plannen is een onderdeel van PRINCE2 en geeft invulling aan het principe van “Focus on products”. Oftewel in gewoon Nederlands: "bedenk wat je wilt hebben vóór je bepaalt wat je gaat doen". Een visueel onderdeel van deze techniek is de product breakdown structure (productdecompositiestructuur). Dit oogt een beetje als een organogram en maakt duidelijk hoe een product is opgebouwd. Productgericht plannen faciliteert de discussie over de scope (wat is belangrijk en wat niet?), maakt het mogelijk 'de neuzen te richten' en benoemt deliverables met kwaliteitseisen die nodig zijn om een doel te bereiken… en uiteindelijk de beoogde verbetering te bewerkstelligen. Meer informatie over deze techniek vind je hier: http://nl.wikipedia.org/wiki/Productgerichte_planning

'Het spelen van het spel' moest centraal staan. Daarvoor was een nieuwe workshop nodig. Ik ben gaan 'koken' met verschillende ingrediënten: een bestaande oefening, nieuwe rolbeschrijvingen inclusief eigen agenda's en een fictief project. Het project omvatte een promotiecampagne van een energiebedrijf, die gebaseerd werd op een gesponsorde Himalaya-expeditie . Voor de casus heb ik gebruik gemaakt van mijn kennis en ervaring met bergbeklimmen, mijn belangrijkste vrije tijdsbesteding.

Nadat het ‘mixen’ was voltooid kwam de eerste uitvoering. De opdrachtgever lichtte de aanleiding toe en na een korte theoretische herhaling gingen de deelnemers aan de slag met de opdracht. De eerste keer vond ik dat best spannend (slaat de opzet aan?) maar men stortte zich erop - met overtuiging. Na de eerste uitvoering is er wat fijngeslepen om de tweede uitvoering nog beter te maken. Tijdens beide workshops heb ik veel zaken geobserveerd. Een aantal sprongen eruit en die wil ik daarom graag delen.

1. Gescheiden uitwerken? Dan wel weer bij elkaar brengen!

De stakeholders waren verdeeld over de twee “hoofdstromen” die bij dit project betrokken waren. Dit waren “expeditie” en “promotie”. Deze verdeling, gecombineerd met tijdsdruk en groepsgrootte, maakte dat men ervoor koos uiteen te gaan in twee groepen om het eigen deel uit te werken. Dit “gescheiden uitwerken” zorgde voor een goed creatief proces maar bracht wel complicaties met zich mee. Er bestonden afhankelijkheden tussen producten  uit de verschillende “hoofdstromen”. Daarnaast moesten de resultaten ook weer geïntegreerd worden. Want uiteindelijk is het één project met één planning en één product flow diagramme (productstroomschema)... In één groep hield de project manager hiermee rekening door wat mensen uit de groepen halverwege te wisselen. Dit had tot gevolg een beter geïntegreerd eindresultaat.

2. De andere kijk van de opdrachtgever.

De opdrachtgever was tijdens het proces ook aanwezig. Aan het begin voor een kick-off en aan het einde om akkoord te geven op de ingeslagen weg. Voor dat akkoord liet hij zich adviseren door de stakeholders. De tijdsdruk zorgde voor een intensief proces en daarmee focus op details. Een opdrachtgever heeft echter zo zijn eigen visie op wat belangrijk is. Deze was vooral geïnteresseerd in hoofdlijnen. Het publiek moest dan ook even flink schakelen bij de vraag: “wat voegt dit product toe als je het bekijkt vanuit mijn business case?”

3. Een heldere discussie over scope en afhankelijkheden.

De productgerichte planningstechniek bestaat uit vier stappen: 

a) het maken van een project product description

b) het maken van een product breakdownstructure

c) het schrijven van product descriptions

d) het maken van een product flow diagramme

Bij een eerste kennismaking met de techniek van productgericht plannen krijg ik weleens de vraag: “waarom sla je het maken van de product breakdown structure niet gewoon over?” Twee keer een schema maken voelt voor sommigen wat dubbel, maar tijdens de workshops werd het belang van deze scheiding opeens erg zichtbaar.

Bij het maken van de product breakdown structure ging de discussie over de scope. Bij de product flow diagramme over afhankelijkheden. Als je daarover nadenkt, is dat wel zo efficiënt. Je wilt immers geen tijd verdoen met het beschrijven van afhankelijkheden die later "buiten de boot" vallen. Betekent dit dan dat discussiëren over de scope uit den boze is zodra de product breakdown structure af is? Dat niet: maar een heldere discussie – waarbij duidelijk is dat de discussie gaat óf over scope óf over afhankelijkheden – voorkomt wel ruis.

4. De projectondersteuner: de ongeprezen helden.

Eén van de rolbeschrijvingen was die van projectondersteuner. De mensen die de rol van projectondersteuner hadden, ontpopten zich tot de ongeprezen helden van de avond, doordat zij allerlei gaten dichtliepen. Misschien kwam dit juist wel door de vrij eenvoudige rolbeschrijving van de projectondersteuner, die niet verder ging dan: “ondersteun de project manager”. Dit maakte een “manusje van alles”-invulling van de rol mogelijk. Niet helemaal conform het principe van “duidelijk gedefinieerde rollen en verantwoordelijkheden”, maar de project managers waren er wel blij mee.

Uit de evaluaties bleek dat de leervorm erg werd gewaardeerd. Dit kwam doordat ervaren en beleven centraal werden gesteld in tegenstelling tot (theoretische) kennisoverdracht. De workshop heeft inmiddels een vervolg gekregen en is nog een aantal malen gepland. Ik zie ernaar uit en ben benieuwd wat voor nieuwe vergezichten het verder nog oplevert!