Wanneer kies je welke projectmethodiek?
4 oktober 2016

Als consultant en trainer houd ik me al ruim 20 jaar bezig met het vervolmaken van projectmanagement binnen grote internationale organisaties en adviseer ik over portfolio- en programmamanagement. Al deze activiteiten hebben hun basis in de traditionele ‘waterval projectsystematiek’ zoals IPMA en Prince 2 waarbij het uitgangspunt is dat de volgende projectfase pas start als de vorige voltooid is. Je werkt van mijlpaal naar mijlpaal of anders gezegd van gate naar gate.

Begin 2016 heb ik voor een productiebedrijf in de VS een project opgezet en uitgevoerd volgens de agile projectmethodiek. We gaven dit project de naam FLOW™ een acroniem dat staat voor Fast Learning On the Workfloor. Binnen drie maanden werden met dit unieke trainingsprogramma maar liefst 12 mensgerelateerde productieverliezen sterk gereduceerd en nam de betrokkenheid van de operators sterk toe. De snelheid van het resultaat werd mogelijk gemaakt door de agile aanpak van FLOW.

Agile komt oorspronkelijk uit de ICT-wereld. Binnen andere vakgebieden zoals HR, productie, commercie is het gebruik van deze projectmethodiek nog minder gangbaar. Dat is jammer want door agile te werken kom je snel tot het gewenste resultaat en de methodiek is zeer toepasbaar bij een breed scala van veranderingen en projecten. Wat me echter opvalt in gesprekken die ik heb op seminars over projectmanagement, in gesprekken met klanten maar ook in literatuur die ik lees over de watervalmethode en over agile, dat er niet echt duidelijk omschreven is welke projecten het beste met de klassieke watervalmethode kunnen worden opgepakt en wanneer agile het meest van toegevoegde waarde is. Mensen zijn vaak ‘believers’ van het één of het ander, terwijl ik van mening ben dat je de keuze van de projectmethodiek moet laten afhangen van de situatie. Daardoor krijg je dus een hybride projectenportfolio.

Ik zal eerst een korte toelichting geven op agile op basis van mijn ervaringen met FLOW.

Snel waarde leveren met agile

Met agile werk je op een flexibele manier aan een snelle oplevering van kwalitatieve producten met de input van het hele ontwikkelteam via korte directe communicatielijnen. Agile werkt met een scrumteam en sprints. De term scrum komt uit het rugby. Het is het moment waarop je als team de armen in elkaar haakt om samen de speelstrategie te bepalen. Zo werkt de scrum in agile ook: het ontwikkelteam werkt intensief samen om in kleine stappen (sprints) snel resultaat neer te zetten.

Het ontwikkelteam

Het ontwikkelteam bestaat uit een producteigenaar, scrum master en de teamleden. Een producteigenaar houdt zich bezig met het 'waarom' van het product, de klantbehoeftes en de prioritering. De scrum master houdt zich bezig met de organisatie van de sprint en het team of met andere woorden het ‘wie doet wat en hoe’. De teamleden zijn professionals die gezamenlijk alle kennis en vaardigheden in huis hebben om het benodigde werk te kunnen verrichten om op het einde van de sprint werkbare producten op te leveren die klaar zijn voor de uitrol.

De kracht van focus

Een sprint is een periode van meestal één tot twee weken waarin het ontwikkelteam een volledige focus heeft op het ontwikkelen van de op te leveren producten. Zij doen tijdens een sprint dus geen andere werkzaamheden, scrum team leden zijn volledig vrij geroosterd van hun reguliere werk. Tijdens de sprint vindt continu het ontwikkelen, controleren, testen en opleveren van de producten plaats. In het geval van FLOW waren dit onderdelen van interne trainingen voor productiemedewerkers en alle ondersteunende materialen die de uitrol van de trainingen mogelijk maakten. Zo kun je als team in hoog tempo opleveren, fouten beperken en een snelle uitrol mogelijk maken. Tijdens een sprint werken de producteigenaar, scrum master en de teamleden zeer intensief samen. Het voelt als een snelkookpan. Onze klanten noemen het vaak ‘een versneller’. De sprint planning, sprint review en sprint retrospective zijn momenten waar alle betrokkenen bij aanwezig zijn. Bij de sprint planning wordt er, voorafgaand aan een sprint, bepaald wat er gemaakt en opgeleverd gaat worden in de beschikbare tijd. Bij de sprint review presenteert het team de gemaakte producten aan de producteigenaar. De sprint retrospective is de sprintevaluatie waarin het continue verbeteren centraal staat. Het goed benutten van de ‘leassons learned’ van deze sprint zodat de werkwijze en kwaliteit van de op te leveren producten verder verbeteren bij een volgende sprint. Dit iteratieve karakter is kenmerkend voor de agile aanpak en past naadloos bij de PDCA-cyclus (Plan-Do-Check-Act).

