Rapporteren in projecten en programma’s: stuurinformatie in plaats van verantwoording

Iedereen die wel eens in een stuurgroep heeft gezeten, kent het verschijnsel. Maandenlang staat het project op groen. Dan staat het ineens op rood, met een uitloop van een halfjaar en een forse budgetoverschrijding. Achteraf blijkt dat de problemen al lang bekend waren bij het projectteam. Ze stonden alleen niet in de rapportage.

In dit artikel beschrijf ik waarom rapportages zo vaak te rooskleurig zijn, wat onderzoek daarover zegt en hoe u rapporteert zodat opdrachtgever en stuurgroep op tijd kunnen bijsturen. Het uitgangspunt is eenvoudig: een rapportage is stuurinformatie, geen verantwoording.

Waarom slecht nieuws niet boven komt

Al in 1970 beschreven Rosen en Tesser het verschijnsel dat mensen slecht nieuws liever niet overbrengen. Zij noemden het het MUM-effect, naar het Engelse keep mum: je mond houden. Smith en Keil (2003) pasten dat toe op ict-projecten. Zij lieten zien dat projectmedewerkers die weten dat een project in de problemen zit, dat vaak niet melden. De redenen zijn begrijpelijk: angst om de schuld te krijgen, hoop dat het nog goed komt, of het gevoel dat melden toch niets uitmaakt.

Keil, Smith, Pawlowski en Jin (2004) onderzochten welke factoren daarbij een rol spelen. Het klimaat in de organisatie bleek belangrijk. Waar het veilig voelt om slecht nieuws te brengen, wordt het ook eerder gebracht. Ook het informatieverschil speelde mee: hoe minder de ontvanger zelf kan zien, hoe groter de verleiding om het mooier voor te stellen dan het is.

Daarbij lopen twee soorten fouten door elkaar. De eerste is een inschattingsfout: de projectleider denkt oprecht dat het beter gaat dan het gaat. De tweede is een bewuste vertekening: de projectleider weet het, maar rapporteert het niet zo. Beide leiden tot rapportages die de werkelijkheid te rooskleurig weergeven.

Waarom projecten te lang doorgaan

Een tweede verschijnsel maakt het probleem groter. Staw (1976) liet zien dat mensen die verantwoordelijk zijn voor een besluit dat slecht uitpakt, geneigd zijn er juist méér in te investeren. Keil (1995) beschreef hetzelfde bij ict-projecten: projecten die duidelijk niet goed gaan, lopen soms nog jaren door. Wie al veel heeft geïnvesteerd, vindt het moeilijk om te stoppen. Onderzoekers noemen dat escalatie van commitment.

Een rapportage die alleen de voortgang op activiteiten laat zien, versterkt dat. Er is immers altijd voortgang: er zijn weer vergaderingen gehouden, documenten opgeleverd en functies gebouwd. Of het project nog op weg is naar de beoogde baten, is een andere vraag. En die vraag moet de rapportage beantwoorden.

Zes principes voor rapportages die helpen sturen

1. Maak het veilig om slecht nieuws te brengen

Het belangrijkste principe gaat niet over de rapportage zelf, maar over hoe erop wordt gereageerd. Edmondson (1999) liet zien dat teams beter leren en presteren als er psychologische veiligheid is: het vertrouwen dat je een probleem kunt benoemen zonder te worden afgestraft. Een opdrachtgever die op slecht nieuws reageert met de vraag wat er nodig is, krijgt de volgende keer eerder en eerlijker informatie. Een opdrachtgever die de boodschapper afstraft, krijgt alleen nog groene rapportages.

2. Kijk vooruit, niet alleen terug

De meeste rapportages beschrijven wat er de afgelopen periode is gedaan. Voor sturing is belangrijker wat er de komende periode gaat gebeuren en of de planning nog haalbaar is. Vraag daarom per onderdeel een prognose: wanneer verwachten we op te leveren, wat verwachten we dat het kost, en hoe zeker zijn we daarvan? Een verschuivende prognose is een vroeg signaal. Een terugblik vertelt u pas iets als het te laat is.

3. Rapporteer op resultaten en baten, niet op activiteiten

Meet voortgang aan opgeleverde en geaccepteerde resultaten, niet aan bestede uren of uitgevoerde activiteiten. Een onderdeel is pas af als de gebruiker het heeft geaccepteerd. Rapporteer bij programma’s daarnaast op de baten: komen die nog binnen bereik? Zo voorkomt u dat een project lang op schema lijkt, terwijl het eigenlijke doel uit zicht raakt.

4. Maak afwijkingen expliciet, met toleranties

Spreek vooraf af hoeveel afwijking in tijd, geld en kwaliteit is toegestaan voordat de opdrachtgever moet worden ingeschakeld. PRINCE2 noemt dat toleranties. Het voordeel is dat een afwijking geen kwestie van interpretatie meer is. Binnen de tolerantie stuurt de projectleider zelf bij. Daarbuiten volgt direct een melding met opties. Dat haalt de druk weg om een afwijking zo lang mogelijk weg te poetsen.

