De ProjectCheck als ondersteunend instrument
Door Antonie Reichling en Tineke Jacobs. Dit artikel verscheen eerder in Kwaliteit In Bedrijf.
Evalueren is vaak een verplicht nummer: het moet, maar het is niet écht leuk en bovendien komt van de goede voornemens veelal bar weinig terecht, met name als een project pas aan het eind wordt geëvalueerd. Toch is het zeker voor mensen uit het kwaliteitsvak evident dat evalueren erbij hoort: de ‘Act’ uit de Deming-cirkel (een vierstappen-model voor continue procesverbetering en kwaliteitsmanagement) is er niet voor niets. In dit artikel geven we handreikingen om meer te halen uit projectevaluaties en presenteren we De ProjectCheck als ondersteunend instrument.
Mogelijk redenen waarom projecten niet geëvalueerd worden
‘Gebrek aan tijd’ en ‘er wordt toch niets met de conclusies gedaan’ zijn veelgehoorde redenen om projecten niet te evalueren. Herkenbaar, maar ook onbevredigend. Is de uitleg werkelijk zo simpel en waarom slagen maar weinigen erin deze drempels te overwinnen? Wat is het ‘probleem-achter-het-probleem’?
In een recent artikel noemden wij een aantal aanvullende redenen, waaronder een te eenzijdig – instrumenteel – perspectief op het project, leren en verantwoorden zijn een slechte combinatie, en het niet betrekken van alle belanghebbenden bij de evaluatie (Jacobs, Reichling 2014). Opmerkende dat zelfs een eenduidige definitie voor projectevaluatie ontbrak, stelden wij de volgende voor: ‘Het tijdens het project met regelmaat met alle stakeholders vaststellen van de stand van zaken van het project, waarbij twee vragen centraal staan: Wat hebben we gedaan en gelaten zodat we op dit moment dit (tussen-) resultaat hebben?, en: Welke acties zijn nodig om in het vervolg van het project, en in vol-gende projecten, zeker zo effectief te werk te blijven gaan?’
Evaluaties het ondergeschoven kindje?
Wat valt ons nog meer op als we kijken naar projecten? Vergaderingen, die inspireren? Waar vind je die? Projectevaluaties, die inspireren? Hetzelfde. Het lijkt wel of projecten evalueren niet leuk kan zijn. En dan hebben we nog het jargon, dat helpt ook al niet. End of stage reports, business objectives, changelogs, product owners, team members, de ‘list of impediments’… het is om horendol van te worden… Sterker nog: het vergroot de kans dat de deelnemers elkaar misverstaan.
Vanuit de constatering dat evaluaties onnodig het ondergeschoven kindje zijn, en dat een aantal redenen daarvoor eenvoudig geadresseerd kunnen worden, hebben de auteurs samen met collega Bart Terlingen het ondersteunend instrument De ProjectCheck ontworpen. In dit artikel geven wij een aantal aanvullende handreikingen voor het gebruik daarvan.
Vergroting effectiviteit: verbreed het perspectief van uw evaluatie
De reikwijdte van de evaluatie draagt veel bij aan de effectiviteit. Standaard staan twee onderwerpen op de agenda: Wat ging goed? En: Wat kan of moet beter?
Voor de verbetering van dat laatste ligt het voor de hand antwoorden te zoeken in de samenwerking binnen het eigen team of in de wijze waarop de projectmanagementmethode is toegepast. Dit zijn namelijk factoren die zelf te beïnvloeden zijn, en zo kom je niet – of in elk geval minder – te zitten met het gevoel dat ‘er toch niets met de conclusies wordt gedaan’.
Je beperken tot deze twee vragen vergroot echter de kans dat in een volgend project dezelfde fouten worden gemaakt. Er zijn, behalve de samenwerking binnen het projectteam, meer factoren die het projectverloop beïnvloeden. Denk daarbij aan het krachtenveld rond het project, de keuze van het project en het projectmanagementklimaat. Zij zijn wellicht lastiger te beïnvloeden dan de teamsamenwerking, maar het zijn wel dé factoren die bepalen of ook in nieuwe projecten de lering uit eerder gemaakte fouten wordt toegepast.
Het project reikt verder dan het projectteam, de evaluatie dus ook
We zeiden het al: Een project bevindt zich in een krachtenveld. En dat heeft grote invloed op het verloop van het project. Dat is niets nieuws. Wat echter zelden gebeurt, is dat alle belanghebbenden betrokken zijn bij het evalueren van het project. Doet u dat wel, dan voorkomt u dat er ‘over’ mensen en partijen wordt gesproken en niet mét hen, en komen belangenverschillen zo niet makkelijker, dan toch in ieder geval eerder, op tafel.
7 typen betrokkenen
Zo onderkent De ProjectCheck zeven typen betrokkenen (rollen) met evenveel verschillende perspectieven. Van directie via projectleider tot aan de projectomgeving. Voor iedere rol is op vierentwintig succesfactoren voor projectmanagement in de eigen taal en vanuit het eigen belang een stelling geformuleerd die de succesfactor weergeeft.
De drempel reduceren
Voor het projectteamlid is een voorbeeld: ‘In de voorbereidingsfase is er voldoende ruimte voor onze bijdragen’. De drempel om vanuit een generieke projectsuccesfactor te associëren naar wat maatgevend is voor het eigen project en de eigen organisatie, is zo tot een minimum gereduceerd.
Creëer een veilige omgeving
Het begint er soms al mee dat een ander ‘voor ons evalueert’, dat wil zeggen: er wordt een (technisch) evaluatierapport geschreven en dat wordt dan in het team besproken. Fout, weerstand, discussies, ingraven, afschuiven, verkeerde volgorde. En dan wordt evalueren vaak pas aan het eind van het project gedaan, waarbij het primaire doel is: verantwoording van proces, resultaten en financiën aan de opdrachtgever.
Verantwoording versus veilig leren
Verantwoording verhoudt zich slecht met ‘open’ evalueren om iets te leren. Immers, als de opdrachtgever een oordeel moet geven, kan het verstandig zijn om niet het achterste van je tong te laten zien. Voor leren heb je juist een veilige situatie nodig.
Dit heeft gevolgen voor de vraag welke belanghebbenden u wanneer bij elkaar brengt. Belanghebbenden laten zich groeperen in strategische, tactische en operationele belanghebbenden, waarvoor u evenzovele evaluaties kunt organiseren.
Worden de beste projecten gekozen?
Doe eens een stap naar achteren en wees eens heel eerlijk: Is het verstandig geweest juist dit project uit te voeren? Hierbij is de vraag of het project een succes was niet eens zo relevant. Waar het om gaat is: in hoeverre heeft het project werkelijk bijgedragen aan de strategie van uw bedrijf? Zou u met de kennis van nu nog steeds…? En wat betekent dat voor de toekomstige keuzes die u gaat maken?
Strategie en projecten
Het gaat dan over programmamanagement, vaak een impopulair onderwerp. Programmamanagement, gepositioneerd tussen strategie en projecten, maakt enerzijds zichtbaar waar in de organisatie projecten uitgevoerd worden die niet bijdragen aan de strategie, maar maakt ook duidelijk waar de projectcapaciteit – projectmanage-mentcapaciteit, uitvoeringscapaciteit, verandercapaciteit – overschreden wordt. Met andere woorden: Het maakt zichtbaar waar het management tegen de capaciteitsgrenzen van de organisatie oploopt en daadwerkelijk zal moeten prioriteren.
Het zal duidelijk zijn dat niet alleen de betrokkenen op het strategisch niveau goed in staat zijn iets over deze vraag te zeggen! Vijf van de vierentwintig stellingen van de projectcheck betreffen dit onderwerp.
| Evaluatieniveau | Wie | Onderwerp |
| Strategisch | Directie, interne opdrachtgever(s) en even-tuele ketenpartners | Projectklimaat, de (in de organisatie) gebruikte projectmethodologie, en wijze en criteria voor de keuze van projecten (programmanagement). |
| Tactisch | Interne of externe op-drachtgever, projectleider en (eind)gebruiker | Bijstellingen in de afbakening van het project, noodzakelijke wijzigingen, en de afstemming opdrachtgever – projectleider – (eind-)gebruiker. |
| Operationeel (en transactioneel) | Projectleider, (externe) teamleden én (eind-) gebruiker | Samenwerking in het team, met de eindgebruiker en de omgeving en de doelmatigheid en het gebruik van instrumenten |
Bezie alle projecten in de context van de reguliere processen
Evalueren gebeurt op projectniveau. Wat we minder tegenkomen is dat gekeken wordt naar de grootste gemene deler van alle projecten in de organisatie. Natuurlijk gaat het dan om de vraag of de projecten voldoende bijdragen aan de gestelde doelen, en of de resultaten behaald worden binnen tijd en met de juiste kwaliteit. Maar daaraan kunnen nog andere aspecten worden toegevoegd.
Spagaat tussen project en reguliere business
Bekend is de spagaat tussen project en reguliere business waarin projectmedewerkers zich al snel bevinden. Tenzij het project in een volledige projectorganisatie uitgevoerd wordt, zal er altijd sprake zijn van die spanning.
De vraag is in welke mate hogere echelons zich bewust zijn van dit gevaar en daarnaar handelen. Hoe vaak staat een opdrachtgever in het MT op de bres voor het project door de problemen op bemensingsgebied ter discussie te stellen? Of, in welke mate accepteren collega-managers dat projectleden apart aan hen rapporteren over een project, waarbij de projectleider wordt gepasseerd? U kent vast nog meer van zulke voorbeelden.
Intrinsiek gemotiveerde verantwoordelijkheid als visie
Uiteindelijk is een succesvol project in hoge mate afhankelijk van wat we zouden kunnen noemen intrinsiek gemotiveerde verantwoordelijkheid van alle betrokkenen in en rond het project. De betrokkenen doen de noodzakelijke dingen proactief en niet omdat ze daartoe bij voortduring aangezet moeten worden. Misschien utopisch, maar als visie het nastreven waard. Een visie die we in De ProjectCheck verwerkt hebben met behulp van het teameffectiviteitsmodel (Fry, Rubin, Plovnick 1981).
Leuker evalueren: verbeter het proces
Een projectevaluatie vraagt een stevige inhoudelijke component en dat leidt kennelijk tot weinig aandacht voor de vorm. Terwijl het één het ander niet hoeft uit te sluiten. Laten we eens kijken. Zet met ‘alle’ betrokkenen (zie eerder) vier stappen:
- warm bad;
- koud bad;
- oorzaakanalyse; en
- concrete acties met gemotiveerde actiehouders.
Effectief evalueren: doen en dan bewijst het zichzelf
Vatten we alles samen, dan handelt het om een breed perspectief en een constructief proces. Betrek alle betrokkenen in het evaluatieproces, maar scheid verantwoorden van leren. Dat betekent mogelijk dat in verschillende samenstellingen het project of projectmanagement in het algemeen wordt geëvalueerd.
WARM BAD
De kaarten met stellingen van De Project-Check verschaffen de triggers voor iedere deelnemer om na te gaan waarom het project gezien vanuit diens perspectief zo goed gelopen is. Hiermee wordt niet alleen een positieve sfeer geschapen in de evaluatie, maar oefenen de deelnemers ook gelijk in het associëren en vertalen van de stellingen naar de eigen beleving en in het delen van de resultaten.
De deelnemers bespreken samen wat de voornaamste succesfactoren van het project zijn. Belangrijk is niet te stoppen bij het benoemen van die factoren, maar door te praten over de oorzaken. Wat maakt dat deze sterke punten bestaan, wat moeten we vooral wel en wat vooral niet doen om ze vast te houden? De volgende vraag is vanzelfsprekend wat beter kan of moet.
KOUD BAD
Ook bij deze ronde helpen de stellingen op de kaarten de deelnemers ieder voor zich vast te stellen wat zij als voornaamste verbeterpunten zien. De ProjectCheck-kaarten maken het voor iedere deelnemer mogelijk eenvoudig te prioriteren met behulp van pair ranking – de belangrijkste kaarten worden een-op-een tegen elkaar afgewogen – als dat nodig mocht zijn.
Gezamenlijk belang
Nu zullen de verschillen van beleving aan de orde komen en zal de taak van een (interne) procesbegeleider nog belangrijker zijn. Het gaat om begrip en respect voor elkaars beleving en perspectief, het vasthouden van het gezamenlijk belang en om gezamenlijk vaststellen en prioriteren van de verbeterpunten.
Teamwerk van de betrokkenen getest
Dit is een eerste test in hoeverre er daadwerkelijk sprake is van teamwerk van de betrokkenen. Evalueren zij inderdaad vanuit een gemeenschappelijk belang? Is er sprake (geweest) van een heldere verdeling van verantwoordelijkheden? Slagen de deelnemers erin om problemen constructief op tafel te krijgen, of niet? Een goede procesbegeleider weet dit onderwerp op een juiste manier te adresseren en zo nodig de samenwerking ter plekke al te verbeteren.
OORZAAKANALYSE
Na de gezamenlijke vaststelling wat de belangrijkste verbeterpunten zijn, staat de discussie over de oorzaakanalyse op de agenda. Ook hier een lakmoesproef voor het teamwerk: geen beschuldigingen over en weer? Oorzaakanalyse voor de verbeterpunten in een project kan vanzelfsprekend aan de hand van Ishikawa, Root Cause Analysis en – voor de heel serieuzen onder ons – systeemdynamica uitgevoerd worden.
3 aanvullende perspectieven
In de gedachten achter De ProjectCheck zijn drie aanvullende methodische perspectieven gehanteerd, als gezegd het teameffectiviteit-model, Plan-Do-Check-Act (PDCA) en de opsplitsing van projectmanagement in vier aandachtsgebieden.
5 systeemfactoren en 1 interpersoonlijke factor
Het teameffectiviteit-model bestaat uit vijf zogeheten systeemfactoren en een laatste interpersoonlijke factor, die van productieve, informele zakelijke communicatie. Uitgangspunt is dat aan de systeemfactoren voldaan moet zijn, willen die productieve, informele zakelijke relaties ontstaan die van levensbelang zijn voor projecten met hun inherente onzekerheid. Je kunt immers in projecten niet alle communicatie voorprogrammeren, als dat wel zo was, dan waren het geen projecten.
Bewustwording
In een blad als Kwaliteit in Bedrijf behoeft PDCA geen uitleg, in De ProjectCheck heb-ben wij een stap vooraf laten gaan aan Plan, namelijk Bewustwording. Voor een voorbeeld van de verwerking van B-PDCA in de stellingen van De ProjectCheck zie het kader bovenaan.
Strategisch, tactisch, operationeel en transactioneel
De ProjectCheck benadert projectmanagement vanuit de aandachtsgebieden ‘Beleid rond projecten’, ‘Kiezen van projecten’, ‘Plannen en uitvoeren van projecten’, en ‘Samenwerken’. Je zou kunnen zeggen: strategisch, tactisch, operationeel en transactioneel.
CONCREET TOEGEWEZEN ACTIES
Vervolgens wordt een belangrijke stap gezet. Iedere deelnemer voor zich beantwoordt vier vragen:
- ‘Hoe kunnen sterke punten uit de eerste ronde helpen bij het aanpakken van de verbeterpunten?’
- ‘Kan ik de verbeterpunten direct zelf oppakken?’
- ‘Zo nee, wie kan het wel? Wat zou die eraan moeten doen? Hoe kan ik eraan bijdragen dat de ander het punt oppakt?’
- ‘Welke quick wins kan ik maken, welke dingen kan ik of kan het team morgen anders doen?’
Hiermee zorgt u ervoor dat niemand ‘wegkomt’ met alleen de opmerking dat ‘een ander’ dat moet oppakken. Zo worden zelfs mensen die niet aan tafel zaten, actief betrokken.
Na een presentatie van ieders voornemens aan de groep, eindigt u met heldere afspraken, zodat u een concrete actiepuntenlijst heeft waarop u kunt terugkomen.
Evalueer ook de condities waaronder projecten gemanaged worden, kijk naar het project-portfolio en kijk naar de verhouding tussen de reguliere processen en het projectmanagement.
Als laatste, zorg voor een constructief en effectief evaluatieproces. Zet daarin vier stappen en sluit af met concrete, gedragen afspraken. De ProjectCheck is op een dergelijk evaluatieproces ontworpen.
Bibliografie
Jacobs, T., Reichling, A. (2014) Projecten evalueren, Zes redenen waarom het er te vaak niet van komt – in Sigma, Nr. 4, september 2014; Fry, R., Rubin, I., Plovnick, M. (1981); “Dynamics of Groups that Execute or Manage Policy.” In “Groups at Work” ed. Roy Payne and Cary L. Cooper, Hoboken: John Wiley, and Sons; Websites: Systeemdynamica, http://en.wikipedia.org/wiki/System_dynamics
Over de auteurs
Antonie Reichling helpt met zijn expertise in programma- en projectmanagement organisaties hun verandercapaciteit optimaal te benutten en oplossingen van strategische waarde te creëren. Als Certiked-beoordelaar is organisatie-leren voor hem speerpunt. Kijk voor meer informatie op www.reichling.nl.
Tineke Jacobs is projectmanagementspecialist met een focus op ICT-projecten. Zij is trainer en projectcoach, en staat ook regelmatig zelf ‘met de voeten in de klei’ als projectmanager.
Antonie en Tineke ontwikkelden samen met collega Bart Terlingen De ProjectCheck, een evaluatie-instrument voor projectmanagement.
