PMI publiceerde in februari van 2020 de 'PMI Pulse of the profession' waarin stond: "Werk is veranderd". De manier waarop de wereld denkt over projecten, moet ook veranderen. "
We moeten onze manier van werken en onze skills continue blijven ontwikkelen, maar 2020 heeft ons ook bewezen dat we over een bepaald niveau van flexibiliteit beschikken.
Volgens PMI moeten onze organisaties agile zijn om succesvol te zijn in de toekomst. Ook moeten onze organisaties leren om te focussen op de juiste technologieën en het aantrekken van relevante vaardigheden. Lees meer in het rapport:
“Het is voor Pulse de eerste keer dat executives hebben geïdentificeerd welke factoren hebben zij het belangrijkste vinden om toekomstig succes veilig te stellen. De top 3 waren: de flexibiliteit (agility) van organisaties (35%), Het kiezen van de juiste technologie om in te investeren (32%) en het aantrekken van relevante vaardigheden (31%). "
Laten we ons focussen op een organisatie die agile principes kan integreren tijdens het managen van het software ontwikkelings / leveringsproces.
Lang geleden waren mensen al bezig om unieke projecten als monumenten en gebouwen, waar we nu nog van kunnen genieten, tot een goed einde te brengen. Ook waren veel bedrijven nieuwe producten als auto's, vliegtuigen en telefoons aan het uitvinden. Al dit gebeurde zonder Gantt-diagrammen, agile frameworks, Prince2®, kritieke-pad methodes en alle andere tools en technieken die je nog kunt gebruiken voor projectmanagement tegenwoordig.
Terugkijkend kunnen we gaan bepalen hoe de aanpak van projectmanagement veranderd is over de jaren en welke impact het heeft op de verschillende fasen van een project. Het is geen volledige geschiedenis van projectmanagement, maar we zullen je meenemen in een aantal voorbeelden.
In het begin van de 20ste eeuw ontwikkelde Henry Gantt een tool die tot op de dag van vandaag nog steeds gebruikt wordt, de Gantt-diagrammen. Het diagram bestaat uit een tijdlijn op de X-as en activiteiten op de Y-as. Alle acties zijn een staaf in het diagram en er wordt duidelijk van welke andere taak een bepaalde taak afhankelijk is.
De waarde van dit diagram zit vooral in het feit dat managers deze toe kunnen passen in meerdere industrieën. Dit wordt ook gezien als een van de redenen waardoor deze methodologie zo belangrijk is geworden in de wereld.
Gantt-diagrammen helpen software ontwikkelaars te begrijpen welk plan er ligt voor hun taken en hoe die taken zijn verbonden met andere taken. In de essentie presenteert het diagram hoe de fases van het project gepland zijn en wanneer welk team klaar is met haar deel van het werk.
Verderop in de 20ste eeuw, in 1975, ontwikkelde Simpact Systems Limited een standaard genaamd PROMPTII. Deze methode werd geadopteerd door de Britse regering in alle IT projecten in 1979.
De levenscyclus van PROMPTII bevatte de volgende onderdelen:
In 1989 kreeg PROMPTII een nieuwe naam, PRINCE. Dit nieuwe acroniem stond in het engels voor ‘Projects In Controlled Environments’. In 1996 kreeg deze standaard zijn laatste naam update en veranderde het in wat we nu kennen als Prince2®. Prince2® is een veel gebruikt standaard voor projectmanagement processen in de software industrie.
Een project manager in de software industrie leidt het werk van het desbetreffende software ontwikkelingsteam. Het team varieert in grootte en het varieert ook in de hoeveelheid rollen, afhankelijk van de opdracht. Een team kan bestaan uit ontwikkelaars, testers, business analisten en product designers.
In 2001 ontmoeten zeventien personen elkaar in Utah (VS) “om te praten, skiën, relaxen en overeenkomsten te vinden”. De uitkomst van deze ontmoeting was wat we tegenwoordig kennen als ‘The Agile Manifesto’.
Source: Agile Manifesto
Agile is als een paraplu - Methodes die ‘The Agile Manifesto’ volgen mogen agile genoemd worden. Om daar daadwerkelijk te komen kan vrij lang duren voor de betrokken stakeholders.
Eerder hebben we drie voorbeelden beschreven waar we aan kunnen zien hoe de aanpak van project management evolueert over de jaren. Sommige project managers passen methodologieën als Prince2® nog steeds toe, hoewel er in software ontwikkeling tegenwoordig veelal wordt gewerkt met methodologieën die gebaseerd zijn op agile principes.
Wij geloven dat deze evoluties zullen blijven bestaan, omdat we in een continue veranderende wereld leven. Ook zullen projectmanagers altijd blijven zoeken naar methodes die risico management verbeteren, de prestaties van de levering verbeteren en de kwaliteit van de opgeleverde software verbeteren.
Project management kan onderverdeeld worden in 2 overkoepelende methodes: waterfall & agile.
De Waterfall methode wordt ook wel de opeenvolgende methode (cascade approach) genoemd. Deze methode is gebaseerd op de gedachte dat de verschillende fases elkaar opvolgen. Een project start met de kosten/tijd inschatting, gaat vervolgens in ontwikkeling, wordt opgevolgd door testen, wordt getest door gebruikers en wordt vervolgens vrijgegeven.
Agile methodes (Scrum, Kanban, FDD, etc.) zijn daarentegen gebaseerd op een gedachte die flexibeler (lean) en iteratief is. Een project dat aan de hand van agile methodes wordt gemanaged doorloopt een cyclus meerdere keren om tot het eindresultaat te komen.
Kanban is een aanpak die als lean beschouwd kan worden in software ontwikkeling. Het team volgt haar eigen processen en gebruikt een Kanban bord om dat te visualiseren. Op dit bord kunnen de verschillende teams hun stappen in het proces definiëren.
Als je Kanban gebruikt voor projecten is het verstandig om een limiet te stellen op het aantal taken dat nog open staat op hetzelfde moment. Dit reduceert de WIP (Work In Progress). Met Kanban kan er in iteraties gewerkt worden, alhoewel dit optioneel is. De essentie van deze aanpak heeft geen strakke tijdsplanningen, waar scrum sprints dat bijvoorbeeld wel hebben. Een team kan er bij Kanban ook voor kiezen om de tijdsbesteding in te schatten voor de taken op het Kanban bord. Ook dit is optioneel en afhankelijk van de wensen binnen het team.
Kanban geeft een hoop flexibiliteit in de manier waarop een team het bord opzet en uiteindelijk werkt. De planningsfase is een minimaal onderdeel van deze methode in vergelijking met andere methodes, wat een voordeel zou kunnen zijn voor verschillende teams. De controle op de voortgang is ook gelimiteerd omdat er geen tijdlijnen of roadmaps vergeleken kunnen worden. Zelfs met deze flexibiliteit zou Kanban nog steeds uitstekend kunnen werken voor grote teams.
Als we Kanban direct met Scrum vergelijken, kunnen we zien dat scrum meer structuur geeft. Die structuur ontstaat doordat er vooraf gedefinieerde processen zijn opgesteld die een project zou moeten volgen. De afbeelding hieronder geeft aan hoe een project aan de hand van de Scrum methodologie zou moeten werken.
Source: PMI.org
Iteraties in scrum worden ook wel sprints genoemd en kunnen verschillen in lengte (meestal 1 t/m 4 weken). Elke sprint begint met een sprint planning meeting, waarin het team een consensus bereikt over de scope van de desbetreffende sprint. Gedurende een sprint vinden er dagelijkse meetings plaats, waarin het team haar voortgang, plannen voor die dag en potentiële blockers bespreekt.
Om ervoor te zorgen dat het projectteam problemen in een vroeg stadium identificeert en er ‘continuous improvement’ plaatsvindt, ontmoeten de teamleden elkaar in een ‘retrospective meeting’. Hier kunnen ze de opgeleverde onderdelen inspecteren en aanpassen als dat nodig is.
Het laatste onderdeel van een scrum sprint is de sprint review. Hier wordt er een demo gegeven van het opgeleverde werk met de klant daarbij. Naast de demo wordt er besproken wat er wel en niet gedaan is.
Als je Scrum kiest voor je organisatie, werkt het het beste als je het in zijn originele vorm toepast. Als je zomaar dingen overslaat, kan dat impact hebben op de tijdsplanning, kosten en/of budget op een negatieve manier.
Stel je team mist een ‘retrospective meeting’, dan zal het geen directe impact hebben op je project. Toch wordt het project hier op de lange termijn minder effectief van en kan dit wel degelijk invloed hebben op de kwaliteit van de uiteindelijk opgeleverde producten.
Tegenwoordig zien we een stijgende mate van populariteit wanneer het aankomt op technieken die de combinatie zoeken tussen Kanban en Scrum, zoals bijvoorbeeld Scrumban. Dit laat ook weer zien dat er nog steeds evoluties ontstaan, zoals eerder in dit artikel beschreven.
Feature driven development (FDD) is een op agile gebaseerde aanpak voor project management in software ontwikkeling. Het doel van FDD is, vergelijkbaar met andere methodes, om werkende onderdelen van een product te Ontwikkelen in een bepaald tijdsbestek. De afbeelding hieronder illustreert het process van FDD.
Source: Agilemodeling.com
Het grootste verschil tussen FDD en bijvoorbeeld Scrum is dat de tijd en resources in zijn geheel wordt gefocust op het ontwikkelen van features die direct waardevol zijn voor de klant.
Waterfall methodes worden gebaseerd op fases in het project die elkaar opvolgen. Binnen deze methodes wordt er vaak aan het begin van het project in detail gepland. Deze aanpak kan er echter wel voor zorgen dat dingen die pas laat worden opgemerkt, een significante impact hebben op de kosten van het project. Ook wordt de time-to-market door het gebruik van Waterfall langer doordat de uiteindelijke levering ook pas aan het eind van de ontwikkeling gebeurd.
Daarnaast wordt de ruimte om fases over te slaan nog kleiner, wat ook weer impact heeft op de uiteindelijk kosten van het project.
Source: Manifesto.co.uk
Dit voorbeeld van de Waterfall methode is Prince2®.
De beschreven methodes hebben zeker overeenkomsten, maar tonen tegelijkertijd ook verschillen. Voor project managers in software ontwikkeling is het belangrijk om deze verschillen te kennen en hun keuze per project hierop te baseren.
| Planning | Uitvoering | Monitoren & controleren | Testen | |
| Kanban | Kanban specificeert geen vaste definitie voor planning. Toch mogen teams bepalen of ze tijdsinschattingen doen voor de taken die in de ‘to-do’ sectie van het Kanban bord staan |
Taken worden uitgevoerd aan de hand van het Kanban bord. Iteraties mogen tussentijds worden toegevoegd. |
WIP (work in progress) is een KPI die wordt gebruikt om de hoeveelheid werk dat tegelijk wordt uitgevoerd in de hand te houden. Doorlooptijd wordt gebruikt om in de gaten te houden wat de gemiddelde tijd is om een taak te voltooien. Teams kunnen ook in de gaten houden of de eventuele inschattingen kloppen. |
Testing is een stap in het process en heeft een aparte sectie op het Kanban bord. |
| Scrum | Er wordt voor elke sprint gepland. Het team stelt de scope van de sprint vast aan de hand van de beschikbare tijd. | Het project wordt uitgevoerd in verschillende iteraties die sprints genoemd worden. Sprints duren in de regel 1 tot 4 weken. | KPI’s die gebruikt worden in Scrum zijn ‘Burndown charts’, ‘velocity charts’, of DoD/DoR checklists. | Testen vind plaats in elke sprint. Het doel van een sprint is om een werkend en getest product te ontwikkeling en demonstreren. |
| FDD | De planning focust zich op waardevolle features en het toewijzen van taken binnen deze features. Het team bepaald in welke volgorde features worden ontwikkeld. | Projecten worden uitgevoerd aan de hand van de gewenste features. Normaliter worden er elke twee weken features geleverd. | ‘Parking lot diagram’ wordt gebruikt om de voortgang te rapporteren.Ook kunnen er ‘feature complete graphs’ of ‘cumulative flow diagrams’ gebruikt worden om de voortgang te controleren. | Aan het einde van een model (meerdere features die een onderdeel van de software maken) worden de features getest en wordt de code geïnspecteerd. |
| Waterfall | Er wordt aan het begin van het project in detail gepland voor het geheel. Denk hierbij aan ‘product roadmaps’, mijlpalen, budget planning, etc. | Uitvoering komt na de planning. Geen iteraties. Het hele product wordt gebouwd in deze fase. | Het monitoren vindt plaats op hetzelfde moment als de uitvoering. De projectmanager is verantwoordelijk of het uitgevoerde werk in lijn ligt met de vooropgestelde roadmaps en planningen. | De testfase komt na de ontwikkelingsfase. Bugs en imperfecties worden dus pas laat opgemerkt die invloed hebben op de performance van het product en de kosten van de ontwikkeling. |
Het kiezen van de juiste methodologie is een essentieel onderdeel van project management in software development. De projectmanager moet alle stakeholders uitleggen wat het plan is en zorgen dat ze op een lijn zitten.
Het leveren van software verandert snel. Het gebruik maken van de beste technieken en methodologieën is essentieel, waardoor het gebruik van hybride aanpakken een goede overweging zou kunnen zijn.
Hybride modellen, die gebruik maken van verschillende onderdelen van verschillende methodologieën, worden steeds populairder binnen de software development industrie.
Deze aanpak maakt projectmangers steeds flexibelere en stelt ze in staat om een op maat gemaakte aanpak te definiëren voor elke klant. Dit verkort de time-to-market en levert meer waarde voor de algehele business van de klant.
De eerste interacties met de klant vinden uiteraard voorafgaand aan de daadwerkelijke ontwikkeling plaats. Een eerste interactie is al van een enorm belang als het gaat om de oplevering van een volwaardig software product. Het team ontmoet de klant, debriefs de uitdaging van deze klant en duikt in het domein waarin de klant opereert.
De klant, aan de andere kant, ontmoet het team, leert de werkwijze van het bedrijf kennen en begint de culturele waardes van het bedrijf te begrijpen.
Na deze fases volgen er vaak sessies waarin we in detail ingaan op de wensen van de klanten en mogelijk ook zorgdragen voor tastbare producten als wireframes, mockups, backlogs, etc. Dit kan per klant verschillen en de aanpak wordt dus ook per klant aangepast.
Afhankelijk van het project, verschilt deze fase per klant als het aankomt op de hoeveelheid tijd die hierin gaat zitten. Als de klant het proces hierna wil vervolgen, begint de ontwikkelingsfase.
Kijkend naar verschillende software projecten, leert onze ervaring dat een stereotypisch project verdeeld is in overeenkomstige fases: Initiëren, planning, uitvoering, monitoren & controleren en afronding.
PMBOK® guide noemt deze vijf groepen ‘process groups’ of ‘project life cycles’. Deze processen interacteren met elkaar. Voorbeeld: Monitoren & controleren is aanwezig gedurende de hele ‘project life cycle’. Dit is bijna hetzelfde als je kijkt naar uitvoering en planning, alhoewel deze hun pieken en dalen kennen gedurende het proces.
Source: PMBOK® Guide
De onderstaande afbeelding geeft nog een ander voorbeeld van ‘process groups’ en hun interacties.
Source: PM Knowledge Hub
Zelfs in agile projecten zien we dezelfde fases terugkeren. Er is een moment waarop het traject wordt geïnitieerd en wordt afgerond. Ook moet er gecontroleerd en uitgevoerd worden. Een agile project betekent niet gelijk dat er een gebrek aan planning is. Eigenlijk is planning een kritiek onderdeel van een agile project, alleen gebeurd het in iteraties.
De conclusie is dat fases als planning, uitvoering, controleren en afronding in alle projecten terugkomen (ondanks de verschillen in methodologieen). Zelfs als we terugkijken naar het begin van de twintigste eeuw, toen Henry Gantt de Gantt diagrammen introduceerde, zien we dat het een planningsmethode was.
We denken niet dat dit gaat veranderen in de toekomst toekomst. Het is namelijk moeilijk voor te stellen dat er projecten zijn waar planning en uitvoering niet in terugkomen. Wat wel zou kunnen veranderen is de waarop we deze fases met elkaar laten interacteren of hoe de verschillende fases uitgewerkt zijn.
Een goede projectmanager is verantwoordelijk voor de juiste keuze als het aankomt op projectmanagementmethoden. Om dit juist te doen zouden we aanbevelen om de strategie van de klant te debriefen, een analyse van het domein te maken en te onderzoeken wat het meeste waarde oplevert voor de business van de klant.
De manier waarop de projectmanager jouw software projecten runt, zal een significante impact hebben op het eindresultaat.
Deze blog verscheen voor het eerst op https://dook.pro. Origineel geschreven door Marta Maciaszek, vertaald door Yannick Caron.
-cropped.png)
