Begin deze maand rolden we Jira uit bij een projectteam waarvan de meeste leden nog nooit met een ticketsysteem hadden gewerkt. Veranderadviseurs, contractmanagers, procesbegeleiders: mensen die uitstekend zijn in hun vak en van wie niemand ooit heeft gevraagd om een sprint board te begrijpen.
Een week later stond het bord, gebruikte het team het, en kwam de eerste voortgangsvraag in het projectoverleg niet van mij maar van een teamlid: "Waarom staat dit ticket nog op TODO?" Dat moment is waar je het voor doet.
De hele onboarding kostte één voorbereidingsdag, één sessie van een uur en een cheatsheet van één A4. Dit is hoe.
Begin bij de structuur van het project, niet bij de tooling
De klassieke fout bij projecttooling is beginnen met wat het systeem kan. Jira kan sprints, story points, epics, releases, roadmaps en nog veertig dingen die een niet-IT-team nooit gaat gebruiken en die vooral intimideren.
Wij zijn andersom begonnen: het projectplan was er al, met werkpakketten en deliverables. Die structuur hebben we één op één overgezet:
- Elk werkpakket wordt een epic. Het team kende de werkpakketten al uit het projectplan, dus de indeling voelde vertrouwd vanaf dag één.
- Elk deliverable wordt een taak. Concreet en afrondbaar: een document, een besluit, een ingerichte omgeving.
- Activiteiten worden subtaken. Alleen waar dat helpt. Niet elke taak hoeft opgeknipt.
Geen story points, geen sprints, geen releases. Vijf statussen, van TODO tot geaccepteerd. Wie meer wil, kan later altijd uitbreiden. Wie met veertig functies begint, raakt het team kwijt voordat het eerste ticket is aangemaakt.
De cheatsheet van één A4
Naast de sessie kreeg het team één A4 met werkafspraken. Niet meer, want een handleiding van twintig pagina's is een handleiding die niemand leest. Op dat A4 staat:
- Waar je je eigen werk vindt en hoe je een status verplaatst.
- Wanneer je een comment plaatst: bij elke voortgang, elke mailwisseling en elk besluit dat het ticket raakt.
- Wat de statussen betekenen, in gewone taal. "IN REVIEW betekent: iemand anders kijkt ernaar, jij hoeft even niets."
- Eén gouden regel: staat het niet in Jira, dan is het niet gebeurd.
Die laatste regel klinkt streng, maar hij is bevrijdend. Niemand hoeft meer te onthouden wat er in welke mail stond. De geschiedenis van elk deliverable staat op één plek, ook voor wie er over een half jaar bij komt.
Adoptie is een ritme, geen sessie
De onboardingsessie is het makkelijke deel. Adoptie ontstaat in de weken erna, en die verloopt via het ritme van het project:
- Het projectoverleg loopt langs het bord, niet langs een aparte actielijst. Wie het bord niet bijwerkt, merkt dat direct, op een vriendelijke manier.
- De projectmanager doet het zelf voor. Elk besluit uit een overleg, elke mailwisseling met de leverancier komt als comment op het ticket. Voorbeeldgedrag werkt beter dan instructie.
- Fouten zijn gratis. Ticket verkeerd aangemaakt? Verkeerde status? Niets kapot, alles terug te draaien. Die boodschap expliciet uitspreken scheelt drempelvrees.
Na twee weken zag ik het kantelen: teamleden begonnen tickets aan te maken voor werk dat ik nog niet had gezien. Dat is het moment waarop het bord van de projectmanager het bord van het team wordt.
Waarom dit meer is dan gemak
Een gedeeld bord verandert de dynamiek van een project op een manier die verder gaat dan handigheid. Voortgang wordt zichtbaar zonder dat iemand ernaar hoeft te vragen. Bottlenecks vallen op doordat tickets blijven hangen, niet doordat iemand klaagt. En de verantwoording aan stuurgroep en PMO wordt een export in plaats van een avond schrijven.
Projectbeheersing hoeft geen zwaar apparaat te zijn. Soms is het een bord, vijf statussen en één A4 met afspraken. De discipline zit niet in de tooling maar in het ritme eromheen.
← Terug naar alle artikelen