Wanneer agile en wanneer waterval?

Wanneer gebruik je nu de klassieke watervalmethode en wanneer is agile geschikt? In mijn ogen zijn er duidelijke uitgangspunten wanneer je het één of het ander het beste kunt gebruiken. Bij grote omvangrijke projecten met een hoog risico en waarbij de scope van het project vooraf redelijk duidelijk vastligt, is de traditionele ‘waterval projectsystematiek’ het beste op zijn plaats. Vaak is er een duidelijke scope en zijn veranderingen hierin beperkt zoals bij het neerzetten van een aangepaste productielijn op basis van een vernieuwde productiemethode. Terwijl als het vooraf lastig is om een projectplanning te maken, de producteisen niet duidelijk gespecificeerd kunnen worden en de projectleider verwacht dat er nog veel scopewijzigingen zullen zijn, dan kun je het project beter via de agile methodiek aanvliegen. Het is niet voor niets dat agile in de ICT sector ontstaan is waar gebruikers vaak moeite hebben om hun wensen SMART te formuleren.

De ervaring leert dat het werken volgens Prince2 of IPMA geen garantie is voor succesvol projectmanagement. Zo is het organiseren van een sprint ook geen garantie voor succesvolle productontwikkeling via de agile werkwijze. Beide zijn raamwerken opgezet met een achterliggende gedachte. En zowel klassiek projectmanagement als agile leer je niet zomaar uit een theorieboek. Alleen door het doen ervaar je de kracht en de snelheid van werken in een scrumteam of de voordelen van een gedegen risicoanalyse uit de klassieke watervalmethode.

Samenvattend, gebruik agile projectmanagement wanneer:

- het moeilijk is om alle eisen vooraf SMART te definiëren.
- het moeilijk is om het project van tevoren volledig te plannen.
- u verwacht dat er veel wijzigingen komen in de scope.
- u zeer snel werkbaar (tussen)resultaat nodig hebt.
- u mensen gedurende de sprints telkens minimaal één werkweek helemaal vrij
   kunt roosteren voor deelname in een scrum team.

 

Gebruik waterval projectmanagement wanneer:

- er een betrouwbare budgetindicatie nodig is bij de start.
- fouten in de beginfase grote invloed hebben op de volgende fasen.
- documentatie van wat gedaan is belangrijk is.
- het project erg groot is en vele deelprojecten met onderlinge verbanden kent.
- u wilt werken met duidelijke tussentijdse mijlpalen.

Marianne Carrière is senior trainer en adviseur bij Lumin. Eén van haar activiteiten is het begeleiden van bedrijven die portfolio-, programma- en projectmanagement invoeren of professionaliseren. Vanuit deze rol werkt ze met agile en scrum en klassiek projectmanagement.. Daarnaast verzorgt zij Train-de-Trainer trajecten, zodat medewerkers in staat zijn om kennis intern aan collega’s weg te leren. Daarnaast werkt Marianne vanuit de principes van TPM en lean.Vanuit deze combinatie van kennis en vaardigheden is FLOW™ ontstaan. Wilt u eens sparren over welke methodiek voor uw project de beste keuze is? Neem gerust contact op.

Geïnteresseerd om verder te praten of FLOW™ een oplossing voor verliesreductie in uw organisatie is? Of over trainingen/coaching in agile of klassiek projectmanagement? Bel of mail met Marianne Carrière.

 

Meer informatie over FLOW vindt u hier.

Reactie toevoegen

Deel dit artikel