5. Gebruik kleuren met een definitie

De bekende stoplichtkleuren zijn handig, maar alleen als vastligt wat ze betekenen. Groen betekent binnen tolerantie en geen verwachte afwijking. Oranje betekent dat een afwijking dreigt en dat er maatregelen lopen. Rood betekent dat de tolerantie wordt overschreden en dat er een besluit nodig is. Zonder zo’n definitie wordt de kleur een gevoel, en gevoelens kleuren meestal groen.

6. Eindig met besluiten

Een rapportage aan een stuurgroep moet eindigen met de vraag welke besluiten nu nodig zijn, met de opties en een advies. Een stuurgroep die alleen informatie ontvangt, gaat die informatie bespreken. Een stuurgroep die een besluit voorgelegd krijgt, gaat sturen. Houd de rapportage daarbij kort. Eén of twee pagina’s met de kern zegt meer dan een dik document waarin het belangrijke tussen het onbelangrijke verdwijnt.

Rapporteren in een programma

In een programma komt daar een extra laag bij. De stuurgroep wil niet twintig projectrapportages lezen, maar één samenhangend beeld. Vraag daarom alle projecten om op dezelfde manier en op hetzelfde moment te rapporteren, zodat de rapportages kunnen worden samengevoegd. Voeg daar de afhankelijkheden tussen projecten aan toe en de stand van de baten. Zo ziet de stuurgroep niet alleen hoe elk project ervoor staat, maar ook waar een vertraging in het ene project gevolgen heeft voor het andere. Over die samenhang schreef ik eerder in Programmamanagement: integreren en veranderen tegelijk.

Wat ik in de praktijk zie

In de praktijk zie ik dat het verschil tussen een goede en een slechte rapportage zelden in het format zit. Het zit in de relatie tussen opdrachtgever en projectleider. Waar de opdrachtgever slecht nieuws welkom heet en er samen iets mee doet, zijn rapportages eerlijk en bruikbaar. Waar dat niet zo is, helpt geen enkel format. Daarom begint goed rapporteren bij goed opdrachtgeverschap.

Checklist: helpt uw rapportage om te sturen?

Principe	Toetsvraag
Veiligheid	Is het in uw organisatie veilig om slecht nieuws te melden, en wordt daar constructief op gereageerd?
Vooruitkijken	Bevat de rapportage een prognose van oplevering en kosten, en hoe zeker die is?
Resultaten	Wordt voortgang gemeten aan geaccepteerde resultaten en baten in plaats van aan activiteiten?
Toleranties	Is vooraf afgesproken welke afwijking is toegestaan voordat de opdrachtgever wordt ingeschakeld?
Kleuren	Is vastgelegd wat groen, oranje en rood precies betekenen?
Besluiten	Eindigt de rapportage met de besluiten die nu nodig zijn, met opties en een advies?

Veelgestelde vragen

Wat is een watermeloenrapportage?

Een watermeloenrapportage is een rapportage die van buiten groen is en van binnen rood. De indicatoren staan op groen, terwijl het project in werkelijkheid in de problemen zit. Dat ontstaat vaak doordat op activiteiten wordt gerapporteerd in plaats van op resultaten, en doordat slecht nieuws niet veilig kan worden gemeld.

Hoe vaak moet een project rapporteren aan de stuurgroep?

Dat hangt af van de omvang en het risico van het project. Een maandelijkse rapportage is gebruikelijk. Belangrijker dan de frequentie is dat afwijkingen buiten de afgesproken toleranties direct worden gemeld, ook tussen de vaste momenten door.

Wat is escalatie van commitment?

Escalatie van commitment is de neiging om te blijven investeren in een project dat niet goed gaat, omdat er al veel in is geïnvesteerd. Het maakt het moeilijk om op tijd bij te sturen of te stoppen. Heldere beslismomenten en eerlijke rapportages helpen om dat te doorbreken.

Bronnen

• Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383.
• Keil, M. (1995). Pulling the plug: Software project management and the problem of project escalation. MIS Quarterly, 19(4), 421–447.
• Keil, M., Smith, H. J., Pawlowski, S., & Jin, L. (2004). “Why didn’t somebody tell me?”: Climate, information asymmetry, and bad news about troubled projects. The DATA BASE for Advances in Information Systems, 35(2), 65–84.
• Rosen, S., & Tesser, A. (1970). On reluctance to communicate undesirable information: The MUM effect. Sociometry, 33(3), 253–263.
• Smith, H. J., & Keil, M. (2003). The reluctance to report bad news on troubled software projects: A theoretical model. Information Systems Journal, 13(1), 69–95.
• Staw, B. M. (1976). Knee-deep in the big muddy: A study of escalating commitment to a chosen course of action. Organizational Behavior and Human Performance, 16(1), 27–44.