# Conceptnotitie – statusupdates en maandrapportage (oefentekst)

## Inleiding
De afgelopen maanden hebben we in meerdere teams besproken dat de manier waarop we updates geven over lopend werk niet altijd goed uitpakt. Soms gaat het prima, maar vaak ook niet. We sturen dan losse berichten via verschillende kanalen, iedereen voegt nog iets toe en uiteindelijk weet niemand meer wat de laatste stand van zaken is. Dat leidt tot vertraging, extra afstemming en irritatie, zeker als er richting klanten of management een verwachting is uitgesproken.

Er is ook discussie over wat een “goede update” eigenlijk is. De een wil vooral details, de ander wil vooral beslispunten. Soms is er een spreadsheet, soms een mail, soms een chatbericht. We hebben bovendien niet altijd dezelfde termen voor dezelfde dingen. In sommige updates noemen we iets “kritiek”, in andere updates “hoog risico”, terwijl het vaak om hetzelfde punt gaat. Daardoor ontstaan misverstanden.

Het idee is nu om “iets van een vaste manier” te introduceren waarmee we maandelijks rapporteren en wekelijks de status delen. Niet om alles te formaliseren, maar wel om te zorgen dat iedereen sneller begrijpt waar we staan, wat er is besloten en wat er nog nodig is. Er zijn al wat losse ideeën: een vast sjabloon, een vaste updatecadans en iemand die het overzicht bewaakt. Wat precies de beste vorm is, is nog niet helemaal duidelijk, maar we moeten er wel iets mee omdat we anders blijven doorpraten over dezelfde punten.

## Wat we nu zien (symptomen)
- Updates staan verspreid over e-mail, chat en documenten.
- Statusinformatie is niet altijd actueel, maar wordt wel doorgeplaatst.
- Acties zijn er wel, maar eigenaren en deadlines ontbreken regelmatig.
- Dezelfde feiten worden op meerdere plekken net anders beschreven.
- Er worden conclusies getrokken zonder dat duidelijk is welke data of bron erbij hoort.
- Er is geen vaste plek waar de “laatste versie” staat.

## Waarom dit nu misgaat (rommelig middenstuk)
Het gaat nu mis omdat we geen vaste structuur hebben en ook niet echt afspreken wie wat doet, en daardoor gaan mensen vanzelf weer de weg van de minste weerstand volgen. Als iemand snel iets moet melden dan gebeurt dat in een chat, en later plakt iemand dat weer in een mail en dan komt het in een document, maar ondertussen heeft iemand anders alweer een nieuw detail ontdekt en dat wordt dan weer los gedeeld. Daardoor krijg je een situatie waarin iedereen denkt dat hij het juiste doet, maar waar het geheel niet klopt. Dit leidt tot vertraging omdat teamleads achteraf vragen moeten stellen, en het zorgt ook voor risico’s omdat er verwachtingen ontstaan op basis van onvolledige informatie. We zeggen soms ook dat “de datakwaliteit niet goed is”, maar dan bedoelen we verschillende dingen: de een bedoelt dat de bron verouderd is, de ander dat definities ontbreken en weer een ander dat er gewoon fouten in de cijfers zitten. En dan gaan we eerst lang praten over wat er fout ging, terwijl de oplossing eigenlijk is dat we vooraf afspreken hoe een update eruit ziet en dat we een vaste check doen voordat we iets rondsturen. Tegelijk willen we ook niet dat dit een groot bureaucratisch proces wordt, want dan gaat niemand het doen. Maar als we niets doen, blijven we toch steeds opnieuw dezelfde discussies voeren, en blijven we brandjes blussen.

## Voorstel (ruw)
Hieronder staan een paar ideeën die waarschijnlijk helpen, maar dit is nog niet uitgewerkt en het is ook niet zeker of dit de juiste volgorde is.

1. We maken elke maand een maandrapportage met kerngetallen en trends, zodat we een terugkerend ritme hebben.
2. We gebruiken een vast sjabloon zodat iedereen weet wat er in hoort.
3. We spreken af dat er één plek is waar de laatste versie staat.
4. We maken een korte wekelijkse update voor het team, die niet lang is maar wel consequent.
5. We zetten in elke update minimaal: status, planning, risico’s, acties en vragen.
6. We doen vooraf een datacheck (maar we moeten nog bepalen wat dat precies is).
7. We maken het ook weer niet te zwaar, anders gaat het niet werken.

## Randvoorwaarden en aandachtspunten
- De update moet in vijftien minuten te lezen zijn.
- Het moet duidelijk zijn wat een feit is en wat een interpretatie of verwachting is.
- We moeten een vaste terminologie gebruiken (bijvoorbeeld altijd “risico” en niet wisselen met “issue” of “knelpunt” voor hetzelfde).
- De maandrapportage moet vergelijkbaar zijn met vorige maanden (dus dezelfde structuur).
- Er moet één eigenaar zijn die de input verzamelt en de versie bewaakt.
- We moeten voorkomen dat mensen alsnog losse updates sturen “omdat het sneller is”.

## Afronding (te vaag)
Als we dit goed doen, wordt het voor iedereen beter en hebben we meer grip. De intentie is om hiermee te starten, maar we moeten nog even kijken hoe precies en wie wat doet. Het is belangrijk dat we dit niet te groot maken, maar wel groot genoeg om effect te hebben. We kunnen hier binnenkort een besluit over nemen en dan kijken we hoe het gaat. Waarschijnlijk is het slim om dit in een project te zetten en het daarna te evalueren, maar dat is nog niet besproken. In elk geval moeten we ergens beginnen.
