Project management kan een project resultaat succesvol maken of verpesten. Onlangs kreeg ik een vraag van een medewerker bij een klant, of ik haar tips wilde geven voor goed project management. Ik heb meerdere projecten bij deze klant gedaan. Door de loop van de jaren, heb ik zo mijn eigen methodes ontwikkeld. Ik heb voor haar mijn eigen praktische tips en aanpak eens op de mail gezet.
More...
Tijd om deze tips ook met jou te delen. Pik er uit wat je aanspreekt.
Doelen en verwachtingen
Een project charter of project initiation document is door mijzelf lange tijd onderschat geweest. Er zijn veel templates voor. Maar in essentie is het een afstemming met de opdrachtgever: wat verwacht hij of zij van jou. Probeer het doel zo concreet / SMART mogelijk te formuleren. Vraag je opdrachtgever wat voor haar/hem belangrijk is en wanneer het project een succes is. Hoor dit direct van de opdrachtgever en zorg dat je het helemaal begrijpt.
Consistent overzicht / Kanban board
Consistent overzicht houden is super belangrijk. Daarmee kun je altijd aantonen waar je staat, heeft iedereen houvast en heb je afspraken en beslissingen vastgelegd. Ook kun je garanderen dat er niets wordt vergeten. Je kunt natuurlijk wel dingen afwijzen, of op de langere baan schuiven, maar dan kan iedereen zien wat er gebeurt is.
Concreet betekent dit voor mij een Kanban board aanmaken en gedurende het project bijhouden. Dit is misschien wel het belangrijkste centrum van het project team. Om dit consistent te blijven doen, is een kunst en gaat vaak mis. Door het Kanban board ook het middelpunt of de agenda van elke team meeting te laten zijn, houd je het up-to-date.
Een Kanban bord is een pagina of canvas met actielijsten. In dit artikel van Zapier staat haarfijn uitgelegd wat Kanban is en waar het vandaan komt. Je maakt een Kanban bijvoorbeeld in Microsoft Planner of Trello. Of als je echt professioneel wilt gaan, Asana. In essentie zijn de lijsten:
- Inbox: nieuwe ideeën of taken buiten de project team meeting worden hieraan toegevoegd. Deze worden in de meeting besproken en aan een andere lijst toegevoegd. Moet aan het einde van elke meeting weer leeg zijn.
- Product Backlog: de lijst met acties/items die opgeleverd moeten worden gedurende het project.
Sprint backlog: de lijst met acties die in de komende sprint moeten worden gedaan. Zorg dat de actie zo concreet mogelijk geformuleerd is en toegewezen aan iemand. Die moet zich hier aan commiteren. Is de actie te groot om in één sprint te doen, zorg dat deze dan wordt opgehakt in meerdere acties. - Doing: hier staan de acties in waar op het moment aan gewerkt wordt. Deze mag niet te lang zijn! Eerst iets afwerken voor het oppakken van iets nieuws. Dit is echt heel belangrijk om dingen gedaan te krijgen!
- To demo: de acties die zijn opgeleverd gedurende de sprint. Klaar om te laten zien aan de andere project team leden tijdens de project team meeting.
- Done: alles wat gedaan is. Evt kun je To demo combineren met deze en vink je ze af zodra ze gepresenteerd zijn. Dan verdwijnen ze afhankelijk van de tool.
- Parking lot: acties of features die een toegevoegde waarde leveren aan het project resultaat, maar niet essentieel zijn. Deze kunnen òf bij voldoende tijd toch worden opgepakt, òf in een volgend project worden geadresseerd. Dit zou de project eigenaar moeten beslissen.
- Rejected: afgewezen acties.
- Decisions: lijstje met beslissingen die gemaakt zijn en je wilt documenteren met redeneringen. Vaak handig om te voorkomen dat dezelfde discussies vaker plaats vinden.
Mijn methode en lijsten veranderen van project tot project. Je zult zelf zien wat handig is. Hoe minder hoe beter. Dit is eigenlijk al aan de lange kant.
Het risico van een dergelijk bord, is dat het vervuild raakt. Als gevolg daarvan, wordt het niet meer gebruikt en grijp je naar andere middelen. Daarom is het essentieel om wat extra tijd te besteden om het af en toe op te schonen.
Consistentie en consequentie zijn dus key… Makkelijker gezegd dan gedaan.
Rollen
Wie is verantwoordelijk voor wat. Zorg bij de start dat iedereen in het project team weet wat zijn of haar rol is en wat er verwacht wordt. Laat mensen ook reflecteren hierop (zie retrospective). Gebruik je de scrum methode, dan is de product owner rol erg belangrijk. De product owner moet begrijpen wat er van ‘m verwacht wordt en eventueel hierin begeleid worden. Dit geldt voor alle rollen, maar in mijn ervaring is dit wel de belangrijkste.
Werken met iets tastbaars
Iedereen heeft aannames in z’n hoofd over wat er opgeleverd moet worden. Ondanks dat je het er honderd keer met elkaar over hebt gehad, blijken verwachtingen en inzichten toch anders te zijn wanneer het project resultaat eindelijk wordt opgeleverd. Dan kan het te laat zijn om dit nog te herstellen.
Daarom werk ik altijd zo snel mogelijk naar iets tastbaars toe. Als het om dashboarding of tooling gaat, is het vaak mogelijk om binnen een week of 2 een “minimum viable product” op te leveren. Iets dat nog lang niet compleet is. En dat alleen voor de “happy flow” deels werkt, de eerste stap in het automatiseren van een proces. Maar wel iets tastbaars. Dan zie je dat iedereen ineens anders kijkt naar het op te leveren product. En je kunt in elke project team meeting bespreken “what’s next to do”.
Kadans / frequentie
Noem het sprints, iteraties, project team meetings. De essentie is: zorg voor een vaste kadans. Oftewel elke twee weken een meeting. Of elke week. Niet cancellen, hooguit een dag verschuiven. Spreek elke meeting af wat er voor de volgende meeting moet gebeuren en kom daar de volgende meeting op terug (gebruik daarvoor het kanban board).
Retrospective
Ik vind het altijd erg waardevol om tijdens team meetings terug te blikken op het proces. Mensen moeten het gevoel hebben dat ze alles mogen zeggen. Over wat iemand anders niet handig had gedaan, iets dat beter kon in het proces, of iets dat juist prettig was in het proces. Hier kun je acties uit halen om het proces steeds verder te verbeteren en het project als een flow te laten verlopen.
Planning bij scrum/sprints
Scrum en tijdsplanningen zijn een lastige balans. Dit is hoe ik vaak te werk ga om toch een planning te kunnen afgeven:
- Zodra ik weet wat er moet gebeuren, maak ik een work-break down: wat zijn de belangrijkste high-over op te leveren producten die opgeleverd moeten worden.
- Zet deze in de tijd achter elkaar.
- Maak een inschatting van de tijd die nodig is hiervoor.
- Bepaal de sprints die in totaal dan nodig zijn. Bijvoorbeeld 20 weken nodig voor het volledige project, 2 weken per sprint is 10 sprints.
- Maak een Gantt chart planning (bijv via MS Project) en zet daarin de acties die nodig zijn voor te kunnen starten. Soms is er nog Design tijd nodig bijvoorbeeld, of input verzamelen.
- Plaats daarna de sprints met begin en einddatum, elkaar opvolgend. Noem ze gewoon sprint 1, sprint 2 enz.
- Voeg milestones toe op basis van de eerste en tweede stap: na welke sprint moeten de op te leveren producten ongeveer klaar zijn.
- Als je Asana gebruikt, kun je het bovenstaande ook als milestones daar toevoegen. In een aparte lijst. Dan heb je vanzelf je Gant chart.
Dit is je planning. Deel dit met de stuurgroep en houd een slag om de arm. Je hebt een paar sprints nodig om te bepalen of het realistisch is. Hier begin je mee en je monitort of de milestones gehaald worden. Worden ze niet gehaald, bekijk dan samen met het project team wat de impact op de planning is. Houd ook vooral de stuurgroep / project owner op de hoogte.
Methode
Voor mij past de scrum methode erg goed. Dit betekent niet dat je dit altijd volledig moet adopteren, soms is het goed om stukjes er uit te halen. Niet alles hoeft rigide volgens de scrum handreiking te gebeuren.
Het belangrijkste is dat je een methode kiest die bij jou past. En bij het project team. Ik heb zelf een scrum master opleiding gedaan, 1-op-1 via Entalis. Pas nadat ik een aantal projecten had gedaan met gebruik van de scrum methode (daarvoor had ik een korte scrum intro gedaan). Zo kon ik praktische vragen stellen, hoe met bepaalde situaties om te gaan.