5 min.
Jont Groenendaal Een projectmanagement methode geeft grip. Het zou je ten alle tijden inzicht moeten geven in: waar staan we nu? Wat staat ons nog te doen? En lopen we nog in de pas met wat we hadden afgesproken over tijd, geld, kwaliteit, communicatie en bemensing? Maar als de methode net niet helemaal aansluit op het type uitdaging waar je mee te maken hebt, geeft het vooral de illusie van grip op je project.
“Alles gaat altijd anders dan verwacht in onze projecten en wij houden van flexibiliteit. Daarom doen wij alles met Scrum. Dat geeft ons tenminste flexibiliteit”. Of: “de complexiteit van dit project is zo groot dat we echt genoeg structuur nodig hebben. Daarom gaan we met PRINCE2 werken.” Als we doorvragen, merken we dat organisaties vanuit de beste intenties soms toch net de verkeerde methoden kiezen bij hun projecten.
Dit artikel geeft jou als opdrachtgever inzicht in:
- Hoe typeer ik mijn uitdaging en welke methode past daarbij?
- Hoe zijn die methodes gefaseerd en hoe geeft dat grip op het project?
- Hoe houdt ik in verschillende typen projecten grip op tijd, geld, kwaliteit en risico’s?
De juiste methode voor jouw uitdaging
Ten eerste: we hebben het in dit artikel over ‘projecten’. Soms gaat het al mis door een uitdaging als project te behandelen, terwijl dat het helemaal niet is. Óf door het niet als een project aan te pakken terwijl dat het wél is. Daarom voor we beginnen: is het wel een project?
Een project heeft een duidelijk begin en een definitief eind (zowel in tijd als in eindsituatie). Het is resultaatgericht: een project moet een tastbaar eindproduct opleveren. Het is een eenmalige klus, dus geen terugkerende routine. De meeste projecten waar wij leiding aan geven zijn complex (meerdere belangen, onzekerheden en afhankelijkheden) en multidisciplinair (er zijn verschillende afdelingen en/of expertisegebieden bij betrokken).
Als je uitdaging hier niet aan voldoet, dan heb je misschien wel te maken met een procesoptimalisatie, of een programma, of een visie traject, of het kan van alles zijn. Daar gaan we nu niet te diep op in: hier gaat het over de juiste aanpak voor je project.
Zijn het probleem en de oplossing allebei vaag?
Het kan zijn dat zowel het probleem dat je op moet lossen, als ook het resultaat van het project, allebei nog vaag zijn. Er is natuurlijk altijd wel een aanleiding, maar die maakt niet per definitie duidelijk welke onderliggende problematiek er moet worden opgelost. Bijvoorbeeld:
“Een deel van de afgestudeerde mbo-studenten kan zelfs in een goede economie geen baan vinden na hun opleiding. De school moet dienstverlening ontwikkelen om de stap naar de arbeidsmarkt voor deze studenten te ondersteunen.”
Dit klinkt als een probleem, maar het is eigenlijk een aanleiding. Het zegt namelijk nog niks over hoe het komt dat deze groep geen werk vindt. Of ze dat zelf als een probleem zien. Wat er precies binnen de cirkel van invloed van de school ligt en wat niet. Wel onderdeel van deze grotere uitdaging de school dus heeft op te lossen. Daarnaast is het ook nieuwe dienstverlening waar scholen nog weinig tot geen ervaring mee hebben. Een kant en klare oplossing is er dus niet.
In zo’n geval kiezen wij vaak voor Design Thinking. Een aanpak die heel geschikt is voor het onderzoeken wat het probleem eigenlijk precies is (vanuit een diepgaand begrip van de belevingswereld van de doelgroep) om van daaruit op creatieve en experimentele wijze naar oplossingen te zoeken en deze te testen in de praktijk.
Is het probleem helder, maar de oplossing nog vaag?
Is het probleem wel grotendeels bekend, maar is er nog geen oplossing waarvan we weten dat die werkt? Dan kiezen we voor Scrum. In korte cycli bouwen, telkens toetsen, en bijstellen op basis van wat je leert. Je kunt je misschien voorstellen dat een Design Thinking traject op een gegeven moment leidt tot een aantal potentiële (maar nog grofmazige en niet getoetste) oplossingen voor een inmiddels helder probleem? Dan kunnen we het verder uitwerken en testen van die oplossingen doen met Scrum.
Zijn het probleem en de oplossing allebei helder?
Is het probleem grotendeels bekend en de oplossing op hoofdlijnen ook redelijk gekaderd? Dan volstaat vaak een klassieke ‘waterval’ projectmanagement methode waarmee je ogenschijnlijk in één rechte lijn naar een eindresultaat toewerkt.
Moet dan het eindresultaat tot in detail bekend zijn voordat je begint aan zo’n project? Nee; ook een klassiek project heeft gewoon een ‘definitiefase’ waarin er nog een heleboel kan en moet worden onderzocht. Maar neem dit voorbeeld:
Een ROC gaat modulair en flexibel onderwijs maken. Dat klinkt misschien als een innovatievraagstuk, want je kunt daar de meest exotische beelden bij hebben. Maar zoveel verschillende (realistische) smaakjes zijn er eigenlijk niet. Je kunt studenten meerdere instroom momenten bieden, je kunt hen de opleiding laten verdiepen en verbreden (door extra modules te kiezen) en je kunt hen de opleiding laten versnellen of vertragen. Daarbij is de kwalificatiestructuur vaak ook erg ‘beperkend’ in wat er kan: een Verpleegkunde student kan echt geen diploma halen als zij heeft besloten dat ze geen prikken hoeft te kunnen zetten, maar in plaats daarvan wel een module nagel styling heeft gevolgd.
Hoe je die vormen van flexibel onderwijs precies mogelijk maakt binnen het bestaande systeem, dat kun je in de definitiefase nog met elkaar beslechten. En dat kan nog best een flinke hap werk zijn. Maar er gaat niet ineens een totaal nieuwe, exotische onderwijsvorm uitkomen waarmee je bij een ROC in Nederland je Verpleegkunde diploma te halen door op Bali te studeren via e-learning, wanneer het je zelf uitkomt, en al je stages loop je in Virtual Reality. Zo’n project kun je dus relatief lineair aanvliegen.
Je kunt je ook voorstellen dat er mogelijke oplossingen uit een Design Thinking traject komen, die worden uitgewerkt en getest met een scrum-achtige aanpak, en als daar een duidelijk ‘bewezen’ eindproduct uit komt dan volgt een een klassiek implementatieproject. Je beweegt dan namelijk van probleem én oplossing onduidelijk, naar probleem duidelijk, oplossing nog niet, naar probleem en oplossing duidelijk.
Heeft je project nog een eigenschap die om iets extra’s vraagt?
Naast de hoofdkeuze hierboven kan een project eigenschappen hebben die om een aanvullende methode vragen. Denk aan:
- Het werk van Common Eye als het om een organisatieoverstijgend vraagstuk gaat
- Methodes als PROSCI als er een sterke veranderkundige kant aan het project zit
- Lean of methodes voor procesontwerp als het resultaat sterk leunt op goede processen
- Het Active Implementation Framework als er werkwijzen moeten worden geïmplementeerd die meer vragen dan alleen training (maar ook borging in aannamebeleid, processen, systemen en managementsturing)
Er zijn meer van dit soort eigenschappen denkbaar. De kern blijft hetzelfde: benoem ze, en vraag je af welke methode je aanvullend op je basisaanpak nodig hebt.
Goede fasering zorgt voor grip
Wat moet er aan het eind van een fase liggen?
Met behulp van ons artikel over de projectscope formuleer je van te voren een beeld van wat er aan het eind van de rit moeten worden opgeleverd (óf welke grote innovatievraag er beantwoord moet zijn). Zelfs als je dat goed doet, kan het voor een team nog verwarrend zijn: “wat is dan nu onze volgende stap om daar uiteindelijk te komen?”
Bij een klassieke aanpak en bij design thinking zit het antwoord op die vraag in de fasering. En dus ook je grip op het project: zit je in de fase waar je in moet zitten? Ben je aan het doen wat je in die fase zou moeten doen? Is de tussentijdse opbrengst voldoende om door te kunnen naar de volgende fase?
Elke fase heeft z’n eigen tussenresultaat. Na afloop van elke fase kijk je opnieuw naar de doelstelling, het probleem, het beoogde eindresultaat en de afbakening (APDRA). Zijn die nu beter in te vullen? Is er reden om af te wijken van wat we dachten? Hebben we meer inzicht in of dit werkt? Ook kijk je na elke fase opnieuw naar de beheersmaatregelen (tijd, geld, kwaliteit, informatie, organisatie, ofwel: TGKIO). Zitten we op schema? Klopt onze kostenraming nog? Is er aanleiding om er andere mensen bij te betrekken?
Hoe doe je dat met Design Thinking?
| Fase | Levert op |
| Context & empathisch onderzoek | Een diepgaand beeld op van de historie en de context van het vraagstuk en de belevingswereld van de doelgroep in relatie tot het vraagstuk. |
| Probleemdefinitiefase | Een of meer concrete probleemdefinities, gebaseerd op inzichten uit de vorige fase en dus vergaand geformuleerd vanuit het perspectief van de doelgroep. |
| Ideeënfase | Een set aan mogelijke oplossingsrichtingen waarmee het probleem van de organisatie kan worden opgelost dóór de problemen van de doelgroep te adresseren en op te lossen. |
| Prototypefase | Minimale versies van een of meer ideeën uit de vorige fase die in de praktijk getest kunnen worden om van te leren wat er wel en niet werkt. |
Zolang je nog niet de informatie of het tussenproduct hebt om in de volgende fase mee verder te kunnen, ben je nog niet klaar. Zolang je wel de stappen aan het zetten bent om tot die informatie of dat tussenproduct te komen, ben je goed bezig. Grip is weten: doen we de goeie dingen, en doen we die dingen goed? En natuurlijk: blijven we binnen de perken?
Hoe werkt dat met Scrum?
Scrum kent geen fases in de zin dat de ene stap een tussenproduct oplevert waar in de volgende stap op voortgebouwd kan worden. Scrum kent herhaling: elke sprint heeft dezelfde vorm, alleen de inhoud verandert. Grip zit hier dus niet in “wat levert deze fase op”, maar in twee andere vragen: blijft het ritme van de sprints hetzelfde, en levert elke sprint iets bruikbaars en getoetst op.
Een team dat de ene sprint twee weken duurt en de volgende ineens vier, of dat een sprint afsluit zonder dat er iets werkends ligt, verliest grip, ook als iedereen het woord ‘scrum’ blijft gebruiken.
Bij scrum vraag je niet wat de volgende fase oplevert, je vraagt of het ritme intact is en of de laatste sprint iets heeft opgeleverd waar je verder mee kunt.
Hoe doe je dat bij een klassiek project?
| Fase | Levert op |
| Initiatief | Een gedeeld beeld bij stakeholders over de opgave en een een goedgekeurde projectopdracht. |
| Definitie | Een programma van eisen waarin duidelijk wordt waar het projectresultaat aan zal moeten voldoen. Dus: met welke eigenschappen, behoeften, mogelijkheden en onmogelijkheden met er in het eindresultaat rekening worden gehouden? |
| Ontwerp | Het eindresultaat in detail uitwerkt op papier, op basis van het programma van eisen uit de vorige fase. |
| Voorbereiding | Een duidelijk en concreet beeld van wat er nodig is voor implementatie (dus bijvoorbeeld niet “een training” maar welke training) en een goedgekeurd realisatieprogramma (implementatieplan). |
| Realisatie | Het realisatieplan is uitgevoerd en het ‘resultaat’ is opgeleverd zoals bedacht. Bestaat en werkt in de praktijk. |
| Nazorg | Het resultaat is duurzaam geborgd in de staande organisatie. |
Het project evolueert, je methode verandert
Vaak lopen de werkwijzen hierboven niet los van elkaar, maar na elkaar, of zelfs in elkaar. Soms begin je met een onduidelijk probleem en een onduidelijke oplossing. Bijvoorbeeld: je zet Design Thinking in om het probleem scherp te krijgen en tot een oplossingsrichting te komen. Met scrum werk je in sprints aan het testen en bijschaven van die oplossing (bijvoorbeeld in een pilot). Als probleem en oplossing eenmaal bekend zijn, kan een bredere implementatie nog steeds nodig zijn. Dan gebruik je een klassieke projectmanagement methode.
Een goede projectleider volgt niet gewoon blind een methode, maar kiest de juiste methode bij de uitdaging die hij op dat moment heeft.
Kunnen we helpen?
Wil je een keer vrijblijvend van gedachten wisselen over je project? Of ben je benieuwd wat een projectleider van Brighthives voor jou kan betekenen? Neem gerust contact op met jont@brighthives.com.
